大数据 标准库 应用库_如何为您的应用选择合适的数据库
大数据 标准库 应用库
选择“正确的”数据库通常对于应用程序的成功至关重要。 与考虑供应商的建议或因为已经碰巧已经拥有数据库而使用数据库相比，考虑数据存储的基本目的和需求很有用。
在选择数据库时，这些是最重要的问题：
- 您希望在应用程序成熟时存储多少数据？
- 您希望在高峰负载下同时处理多少个用户？
- 您的应用程序需要什么可用性，可伸缩性，延迟，吞吐量和数据一致性？
- 您的数据库架构多久更改一次？
- 您的用户群体的地理分布是什么？
- 您的数据的自然“形状”是什么？
- 您的应用程序需要在线事务处理（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 and 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-the-right-database-for-your-application.html
大数据 标准库 应用库