编译：ImportNew/唐尤华
www.javaworld.com/article/3452894/how-to-choose-a-database-for-your-application.html
正确选择数据库至关重要。从性能到可编程性，下面12个关键问题可以帮助您正确选择
选择“正确的”数据库对于应用程序成功运作至关重要。不加思索采纳数据库提供商的方案，或者碰巧使用某个数据库都不可取。仔细考虑数据存储的基本目的和需求才是正途。
下面是选择数据库时需要考虑的最重要问题：
-
应用程序正常投用时存储的数据量有多大？
-
负载高峰时支持多少并发用户？
-
应用程序需要怎样的可用性、可扩展性、延迟、吞吐量和数据一致性？
-
数据库 schema 多久改一次？
-
用户的地理分布如何？
-
数据的自然“形态”是怎样的？
-
需要在线事务处理（OLTP）、分析查询（OLAP）还是都支持？
-
生产环境中预期读写比是多少？
-
需要查询地理信息或者全文检索吗？
-
首选编程语言是什么？
-
预算是怎样的？如果有预算，是否包含授权和合同费用？
-
存储数据是否有法律限制？
接下来会对每个问题展开讨论。
预计存储数据量？
如果数据规模不超过 GB，那么任何数据库都可以满足要求，还可以使用内存数据库。
规模达到 TB 时，也有许多数据库可供选择。
如果答案是 PB（百万兆字节）或者更多，那么仅剩下少数几个数据库可供选择。这种情况需要做好资金准备，无论本地存储还是云存储运营都需要资金。这种规模的数据量还需要分级存储，以便数据“实时”查询可以在内存或本地 SSD 中执行，加快查询速度。
完整数据则存到传统磁盘上，节省成本。
支持多少并发用户？
安装生产数据库前需要预估并发访问负载并进行相应调整。不幸的是，许多数据库由于自身伸缩性问题无法支持千上万个用户同时查询 TB 或 PB 规模的数据。
预估内部员工使用的数据库并发用户数要比公共数据库容易得多。对于后者，可能需要扩展多个服务器应对突发或季节性负载。并非所有数据库都支持水平扩展，而且对大数据表手工分片非常耗时。
对“灵活性”有哪些要求？
这里讨论的是可用性、可伸缩性、延迟、吞吐量和数据一致性。
可用性是事务数据库的关键指标。尽管并非每个应用都要求7x24小时99.999％可用，但有些应用程序的确如此。一些云数据库通过在多个区域同时运行，可以保证“5个9”可用性。如果能负担“双活”费用，本地数据库也可以实现非维护时段高可用。
过去，NoSQL 数据库的可伸缩性（尤其是水平可伸缩性）比SQL 数据库要好。现在一些 SQL 数据库正在迎头赶上。动态可伸缩性在云端更容易实现。伸缩性较好的数据库可以通过垂直或水平扩展让吞吐量满足大量用户并发的负载需求。
延迟包含数据库响应时间以及应用程序端到端响应时间。理想情况下，每个用户操作的响应时间为亚秒级。这意味着数据库会在100毫秒内对简单事务作出响应。分析查询通常可能需要几秒或几分钟。应用程序可以在后台执行复杂的查询节省响应时间。
OLTP 数据库的吞吐量通常按照每秒处理的事务数计算。高吞吐数据库可以支持许多并发用户。
SQL 数据库通常具有“强”一致性，这意味着每次读取都会返回最新数据。对于 NoSQL 数据库，数据一致性可以介于“最终一致性”和“强一致性”之间。最终一致性的延迟较低，但存在读取过时数据的风险。
一致性是 ACID 属性中的“C”，在发生错误、网络分区或电源故障需要的特性。ACID 指原子性、一致性、隔离性和耐久性。
数据库架构稳定吗？
如果数据库 schema 在未来不太可能发生大的变化，并且希望大多数字段类型保持一致，那么 SQL 数据库会是最理想的选择。其他情况，NoSQL 数据库（其中一些甚至不支持 schema）对应用程序可能更合适。但也有例外。例如，Rockset 支持 SQL 查询，然而不需要固定的 schema 或保持类型一致。
用户地理分布
当数据库用户遍布世界各地时，除非在用户所属区域中部署服务器，否则就要依赖光速为远程用户降低数据库延迟限制。一些数据库支持分布式读写服务器，其他则提供分布式只读服务器，即必须通过单个主服务器进行写入。地理位置分散使得在一致性和延迟之间找到平衡更加困难。
大多数支持全局分布节点并具备强一致性的数据库通常使用 Paxos（Lamport，1990）或 Raft （Ongaro and Ousterhout，2013）算法在加速写入的同时避免对一致性造成损害。具备最终一致性的分布式 NoSQL 数据库通常采用非一致点对点复制。当两个副本收到对同一记录的并发写入时，可能导致冲突。通常采用启发式解决此类冲突。
数据形态
SQL 数据库通常把强类型数据存储在由行和列组成的矩形表中。它们依赖表之间已定义的关系，使用索引来加快特定查询的速度，并且使用 JOINS 一次查询多张表。文档数据库通常存储弱类型 JSON，其内容可能包含数组和嵌套文档。图形数据库既可以存储顶点和边，也可以存储三元组或四元组。其它 NoSQL 数据库的形态包括键值存储和列存储。
有时候，生成的数据形态还可以用于分析，有时却不是。因此有必要进行转换。还有的时候，一种数据库建立在另一种数据库之上。例如，键值存储几乎可以作为任何数据库的基础。
OLTP、OLAP 还是 HTAP？
为了更好地澄清上面的缩写，这个问题指应用程序是否用数据库进行交易、分析或两者兼而有之。要求事务快速执行意味着快速写入和最少的索引。要求分析意味着快速读取快和大量索引。混合系统采用各种技巧满足这两种需求，包括让主事务存储通过复制提供辅助分析存储。
读写比
一些数据库读取和查询速度更快，而其他数据库写入速度更快。在数据库选择标准中，可以加入期望的应用读写比率指导基准测试。选择索引类型会根据使用场景有所不同。应用程序频繁读取通常使用 B 树，而需要频繁写入时通常选择日志结构的合并树，也称为 LSM 树。
地理空间索引和查询
如果存储内容包含地理或几何数据，并且希望执行有效的查询来查找边界内的对象或给定位置距离内的对象，则需要与典型关系数据不同的索引。R 树是地理空间索引的首选，但除此以外还有其他十多种地理空间索引数据结构。有几十个支持空间数据的数据库，大多数部分或完全支持开放地理空间联盟标准。
全文索引和查询
同样，对文本字段进行全文搜索需要的索引不同于关系数据或地理空间数据。通常，需要构建一个标记词的倒排列表索引，搜索时可以避免开销巨大的表扫描。
首选编程语言
尽管数据库大多提供了各种编程语言的 API，但是应用程序的首选编程语言有时会对选择数据库产生影响。例如，JSON 是 JavaScript 的自然数据格式，因此会希望选择一个支持 JavaScript 应用程序的 JSON 数据类型的数据库。使用强类型编程语言时，会希望选择一个强类型数据库。
预算限制
数据库的价格有免费，也可以非常贵。许多数据库有免费版本，也提供付费版本。有时候会提供不止一个级别的付费产品，例如企业版以及不同的服务响应时间。此外，某些数据库云服务可以按需付费。
如果选择免费的开源数据库，可能不得不放弃供应商支持。只要有相关的专业知识，也可以。另一方面，如果让员工专注于开发应用程序，把数据库管理和维护交给供应商或云提供商，可能更有效率。
法律限制
有关数据安全和隐私的法律很多。在欧盟， GDPR 对数据保护和数据存储地点有着广泛的影响。在美国，HIPAA 规定了医疗信息的处理方式，与之对应 GLBA 规定了金融机构处理客户私人信息的方式。在加利福尼亚州，新 CCPA 加强了对隐私权和消费者的保护。
只要遵循最佳实践，这些数据库就能用合乎法规的方式处理数据。无论多么小心，那些有缺陷数据库都很难用来保存个人身份信息。
坦白地说，以上是一长串选择数据库时要考虑的因素，比一般考虑的因素更多。不过，把项目冒着风险交给那些被证明无法满足要求或者过于昂贵的数据库之前，有必要尽最大努力回答上述问题。
补充： 对于国内环境来说，可能更得考虑政策问题~