What is Column Oriented Database?

A column-oriented DBMS is a database management system (DBMS) that stores its content by column rather than by row. This has advantages for data warehouses and library catalogues where aggregates are computed over large numbers of similar data items.

In practice, row-oriented architectures are well-suited for OLTP-like workloads which are more heavily loaded with interactive transactions. Column stores are well-suited for OLAP-like workloads (e.g., data warehouses) which typically involve a smaller number of highly complex queries over all data (possibly terabytes).

Up to now, column oriented DBMS were a niche segment in the OLAP world. Although used by system vendors in the OLAP benchmarks, such as TPC-H to demonstrate system capabilities for record breaking, mainstream DMBS such as Microsoft SQL Server 2008 and Oracle 11 still used row oriented architecture.

Commercial columnar DBMS such as HP-Vertica, VectorWise, Sybase IQ and more were used mainly for high analysis environments, usually aside with the main organization’s DBMS. However, the growth of data and the demand for advanced analytics, data warehousing and business intelligence along with the rise of Big Data in cloud environments, have moved more and more organizations to adopt column oriented architecture.

These market demands have caused Microsoft to integrated “Project Apollo” to the new SQL Server 2012 (currently available as RC0 version). Although not a column oriented DBMS (as the above examples), the new SQL server 2012 offers “Column Store Indexes“.

A columnstore index stores each column in a separate set of disk pages, rather than storing multiple rows per page as data traditionally has been stored. In case of the row store indexes multiple pages will contain multiple rows of the columns spanning across multiple pages. In case of column store indexes multiple pages will contain multiple single columns. This will lead only the columns needed to solve a query will be fetched from disk. Additionally there is good chance that there will be redundant data in a single column which will further help to compress the data.

Flash Based Storage Opportunities

So, what are the opportunities for flash base storage with column oriented architecture? For this, let’s review the main features and see how they suit the flash based architecture:

Read Only –OLAP processing is a read only application by its nature. This is ideal for flash storage, both as a primary storage (operates better in reads, no endurance problems) and as cache tier (the cache applications such as Fusion-IO’s IO Turbine, EMC Lightning and OCZ’s VXL operate in a write through mode).

Compressed Data – the columnar nature of the records storage enable high compression of the information. Thus, the database can fit in the more expensive flash storage, both as primary storage or as a cache tier.

Random Workload – as compressed and non-sequenced, the column storage of the information dictates more random and smaller type of read workload. As indexes are spread over the DB and requires less read (does not require massive pages read), the result workload is more random, less sequential and with smaller commands – ideal for flash storage.

Higher Entropy – for optimization, data is further stored with the indexes, causing query process to derive its data from indexes’ search. As a result, the DB information is segmented with high access pick areas and massive low access areas. This histogram is ideal for flash cache application, caching the hot zones of the database (the areas that stores the column indexes).

Analysis

To demonstrate the capabilities of column oriented databases, we take the TPC-H benchmark, an OLAP benchmark with 22 queries simulating a suite of business oriented ad-hoc queries and concurrent data modifications. The benchmark specifies several database sizes, from 100G to 30T. Our examples relate to the standard 100G benchmark.

SQL Server 2012 (RC0)

As mentioned, the new 2012 SQL Server is not a true column oriented database but supports limited column indexes (one per table). Furthermore, after inserting the column indexes, data cannot be inserted to the database. However, even this limited addition has a huge impact on the performance.

As can be seen, moving from SQL Server 2008 row indexing to SQL Server 2012 with columnstore indexes reduces dramatically the query process time. The total query time reduces from 8047 to 2138, almost 4 times faster. Using flash storage (OCZ Z Driver R4) reduces the overall query time to 618 seconds – 4x improvement.

To see how it is done, we should look at the workload analysis of the server. As can be seen in the histogram (processing Query 1):

The database is divided into two major areas – the data area that stores the records and the index area that stores the columnstore indexes (and some attached data). The size of the data area is about 100G (as regular database) and the index area is about 25G. Obviously, the temperature (i.e., access frequency of the space) of the index area is much higher (10x) than the data area. Hence, flash caching software should mainly warm (pre-fetch) the index area to achieve more than 90% hit ratio. Using OCZ’s VXL cacheing software in VMware environment, the total query time reduces from 2138 to 828 – 4x improvement.

HP-Vertica

