Guidelines for Selecting In-Memory Databases and Corresponding Hardware
This article compares ten typical in‑memory databases, discusses their technical characteristics such as performance, ACID support and SQL compatibility, and provides comprehensive technical and non‑technical criteria as well as hardware recommendations for choosing the most suitable in‑memory database solution.
Based on the DB‑Engines Ranking, ten representative in‑memory databases are compared, highlighting that Redis and Memcached are the most popular key‑value stores, SQLite leads among relational in‑memory databases, and SAP HANA is the most active commercial product.
The article notes historical entries like Oracle TimesTen (1995) and the rising popularity of Apache Ignite (2014), and mentions that most relational in‑memory databases claim ACID support with performance trade‑offs.
Memory Database Selection Advice
Selection should start from business requirements, translating data volume, concurrency, read/write patterns, consistency, latency, operational complexity, and continuity into technical requirements such as consistency, fault tolerance, scalability, and security.
1. Technical Factors
Key technical criteria are performance, consistency requirements, and SQL compatibility:
High‑performance, low‑latency workloads (e.g., real‑time game leaderboards, live streaming fan counts) favor in‑memory databases.
Strong consistency and ACID‑level transactions may necessitate traditional relational databases like MySQL, though this can impact performance.
SQL compatibility is important for fixed schemas with complex joins; otherwise, key‑value stores are suitable for flexible, high‑scalability scenarios.
Additional considerations include data size, cost, scalability, and maintainability.
2. Non‑Technical Factors
Other dimensions include ecosystem maturity (tools, community, commercial support), architecture fit (compatibility with application stack), and team familiarity (learning curve, operational tooling).
Hardware Selection Recommendations
For in‑memory databases, prioritize large memory capacities (e.g., 256 GB or 512 GB). If persistence is required (e.g., Redis RDB+AOF), use SSD or PCI‑e storage for adequate IOPS. Persistent Memory can be considered when budget allows and latency requirements are moderate.
Network: 1 GbE suffices for most cases; 10 GbE or higher is recommended for extreme performance needs.
CPU: High‑single‑core performance x86 CPUs are generally preferred; ARM CPUs are cheaper but support fewer in‑memory database products.
The article also references a newly released "In‑Memory Database Whitepaper" by the China Academy of Information and Communications Technology, which provides further technical and management guidance and outlines future trends.
Architects' Tech Alliance
Sharing project experiences, insights into cutting-edge architectures, focusing on cloud computing, microservices, big data, hyper-convergence, storage, data protection, artificial intelligence, industry practices and solutions.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.