这里介绍了如何判断数据库何时适合您的项目。当您为最新用例选择数据库时（或替换不满足当前需求的数据库），现在的好消息是您有很多选项可供选择。当然，这也是一个坏消息。你有很多东西要整理。有比以往更多的数据库需要考虑和比较。2012年12月底，即DB-Engines.com首次开始对数据库进行排名的第一年，他们列出了73个系统（比最初列出的18个有显着增加）。截至2022年12月，他们只有不到400个系统。这代表了过去十年数据库技术的寒武纪大爆发。有很多选项可供导航：SQL、NoSQL和“多模型”数据库的混合，它可以是SQL和NoSQL的混合，或者NoSQL的多个数据模型（结合两个或多个选项：文档、键-值、宽列、图表等）。此外，用户不应将完全流行与适用于他们的用例相混淆。虽然网络效应当然有优势（“如果每个人都在使用X，它就不会出错”），但它也会导致集体思维，扼杀创新和竞争。我和我的同事ArthurPesa最近讨论了用户在筛选和比较数据库时应首先考虑的五个因素。让我们直接进入列表的五个因素。软件架构——数据库是否使用最高效的数据结构、灵活的数据模型和丰富的查询语言来支持您的工作负载和查询模式？硬件利用——你能充分利用现代硬件平台吗？还是您留下了许多未充分利用的CPU周期？互操作性——集成到您的开发环境中有多容易？它支持你的编程语言、框架和项目吗？它是否旨在集成到您的微服务和事件流架构中？RASP-它是否具有可靠性、可用性、可扩展性、可维护性以及性能的必要品质？部署——这个数据库是否只能在有限的环境中工作，例如只能在本地，或者只能在单个数据中心或单个云提供商中工作？或者它是否适合按照您想要的方式在全球部署？任何此类失败都是主观的。您可能有自己的4因素列表，或12、20或100个标准。当然，软件架构等这些因素中的每一个都细分为“存储引擎”、“分布式处理架构”甚至“查询语言”等子类别。但这就是我将它们分为一般类别的方式。软件架构这里的关键考虑因素是“数据库是否使用最高效的数据结构、灵活的数据模型和丰富的查询语言来支持您的特定工作负载和查询模式？”工作负载——您是否需要执行繁重的写入或混合读写的事务性工作负载？或者你打算做一个完成大部分阅读的分析工作量？您是否需要混合事务和分析的混合工作负载？工作负载是实时的、批处理的还是混合的？它是每秒稳定的事件流，还是一天内平稳、规律、可预测的上升和下降？或者您是否需要为突发流量的随机冲击做好准备（例如，突发新闻或任何其他突然流行的记录）？数据模型——你在处理键值对吗？宽列存储（基于行的key-key-value数据）？列存储（列数据）？文档？图形？RDBMS（带有表和JOIN）？或者完全是别的东西。您是否真的有时间并且需要完全规范化数据，或者您是否会如此快速地摄取如此多的非结构化数据以致于规范化是徒劳的，您最好从非规范化数据模型开始？这里没有单一的“正确”答案。“这取决于”应该是你的口头禅。查询语言——这里肯定有更多的偏见。因为虽然您的数据工程团队可能能够掩盖或隐藏您的后端查询模型，但您的许多用户都有自己的偏见和偏好。这是SQL仍然如此锁定的主要原因之一。此外，还提供了一种新的查询语言。有些类似于SQL，例如Cassandra和ScyllaDB使用的Cassandra查询语言(CQL)。SQL用户对它非常熟悉。但不要被愚弄-没有表JOIN！然后还有一系列新派的查询语言可能会用到，比如JSON。这就是AmazonDynamoDB查询的工作方式。同样，在这里，ScyllaDB使用我们的Alternator接口支持这样的JSON查询模型，它与DynamoDB兼容。不管你向哪个方向倾斜，交易/运营/CAP——哪个对你来说更重要？完全一致的ACID事务？还是高性能、高可用的基本CRUD操作？CAP定理表示您可以拥有以下三项中的任意两项：一致性、可用性或分区容错性。考虑到分布式数据库总是需要分区容错性，这允许您在所谓的“CP”模式一致性导向系统或“AP”模式可用性导向系统之间进行选择。在这些模式中，需要考虑实现细节。例如，在分布式系统中实现强一致性的方法可能千差万别。甚至考虑选择各种共识算法来保证线性化，例如Paxos、Raft、Zookeeper（ZAB）等。除了不同的算法之外，每个实现都可能与另一个有很大的不同。数据分布——当你说“分布式系统”时，你到底是什么意思？我们是在谈论本地单数据中心集群吗？或者我们在谈论多数据中心集群？跨集群更新是如何发生的？它是否被视为所有一个逻辑集群，还是需要集群间同步？它如何处理数据本地化，例如GDPR合规性？硬件利用我们正处于持续推动软件开发的底层硬件革命之中。许多软件应用程序，尤其是许多数据库，仍然植根于几十年前的起源、设计和假设。CPU利用率/效率-如果CPU利用率超过40%或50%，许多软件将运行不佳。这意味着您应该低效地运行软件，定期让一半的机器未得到充分利用。实际上，您为基础设施支付的费用是您实际需要的两倍（或更多）。因此，值得研究您的系统如何处理分布式处理。RAM利用率/效率-您的数据库是否始终受内存限制？它的缓存是否过于激进或臃肿（例如，具有多层缓存），将不必要的数据保留在内存中？它如何优化其读写路径？存储利用率/效率——您的数据库使用什么存储格式？它是否具有可能需要重量级文件锁定机制的紧凑型可变表？或者它是否使用可能产生快速写入但以空间和读取放大为代价的不可变表？它是否允许分层存储？它如何处理并发？文件是按行存储（用于交易用例）还是按列存储（用于高度重复数据的分析）？请注意，不只有一个“正确”答案。每个解决方案都针对不同的用例进行了优化。网络利用率/效率——在这里您应该同时考虑客户端-服务器集群通信的效率，以及集群内通信的效率。客户端/服务器模型可以通过并发、连接池等提高效率。集群内通信涵盖典型的操作/事务聊天（在更新或写入中复制数据），以及管理任务，例如节点之间的流式传输和平衡数据在拓扑更改期间。互操作性没有数据库是孤岛。集成到您的开发环境中有多容易？它支持你的编程语言、框架和项目吗？它是否旨在集成到您的微服务和事件流架构中？编程语言/框架——您一遍又一遍地听到“我们是一家X商店”，其中X代表您首选的编程语言或框架。如果您的数据库没有必要的客户端、SDK、库、ORM和/或其他包来将其集成到语言中，那么它可能不存在。公平地说，数据库的大规模爆炸与编程语言的大规模爆炸同时发生。但是，值得查看对客户端的编程语言支持。请注意，这与数据库本身可能使用的语言不同（这可能会影响其软件架构和效率）。它纯粹是关于你可以用什么语言编写你的应用程序来连接到那个后端数据库。事件流/消息队列——数据库可能是唯一的真实来源，但它们并不是您公司中运行的唯一系统。事实上，您可能拥有不同的数据库，它们都在处理、分析和共享公司整体数据和信息空间的不同部分。事件流是现代企业避免数据孤岛的一种越来越普遍的媒介，如今您的数据库只有在与实时事件流和消息队列技术集成时才能正常运行。您的数据库能否同时充当数据接收器和数据源？它是否具有变更数据捕获(CDC)？它是否连接到您最喜欢的事件流和消息队列技术，例如ApacheKafka、ApachePulsar或RabbitMQ？API——为了便于将您的数据库集成到您的应用程序和微服务架构中，您的数据库是否支持一个或多个API，例如RESTful接口或GraphQL？它是否具有管理API，以便您可以通过编程方式配置它，而不是通过GUI界面完成所有操作？起初使用GUI似乎很方便，直到您必须管理和自动化您的部署系统。其他集成怎么样——CI/CD工具链？可观察性平台？您如何将数据库用作可插拔存储引擎或更广泛架构的底层元素？它作为基础架构的效果如何，或者它是否适合您已经使用的基础架构？首字母缩略词RASP可以追溯到几十年前，通常用于硬件上下文中。它代表可靠性、可用性、可维护性（或可扩展性）和性能。基本上，这些“-ilities”是“facilities”——使系统运行更容易的东西。在数据库中，考虑您可能需要执行多少手动干预和“旋转”以保持系统正常运行和稳定是至关重要的。它们表明数据库能够自我照顾的程度，甚至可以在典型操作条件下尽可能地减轻故障情况。一个典型的平台工程师启动了一堆新节点。可靠性——你需要做多少补丁才能防止这个东西崩溃或数据消失？你的数据库是否具备良好的持久化能力？它的生存能力如何？它包括什么反熵机制来使集群恢复同步？您的备份系统有多好？更重要的是，您的还原系统有多好？是否有操作护栏来防止个人用“哎呀！”搞砸事情？可用性——当您遇到短暂的网络分区和临时节点不可用时，您的数据库会做什么？当一个节点完全失效时会发生什么？如果网络中断持续超过几个小时怎么办？可服务性——如今流行的流行语是“可观察性”，它通常包含日志记录、跟踪和指标这三大支柱。当然，您的数据库需要内置可观察性。但是，可维护性远不止于此。在不停机的情况下执行升级有多容易？维护操作有多容易？可扩展性——一些数据库非常适合入门。然后……你撞墙了。难的。可扩展性意味着您不必担心在管理的总数据量、每秒总操作数或地理限制方面达到极限——例如??超越单个数据中心以实现真正的全球部署。此外，还有水平可扩展性——通过向集群添加更多节点进行水平扩展——以及垂直可扩展性——将您的数据库放在具有不断增加的CPU数量、更多RAM和更多存储（请参阅硬件部分）的服务器上（超过）.性能-底线：如果数据库不能满足您的延迟或吞吐量SLA，它就不会在生产环境中运行。此外，与可扩展性相关，许多数据库似乎可以在小规模或基于使用测试数据的静态基准测试中满足您的性能要求，但跟不上不断增加的频率、可扩展性等变化和查询复杂性。因此，性能需要与线性缩放具有很强的相关性。部署然后，以上所有内容都需要在您需要的地方运行。这个数据库是否只能在有限的环境中工作，比如只能在本地，或者只能在单个数据中心或单个云提供商中工作？或者它是否适合按照您想要的方式在全球部署？问自己这些问题：锁定-这会在本地工作吗？或者，相反，它是否仅限于本地部署？它是否仅限于某个公共云提供商，还是会在您选择的云提供商上运行？您的混合云或多云部署选项是什么？管理/控制——同样，这是否仅可用作自我管理的数据库，或作为完全托管的数据库即服务(DBaas)？前者让团队完全掌控系统，后者减轻团队的行政负担。两者都有其权衡。只能选择一个，还是数据库允许用户在两??种商业模式之间切换？自动化和编排——KubernetesOperator是否在生产中支持这一点？Terraform和Ansible脚本？虽然这是列表中的最后一项，但请放心，在任何生产考虑中都不应该事后才想到它。