In this example, a true columnar database is tested. HP-Vertica is high performance and high compressed analytical database. Here, no indexes need to be defined and data is inserted in a columnar way. As can be seen from the histogram:

• Database is highly compressed – about 25G comparing to the 160G of SQL server (with indexes).
• Indexes area is 10x hotter than data area. Also, index area is much more narrow than 2012.

Again, flash cache applications can take advantage of this structure and gain high hit ratio. Furthermore, with the high compression (only 25G for 100G database), the entire database can reside in flash and achieve high performance.

Summery

Clearly, column oriented databases will enter more and more to data centers and cloud environments, both via mainstream DBMS (i.e., Microsoft) and smaller vendors (e.g., HP-Vertica). The growing demand for analytical services and big data will also push flash based storage either as primary tier or cache to provide the high performance required.

Due to the need to efficiently utilize WAN resources, remote replication works by collecting data changes and transferring only those collected changes across the WAN.  As this data needs to be collected and sent without affecting volume performance, Flash becomes an efficient medium for temporally storing the data changes.

Now consider the following:

1)      WAN replication requires you to store the latest data changes.

2)      Caching for acceleration requires you to store the “hottest” data with the highest chance of being read soon.

When you think of it, it is not surprising that there is a very large overlap between the “hottest” data you should be saving for caching, and the “latest changes” data you should be saving for WAN replication.

Therefore you can nearly double the utilization of your Flash resources by sharing the stored data for the dual purposes of both volume replication (protection) and volume acceleration (performance).

HDD advocates would balk at such a suggestion, immediately asking: doesn’t using the same data for dual purposes impact performance?  The short answer is yes if the collected data is on an HDD, but a definite NO when the collected data is on Flash.

HDD’s need to move a mechanical head each time someone is reading from a different location on the data set.  If you just read cached data form area A on the data store, you slowed down the access to area B containing the data you want to replicate.  A large performance overhead is added just from the need to move the mechanical head from reading one location to reading another.

Flash storage has no mechanical heads to move.  It therefore has a great advantage when collecting random reads from multiple locations on the data set.  Reading from location A has no impact on the speed to read from location B.  And both reads will be much faster than the reads from an HDD.

So when using Flash as the medium to store your data for both volume acceleration and volume replication you will experience no performance hit. On the contrary, you are gaining both volume acceleration and volume protection at the same time.   In effect not only is the Flash utilization doubled, but the user receive integrated data protection for their accelerated volumes.

However, there is one common issue to all the above configurations – they are all interfacing to hardware and software in the same way HDDs do. In other words, we are still in the backward compatible phase of the storage evolution. The mechanical form factor of the SSD disk is the same as the HDD, enabling it to be paced in the same chassis. The software interface of the flash storage is still SCSI block commands.

Is this necessary? The usage of the HDD form factor to an electronic device that uses only 1% of the required space and the usage of “sectors” oriented commands to reference page based architectures is obviously not the best utilization of the flash storage. Even if we agree to the assumption that the data center will always be dominated by HDD storage (because of its low price), there is still a need for some adaptation to the flash storage to get the best out of it.

Some elements of adaptation have already begun. We see a shift from the SSD form factor to a PCI-e based storage. The success of Fusion-IO triggered a standardization effort toward more efficient mechanical and electrical connectivity. In the software integration, SCSI commands such as “trim” were presented for more efficient use of the flash storage.

Is this enough? While the hardware aspect is moving forward to a more dedicated environment, the software environment is still “general purpose” in its nature. Meaning it does not have any “flash awareness” to use flash’s potential. So, what should be changed in order to fully utilize the flash storage?

Software Layers

In general, there are 3 software layers on top of storage media: the hardware adaptation layer (SCSI and driver), the File System and the application. Although more layers and sub-layers may apply, these are the general layers in most environments. Although some environments lack some of the layers or have different architecture, for example a caching device does not have file system or some application bypass the file system (e.g., Oracle), this is the most common topology in data center environment.

Hardware Adaptation Layer

The hardware adaptation layer reads and writes data to/from the storage device. It includes a SCSI layer (in most common OSes) and a driver. By connecting flash storage to such environments we have a chain of SCSI-driver-FTL (flash translation layer) and flash. In other words, we doubled our adaptation effort.

Currently, flash storage has its adaptation logic in the device (both SSD and PCI-e devices). This allows them to be fully integrated to a servers’ environment. But is this the best place for this logic? Some elements in the flash control should stay close to the flash – Error Correction and Signal Processing are better there. But the mapping from logical space to physical space, wear leveling and garbage collection can be done better in the server. Furthermore, the resources required for those operations (memory, CPU) are much more prevalent in the server.

