While much attention, technology and consulting fees are dedicated to getting data out of database management systems (DBMSs) rapidly, with faster queries, much less interest is paid to optimizing the process of putting the data in.
This stems at least partly from the fact that most enterprise data is not loaded all at once. Instead, it is built up gradually through a company's everyday processes such as sales, shipping and manufacturing. The data is already in the database when someone needs it. But queries against this data are often intended to support tasks with exacting deadlines — hence the emphasis on optimizing query performance.
But for HPC, optimizing the process of filling up a database — also called database provisioning or “data ingest” — takes on greater importance, due to the fact that many HPC analytical tasks such as data mining and scientific research involve assembling very large databases (VLDBs) using previously collected data external to the database management system. This aggregation could require a database to ingest terabytes before queries can be performed to support a time-sensitive analytical goal, such as predicting a competitor's next move or discovering a new blockbuster drug.
The VLDB ingest process can stretch into days, which is a highly unwelcome delay for a competitive project. And the wait is exacerbated by a particular frustration of VLDB loading: as more data is added, the ingest rate slows down markedly, with the record-per-second insertion rate waning by more than half. This article explores the technological reasons for this dwindling performance, and a possible solution in the use of database technology that stores and manages records entirely in memory.
Certain techniques are available to accelerate ingest with traditional on-disk enterprise database systems. For example, when using the INSERT statement (part of the industry standard SQL database language) to load data row-by-row from a flat file into relational database tables, it can help to strip all indexes (data structures commonly used for quick access to records) from the tables, because the database system can create new indexes more quickly after the insert process is complete, than it can update indexes as records are inserted. This approach can be combined with special bulk load features of many database systems that insert multiple records simultaneously, for greater efficiency.
But a progressively dwindling ingest rate remains a problem, due to facts of enterprise database system structure. Traditional database systems are premised on storing data on permanent media. Because commonly-used hard disks operate mechanically, with spinning platters and heads that slew across the disk surface, such disks are thousands of times slower than processes working in solid state hardware, such as writing to a region of memory. In recognition of this performance burden, database systems provide a cache to hold frequently-used records in memory.
To speed data ingest, records are written to the cache. But eventually, memory buffers fill up, and the system writes the data to the file system (logical I/O). Each logical I/O requires some time interval (usually measured in microseconds). Eventually, the file system buffers also fill up, necessitating writing of the data to the hard disk (at which point logical I/O implicitly becomes physical I/O). Physical I/O is usually measured in milliseconds, therefore its performance burden is several orders of magnitude greater than logical I/O. Physical I/O may also be imposed by the DBMS, for instance to guarantee transactional integrity.
Mounting I/O requirements — both logical and physical — impair performance more and more as a database grows larger, for several reasons. First, as database size increases, the tree indexes used to organize data grow deeper, and the average number of steps into the tree, to reach the storage location, expands. Each step imposes a logical disk I/O. Assuming cache size stays the same, then the percent of the of the database that is cached is smaller; therefore the likelihood that a logical I/O is actually physical I/O is greater.
Second, assuming that the cache size stays the same, the percent of the database that is cached is smaller. Therefore, it is likely that any logical disk I/O — not only from tree navigation, but also the abundant I/O from writing pages of data files, checkpointing, log files, and other operations — is actually physical disk I/O.
Third, not all instances of physical I/O are equal. As the database gets larger, it consumes more physical space on the disk platter, and the average time to move the head from position to position is greater. The greater the distance traversed by the head, the longer each physical I/O's time interval. Therefore each individual physical I/O can represent a greater performance burden as data ingest proceeds.
The VLDB data ingest slowdown is endemic to traditional disk-based database architecture. As it turns out, a way to avoid this problem with provisioning — and to obtain significantly faster queries as well — is to completely eliminate physical I/O and logical I/O, along with reliance on a file system and hard disk, from the database system.
A relatively new database technology, the in-memory database system (IMDS), has been examined largely from the standpoint of extracting data. IMDSs store records entirely in memory — they never go to disk. Because an in-memory database is already in memory, a cache would be redundant. Accordingly, the DBMS cache logic is eliminated, as is all interaction with the file system and its separate cache, and with the physical media. A major consequence of this simplification is a dramatic reduction in the number of movements (copies) of the data as it makes its way from the application to the DBMS storage.
Querying is greatly accelerated via elimination of I/O, caching and related overhead. This accomplishment alone would merit consideration of in-memory database technology in high performance computing applications (for an idea of IMDS query performance, see the benchmark results presented below). But IMDS proponents have also suggested that by jettisoning both logical and physical I/O, their systems should be able to ingest very large amounts of data without experiencing the performance falloff inherent in disk-based systems.
Until recently, this advantage existed only in theory. IMDS performance remained uncharted in the terabyte-plus size range, due partly to the technology's relative newness and partly to its origins in real-time embedded systems, which did not require management of very large databases.
But as in-memory databases catch HPC system architects' attention, and roll out in VLDB systems such as stock exchanges' automated trading applications, engineers are pushing the technology beyond previously known boundaries.
McObject helped move this software category forward in late 2006 when it tested its eXtremeDB-64 in-memory database beyond the one terabyte size boundary. The benchmark took place on a 64-bit Linux-based 160-core SGI Altix 4700 server housed at the Louisiana Immersive Technology Enterprise, a supercomputing research center housed at the Research Park of the University of Louisiana at Lafayette.
Testing ingest performance was an important goal — engineers sought to nail down whether the VLDB ingest rate would remain stable, without the performance slowdown seen in on-disk databases. (No IMDS vendor had, until then, published a benchmark involving a terabyte or more of data.)
For the benchmark, engineers created a simple database structure consisting of two tables: a PERSONS table and an ORDER table. These tables represent the two sides of any generic transaction in which there are two instances of a 'person' (one for each side of the transaction) and one instance of an 'order' that represents the transaction between the two entities. To populate the database, engineers created an array of 30,000 random strings and selected random elements from the array to populate the NAME and ADDRESS columns. Unique values for PERSON_ID and ORDER_ID were generated sequentially.
Engineers then created 3 billion PERSONS records (rows) and 12.54 billion ORDERS records (rows), resulting in a database size of 1.17 terabytes, and performed queries of varying degrees of complexity against this data store.
Benchmark results illustrate IMDSs' querying speed. For a simple SELECT statement, eXtremeDB processed 87.78 million query transactions per second using its native application programming interface (API) and 28.14 million queries per second using a SQL ODBC API. In a more complex JOIN operation, a result of 11.13 million queries per second was achieved with the native API, and 4.36 million queries per second using SQL ODBC. Comparing performance between different applications in different operating environments is notoriously tricky. But to put these results in perspective, consider that the “standard currency” of such comparisons is transactions per minute. From these results, it is understandable why IMDS technology could appeal to the designer of corporate data mining or pharmaceuticals research applications seeking to rapidly sift great volumes of data.
The benchmark also documented the predicted, but until now unproven, data ingest advantage: based on the results, IMDSs appear to avoid the performance plunge imposed by on-disk databases as they grow larger. Total provisioning time for the 1.17 terabyte, 15.54 billion row eXtremeDB-64 database was just over 33 hours. The per-row insert time for the first quartile of data was 6.9 microseconds, while the rate for the last quartile was a very respectable 8.3 microseconds. Ingest performance between first and last quartile decreased by just 20 percent — much less than the precipitous performance drop-off seen in the later stages of populating an on-disk very large database.
It is important not to confuse the time required to ingest a data set, with the time needed to back up the data once it has been loaded, or to restore it after potential failure. As part of this benchmark test, engineers backed up the fully provisioned in-memory database in 4.3 hours, and restored it in 4.76 hours. So, while initial ingest took 33 hours, the database could be saved and reloaded for subsequent use in a fraction of that time. (And, once reloaded, it can be extended with new data.) Backing up and restoring the provisioned database is a simple matter of streaming the in-memory image to persistent storage; there is no need to allocate pages, assign records to pages, maintain indexes, etc., so back up and restore is largely a function of the speed of the persistent media.
Backup and restore capabilities are especially important when working with in-memory database systems because these functions are the primary means to achieve data persistence. While IMDSs offer persistence mechanisms such as transaction logging, the types of applications served by IMDSs for data analysis have data persistence needs that differ from most mainstream enterprise systems. Data mining, modeling and other analytics applications exist to process data in its transient state, rather than provide long-term storage.
Querying will likely remain the “superstar” function of in-memory databases and the most talked about performance advantage. But backup and restore are important, and complement IMDSs' highly efficient ingest capability. They ensure data is available when needed to support time-sensitive, data-intensive tasks.
—–
About the Author
Steven Graves co-founded McObject (www.mcobject.com) in 2001. As the company's president and CEO, he has helped the company attain its goal of providing embedded database technology that makes embedded systems smarter, more reliable and more cost-effective to develop and maintain. Prior to McObject, Mr. Graves was president and chairman of Centura Solutions Corporation, and vice president of Worldwide Consulting for Centura Software Corporation; he also served as president and chief operating officer of Raima Corporation. Mr. Graves is a member of the advisory board for the University of Washington's certificate program in Embedded and Real Time Systems Programming.