“我会选择 X，它是我认识并与之合作过的数据库” 。
大多数开发人员和学生在为项目选择数据库时都会使用此语句。如果性能不是您的系统的重要要求，那么使用您已经熟悉的数据库是完全可以的，但请考虑当您的应用程序增长并且几年后您的应用程序开始面临一些问题时的情况。解决此问题将成为开发人员和管理员头疼的问题。无论您是从头开始从事项目还是已经在从事成熟的项目，了解数据库的局限性并确定何时在项目中添加另一种类型的数据库都很重要。
市场上有300 多种数据库管理系统，选择其中一种可能会让开发人员不知所措。您在关系(MySQL、PostgreSQL、Oracle DB 等)和非关系(MongoDB、Apache HBase、Cassandra 等)数据库中有多种可用选项，但您需要了解它们中没有一个适合所有类型的项目要求。他们每个人都有一些优点和缺点。让我们看一些案例研究，说明您应该如何为您的应用程序选择正确的数据库。
选择正确的数据库
当你在构建一个给定的系统时，你是如何做出这个决定的? .
有如此多的数据库可用，选择一个数据库而不是另一个数据库是一个复杂的决定。好吧，没有您可以遵循的真正公式，但是您应该考虑一些事情。这不是一个容易的决定，但擅长它的人会赚大钱。首先抛开您将找到一个比其他一切都更好的真正数据库的想法。现在在考虑一个特定的数据库之前，花一些时间问一些与你的项目相关的重要问题……
- 当应用程序成熟时，您希望存储多少数据?
- 您希望在峰值负载时同时处理多少用户?
- 您的应用程序需要什么样的可用性、可扩展性、延迟、吞吐量和数据一致性?
- 您的数据库架构多久更改一次?
- 您的用户群的地理分布是什么?
- 数据的自然“形状”是什么?
- 您的应用程序是否需要在线事务处理 (OLTP)、分析查询 (OLAP) 或两者兼而有之?
- 您期望生产中的读取与写入比率是多少?
- 您首选的编程语言是什么?
- 你有预算吗?如果是，它是否涵盖许可证和支持合同?
- 您对发送到数据库的无效数据有多严格? (理想情况下，您非常严格并在将其持久化到数据库之前进行服务器端数据验证)
现在让我们谈谈一些关键方面，这些方面将回答上述问题，并帮助您为您的应用程序选择正确的数据库……
1. 整合
选择正确的数据库时要考虑的最重要的事情是您需要集成什么系统?确保您的数据库管理系统可以与项目中的其他工具和服务集成。不同的技术对于不同的其他技术有不同的连接器。例如，如果您有一个当前正在运行Apache spark的大型分析作业，那么您可能希望将自己限制在可以轻松连接到 apache spark 的外部数据库。现在假设您有一些前端系统实际上依赖于后端的 SQL 接口，并且您正在考虑从单体数据库转移到非关系数据库。如果您要迁移的非关系数据库提供某种类似 SQL 的界面，可以轻松地从前端应用程序迁移到该界面，那么这将是一个不错的选择。因此，请考虑需要在您的系统中一起讨论的部分，看看它们是否真的可以与现有的现成组件一起讨论，以及这些组件是否实际上得到了良好的维护和更新。
另一个例子是 ArangoDB，它具有出色的性能，但是这个 DBMS 的库还很年轻，缺乏支持。将 ArangoDB 与其他工具结合使用可能会有风险，因此社区建议避免将 ArangoDB 用于复杂项目。
2. 扩容要求
在安装生产数据库之前了解扩展要求很重要。你真正在谈论多少数据?随着时间的推移，它真的会无限增长吗?如果是这样，那么您需要某种数据库技术，该技术不仅限于可以存储在一台 PC 上的数据。您需要查看诸如 Cassandra 或 MongoDB 或 HBase 之类的东西，您可以在其中实际将数据存储分布在整个集群中并水平而不是垂直扩展。由于扩展问题，许多数据库无法处理数以千计的用户查询 TB 或 PB 级数据。
在选择数据库时，您还需要考虑事务率或吞吐量，这意味着您打算每秒获得多少请求。具有高吞吐量的数据库可以支持多个并发用户。如果我们谈论的是数千个，那么单个数据库服务将无法正常工作。当您在一些大型网站上工作时，这一点尤其重要，在这些网站上，我们有很多 Web 服务器同时为很多人提供服务。您必须选择一个分布式数据库，并允许您更均匀地分布这些事务的负载。在这些情况下，NoSQL 数据库是一个不错的选择，而不是 RDBMS。
3. 支持考虑
想想您的数据库可能需要的支持。 您是否拥有内部专业知识来启动这项新技术并对其进行正确配置?这将比您想象的要困难，特别是如果您在现实世界或任何类型的情况下使用它，其中您从最终用户那里混合了个人身份信息。在这种情况下，您需要确保您正在考虑系统的安全性。事实是，我们讨论过的大多数 NoSQL 数据库，如果您使用默认设置对其进行配置，则根本没有安全性。任何人都可以连接到这些东西并检索数据并将数据写入其中。因此，请确保您有可用的人知道他们在以安全的方式进行设置。如果您所在的大型组织内部拥有这些专家，那就太好了，但如果您所在的组织较小，则可能必须选择提供专业付费支持的技术，他们可以在初始阶段指导您完成初始设置决策随着时间的推移管理您的服务器。您还可以将管理员外包以获得支持。像 MongoDB 这样更企业化的解决方案已经付费支持，如果我们谈论 Apache 项目，那么有一些公司提供付费专业支持。
4. CAP 考虑
CAP 代表Consistency, Availability, and Partition tolerance 。该定理指出，您无法在单个数据库中获得最佳级别的所有属性，因为项目之间存在自然的权衡。您一次只能从三个中选择两个，这完全取决于您根据需求确定的优先级。例如，如果您的系统需要可用和分区容忍，那么您必须愿意接受一致性要求中的一些延迟。
传统关系型数据库自然适合CA端，而非关系型数据库引擎主要满足AP 和 CP要求。
- 一致性意味着任何读取请求都将返回最近的写入。 SQL 数据库的数据一致性通常是“强”的，而 NoSQL 数据库的一致性可能是从“最终”到“强”的任何内容。
- 可用性意味着非响应节点必须在合理的时间内响应。并非每个应用程序都需要以 99.999% 的可用性运行 24/7，但您很可能更喜欢具有更高可用性的数据库。
- 分区容错意味着尽管网络或节点出现故障，系统仍将继续运行。
应用程序的类型将决定您在那里想要什么，只有您知道实际要求。如果您的系统停机几秒钟或几分钟，实际上是否可以，如果没有，那么可用性应该是您的首要关注点?如果您正在处理具有真实交易信息的事物，例如股票交易或金融交易，您可能首先重视一致性。尝试选择最适合您要进行权衡的技术。
5. 模式或数据模型
关系数据库以固定和预定义的结构存储数据。这意味着当您开始开发时，您必须根据表和列定义数据模式。每次需求更改时，您都必须更改架构。这将导致创建新列、定义新关系、反映应用程序中的更改、与数据库管理员讨论等。
NoSQL 数据库在处理数据时提供了更大的灵活性。无需指定架构即可开始使用应用程序。此外，NoSQL 数据库对可以存储在一起的数据类型没有限制。它允许您随着需求的变化添加更多新类型。在应用程序构建过程中，大多数开发人员更喜欢高编码速度和高敏捷性。在这方面，NoSQL 数据库已被证明是更好的选择，尤其是对于需要快速实施的敏捷开发。
您确实需要注意提到的所有 5 点，但最重要的是，最重要的建议是保持一切简单。不要仅仅因为它在市场上闪亮和流行而选择数据库。如果您不需要设置高度复杂的 NoSQL 集群或需要大量维护的东西，例如 MongoDB 或 HBase，其中您拥有所有这些维护配置的外部服务器，如果您不需要，请不要这样做。考虑系统所需的最低要求。如果你不需要处理大规模的，那么就没有必要使用NoSQL数据库，你可以选择MySQL，在某个地方就可以了。除非您确实需要，否则在您的组织内部署一个没有良好专业知识的全新系统是没有意义的。简单的技术和简单的架构将更容易维护。毕竟，当您在凌晨 3:00 醒来时，您不会感到高兴，因为某些随机服务器在您无缘无故设置的过于复杂的数据库系统上出现故障。所以尽可能让一切保持简单。