Thus, a two legs adaptation layer – one for HDD and one for flash looks as a better architecture for the server or appliance environment.

File System

The file system layer in the OS exposes a file level to the user space. Such general FS as NTFS, ett4 in common OS or proprietary FS such as VMFS provide the functionality. Again, the FS doesn’t have a media aware optimization to fully utilize the flash storage. Such optimization is the new SCSI trim command, introduced to release logical space when the FS deletes a file. File deletion is done via modifying a table in the FS metadata. However, the data of the file still remain in the media. The trim commands informs the media that the data can be released (and its blocks can be used). This is example of a flash unique requirement (there is no need for trim in HDD storage).

Another optimization is to align the table (format with alignment) of the FS. Thus, targeting to the internal flash pages construction.

But is this enough? Flash storage is better in small and random access workload. The file system has metadata and data to manage. While data is optimized to be placed in single chunk per file (see ext4), metadata is by nature small and random oriented. If the FS is aware of its media – combination of HDD and flash, it can place metadata and other random nature information on the flash and files’ information on the HDD. This hybrid architecture is suited to the flash-HDD capacity ratio with small metadata and large data.

Modern FS such as BTRFS and distributed FS (GPFS and more) implement further functionality such as snapshots, versioning and replications. On those, metadata maintenance has much higher workload and requirements. Such file systems can even better utilize hybrid architectures.

Application

Most applications use the FS abstraction toward the storage media. Some applications (e.g., Oracle) bypass this layer to optimize the media load, managing their own abstraction.

An example of an application level optimization is the usage of Write Ahead Log in database applications or any application that uses a database (e.g., Microsoft Exchange). The data is inserted first to a logger in a sequential way, thus enabling fast insertion of information. The data is then placed in the background to the real database (random operation). The application notes also advise (or even mandates) the user to place the log and database in different physical disks, so that the rotating of the log will not interfere with database operations.

This is a very efficient optimization for HDD storage, but is it enough for flash storage? The log doubles the write operations (bad for flash). Instead, we can just write the information to the flash and just change the mapping. Also, the B-tree construction of the database should be adapted to the page construction of the flash. And what to put in the flash? If the database is relatively small, the flash is an ideal storage, however in large database we need to implement hybrid storage. Then the question arise – what to place in the flash and what in the HDD.

So, what is the best integration?

So what are we going to see in the future? Currently we are in the beginning of the flash adaptation – the phase of backward compatibility. In the coming future we will see the environments, hardware and software adapt themselves toward the unique characteristics of the flash storage to use its full potential. This architecture will probably be based on two legs – HDD storage (still for the mass data) and flash storage (mostly for metadata and high performance – small capacity). The flash adaptation will reside either directly on the servers’ platform or in network based server appliances, enabling efficient logic (due to large resources) and full path (application – FS- adaptation – driver) optimization.

Like all good products the V-Switch XL did not appear out of thin air, it is the culmination    of the work of many talented individuals that worked together to turn an insight and a vision into a real physical solution.   As I once heard heard Amdoc’s CEO, Eli Gelman, say: Look behind any “overnight success” and you will see lots of long nights filled with product development work.

But  what makes me even more proud of our team and happy to announce this product is that the V-Switch XL is the result of the two most important ingredients that are at the heart of any successful solution:  Real world requirements from real world customers and a technological breakthrough that truly address them.

Microsoft’s Jetstress is an excellent free tool from Microsoft for testing your planned Microsoft Exchanger Server 2010 storage configurations.  However, like many great tools, Jetstress excels at more than the task it was originally designed for.

Taking a Closer Look

To closely simulate Exchange, Jetstress uses the same storage engine as Exchange: ESE. It then generates the types of operations Exchange server would have performed on the database. These operations are simply inserts (40%), reads (35%), updates (5%) and deletes (20%); where the numbers in parenthesis represent the default operations mix.  This default mix of operations is designed to emulate common e-mail usage scenarios.  I.e., e-mails being created (or arriving), being read, moved around, and deleted.

Readers with a sharp eye will notice that the default usage scenario has twice the number of inserts than deletes…remember this….we will come back to this fact later.

Extending the Usage Parameters

