Webinar Reveals DBMSs' 'Memory Tables' As Slower, Less Flexible Than In-Memory Database Systems (IMDSs)
Issaquah, Washington February 15, 2011 Technology News(PRLEAP.COM) Some traditional database management systems (DBMSs) provide a feature called "memory tables," through which certain tables can be designated for all-in-memory handling. That sounds similar to a different technology, the in-memory database system (IMDS), which claims to accelerate data storage, sorting and retrieval by keeping all data in memory.
Can memory tables deliver the same benefits as in-memory database systems? Not if the goal is to obtain the best performance, smallest footprint, and maximum flexibility, as illustrated in McObject's upcoming February 17 Webinar, "What Makes a Database System 'In-Memory'?"
As explained in McObject's free Webinar, memory tables don't change the underlying assumptions of database system design—and the optimization goals of a traditional DBMS are diametrically opposed to those of an IMDS. With an on-disk database, the primary burden on performance is file I/O. Thus its design seeks to reduce I/O, often by trading off memory consumption and CPU cycles to do so. This includes using extra memory for a cache, and CPU cycles to maintain the cache.
In addition, much redundant data is stored in the indexes that are used in searching for data in on-disk DBMSs' tables. This is useful in avoiding I/O because if searched-for data resides in the index, there is no need to retrieve it from the file. To prevent I/O, on-disk databases can justify the extra storage space to hold redundant data in indexes. Such tradeoffs are "baked into" on-disk DBMSs. The redundant data in indexes is present – and contributes to a large footprint – whether or not a table is "in memory."
What's more, a closer look at specific vendor implementations of memory tables reveals this feature imposes more restrictions than the conventional file tables used in the same DBMS.
For example, in MySQL, memory tables cannot contain BLOB or TEXT columns, and maximum table size is 4 GB. In addition, space that is freed up by deleting rows in a MySQL memory table can only be reused for new rows of that same table. In contrast, when something is deleted in an IMDS, that free space goes back into the general database memory pool and can be reused for any need. Memory tables are subject to additional limitations, compared to traditional "on-disk" tables, when they are used with MySQL's replication feature.
Memory tables in the SQLite database also impose limitations. For example, these memory tables cannot be shared, which relegates their usefulness to nothing more than user-defined temporary tables. In addition, memory table contents cannot be saved to persistent storage with the SQLite product (though you can find one or more 3rd party patches that claim to provide this ability).
Register now and attend "What Makes a Database System 'In-Memory'?" on February 17, 2011. Learn what's truly unique about in-memory database system technology, and how to harness this innovation to develop faster, more reliable, smaller-footprint real-time applications.
Additional IMDS misconceptions that will be debunked in the Webinar include:
Myth 1: On-Disks DBMSs Can Use Caching To Equal In-Memory Database Systems' Performance
Myth 2: An IMDS Is Essentially a "Traditional" Database That Is Deployed In Memory, Such As On a RAM-Disk
Myth 3: By Using A Solid State Drive (SSD) For Storage, an On-Disk Database System Offers Performance Equal to an In-Memory Database System
Founded by embedded database and real-time systems experts, McObject offers proven data management technology that makes applications and devices smarter, more reliable and more cost-effective to develop and maintain. McObject counts among its customers industry leaders such BAE Systems, Siemens, Phillips, EADS, JVC, Tyco Thermal Controls, F5 Networks, CA, Motorola and Boeing. McObject, based in Issaquah, WA, is committed to providing innovative technology and first-rate services to customers and partners. The company can be reached at +1-425-888-8505, or visit www.mcobject.com.
McObject and eXtremeDB are registered trademarks of McObject LLC. All other company or product names mentioned herein are trademarks or registered trademarks of their respective owners.