memgraph是一个内存图数据库，最近添加了对无法适应内存的数据的支持。这使预算较小的用户仍然可以将大图加载到Memgraph，而无需支付（更多）昂贵的RAM。但是，扩展主要内存图数据库以支持磁盘存储，这一定是一项复杂的工程努力。让我们将这个过程分成部分。
盘中数据库
基于磁盘的数据库很长一段时间以来一直是数据库开发世界中的事实上的标准。他们的巨大优势在于他们能够在磁盘上相对便宜地存储大量数据的能力。但是，由于与低级操作系统的相互作用，该开发可能非常复杂。从磁盘获取数据是每个人都在努力避免的事情，因为它比在主内存中使用它的时间大约要多10倍。 neo4j是图形的一个示例，该图是一个使用磁盘作为其主要存储媒体的磁盘数据库的示例，同时试图将尽可能多的数据缓存到主内存，以便之后可以重复使用。
内存数据库
内存数据库避免通过简单地将其所有数据存储在主内存中，从而避免访问磁盘数据的基本成本。由于不需要缓冲池，因此此类体系结构还大大简化了数据库存储部分的开发。但是，内存数据库的最大问题是数据无法适应随机访问存储器，因为唯一可能的方法是将数据传输到更大的，因此更昂贵的机器。
内存数据库用户依赖于以下事实：耐久性仍然通过耐用性机制（如事务记录和快照）确保，以免发生数据丢失。
大于内存的体系结构
主内存计算
大多数计算仍在主内存范围内时描述了数据库架构，但数据库也提供了在磁盘上存储大量数据的能力，而无需具有交互的计算复杂性带缓冲池。
识别热和冷数据
大于内存的体系结构利用了一个事实，即在访问数据库方面总是有一个热和冷的部分。然后，目标是找到存储的冷数据并将其移至磁盘上，以便交易仍然可以快速访问热数据。冷数据标识可以通过直接跟踪交易访问模式（在线）或通过在线计算进行分析数据来完成。
。超过记忆结构的第二个非常重要的特征是驱逐冷数据的过程。这可以通过两种方式完成：
- DB跟踪内存使用情况，并在达到预定义阈值后立即驱逐数据。
- 只有在需要新数据时才能进行驱逐。
交易管理
不同的系统在交易管理方面的行为也有所不同。如果交易需要当前存储在磁盘上的数据，则可以：
- 中止交易，获取存储在磁盘上的数据并重新启动交易。
- 通过同步获取磁盘的数据来使交易失速。
交易必须适合记忆
问题是，当交易数据无法适应随机访问存储器时会发生什么？在MEMGRAPH中，我们决定从所有交易数据都必须适合内存的方法开始。这意味着不能在大型数据集上执行某些分析查询，但这是我们在第一次迭代中愿意接受的权衡。
大于内存数据库的好处
memgraph使用RocksDB作为key-value store，以扩展内存数据库的功能。不要详细介绍RockSDB的细节，但请简短地提及它是基于一个称为Log-Structured Merge-Tree（LSMT）的数据结构（而不是B-Trees，通常是数据库中的默认选项），这些选项保存在上磁盘和由于设计的带有比B-Trees小得多的write amplification。
MEMGRAPH中内存版本使用Delta Storage来支持多次并发控制（MVCC）。但是，对于大于内存的存储，我们决定使用乐观的并发控制协议（OCC），因为我们认为冲突很少会发生，并且我们可以使用RocksDB’s transactions而无需处理像一样的自定义复杂性层增量存储。
我们以每个交易都有自己的私人工作空间的方式实施了OCC，因此在提交时间会检测到潜在的冲突。在开始添加基于磁盘的数据存储之前，我们的主要要求之一不是破坏基于内存的主要存储的性能。尽管我们都知道没有zero-cost abstraction这样的东西，但我们设法停留在原始版本的10％之内。我们决定将snapshot isolation用作适当的并发隔离级别，因为我们认为这可能是大多数Memgraph用户的默认选项。
大于内存数据库的缺点
一如既往，并非所有内容都是阳光和花朵，尤其是在将如此重要的功能引入现有数据库时，因此仍有改进。首先，单一交易必须适合内存的要求使得不可能使用大型分析查询。
它还使我们的LOAD CSV命令用于导入CSV文件，因为该命令被执行为单个事务。尽管RockSDB确实很不错，但确实非常适合我们的代码库，并且被证明在其缓存机制上非常有效，但保持外部库总是很难。
回想起来
尽管有重要的工程努力，但比起内存的体系结构是Memgraph用户的超级宝贵资产，因为它允许他们在不牺牲内存计算的性能的情况下便宜地存储大量数据。我们正在积极研究新的存储模式引入的问题，因此请随时使用ask，open an issue或pull a request。我们将很乐意提供帮助。直到下一次ð««