As Jetstress performs these simulations so well, it was quickly realized that the same tool could also be used for other purposes.  One such use is testing the affect of changes to the environment in which Exchange runs.  Good examples are testing how Exchange would react to such things as networking configuration changes, storage tiers, caching algorithms, server configuration changes, and so forth.

An Example Test…and a Warning….

Think about the following test.

I have 3 network configurations that I am considering using in my Exchange environment; let’s call them configurations A, B, and C.

I want to choose which configuration will best fit my environment.  What would be the best way to go about this?

The first thing that comes to mind is the most obvious; I will perform the following actions:

1) Run Jetstress with network configuration A and record the results.

2) Run Jetstress with network configuration B and record the results.

3) Run Jetstress with network configuration C and record the results.

4) Compare the three results I recorded and choose the configuration that brought me the highest result.

Is this the best methodology to follow? It seems so obvious that surely the answer should be yes.  However, as it turns out, the correct answer is: NO.  This method has a likely result of getting you to choose a wrong configuration.

How can this be?  Well, look for that old notebook from college with your notes from STATISTIC 101.  On one of the first pages you’ll find that when comparing results from different tests, the tests need to be independent.  That is, the results of any one test should not be affected by having previously run the other tests.

As it turns out consecutive Jetstress tests are not independent.

Another Look

Remember the insert/delete ratio?  (I asked you to remember, didn’t I?) Recall that the amount of inserts was twice the amount of deletes.  These access inserts must be going somewhere…

Well, there is no magic here: the database is growing (along with its edb file).  This means that the database you had at the beginning of the test is not the identical to the database at the end of the test.  It has grown larger.

More Changes between Consecutive Jetstress Runs

But this is not the only change.  To truly emulate the behavior of Exchange 2010, Jetress also performs Background Database Maintenance (BDM) on the database file during a test run.  The BDM process essentially scans the database using very large read commands.  As the name implies it is a maintenance task and is intended to run throughout the day on the entire database.

Now, the regular Jetstress test run time is 2 hours.  So, for larger databases the scan will not complete doing one run.  Jetstress will scan the first part of the file in the first test run and leave a marker noting where it stopped scanning.  On the second run, Jetstress (emulating Exchange) will not start the scan from the beginning of the file, rather it will continue from where it previously stopped.

All this is very good for emulating real Exchange Server 2010 environments.  However, it results in a side affect that the storage patterns generated in consecutive Jetstress runs can be very different even if the runtime parameters are identical.

Be Careful

Special caution should be taken particularly when testing in environments which use caching algorithms.   Good caching algorithms will automatically detect application hot zones and store them in fast storage (e.g. flash).  However the hot zones in two consecutives runs of Jetstress will be very different due the affects of both the BDM scan and the growing database structure described above.  Therefore, some algorithms that will work perfectly well during one particular Jetstress run will degrade over time due to the dynamic nature of the storage IO hot zone patterns.

Jetstress actually correctly emulates Exchange Server, which in itself has dynamic moving hot zones.  So that the same algorithms, whose performance degrades over time in Jetstress runs, will degrade over time in real Exchange environments.

In contrast, the caching algorithms that will give you the best consistent performance enhancements are the ones that dynamically adapt to the changes in application storage hot zones.  A good caching algorithm that dynamically fits its behavior to the changing edb file patterns will produce consistently superior performance in both Jetstress tests and production Exchange environments.

Next Steps

So does this mean that Jetstress should not be used for performance testing with caching?  Quite the opposite, is should be used more.  One test is simply not enough.   A true test of performance is one that not only gives you high performance on the first run, but continues to give high performance over multiple runs.

Don’t run Jetstress just once, run it multiple times for each environment you are checking.  Alternatively when evaluating the performance report someone else is providing make sure it provides information on consistent performance over time!

Is this a real revolution in the storage industry or just a temporary trend? Will we see flash based storage in the data center in the coming years and in what construction? For this we need to analyze the benefits and weaknesses of flash based storage:

Performance

Most people outside the IT world would say that “SSD is much faster than regular disk (HDD)”. However, in the storage world we know that there is no such metric as “fast”. There are 3 orthogonal metrics to measure performance: bandwidth, IO per second (IOps) and latency. Each one is relevant to different types of applications. For example, video stream application would require large bandwidth while the IOps and latency are irrelevant. OLTP database applications require high IOps and low latency while bandwidth is irrelevant.

