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