数据库如何选择

这篇文章给大家分享的是有关数据库如何选择的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。

数据库是模块化的系统，由多个部分组成：接受请求的传输层、决定以最高效方式运行查询的查询处理器、执行操作的执行引擎以及存储引擎。

存储引擎(或数据库引擎)是数据库的一个软件组件，它负责在内存和磁盘上存储、检索和管理数据，而设计它的目的是长久保存每个节点的数据[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和Database  of  Databases等数据库比较网站所呈现的流行度值)或实现语言(C、Java或Go等)来比较数据库，可能导致无效和不成熟的结论，这些方法只能用于高层次上的比较，并且可能出现例如在  HBase 和 sqlite  之间进行选择这样粗糙的对比。因此，即使只是对每个数据库的工作原理和内部结构有粗浅了解，这些了解也可以很好地帮助你得出一个更可靠的结论。

每一次比较都应该从清晰界定的目标开始，因为哪怕是最小的偏差都可能使整个调查完全无效。如果你正在找寻一个非常适合当下(或者未来)的工作负载的数据库，那么你所能做的最好的事情就是在不同的数据库系统上模拟这些工作负载、测量对你很重要的那些性能指标，并比较结果。有些问题(特别是性能和可伸缩性方面的问题)只有在一段时间后或随着容量的增长才会开始显现出来。为了发现潜在的问题，最好在尽可能接近真实生产环境的环境中进行长期的运行测试。

模拟现实世界中的工作负载不仅能帮助你了解数据库的运行方式，还能帮助你学习如何操作与调试数据库，并了解其社区的友好程度和能提供帮助的程度。数据库的选择总是这些因素的组合，而性能通常并不是最重要的方面：使用保存数据缓慢的数据库通常比使用会快速丢失数据的数据库要好得多。

要比较数据库，非常详细地理解用例并定义当前和预期的变量是有帮助的，例如:

表结构和记录大小

客户端数量

查询类型和访问模式

读写查询速率

任何这些变量中的预期变化

明确这些变量可以帮助回答以下问题：

数据库支持所需的查询吗?

数据库能够处理我们计划存储的数据量吗?

单个节点可以处理的读写操作有多少?

一个系统计划要有多少个节点?

鉴于预期的增长率，我们如何扩展集群?

维护过程是什么?

在回答了这些问题之后，你可以构建一个测试集群并模拟你的工作负载。大多数数据库已经有了压测工具，可以用来重现特定的用例。如果没有标准的压测工具用来在数据库生态系统中生成现实中的随机工作负载，那么这可能是一个危险的信号。如果有什么东西让你无法使用数据库自带的工具，那么你可以尝试一个现有的通用工具，或者从零开始实现一个。

如果测试结果理想，那么进一步熟悉数据库代码可能会有更大的帮助。为了阅读源代码，首先要了解数据库的各个部分、如何查找不同组件的源代码，然后浏览这些组件。即使仅对数据库代码库有一个粗略的了解，也有助于你更好地理解它产生的日志和配置参数，并帮助你在使用数据库的应用程序中，甚至在数据库代码本身发现问题。

有些人以为，可以将数据库当作黑匣子而无须了解其中的内容是件好事。但实践往往表明，这样做迟早会碰到bug、服务中断、性能倒退或其他问题。你最好为这些问题做好准备，如果你了解并且理解数据库的内部结构，就可以减少业务风险且更有可能快速地恢复。

用于基准测试、性能评估和比较的一个流行工具是Yahoo! Cloud Serving  Benchmark(YCSB)。YCSB提供了一个框架和一组可应用于不同数据存储的公共工作负载集。就像任何通用的东西一样，你应该小心使用这个工具，因为使用它很容易得出错误的结论。为了进行公平的比较并做出明智的决定，你需要投入足够的时间来了解数据库将在何种实际环境下运行，并相应地调整基准测试的内容。

TPC-C基准事务处理性能委员会(Transaction Processing PerfORMance  Council，TPC)提供了一组数据库厂商用来比较和宣传其产品性能的基准。TPC-C是一个联机事务处理(OLTP)基准，它是只读事务和更新事务的混合，用于模拟常见的应用程序工作负载。

该基准关注的是执行的并发事务的性能和正确性。主要性能指标是吞吐量：数据库系统每分钟能够处理的事务数。其需要执行事务具备 ACID  属性并符合基准本身定义的属性集。

此基准不专注于任何特定的业务部门，但提供了对大多数适用 OLTP  数据库的应用都很重要的抽象操作集。它包括几个表和实体，如仓库、库存、客户和订单，并指定了表布局、可以对表执行的事务的细节、表的最小行数和数据持久性约束。

这并不意味着基准测试只能用于比较数据库。基准可用于定义和测试服务级别协议注1的详细信息、了解系统要求以及容量规划等。你在使用数据库之前对它了解得越多，在生产环境中运行数据库时节省的时间就越多。

选择数据库是一个长期的决定，最好跟踪新发布的版本，了解到底发生了什么变化及其原因，并制定升级策略。新版本通常包含对 bug  和安全问题的改进及修复，但也可能会引入新的  bug、性能退化或意外行为，因此在部署新版本之前测试新版本也是至关重要的。查看数据库开发者以前是如何处理升级的，可能会让你对将来的情况有一个很好的了解。过去的顺利升级并不能保证未来的升级也会如此顺利，但过去复杂的升级可能也是未来升级亦会不容易的标志。

理解权衡取舍作为用户，我们可以看到数据库在不同条件下的行为，但是在使用数据库时，我们必须做出选择来直接影响其行为。

设计一个存储引擎肯定比仅实现一个教科书上的数据结构要复杂得多：很难在一开始就将许多细节和边界情况处理正确。我们需要设计物理数据布局和组织指针、决定序列化格式、了解数据将如何被进行垃圾收集、存储引擎如何适应整个数据库系统的语义、探索如何使其在并发环境中工作，以及最后确保在任何情况下都不会丢失任何数据。

不仅有许多事情需要决定，而且这些决定中的大多数都涉及权衡取舍。例如，如果按数据插入数据库的顺序保存，我们就可以更快地存储它们;但是如果按字典顺序检索它们，我们就必须在将结果返回给客户端之前对它们进行重新排序。正如你将在本书中看到的那样，存储引擎设计有许多不同的方法，每个实现都有它自己的优点和缺点。

在研究不同的存储引擎时，我们会讨论它们的优点和缺点。如果对于每个可以想到的用例都有一个绝对最优的存储引擎，那么人人都一定会使用它。但是并不存在这样的储存引擎，因此我们需要根据服务的工作负载和用例进行明智的选择。

市面上有许多存储引擎，它们使用各种数据结构并且用不同的语言实现—从低级语言(如C)到高级语言(如Java)。所有存储引擎都面临相同的挑战和限制。可以将其与城市规划相类比：我们为特定的人口数量构建一座城市，并选择是在高度上还是面积上对这座城市进行扩展。这两种情况都可以将同样数量的人放入该城市，但这些方法导致了截然不同的生活方式。当在高度上建设城市时，人们住在公寓里，人口密度可能导致面积较小地区的交通流量增加;而在一个面积更大且更分散的城市中，人们更有可能住在大房子里，但通勤则需要走更远的路。

类似地，存储引擎的开发人员所做的设计决策使它们更适合于不同的情况：有些对低读写延迟进行了优化，有些则试图最大化存储密度(每个节点存储的数据量)，而有些则专注于运维上的简单性。

感谢各位的阅读！关于“数据库如何选择”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！