So how does flash based storage perform in each of those metrics comparing to HDD? The main advantage of flash over hard drive is the lack of moving parts or mechanical parts. Each command in the hard drive applies seek (the rotor moves to the required offset) and transfer of data. In flash based storage on the other hand, only data transfer phase apply. So what is the improvement? If the seek element is dominant (in case of small data transfer and random pattern), then the improvement is big. However, if the data transfer is dominant (large transfer and sequential pattern), then the improvement is minor or even not exists (in case of fast disks or RAID).

Returning to the metrics above, we can see that the bandwidth of flash based storage is about the same as HDD (as it being measured with large commands). The IO per second and latency however have improvement potential in a workload profiled with small command and random pattern.

Size

Unlike the mechanical construction of a hard drive, the flash based storage is pure silicon device. Although SSD disks are sometimes packaged for compatibility as hard drives, the storage element itself is a small fraction of a hard drive. Obviously, this feature is critical to portable devices, hence we will see flash based storage in smart phones and tablets. Thin laptops can also benefit from this capability. But this can provide cost benefit in space in highly expensive rent areas.

Power

As an electrical component without moving parts, the flash based storage is a pure electronic device. While the hard drive requires power to operate an electric motor, the flash based storage only requires standard operation power of a memory device. Furthermore, the size factor difference applies further power for cooling to the hard driver. Traditionally, this feature is related to portable devices with limited battery power supply. However, the power consumption of data centers becomes major part of the expenses. Furthermore, while the electrical consumption of data centers in the US reaches to the level of entire country consumptions, power regulations may force power saving and power cut.

Endurance

Due to the internal mechanism of the flash cell, the number of erase and programming cycles is limited. While in SLC (single bit per cell) the endurance level is 100K, the endurance level in MLC (multiple bits per cell) reduces to several thousands for x2 MLC (two bits per cell) and even hundreds for x3 MLC (3 bits per cell). Although signal processing algorithms raise the endurance level of MLC (also called eMLC), this is a limit (even psychological) to IT managers.

Cost

Last, but with most importance is the cost difference. Here is still the main barrier for the flash based storage. While 1TB of HDD cost less than 100$, 1TB of flash based storage would vary from 10K$ of SLC flash to 2K$ of MLC x3, almost 100 times more expensive! Furthermore, while the HDD drives’ cost per volume keeps dropping, the flash memory may have reached its technological limit. Current layout of 24 nm may be the barrier in the next years.

So where and how will flash based storage reside in the data center?

Eventually, when it comes to the IT manager, it all ends in ROI considerations. As long as the cost difference is about 100 times, full deployment of flash based storage in the data center is not realistic. Although flash based appliances exists (Violin, Virident, XtremIO), their high cost locates them into dedicated niches such as financial trading. Furthermore, the performance benefit is limited for only parts of the applications in the data center.

If full deployment is not seen in the near future, where is the suited place for flash based storage? Their performance capabilities can be used for two functions – caching and tiering.

Flash Tier

Flash tier is a storage appliance with some portion of the overall storage is flash based. An external storage places the data with the largest acceleration potential (e.g., hot zones, database hot area) in the flash tier dynamically. Such approach exists in EMC’s FAST, where the flash tier is part of a multi tier construction of the storage.

Another tier approach places dedicated critical data in the flash. For example, file system or NAS indexes (e.g., Alacritech) or any other metadata. Metadata is by nature profiled as small granularity and random access, best fitted for flash.

By any architecture, flash based tier should use high level flash (i.e., SLC or at least eMLC). The production data resides on the flash and should be protected from endurance for several years’ retention. This constraint limits the flash usage to small portion of the storage (about 1%).

Cache

Flash Caching used the flash storage for data caching between the server and the storage. There are two types of such cache – a write through (read) cache that always coherent with the back end storage and write back cache, where data in the back end is not updated. A read cache is safer to use and ensures full coherency at the back end storage for any functionality (e.g., replication, backup, snapshots, etc.).

A write back cache (write cache) must ensure the validity of the data in it, thus must use high level cache (SLC). Furthermore, due to the high requirements of data center reliability, it should provide cluster architecture with data synchronization. Read cache on the other hand, can relax the reliability requirements since data always can be retrieved from the back end storage. Hence, a low level flash (MLC) can be used.

As a results, a write cache approaches to the high end of the data centers and high performance computing, while read cache is more common. Furthermore, due to the flash requirements, a read cache can apply cheaper flash (MLC) and obtain larger volumes up to 10% from the back end storage.

