我最近一直在探索 MMDB 系统，但我找不到太多关于内存数据库应该如何扩展的信息。我非常基本的假设是主内存数据库受到数据库节点上可用内存以及该内存的操作系统管理的约束。那么如何将内存系统大小扩展到可用的主内存之外呢？我认为答案类似于分布式系统，但我还不清楚它是如何工作的。当然，我也有可能完全误解了 mmdb 的想法，我遗漏了一些明显的东西。
关于这个问题的一些背景知识：我正在编写一些跨平台的移动应用程序（尽管我的背景主要涉及 mysql 和 mongodb），并且我不喜欢用于 android 和 ios 的 sqlite 等原生数据库解决方案。所以我想我会用javascript编写自己的解决方案（site和github）（我正在研究cordova/phonegap）。我意识到我可以把它做成一个 nodejs 模块并将它用作 web 应用程序的数据库（我正在创建一个由它提供支持的博客作为实验，它运行得很好），但当然我现在正在考虑制作它是一个单独的层，我开始考虑内存大小的明显限制，因此我提出了问题。
内存数据库在规模上的扩展方式与磁盘（又称持久）数据库相同：要么向其投入更多存储（在本例中为内存），要么将其分布在集群的多个节点上。相对于单个系统上的内存数据库，后一种选择增加了复杂性（包括 DBMS 和您对它的管理）。考虑 vanilla MySQL 和 MySQL Cluster 之间的区别。而且，当 DBMS 必须执行节点间操作（例如，分发数据或从多个节点提取数据以满足查询）时，您将需要一个非常快速的网络。
在这方面，内存数据库没有什么特别之处。当您知道存储是内存时，数据库引擎中有一些特殊的优化。但它并没有改变数据库系统的基本原理。
您不想做的是创建一个大于物理内存的内存数据库。您将强制操作系统将内存数据库页面换入/换出交换空间，并且性能会很糟糕。在这种情况下，您最好使用传统的 DBMS 并为其提供尽可能多的缓存，因为您有可用的内存。DBMS 将比操作系统更智能地使用缓存，而不是交换空间。
当前的生产就绪内存数据库主要集中在纵向扩展而不是横向扩展。到目前为止，他们要么设法将主存层集成到他们的核心现有架构中（IBM 通过 Blu 加速），要么几乎从头开始重建数据库以利用主存作为主存储层（SAP HANA） ，并且在这两种情况下，他们声名鹊起的是 DRAM 与磁盘相比提供的明显加速。
然而，目前很少有数据库拥有一个完整的产品，可以在多个节点上横向扩展内存中的性能优势。大多数内存数据库都需要应用程序来管理跨节点的数据/对象分布（例如：SAP HANA）。
目前，Oracle 的 DBIM 和 MemSQL 是一些可扩展的分布式选项，它们通过在集群中集体利用内存资源（Oracle 的 RAC）来实现分布式内存数据库/层。MemSQL 可以部署在商用计算节点集群上，它声称可以通过利用包括内存在内的聚合资源进行扩展。Oracle RAC 是一种共享缓存架构，它克服了传统无共享和共享磁盘方法的限制，提供高度可扩展和可用的数据库解决方案，包括内存中的优势。