作者
AlexPetrov
所有数据库管理系统的主要工作都是可靠地存储数据并使其对用户可用。我们使用数据库作为数据的主要来源，帮助我们在应用程序的不同部分之间共享数据。我们使用数据库，而不是在每次创建新应用程序时寻找存储和检索信息的方法，也不是每次都去发明一种组织数据的新方法。这样一来，我们就可以专注于应用程序逻辑而不是基础设施。
数据库是模块化的系统，由多个部分组成：接受请求的传输层、决定以最高效方式运行查询的查询处理器、执行操作的执行引擎以及存储引擎。
存储引擎（或数据库引擎）是数据库的一个软件组件，它负责在内存和磁盘上存储、检索和管理数据，而设计它的目的是长久保存每个节点的数据[REED78]。数据库可以响应复杂的查询，存储引擎则会更细粒度地看待数据并提供一组简单的数据操作API，允许用户创建、更新、删除和检索数据记录。从某个角度来看，数据库是构建在存储引擎之上的应用程序，它提供了表结构（schema）、查询语言、索引、事务和许多其他有用的特性。
为了获得灵活性，键和值都可以是没有预设格式的任意字节序列。它们的排序和表示语义是在更高级别的子系统中定义的。例如，你可以在一个表中使用int32（32位整数）作为键，而在另一个表中使用ascii（ASCII字符串）；从存储引擎的角度来看，这两个键都只是序列化的条目。
BerkeleyDB、LevelDB（及其后代RocksDB）、LMDB（及其后代libmdbx、Sophia和HaloDB）等存储引擎的开发都与它们现在所嵌入的数据库彼此独立。使用可插拔的存储引擎使数据库开发人员能够使用现有存储引擎来构建数据库系统，并将精力集中在其他子系统上。
同时，数据库系统组件之间清晰的解耦为切换不同引擎提供了机会，这些引擎可能分别适用于特定的用例。例如：流行的数据库MySQL有几个存储引擎，包括InnoDB、MyISAM和RocksDB（在MyRocks发行版中），而MongoDB则允许在WiredTiger、内存以及（现已弃用的）MMAPv1存储引擎之间进行切换。
数据库的比较
对数据库系统的选择将会产生长期的影响。如果选择的数据库不合适（因其导致性能问题、一致性问题或运维上的挑战），那么我们最好在开发周期的早期就发现这一点，因为迁移到不同的系统可能并非易事，甚至在某些情况下，你还需要对应用程序的代码进行重大的修改。
每个数据库系统都有优点和缺点。为了降低进行高成本迁移的风险，你可以在选择数据库上投入一些时间，以确保其具备满足应用程序需求的能力。
试图根据数据库的组件（例如：使用的存储引擎，数据共享、复制和分布的方式等）、它们的排名（ThoughtWorks等咨询机构或诸如DB-Engines和DatabaseofDatabases等数据库比较网站所呈现的流行度值）或实现语言（C、Java或Go等）来比较数据库，可能导致无效和不成熟的结论。这些方法只能用于高层次上的比较，并且可能出现例如在HBase和SQLite之间进行选择这样粗糙的对比。因此，即使只是对每个数据库的工作原理和内部结构有粗浅了解，这些了解也可以很好地帮助你得出一个更可靠的结论。
每一次比较都应该从清晰界定的目标开始，因为哪怕是最小的偏差都可能使整个调查完全无效。如果你正在找寻一个非常适合当下（或者未来）的工作负载的数据库，那么你所能做的最好的事情就是在不同的数据库系统上模拟这些工作负载、测量对你很重要的那些性能指标，并比较结果。有些问题（特别是性能和可伸缩性方面的问题）只有在一段时间后或随着容量的增长才会开始显现出来。为了发现潜在的问题，最好在尽可能接近真实生产环境的环境中进行长期的运行测试。
模拟现实世界中的工作负载不仅能帮助你了解数据库的运行方式，还能帮助你学习如何操作与调试数据库，并了解其社区的友好程度和能提供帮助的程度。数据库的选择总是这些因素的组合，而性能通常并不是最重要的方面：使用保存数据缓慢的数据库通常比使用会快速丢失数据的数据库要好得多。
要比较数据库，非常详细地理解用例并定义当前和预期的变量是有帮助的，例如
/p>
表结构和记录大小客户端数量查询类型和访问模式读写查询速率任何这些变量中的预期变化明确这些变量可以帮助回答以下问题：
数据库支持所需的查询吗？数据库能够处理我们计划存储的数据量吗？单个节点可以处理的读写操作有多少？一个系统计划要有多少个节点？鉴于预期的增长率，我们如何扩展集群？维护过程是什么？在回答了这些问题之后，你可以构建一个测试集群并模拟你的工作负载。大多数数据库已经有了压测工具，可以用来重现特定的用例。如果没有标准的压测工具用来在数据库生态系统中生成现实中的随机工作负载，那么这可能是一个危险的信号。如果有什么东西让你无法使用数据库自带的工具，那么你可以尝试一个现有的通用工具，或者从零开始实现一个。
如果测试结果理想，那么进一步熟悉数据库代码可能会有更大的帮助。为了阅读源代码，首先要了解数据库的各个部分、如何查找不同组件的源代码，然后浏览这些组件。即使仅对数据库代码库有一个粗略的了解，也有助于你更好地理解它产生的日志和配置参数，并帮助你在使用数据库的应用程序中，甚至在数据库代码本身发现问题。
有些人以为，可以将数据库当作黑匣子而无须了解其中的内容是件好事。但实践往往表明，这样做迟早会碰到bug、服务中断、性能倒退或其他问题。你最好为这些问题做好准备，如果你了解并且理解数据库的内部结构，就可以减少业务风险且更有可能快速地恢复。
用于基准测试、性能评估和比较的一个流行工具是Yahoo!CloudServingBenchmark（YCSB）。YCSB提供了一个框架和一组可应用于不同数据存储的公共工作负载集。就像任何通用的东西一样，你应该小心使用这个工具，因为使用它很容易得出错误的结论。为了进行公平的比较并做出明智的决定，你需要投入足够的时间来了解数据库将在何种实际环境下运行，并相应地调整基准测试的内容。
TPC-C基准
事务处理性能委员会（TransactionProcessingPerformanceCouncil，TPC）提供了一组数据库厂商用来比较和宣传其产品性能的基准。TPC-C是一个联机事务处理（OLTP）基准，它是只读事务和更新事务的混合，用于模拟常见的应用程序工作负载。
该基准