So where is the cache located between the servers and the storage?

There are several places in the data path between the servers in the front end and storage in the back end. Server cache is an intuitive and simple location for the cache. In server cache (as FusionIO) is close to the server’s backbone and provide low latency caching. However, this approach is good for a single server while a cluster of servers (e.g., VMware environment) will require per server cache and will not be coherent for tasks’ transfer (e.g., vMotion).

Caching in the storage appliance is available in compliance with tier approach. This can be a simple approach for a storage construction, but may apply complexity in scaling up.

Third approach places the cache half way between the servers and the storage – in the switch. Such connectivity (e.g., Grid Iron, Dataram) is usually accomplished with virtualization and network management capabilities. Its central location enables manageability with caching and hence easy to scale up both directions – servers and storage.

So where will we see flash based storage in the data center? We will probably see it as tier in storage appliance or some for of caching, most likely a read cache in some form. The applications it will accelerate are forms of databases, VDI, Exchange and other intensive read applications. The new challenges now facing storage designers include the decisions what to put in the flash tier/cache to best utilize this new storage media.

It goes more or less like this:

When lifting off the Shuttle is always aided by two side boosters attached to the main fuel tank. When compared to other space exploration rockets these two boosters always seem very narrow (and were the cause of major issues). Incredibly NASA confirmed there was an engineering constraint on the design that had nothing to do with space flight. You see the boosters were manufactured in Utah and had to be transported by rail to Florida. This meant they had to pass through the railway tunnels on the way. Now the railway tunnels were designed by engineers in the 19th century that did not specify the width requirement based on space vehicle booster rockets. No, they designed train tunnels to be large enough to fit…. trains.

Here is where it gets interesting. The width of trains were set by British engineers based on common widths of already existing tracks in coal mines.  These tracks, in turn, were designed for the steam powered trollies that transported coal out of the mines. The width of the coal mine tracks were based on the width of horse drawn tram tracks designed to ease the burden of horses as they transport passengers on otherwise muddy English roads. These were based on the standardized widths of wagons.  As history buffs will tell us, wagons were standardized in an imperial decree by Julius Caesars.  The imperial decree was passed to allow carts throughout the vast Roman Empire to pass unobstructed on busy Roman streets.

In essences Julius Caesars first century BC decree dictated the width of the space shuttle booster rockets….

Lesson Learned?

There is much debate on the web on the accuracy of the details of this ancdote, but it seems that the spirit of it lives on in some modern day storage products.

Modern servers have two major methods for connecting add-ons that communicate with the CPU. One, PCIe slots, was designed for very fast high bandwidth internal connections.  The designers envisioned performance extension cards that would potentially need high power and multiple access lines but would not require frequent physical accessed or replacement.

Storage interface connectors, such as SAS and SATA, are the other connectivity option.  They were designed with failure prone mechanical disks in mind.  The designers put great emphasis on the capability to easily access and replace storage disks, but the bandwidth and power were set at just the right amount to support the limited capabilities of physical disks.

When flash storage entered the ring it didn’t neatly fit into either connectivity model.  On the one hand it was storage.   It needed an easy way of access for maintenance and upgrades, and needed to sit at the locations people in IT expected to find storage.   So some thought packaging flash storage to look like a disk with a SATA or SAS connection would be the best choice.  However flash storage’s key advantage is in the capability to generate massive data bandwidth in parallel from multiple NAND chips.  This requires a very fast connection as well as higher power consumption at peak, both of which are lacking in SAS and SATA connectors.   In fact packaging flash chips into an SSD (Solid State Drive) from factor with SAS or SATA connectivity is akin to fitting your space age rocket into a 19^th century train tunnel.  It will work…but you will lose a lot of power in the process.   You will be paying for very high performance chips, but connecting those chips to your network through a much slower interface designed to support an old mechanical system.

To fully benefit from your flash storage, a much better approach is to find a system that can satisfy both the high bandwidth (PCIe) connectivity requirement, but at the same time also places your flash in an easily accessible front loadable module.  If you are looking for such a solution, you just found it.

Contrary to what you may first think, the e-mails that are most time wasting are not the ones you get from your boss, colleagues, family or friends.   No, the e-mails ordering us to waste endless time are not sent by humans at all. The e-mails along with the marching orders they provide are automatically generated by computers we ironically call “servers”.

Case in Point

