从性能到可编程性，正确的数据库至关重要。以下是12个关键问题，可帮助你进行选择。
选择“正确的”数据库通常对于应用程序的成功至关重要。考虑到数据存储的基本目的和要求，与其采取供应商的建议，或因为已经碰巧而使用数据库，不如来点有用的。
在选择数据库时，这些是重要的问题：
- 你希望在应用程序成熟时存储多少数据？
- 你希望在高峰负载下同时处理多少个用户？
- 你的应用程序需要什么可用性，可伸缩性，延迟，吞吐量和数据一致性？
- 你的数据库架构多久更改一次？
- 你的用户群体的地理分布是什么？
- 你的数据的自然“形状”是什么？
- 你的应用程序需要在线事务处理（OLTP），分析查询（OLAP）还是同时需要两者？
- 你期望生产中的读写比例是多少？
- 你需要地理查询和/或全文查询吗？
- 你首选的编程语言是什么？
- 你有预算吗？如果是这样，它将涵盖许可和支持合同吗？
- 你的数据存储是否有法律限制？
让我们扩展一下这些问题及其含义。
将存储多少数据？
如果估算数据以GB计算或更少，那么几乎任何数据库都可以处理你的数据，内存数据库是完全可行的。仍然有许多数据库产品可以处理TB级的数据。
如果你的答案是PB（百万兆字节）或更多，那么只有少数几个数据库能为你服务，并且你需要为大量数据存储成本做好准备，无论是内部存储的资本支出，还是用于云储存运营支出。在这种规模下，你可能需要分层存储，以便对“实时”数据的查询可以在内存中运行，也可以针对本地SSD运行以提高速度，而完整的数据集则驻留在磁盘上以节省成本。
同时多少个用户？
估计来自多个同时用户的负载，通常被视为要在安装生产数据库之前进行的服务器大小调整工作。不幸的是，由于伸缩性问题，许多数据库无法处理成千上万个TB级或PB级查询请求。
对于雇员使用的数据库，与使用公共数据库相比，估计同时用户要容易得多。对于后者，可能需要选择扩展到多个服务器以应对意外或季节性负载。不幸的是，并非所有数据库都支持水平扩展，而没有耗时的大型表分片。
“灵活性”要求是什么？
在此类别中，包括可用性，可伸缩性，延迟，吞吐量和数据一致性。
可用性通常是事务数据库的关键标准。尽管并非每个应用程序都需要以99.999％的可用性运行7*24小时，但有些应用程序却需要。只要你在多个可用性区域中运行它们，一些云数据库就可以提供“五个九”的可用性。通常，可以将本地数据库配置为在计划的维护时段之外实现高可用性，尤其是在你可以负担得起建立双活服务的情况下。
从历史上看，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增强了隐私权和消费者保护。
只要遵循最佳实践，某些数据库就能以符合某些或所有这些法规的方式处理数据。其他数据库也存在缺陷，无论多么小心，都很难将其用于个人身份信息。
坦白地说，这是一长串选择数据库时要考虑的因素，可能比更希望考虑的因素更多。不过，在冒险将项目提交到事实证明数据库不足或过于昂贵的风险之前，尝试尽所能来回答所有问题是值得的。
原文链接：
https://www.infoworld.com/article/3452894/how-to-choose-a-database-for-your-application.html
