ACM通信
实践
二义性消除数据库
信贷:帕特里克·乔治
在出现错误(数据消失)或真正正确(客户太多)之前，不需要很好地理解数据存储的主题。因为数据库可以被视为带有API的黑盒子，它们的内部工作方式常常被忽略。它们通常被视为神奇的东西，只在提供数据时接受数据，在要求时提供数据。由于这两种操作是该技术的唯一被理解的活动，所以在比较不同的技术时，它们通常是呈现的唯一特征。
中通常提供基准操作每秒，但操作到底是什么呢?在数据库领域内，这可能意味着许多事情。该操作是一个事务吗?它是数据的索引吗?从索引中检索?它是将数据存储到硬盘等耐用介质中，还是用激光将数据传送到半人马座阿尔法星?
正是这种模糊性导致了软件行业的混乱。误解数据库系统的特性和保证，最多只能导致用户因运行缓慢或不可用而感到恐慌。在最坏的情况下，它可能会导致财政损失，甚至由于数据丢失而坐牢。
术语的范围数据库是巨大的。从技术上讲，任何存储数据供以后检索的东西都是数据库。即使按照这个宽泛的定义，也有大多数数据库所共有的功能。本文在较高的级别上列举了这些特性。目的是为读者提供一个工具集，他们可以用它来评估数据库的相对优点。由于这里无法详细介绍这些主题，因此还包括了额外阅读的参考资料。这些主题可能是以后文章的主题。
这种特性驱动的方法应该允许读者评估他们自己的需求，并通过将相似的特性配对来比较技术。从这个角度来看，比较基准只有在执行相同工作并提供相同保证的数据库上才有效。
在深入研究数据库的特性之前，让我们讨论一下为什么不采用所有的特性。简短的回答是，每个特性通常都有性能成本，如果不是复杂性成本的话。
数据库执行的大多数功能，以及实现它们的算法，都是为了解决硬盘这一性能瓶颈而构建的。如果你要求你的数据(和元数据)是持久的，那么你必须付出这样或那样的代价。
硬盘
典型服务器(Ivy Bridge Architecture)的串行ATA (SATA)总线理论最大带宽为750MB / s。这似乎很高，但与PCI 3.0总线相比，它的最大速度是每秒40GB，或者与内存总线相比，它的每通道速度是每秒14.9GB(至少有4个通道)。SATA总线具有现代服务器(不包括外设)中最低带宽的数据路径。5
除了带宽瓶颈之外，还需要考虑延迟问题。在数据中心中遇到的最高延迟操作是查找硬盘上的随机位置。目前，一个7200RPM的磁盘寻道时间约为4毫秒。这意味着它每秒可以在磁盘上查找和读取大约250次新位置。如果一个服务器应用程序依赖于在每个请求时都在磁盘上查找一些东西，那么它将被限制在每个磁盘每秒250个请求。4
一旦找到了位置，在同一位置上的连续追加或读取操作的成本就会低得多。这被称为顺序读或写。自磁碟发明以来，关于数据存储和检索的算法就针对这一事实进行了优化。通常，人们将文件操作称为随机操作或顺序操作，认为后者的成本远低于前者。
固态驱动器(ssd)为磁盘带来了巨大的延迟和吞吐量改进。SSD盘的寻道速度大约是硬盘的60倍。然而，ssd也带来了自己的挑战。例如，SSD中的存储单元有固定的生命周期，也就是说，它们在失败之前只能处理一定数量的写入。由于这个原因，它们有专门的固件在磁盘上传播写操作、垃圾收集和执行其他簿记操作。因此，它们具有较少的可预测的性能特征(尽管它们可预测的速度比硬盘快)。
页面缓存
由于硬盘驱动器的高延迟和低吞吐量，几乎在每个操作系统中都发现了页面缓存或缓冲区缓存的优化。顾名思义，页面缓存旨在通过将文件的内容存储在由操作系统内核映射到磁盘的内存页面中，透明地优化磁盘访问的成本。其理念是，磁盘或文件的相同局部将在短时间内被多次读写。对于数据库通常是这样。
当发生读操作时，如果页面缓存的内容与磁盘同步，它将从内存返回该内容。相反，写操作将修改缓存的内容，但不一定写入硬盘本身。这是为了消除尽可能多的磁盘访问。
假设写入一条数据记录需要5毫秒，并且必须将20条不同的记录写入磁盘，那么在页面缓存中执行这些操作然后刷新到磁盘只需要一次磁盘访问，而不是20次。考虑到访问机器上的主内存比在磁盘上查找数据要快大约40000倍，因此性能节省很快就会增加。
每个操作系统在将更改刷新到磁盘上方面都有不同的模型，但几乎所有操作系统都与调度器一起查找适当的点，以静默地将内存中的数据同步到磁盘上。文件和页面也可以手动刷新到磁盘。当您需要确保数据更改是永久性的时，这非常有用。8
请注意，页面缓存是优化的重要来源，但它也可能是危险的来源。如果对页缓存的写入没有刷新到磁盘，并且发生电源、磁盘或内核故障，则将丢失数据。在分析专门利用页面缓存进行持久性操作的数据库解决方案时，请注意这一点。
数据库特性
数据库有几十种分类。数以百计的商业或免费可用的数据库系统中的每一个都可能属于这些类别中的几个。本文跳过了分类，而是提供了一个框架，通过该框架可以根据每个数据库的特性对其进行评估。
本文探讨的五类特性是:数据模型、API、事务、持久性和索引。
数据模型。基本上有三类数据模型:关系模型、键值模型和层次模型。大多数数据库系统明显属于一个阵营，但可能提供另外两个阵营的功能。
关系模型。关系数据库在近代史上很受欢迎。在整个20世纪80年代和90年代，数据库的主要要求是保存一种稀有而昂贵的资源:硬盘。这就是关系数据库发挥作用的地方。它们允许数据库设计人员通过一种称为规范化的过程最小化数据库中的数据重复。7
然而，最近磁盘存储的成本已经大幅下降，3.使关系数据库的经济因素不那么重要。尽管如此，由于它们的灵活性和易于理解的模型，它们今天仍然被广泛使用。此外，sql是关系数据库的通用语言，在程序员中很常见。
关系数据库的工作原理是允许创建任意表，这些表将数据组织成列的集合。表的每一行包含每列的一个字段。习惯做法是将数据组织到逻辑上独立的表中，然后将这些表彼此关联起来。这使得一个大整体的组成部分可以被独立地修改。
关系数据库的一个主要缺点是它们的存储模型不能很好地存储或检索大量数据。对关系表的查询操作通常需要访问多个索引，并连接和排序来自多个表的结果向量。这些复杂的方案对于1GB的数据工作得很好，但是对于1TB的数据就不那么好了。
关系数据库所做的基本权衡是节省磁盘空间，以换取更大的CPU和磁盘负载。
这种模式的好处有很多:它使用的磁盘空间最少;它是一种易于理解的模型和查询语言;它可以支持各种各样的用例;它具有模式强制的数据一致性。
这种模式的缺点是它通常是最慢的;它的模式意味着迭代更改需要更高的程序员开销;而且它有很多调谐旋钮，非常复杂。
键-值模型。键值存储从持久存储开始就已经存在了。当不需要关系系统的复杂性和开销时，就使用它们。由于它们的简单性、高效的存储模型和较低的运行时开销，它们通常可以比关系数据库每秒多管理数量级的操作。最近，它们被用作事件日志收集器。此外，由于它们的简单性，它们经常作为内部数据存储被嵌入到应用程序中。
键值存储的操作方式是将键(通常是一组字节)与值(通常是另一组字节)关联起来。另外，由于记录的大小通常是相同的，并且具有复制的数据，因此在存储到磁盘上之前可以对它们进行大量压缩。这可以大大减少跨SATA总线所需的带宽，从而获得性能上的提升。
通过巧妙地创建行和列，甚至模式应用程序，一些键值存储可以提供关系特性的子集，但它们提供的数据建模特性通常比关系系统少得多。如果需要多个索引，则使用附加的键值查找来模拟它们。
这是一个快速、相当灵活且容易理解的存储模型;但是，它通常没有模式支持，因此没有一致性检查，而且它的应用程序逻辑更复杂。
层次模型。分层(或文档数据)模型在最近比较流行。它的主要优点是人体工程学。按照存储在应用程序对象中的方式从数据库中存储和检索数据。
层次模型倾向于将所有相关数据存储在单个记录中，该记录描述了多个键和值，其中值可以是键和值的附加关联。
在一般情况下，真实世界对象的所有数据都可以在单个记录中找到。这意味着它必然比关系模型使用更多的存储空间，因为它是复制数据而不是引用数据。它还简化了查询模型，因为只需要从单个表检索单个记录。
由于所存储的数据本质上是异构的，压缩只能提供有限的增益，因此通常不使用压缩。
分层数据库通常提供一些关系特性，如外部引用和多个索引。许多这样的数据库不提供任何模式支持，因为数据结构是任意的。
这是最灵活的模式。它的任意索引支持对数据的轻松访问，并且在应用程序数据结构和磁盘数据结构之间具有最高的保真度。
由于硬盘驱动器的高延迟和低吞吐量，几乎在每个操作系统中都发现了页面缓存或缓冲区缓存的优化。
缺点是，这种模式的磁盘空间使用率最高;如果没有模式，数据布局是任意的，因此没有模式或一致性检查。
API
简而言之，应用程序编程接口(API)就是您和您的程序与数据库交互的方式。这个界面可以划分为许多不同的维度，但让我们先从两个维度开始:
过程中vs.过程外。如果数据库运行在与客户机应用程序相同的进程中(至少部分地)，那么通常会有一个函数调用库，直接调用数据库引擎中的方法。这种紧密耦合导致了尽可能低的延迟和尽可能高的带宽(内存)。但是，它降低了灵活性，因为它意味着一次只能有一个客户机应用程序访问数据。这也带来了额外的风险:如果客户端应用程序崩溃，数据库也会崩溃，因为它们共享相同的进程。
如果数据库运行在单独的进程中，则通常使用TCP/IP协议。许多rdbms(关系数据库管理系统)以及最近的其他类型的数据库都支持ODBC(开放数据库连接)或JDBC (Java数据库连接)协议。这简化了客户端应用程序的创建，因为可以利用这些协议的库非常多。网络协议确实极大地提高了数据库的灵活性，但与直接内存访问相比，TCP会带来延迟和带宽损失。
SQL和不是。SQL是一种声明性语言，最初设计它是为了简化关系数据的存储和检索。它的使用非常普遍，因此许多开发人员都能流利地使用这种语言。这有助于采用数据库。
大多数NoSQL数据库宣扬的最大“创新”只是通过删除事务和关系表来实现更快的操作。许多这样的数据库开始支持SQL作为API语言，即使它们不使用它的关系特性。查询、过滤和聚合等SQL特性非常有用。因此，有人说NoSQL数据库应该改名为NoACID(原子性、一致性、隔离性和持久性)，因为它们缺乏事务支持。在2015年，许多相同的数据库现在都有了事务支持。现在，NoSQL可能更准确地称为NoRelational，但NoSQL听起来更好，也足够接近。
SQL的一个挑战是它必须被数据库引擎解析和编译才能被使用。这会增加运行时开销。大多数数据库引擎或客户端api通过预编译或在第一次运行时将基于sql的函数调用编译为准备好的语句来解决这个问题。然后保存编译后的版本，用于将来的调用。
SQL不能有效地描述所有的数据关系。例如，在SQL中很难描述层次关系。此外，由于SQL的声明性，迭代或其他命令式操作在核心SQL规范中无法描述。该规范已经扩展到包括递归，以处理迭代和层次关系。此外，供应商也提供了自己的非标准扩展。然而，对这些扩展的支持并不普遍，对如何利用它们的理解也不普遍。9
在许多情况下，数据库的特性非常稀疏，缺乏索引或聚合等特性，根本没有理由支持复杂的SQL解析和执行引擎。键值存储常常属于这一类。
交易
根据定义，数据库事务是一个以一致和可靠的方式处理的工作单元。数据库事务最常见的方法是ACID。许多数据库系统声称支持事务或“轻量级”事务，但它们可能只提供ACID中方便和有效支持的特性。例如，许多分布式数据库提供了事务的概念，但没有隔离步骤。这意味着数据正在被修改，其他事务在修改数据时看到该数据。如果这种行为是预期的，您可以绕过它。否则，结果可能是灾难性的。
让我们简单地看看ACID保证，然后再看看数据库为提供这些保证可能会做些什么。
原子性。在一个事务中，可以有多个操作。原子性保证了所有操作一起成功或一起失败。操作失败的原因有很多:
- 约束。违反了逻辑约束，例如外键或惟一性。
- 并发性。另一个进程完成了您的进程将要修改的字段的修改，如果继续这样做将违反其事务的原子性保证。
- 失败。硬件或软件堆栈中的某些东西失败，导致其中一个操作失败。
在一个繁忙的并发数据库中，故障可能经常发生。如果没有原子性，数据会很快进入不一致的状态。因此，原子性是ACID的下一个属性的关键组成部分。
一致性。这个保证意味着数据库的状态对事务之前、期间和之后的所有用户都是有效的。数据库可以对数据本身做出一定的保证。串行性等基本保证意味着所有操作都将按照应用它们的顺序进行处理。这听起来可能很容易，但是当许多具有多个线程的应用程序同时在一个系统上操作时，必须采取(昂贵的)步骤来确保这是可能的。
关系数据库通常提供更大的一致性保证集，包括外键约束、依赖类型上的级联操作或可能作为该操作一部分执行的触发器。就性能而言，这意味着所有这些操作都可能在行和/或页被锁定以进行编辑时运行，因此在此期间没有其他客户机能够使用系统的这些部分。它还明显影响请求的往返时间。
隔离。事务不会立即发生。它们是按步骤发生的，并且，就像原子性的例子一样，如果一个局外人看到完成步骤的部分集合，结果将从“有趣的”到“严重错误的”不等。孤立是保证这种情况不会发生的保证。它对其他人隐藏所有操作，直到事务成功完成。
耐久性。持久性确实是一个重要的特性，它承诺当事务完成时，操作的结果将成功地持久化到指定的存储介质上(通常是硬盘)。
交易的实现。ACID事务共有六个步骤:
- 将传入的请求记录到事务日志(也称为预写日志)中的持久存储中。这将在系统故障的情况下保护数据。在最坏的情况下，该事务将能够在启动时从日志中重新启动。
- 以不干扰现有操作的方式将新值序列化到索引和表数据结构中。
- 获取所有需要修改的单元格上的写锁。根据相关操作和数据库的不同，这可能意味着锁定整个表、行或内存页。
- 将新的值移到适当的位置。
- 将所有更改刷新到磁盘。
- 在事务日志中记录已完成的事务。
事务具有性能影响。由于所有磁盘操作都被批处理为一组操作，因此它们可能会导致执行操作的速度加快。另外，如果是ACID，事务是并发控制的一种形式。由于它们位于数据本身，它们通常比应用程序本身中定制的并发解决方案更有效。
缺点是，事务并不适合高度并发的应用程序。具有高度争议的操作将产生过多的重放和中止(这将导致更多的重放)。它们也很复杂，提供事务所需的所有移动部分增加了更大、更不容易维护的代码库。
持久性模型
如前所述，事务甚至索引在数据库中都是完全可选的。然而，坚持是他们的强项存在的理由。
与磁盘相关的性能成本(以及与页面缓存相关的数据丢失风险)意味着在数据存储和检索方式方面的权衡。许多高度专门化的数据结构都是为不同的访问模型量身定制的，通常情况下，如果一个数据结构在一个领域表现出色，那么它在另一个领域的表现就会很差。以顺序方式插入大量传入事件的方案可能不会为随机更新提供良好的性能(甚至可能根本不提供这种功能)。
在所有存储和检索数据的潜在方案中，最广泛的四种是:基于行、列、仅内存和分布式。
行基础。最常见的存储方案是将数据逐行存储在本地硬盘上的树或其他紧凑数据结构中。尽管确切的数据结构和访问模型各不相同，但这种机制是相当通用的。
在基于行的存储中，行本身在内存中是连续的。这通常意味着存储模型本身经过了优化，可以一次获取整行数据的各个区域。
存储行有两种常用的数据结构。B+树为随机检索而优化，log-结构化合并(LSM)树为大容量顺序写入而优化。
B+树。B+树是一种B-树样式的索引数据结构，您已经猜到了，它优化了最小化磁盘寻道。它是数据库中用于表存储的最常用存储机制之一。它也是几乎所有现代文件系统所选择的数据结构。B+树通常是一个具有高分支因子的搜索树，每个节点都是一个连续的内存块，包含多个键。这是专门设计来最大限度地提高从磁盘检索数据时可以比较多个键的概率的。1
图1展示了如何在内存中布局基于b树的行存储。每个叶节点有四个键的空间，减少了每行需要执行的磁盘查找量。树中的键指向磁盘或内存中存储行(按列顺序排列)的区域。还要注意，在每个节点上，并不是每个单元格都需要填充;它们可以为未来的价值保留自由。
日志结构化。LSM树是一种较新的磁盘存储结构，针对大量的顺序写操作进行了优化。它的设计目的是处理大量的流事件，例如实时接收web服务器访问日志，以便以后进行分析。
尽管LSM树起源于日志风格的事件收集，但它也开始在关系数据库中使用。然而，它有一个主要的权衡，即您不能将LSM数据结构作为标准数据路径的一部分进行删除或更新。这样的事件被记录为日志中的新记录。在读取LSM树时，通常从后面开始读取数据的最新版本。
必须定期地对因后续删除或更新而过时的记录进行垃圾回收。这通常被称为压缩过程。一些LSM系统在运行时在独立的线程中压缩;其他系统试图在适当的地方逐步压缩。6
柱状。基于列的数据存储优化为检索同一列数据的区域，而不是检索数据行的区域。因此，连续的列被连续地存储在内存中。
由于列中的所有数据类型都必须相同，因此压缩可以产生巨大的积极影响，从而增加可以通过总线存储和检索的数据量。另外，将数据分解为多个文件，每列一个文件，可以利用同时跨多个磁盘的并行读写。
基于列的数据库的缺点是它们通常不灵活。一个简单的插入或更新需要大量的协调和计算。由于数据通常被紧密地打包(和压缩)在列中，因此不容易找到和更新适当的数据。
真实世界对象的所有数据通常都在单个记录中找到。这意味着它必然比关系模型使用更多的存储空间，因为它是复制数据而不是引用数据。
为了帮助保持列文件之间的“行”同步，很多时候列字段还将包含主键(或行ID，如果没有键)的副本。这有助于将数据重新组合成行，但降低了存储和检索的效率。2
图2显示柱状数据文件。每个数据类型都在其自己的连续区域中布局，其偏移量在主列中表示。列文件通常是批量构建和重新构建的，以服务于海量数据集的数据仓库应用程序。
只有记忆。在许多情况下，持久性根本不是必要条件。这对于诸如缓存这样的系统是很常见的，这些系统经常更新，并且只针对访问速度进行优化。由于缓存中的数据通常是短寿命的，因此可能不需要持久化到磁盘。这就是内存数据库发挥作用的地方。在不需要存储和从磁盘检索的情况下，可以利用更多种类的复杂树。
分布。分布式数据库的主题非常广泛，需要单独的系列文章进行适当的介绍。然而，在持久性上下文中，有一个相关的事实:在数据中心内跨网络复制数据集比将数据集存储到本地磁盘要快得多。
在建立速度和持久性之间的平衡时，分布式数据库可以提供一个有趣的选择。只将数据存储在本地机器的内存中可能风险太大，因为如果机器崩溃，数据将全部丢失。如果跨多台机器复制数据，那么丢失全部数据的风险就会降低。由应用程序开发人员来确定机器故障的概率和可接受的风险级别。
页面缓存问题
当选择存储到磁盘时，可能会涉及到页面缓存。直接访问磁盘会非常麻烦，并且会妨碍系统上运行的任何其他应用程序的性能，因为您将不必要地独占磁盘。
何时从页面缓存刷新到磁盘的问题可能是设计数据库时最重要的问题，因为它确切地告诉您数据丢失的风险有多大。
许多数据库声称每秒要进行数千次操作。这些数据库通常完全操作于页缓存中内存映射页上的数据结构。这就是他们如何通过处理内存中的数据结构来实现速度和吞吐量。它们通过将所有刷新和同步操作延迟到操作系统本身来实现这一点。这意味着应该由内核决定何时将缓存中的数据持久化到磁盘。它可能不仅要考虑数据库，还要考虑系统上运行的所有应用程序。这意味着数据的实际持久性是留给操作系统的，而操作系统不了解应用程序领域或数据可靠性需求。
如果持久性不是一个强烈的要求，那么延迟到操作系统可能是好的。但是，在大多数情况下，重要的是要清楚关于页面缓存的数据库行为。
对于自动同步的系统:
- 如果刷新过于频繁，则性能较差。
- 如果刷新频率不高，则刷新速度会更快，但有数据丢失的风险。
更好的方法可能是利用数据库的手动同步方案，因为这将提供与应用程序所需的保证相匹配的控制。这增加了应用程序的复杂性。对于高并发系统，难度会增加，因为服务于一个应用程序的磁盘操作可能会过度干扰另一个应用程序。
事务和批处理操作等在最后进行同步的系统可能是有益的。这将减少磁盘访问的次数，但对于何时将数据刷新到磁盘有非常明确的保证。
索引
数据很少作为孤立值存储。它通常是组成记录的多个字段的异构集合。在关系数据库中，这些字段称为列，它们固定在定义表的模式中。
在非关系数据库中，仍然经常容纳异构字段，甚至建立索引。当您希望通过指定记录中的一个字段来查找表时，该字段需要成为索引的一部分。索引只是一个用于执行随机查找的数据结构，给定一个指定字段(或者，在支持的情况下，指定字段的元组)。
要么树，要么不树。因为b -树也是磁盘上的数据结构，所以它是大多数查找索引的首选工具，因为它有效地支持硬盘。与存储数据的B+树不同，查找索引针对存储对数据的引用进行了优化。b树可以有效地容纳插入，而不必为每个操作分配存储单元。它的结构也趋于扁平，减少了需要搜索的节点数量，因此减少了潜在的磁盘寻道的数量。
然而，还有其他的选择。例如，位图索引是一种数据结构，它提供对多个表的高效连接查询。
树型索引随索引中条目的数量线性增长，搜索时间随树的深度(总深度的对数函数)而增长。
另一方面，位图索引会随着索引中不同项的数量而增长。顾名思义，它构建一个位图，表示所有相关列的值的成员关系。针对位图索引的多个布尔运算非常快，它们生成的新位图可以作为搜索结果高效地缓存。
位图索引的另一个主要创新是它可以被压缩，甚至可以在压缩时执行查询操作。这使得存储检索更快。它还使位图索引对CPU缓存更加友好，从而可以进一步减少延迟。由于其更复杂的更新过程，位图索引倾向于在大量读取的系统中使用，特别是那些具有多维查询的系统，如OLAP(在线分析处理)多维数据集。
索引性能总结。除非您唯一的数据访问模型是对大区域数据的全面扫描，否则您可能需要索引。但是，数据集利用的每一个额外索引都会增加磁盘和CPU负载，并增加插入的延迟。
如果您的系统读量很大，并且列中的数据种类相对较少(称为低基数)，那么您可以利用位图索引。对于其他所有东西，都有树索引。
许多索引需要一个唯一的键来指向一个记录。如果它是该记录的唯一索引，则称为主键。即使是无模式的数据库也常常支持这样的索引约束。它们可以帮助确保一致性，并在加载数据时检测错误。
对于性能，有一个基本的规则要遵循:索引越少越好。几乎所有支持添加索引的数据库都允许在加载数据后添加索引。所以，一旦你确定你需要它们，以后再添加它们。使用唯一索引可以提供确保数据一致性的双重好处。
如果一次性加载所有数据(也许在数据集市模型中)，那么您可能会从随后创建索引中受益。这甚至可以产生更高效的索引，因为许多索引会受到多次插入和更新导致的碎片的负面影响。
把一切都拼凑在一起
性能和安全性之间的权衡围绕着磁盘。如果您选择的数据库完全是为您的访问模型构建的，那么您可能会两全其美。花点时间彻底理解您的访问模型，并了解您需要哪些特性，哪些特性愿意为了性能而放弃。
如果不需要保证每个操作的持久性和立即持久性，可以通过利用内存映射的数据结构来延迟将操作持久化到磁盘。要了解数据丢失的风险是存在的任何时候，您依赖内存来加快事情。如果发生失败，那些挂起的写操作就会消失。
无论您的应用程序是什么，都要花时间了解操作系统中的页面缓存。你认为安全的文章可能并不安全。它也有许多用于微调性能的设置。它可以被设置为高度偏执但忙碌，或者无忧无虑且快速。您应该非常清楚数据库如何以及何时写入磁盘。如果它遵从操作系统，那么采取步骤确保它对您的用例正确地运行。
验证你的期望是否符合现实是值得的。它可能只是保存你的数据。
相关文章
在queue.acm.org
弥合对象-关系的鸿沟
克雷格·罗素
http://queue.acm.org/detail.cfm?id=1394139
通过各种设备的感知数据访问
George W. Fitzmaurice等人。
http://queue.acm.org/detail.cfm?id=966721
分布式计算经济学
吉姆灰色
http://queue.acm.org/detail.cfm?id=1394131
参考文献
1.b树;http://www.scholarpedia.org/article/B-tree_and_UB-tree．
2.用于数据库;http://en.wikipedia.org/wiki/Column-oriented_DBMS．
3.硬盘成本;http://www.mkomo.com/cost-per-gigabyte-update．
4.延迟数;http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html．
5.达到;http://en.wikipedia.org/wiki/LGA_2011．
6.LSM树;http://dlacm.org/citation.cfm?id=230826；而且http://www.eecs.harvard.edu/~margo/cs165/papers/gp-lsm.pdf．
7.归一化;http://en.wikipedia.org/wiki/Database_normalization．
8.页面缓存;http://www.westnet.com/~gsmith/content/linux-pdflush.htm．
9.SQL;http://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL．
数字图书馆是由计算机协会出版的。版权所有©2015 ACM, Inc.
没有发现记录