In-Memory Database System Benchmarks & White Papers
“It is a capital mistake to theorize before one has data.” – Sir Arthur Conan Doyle, Author
These in-memory database system benchmarks and white papers review the distinction between an in-memory database vs. just running a disk database in-memory, and the performance results that a true IMDS can offer. Our goal is replacing IMDS myths with facts, and we encourage you to contact us if you have any questions after reviewing the following materials.
Benchmarking In-Memory & On-Disk Databases With Hard-Disk, SSD and Memory-Tier NAND Flash
In-memory database systems (IMDSs) accelerate data management. To provide data durability, IMDSs offer transaction logging, in which changes to the database are recorded on persistent media. But critics object that logging re-introduces the storage-related latency of on-disk DBMSs. Will an IMDS with transaction logging still outperform a traditional DBMS? Will type of storage—hard disk drive vs. solid state drive vs. state-of-the-art memory-tier products—affect the results? McObject’s original research answers these and related questions.
In-Memory Database Systems: Myths and Facts
In the past decade, software vendors have emerged to offer in-memory database system (IMDSs), described as accelerating data management by holding all records in main memory. But is this new? For years, database management systems have employed caching. Several vendors offer something called “memory tables.” RAM-disks and — more recently — Flash-based solid state drives (SSDs) are available for use with databases. Do IMDSs really add anything unique? In fact, the distinction between these technologies and true in-memory database systems is significant, and can be critical to project success. This paper explains the key differences, replacing IMDS myths with facts.
Will the Real IMDS Please Stand Up
In-memory database systems (IMDSs) have changed the software landscape, enabling “smarter” real-time applications and sparking mergers and acquisitions involving the largest technology companies. But IMDSs’ popularity has sparked a flurry of products falsely claiming to be in-memory database systems. Understanding the distinction is critical to determining the performance, cost and ultimately the success or failure of a solution. This white paper examines specific products, seeking to answer the question, “is it really an in-memory database system?”
Terabyte-Plus In-Memory Database System (IMDS) Benchmark
In-memory database systems (IMDSs) hold out the promise of breakthrough performance for time-sensitive, data-intensive tasks. Yet IMDSs’ compatibility with very large databases (VLDBs) has been largely uncharted. This benchmark analysis fills the information gap and pushes the boundaries of IMDS size and performance. Using McObject’s 64-bit eXtremeDB-64, the application creates a 1.17 Terabyte, 15.54 billion row database on a 160-core Linux-based SGI® Altix® 4700 server. It measures time required for database provisioning, backup and restore. In SELECT, JOIN and SUBQUERY tests, benchmark results range as high as 87.78 million query transactions per second. The report also examines efficiency in utilizing all of the test bed system’s 160 processors. The full report includes complete database schema, relevant application source code and additional analysis.
In-Memory vs. RAM-Disk Databases: A Linux-based Benchmark
The in-memory database system (IMDS), claims breakthrough performance and availability via memory-only processing. But doesn’t database caching, or using a RAM-disk, achieve the same result with a traditional (disk-based) database? This benchmark tests eXtremeDB against a widely used embedded database, in both disk-based and RAM-disk modes. Deployment on RAM-disk boosts the traditional database by as much as 74 percent, but it still lags the IMDS substantially. Read about the architectural reasons for this disparity.
The Role of In-Memory Database Systems for Routing Table Management in IP Routers
Core Internet bandwidth grows at triple the rate of CPU power, but high-value applications depend on managing much more data traffic at the network’s edge. This requires rapid evolution of routing table management (RTM) software within IP routers. This paper examines using in-memory database systems (IMDS) to add RTM development flexibility, data integrity and fault tolerance. It provides performance examples on Linux and Windows 2000. This embedded database solution adds to vendors’ ability to produce new generations of routers faster and at less cost, improving their competitive position.
Did you find the IMDS benchmarks and white papers interesting?
We are a dedicated group of specialists and our only focus is database management systems. We invite you to review additional articles and research, and learn more about eXtremeDB.
If you have reviewed our in-memory database system benchmarks and white papers, and still have questions, our HTML documentation includes an extensive online library to introduce eXtremeDB. It will walk you through the installation process, and the use of key features.
Online DBMS documentation menu items include:
- The eXtremeDB Product Family
- eXtremeDB Supported Platforms
- What’s New in This Release
- Getting Started
- eXtremeDB Fundamental Concepts
- eXtremeDB User’s Guides
- Programming with eXtremeDB
- SQL Samples
- Using the eXtremeDB Feed Handler
Includes modules modules for Refinitiv (formerly Thomson Reuters) Elektron Message API (EMA) and VELA SMDS frameworks, as well as a test module provided for demonstration of the Feed Handler Module API.