“我只选择X，这是我知道并使用过的数据库” 。
在为项目选择数据库时，大多数开发人员和学生都使用此语句。如果性能不是系统的重要要求，那么使用您已经熟悉的数据库就可以了，但是要考虑应用程序增长的情况，并且几年后您的应用程序开始遇到一些问题。对于开发人员和管理员来说，解决该问题将变得头疼。无论您是从头开始工作还是已经在成熟的项目上工作，了解数据库的局限性并确定何时在项目中添加另一种类型的DB都非常重要。
市场上有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代表一致性，可用性和分区容忍度。该定理指出，您无法在单个数据库中以最佳级别获得所有属性，因为项目之间存在自然的取舍。您一次只能选择三分之二，这完全取决于您根据需求确定的优先级。例如，如果您的系统需要可用并且可以容忍分区，那么您必须愿意在一致性要求中接受一些延迟。
传统的关系数据库很适合CA端，而非关系数据库引擎大多满足AP和CP的要求。
- 一致性意味着任何读取请求都将返回最近的写入。对于SQL数据库，数据一致性通常是“强”，对于NoSQL数据库，数据一致性可以是“最终”到“强”。
- 可用性意味着无响应的节点必须在合理的时间内响应。并非每个应用程序都需要24/7全天候运行并具有99.999％的可用性，但是您很可能会希望使用具有更高可用性的数据库。
- 分区容限意味着即使网络或节点出现故障，系统仍将继续运行。
应用程序的类型将确定您要在那里的内容，只有您知道实际需求。如果您的系统停机几秒钟或几分钟，实际上是否可以，如果不是，那么可用性应该是您的首要考虑?如果您要处理的是具有真实交易信息(例如股票交易或金融交易)的东西，那么您可能会最先重视一致性。尝试选择最适合您要权衡的技术。
5.模式或数据模型
关系数据库以固定和预定义的结构存储数据。这意味着当您开始开发时，您将不得不根据表和列来定义数据模式。每次需求更改时，您都必须更改架构。这将导致创建新列，定义新关系，反映应用程序中的更改，与数据库管理员进行讨论等。
NoSQL数据库在处理数据时提供了更大的灵活性。无需指定架构即可开始使用该应用程序。另外，NoSQL数据库对可以存储在一起的数据类型没有限制。它允许您随着需求的变化添加更多的新类型。在应用程序构建过程中，大多数开发人员都喜欢较高的编码速度和较大的敏捷性。在这方面，NoSQL数据库被证明是更好的选择，特别是对于需要快速实现的敏捷开发。
您确实需要照顾所有提到的5点，但最重要的是，最重要的建议是使所有内容保持简单。不要仅仅因为市场上有光泽和新潮而选择数据库。如果您不需要设置高度复杂的NoSQL集群或需要大量维护的项目(例如MongoDB或HBase)，那么您无需维护就可以使用所有这些外部服务器来维护配置。考虑一下系统所需的最低要求。如果您不需要处理大规模的数据，那么就不需要使用NoSQL数据库，您可以选择MySQL，这样就可以了。除非您确实需要，否则没有必要在您的组织内部署没有良好专业知识的全新系统。简单的技术和简单的体系结构将易于维护。毕竟，当您在凌晨3:00醒来时，您不会感到高兴，这是因为在没有充分理由的情况下，随机服务器在这个过于复杂的数据库系统上崩溃了。因此，请尽可能使一切简单。