Case in point:  the dreaded “your mailbox is almost full” message. Your e-mail server, be it MS Exchange or some other e-mail server is sending you a clear warning…”I am on to you, I am watching you, I am going to make your life miserable until you completely submit to my will.” Much like an army boot camp drill sergeant, the server actually means it.  The server will now work as hard as it can to make your life as miserable as it can for the duration you are under its command.

A widely known secret is that everybody does the same thing that you did when you first received the warning e-mail: they ignored it.  Using the “if I don’t open the e-mail it will go away” tactic you look the other way.  The bravest of brave even try to delete the vile e-mail.  However, this tactic never really succeeds with Sergeant “Server”.  Open your e-mail client the next morning and the “your mail box is almost full” message magically reappears.  The warnings get stronger and stronger, and before you know it Sgt. Server is standing over your shoulder with a swagger stick and blocking you from sending an important e-mail.

Panic Time

At this point Sgt. Server will start molding a corporate soldier out of you.  Like any drill sergeant it will task you to repeatedly do an annoying mundane, useless, time wasting task.  No, it can’t make you clean the lavatories with a toothbrush or dig trenches and refill them.  It can make you do the next best thing: sort and clean the thousands of unread e-mails in your mailbox from eons past.

Yes, you must now go through all those long forgotten e-mails, sorting out the emails of type “I know I must save this – it’s very important” from the e-mails of type “I wonder why I didn’t delete this months ago” e-mails.  More difficult is deciding whether the e-mails of type “I was planning to read this when I had the time” should be deleted to leave room for the “I remember I kept this for some reason but for the life of me I can’t remember why” e-mails.  Yes your day’s work is cut out for you.  Prepare for a long night.  Until you finish, the Sgt. won’t let you send any new e-mails.  If you don’t finish by dawn he will completely isolate you and stop passing you e-mails from others.

Why is This Happening to Me?

Like many Drill Sergeants, the Server is mindlessly policing a corporate policy whose authors have long forgotten the reason it was put in place in the first place.  Long ago (literally in the last century, the 20^th century that is) disk space was very expensive.  This held even truer for the type of enterprise storage used by servers.  Storage was expensive.  Saving storage, the axiom held, was more economically efficient than saving employees’ precious time.

In this century however, as the idiom goes, the entire public digital content of the library of congress can be saved in about twenty five 3 TB disk (more or less) costing around $150 each.

Consider this example: 100 employees, each receiving 100 e-mails a day, with an average size of about 10KB per e-mail, produce all together 100MB of e-mail storage a day.  This may sound like a large number but is actually just 0.003% of a 3TB disk.  This means that even with zero e-mail deletions, it would take the 100 employees more than 25 years to fill one $150 3TB SATA disk.  Invest $300 and you are good for more than 50 years…  Yes, 100 employees can share two disks (a once in a lifetime investment of only $3 each) and every one of them will retire long before the disks fill up.  Did “Mr. Your-mailbox-is-almost-full” mention you can buy him one soda from the vending machine…and never see him again for the rest of your life?

Ah, But There is a Catch

OK, you think, now that we know we have been duped for years, I can gather my 100 comrades/colleagues, march on to the Tahrir Square in front of the CIO’s office and cry FREEDOM!  Put our e-mail server on these large SATA disks and let my people go!

Not so fast…In their offices overlooking the square, you will find the CIO and his elite force of storage administrators armed to their teeth.  They are not holding guns. No, they wield a much more powerful weapon.  They possess an age old knowledge traditionally revealed only to the initiated: the secrets of storage networking.

“Sure” they will tell you with a cunning smile, “go ahead, put your massive SATA disks behind our E-Mail servers, and let’s see if you can live with the results in the morning. You ignorant fools, there was something you failed to take into account.  Yes SATA disks are large and inexpensive, but we can’t use them. They are simply too slow.  A hundred people can share a disk in terms of content, but let’s see all of them try to access that content all at the same time.  Tomorrow at 9 am you will all come in and attempt to open you e-mail inbox.  You will curse the moment you traded our small fast disks for these large slow ones. When the performance plague will hit you you’ll come back on your knees begging us to bring back the fast storage.  Go back to your cubicles.  Get back to work on sorting and deleting old e-mails.”

So there you have it, an impasse.  The promise of essentially endless low cost storage confronted by the threat of a horrible network bottleneck.   Can we hope for deliverance?

Stay tuned for part II.

Please stay tuned…