从性能到可编程性，正确的数据库至关重要。以下是指导您选择的12个关键问题。
选择“正确的”数据库通常对于应用程序的成功至关重要。与其考虑供应商的建议或因为已经碰巧已经拥有数据库而使用数据库，不如考虑数据存储的基本目的和要求。
在选择数据库时，这些是最重要的问题：
您希望在应用程序成熟时存储多少数据？
您希望在高峰负载下同时处理多少个用户？
您的应用程序需要什么可用性，可伸缩性，延迟，吞吐量和数据一致性？
您的数据库架构多久更改一次？
您的用户群体的地理分布是什么？
您的数据的自然“形状”是什么？
您的应用程序需要在线事务处理（OLTP），分析查询（OLAP）还是同时需要两者？
您期望生产中的读写比例是多少？
您需要地理查询和/或全文查询吗？
您首选的编程语言是什么？
你有预算吗？如果是这样，它将涵盖许可证和支持合同吗？
您的数据存储是否有法律限制？
让我们扩展这些问题及其含义。
您将存储多少数据？
如果您的估计数以GB或更少为单位，那么几乎所有数据库都可以处理您的数据，内存数据库是完全可行的。仍然有许多数据库选项可以处理TB级（数千GB）的数据。
如果您的答案以PB（百万兆字节）或更多为单位，那么只有少数几个数据库将为您提供满意的服务，并且您需要为大量数据存储成本做好准备，无论是内部存储的资本支出还是用于内部存储的运营支出云储存。在这种规模下，您可能需要分层存储，以便对“实时”数据的查询可以在内存中运行或针对本地SSD运行以提高速度，而完整数据集则位于旋转磁盘上以节省成本。
多少个同时用户？
估计来自许多同时用户的负载通常被视为服务器大小确定练习，仅在安装生产数据库之前完成。不幸的是，由于伸缩性问题，许多数据库无法处理成千上万个查询TB或PB数据的用户。
对于雇员使用的数据库，与使用公共数据库相比，估计同时用户要容易得多。对于后者，您可能需要选择扩展到多个服务器以应对意外或季节性负载。不幸的是，并非所有数据库都支持水平扩展，而没有费时的大表手动分片。
您的“灵活性”要求是什么？
在该类别中，我包括可用性，可伸缩性，延迟，吞吐量和数据一致性，尽管并非所有术语都以“ -ility”结尾。
可用性通常是事务数据库的关键标准。尽管并非每个应用程序都需要24/7运行，且可用性高达99.999％，但有些应用程序却需要。只要您在多个可用性区域中运行它们，一些云数据库就可以提供“五九”的可用性。通常，可以将本地数据库配置为在计划的维护时段之外实现高可用性，尤其是在您可以负担得起建立双活服务器对的情况下。
从历史上看，NoSQL数据库的可伸缩性（尤其是水平可伸缩性）比SQL数据库要好，但是一些SQL数据库正在追赶。动态可伸缩性在云中更容易实现。具有良好可伸缩性的数据库可以通过向上或向下扩展直到吞吐量足以满足负载的需求来处理许多同时用户。
延迟既指数据库的响应时间，又指应用程序的端到端响应时间。理想情况下，每个用户操作都将具有亚秒级的响应时间；这通常意味着需要数据库在100毫秒内对每个简单的事务做出响应。分析查询通常需要几秒钟或几分钟。应用程序可以通过在后台运行复杂的查询来保留响应时间。
OLTP数据库的吞吐量通常以每秒事务数来衡量。具有高吞吐量的数据库可以支持许多同时用户。
对于SQL数据库，数据一致性通常是“强”的，这意味着所有读取都将返回最新数据。对于NoSQL数据库，数据一致性可以从“最终”到“强”。最终的一致性提供了较低的延迟，但有读取陈旧数据的风险。
一致性是错误，网络分区和电源故障时有效性所需的ACID属性中的“ C”。ACID的四个属性是原子性，一致性，隔离性和耐久性。
您的数据库架构稳定吗？
如果您的数据库架构不太可能随着时间的推移发生显着变化，并且您希望大多数字段在记录之间保持一致的类型，那么SQL数据库将是您的理想选择。否则，NoSQL数据库（其中一些甚至不支持架构）可能对您的应用程序更好。但是也有例外。例如，Rockset允许SQL查询，而无需在其导入的数据上施加固定的架构或一致的类型。
用户的地理分布
当您的数据库用户遍布全球时，除非您在其区域中提供其他服务器，否则光速将为远程用户施加较低的数据库延迟限制。一些数据库允许分布式读写服务器。其他的则提供分布式只读服务器，所有写入都必须通过单个主服务器。地理分布使一致性和延迟之间的权衡更加困难。
大多数支持全局分布节点和强一致性的数据库都使用共识组来加快写入速度，而不会严重降低一致性，通常使用Paxos（Lamport，1990）或Raft（Ongaro和Ousterhout，2013）算法。最终一致的分布式NoSQL数据库通常使用非一致的点对点复制，当两个副本收到对同一记录的并发写入时，这可能导致冲突，通常通过启发式解决冲突。
数据形状
通常，SQL数据库将强类型的数据存储在具有行和列的矩形表中。他们依靠表之间已定义的关系，使用索引来加快所选查询的速度，并使用JOINS一次查询多个表。文档数据库通常存储弱类型的JSON，其中可能包含数组和嵌套文档。图形数据库要么存储顶点和边线，要么存储三元组或四元组。其他NoSQL数据库类别包括键值存储和列存储。
有时，数据的生成形状也可以用于分析；有时不是，并且有必要进行转换。有时，一种数据库是建立在另一种数据库上的。例如，键值存储几乎可以构成任何数据库的基础。
OLTP，OLAP或HTAP？
为了使上面的首字母缩略词无误，问题是您的应用程序是否需要数据库来进行事务处理，分析或两者兼而有之。需要快速的事务意味着快速的写入速度和最少的索引。需要分析意味着读取速度快并且索引很多。混合系统使用各种技巧来满足这两个要求，包括让主事务存储通过复制为辅助分析存储提供服务。
读写比
一些数据库的读取和查询速度更快，而其他数据库的写入和写入速度更快。您希望从应用程序中获得的读写混合是一个有用的数字，可以包含在数据库选择标准中，并且可以指导基准测试。索引类型的最佳选择在读取繁重的应用程序（通常是B树）和写入繁重的应用程序（通常是日志结构的合并树，也称为LSM树）之间有所不同。
地理空间索引和查询
如果您具有地理或几何数据，并且想要执行高效的查询以查找边界内的对象或位置的给定距离内的对象，则与典型关系数据相比，您需要的索引不同。R树通常是地理空间索引的首选，但是有十多种其他可能的地理空间索引数据结构。有几十个支持空间数据的数据库。大多数支持部分或全部开放地理空间联盟标准。
全文索引和查询
同样，对文本字段进行有效的全文搜索需要的索引要比关系或地理空间数据的索引不同。通常，您构建标记词的倒排列表索引并进行搜索以避免进行昂贵的表扫描。
首选编程语言
尽管大多数数据库都支持多种编程语言的API，但是应用程序中首选的编程语言有时会影响数据库的选择。例如，JSON是JavaScript的自然数据格式，因此您可能想要选择一个支持JavaScript应用程序的JSON数据类型的数据库。当您使用强类型的编程语言时，您可能想要选择一个强类型的数据库。
预算限制
数据库的价格从免费到非常昂贵。许多数据库既有免费版本又有付费版本，有时还提供不止一个级别的付费产品，例如，提供企业版和不同的服务响应时间。此外，云中的某些数据库可以按需付费。
如果选择免费的开放源数据库，则可能必须放弃供应商支持。只要您具有内部专业知识，那也可以。另一方面，让您的员工专注于应用程序，而将数据库管理和维护交给供应商或云提供商，可能会更有效率。
法律的限制
有关数据安全和隐私的法律很多。在欧盟，GDPR对隐私，数据保护和数据位置具有广泛的影响。在美国，HIPAA规定医疗信息，而GLBA规定金融机构处理客户私人信息的方式。在加利福尼亚州，新的CCPA增强了隐私权和消费者保护。
只要您遵循最佳实践，某些数据库就能以符合某些或所有这些法规的方式处理数据。其他数据库也存在缺陷，无论您多么小心，都很难将它们用于个人身份信息。
坦白地说，这是选择数据库时要考虑的一长串因素，可能比您更希望考虑的因素更多。但是，在您冒险将项目提交到事实证明数据库不足或过于昂贵的风险之前，尝试尽您所能来回答所有问题是值得的。
最后，开发这么多年我也总结了一套学习Java的资料与面试题，如果你在技术上面想提升自己的话，可以关注我，私信发送领取资料或者在评论区留下自己的联系方式，有时间记得帮我点下转发让跟多的人看到哦。
