数据库架构和用例 - 解释

市场上有 300 多个数据库，您如何确定哪个适合您的特定用例或技能组合？

我们在社交媒体和 dev.to 等平台上持续看到关于 SQL 与 NoSQL 以及其他数据库的争论。在大多数情况下，并非某个数据库比另一个更好，而是由于多种因素，某个数据库更适合特定的用例。

几个月前，我们的首席技术官 Kyle Bernhardy 主持了一场精彩的演讲，题为《深入探讨数据库架构》。您可以通过链接观看此演讲，但由于这是一个非常突出的讨论话题，我们认为总结一下可能会有所帮助。本文将概述数据库架构，包括每种架构的用例和优缺点。


让我们从选择数据库时的一般考虑因素开始。了解数据类型/结构、数据量、一致性、写入和读取频率、托管、成本、安全性和集成约束等内容非常重要。您对这些因素了解得越多，就越容易为您的项目选择合适的数据库。

您可能已经知道，通常有3 种数据库托管选项：

• 内部
  数据库完全由组织在其数据中心内运行的服务器上维护，
  控制力更强，但通常更昂贵且耗时

• 云托管
  服务器由云提供商维护，组织维护在机器上运行的数据库软件和操作系统，
  灵活扩展且无需服务器维护，但无法控制物理服务器和潜在的网络限制

• 数据库即服务 (DBaaS)
  数据库由服务提供商维护，组织仅需支付服务使用
  费 成本效益高且零维护，但存在数据管理和潜在的网络限制

现在来看看您一直在等待的部分——数据库架构。

关系数据库

我们将从最常用的开始。关系型 (SQL) 数据库（例如 Oracle、MySQL、PostgreSQL、Microsoft SQL Server 和 SQLite）将数据组织到包含列的表中，每个列都有指定的名称和数据类型。此外：

• 行由唯一属性或属性组标识，称为主键（通常是单列）
• 表之间的关系通过引用主键的外键来定义
• 严格执行模式（数据模型）
• 通过结构化查询语言（SQL）访问的数据
• 符合 ACID（原子性、一致性、隔离性和持久性）
• 触发器和存储过程等额外功能

关系数据库的优点在于，它采用成熟、广为人知且文档齐全的技术。SQL 标准定义明确，定义的约束能够确保数据完整性，避免数据重复，并且高度安全且符合 ACID 标准。然而，缺点在于，SQL 数据库无法处理非结构化或半结构化数据，其表不一定映射到对象，需要复杂的 ETL（提取、转换、加载）和维护，存在行锁定，而且某些产品（Oracle、SAP）的价格对于开发人员和一些组织来说难以承受。
注意：虽然一些 RDBMS 系统现在可以处理 JSON，但它们并非专门为此构建的。

关系数据库有几个很棒的用例；数据完整性绝对至关重要的情况（金融应用、国防和安全、私人健康信息）、高度结构化的数据以及内部流程的自动化。

接下来就是其他一切了……

关系数据库是当今生产环境中最常见的数据库，但它们的设计初衷并非为了满足现代应用程序的规模和敏捷性。大约 10 年前，NoSQL 运动应运而生，解决了这些问题，并彻底改变了数据库的格局。注意：

• NoSQL 并不意味着什么（非 SQL、非关系型 SQL、不仅仅是 SQL）
• 旨在解决结构、性能、数据量和可扩展性
• 关系数据库已经解决了许多此类问题

虽然数据库通常分为 SQL 和 NoSQL 两类，但 NoSQL 数据库却有很多复杂之处。让我们来深入了解一下。

键值存储

键值存储通常用作高级数据库的底层存储。例如，MongoDB 使用名为 WiredTiger 的键值存储作为其默认存储引擎。Redis、DynamoDB 和 Cosmos DB 等键值存储具有以下特点：

• 简单、基础且无模式
• 提供通过特定键检索任意数据的基本功能
• 值可以是任何东西：单个值、数组、对象、文件等。
• 数据库不评估其存储的数据
• 数据结构可以称为字典或哈希表

对于专业人士来说，键值存储提供快速、低复杂度的数据访问，灵活且能够快速且低成本地扩展。然而，它们的功能极其有限，无法处理复杂的结构或基于键以外的任何查询或搜索，随着数据模型的增长，其扩展性不佳，并且复杂的实现需要更多的编程开销。

键值存储的示例用例包括嵌入式系统、URL 缩短器、配置数据、Web 应用程序的应用程序变量和标志、状态信息以及由字典或哈希表示的数据。

文档存储

文档存储（例如 MongoDB、DynamoDB、Couchbase 和 Firebase）类似于键值存储，但值是一个文档。

• 通常文档格式为 JSON、BSON 或 XML 文档
• 无模式，无数据结构强制（文档可以不同）
• 通过 NoSQL（或专有语言）访问和修改数据
• 非常适合非结构化和半结构化数据
• 更容易开发

文档存储的优点包括灵活性和可扩展性、无模式、写入速度快，非常适合半结构化和非结构化数据，并且开发人员无需提前了解数据结构/数据结构可以随时间变化而无需停机。缺点是它们不符合 ACID 标准，仅限于文档内查询，关系/交叉引用未强制执行，搜索速度慢，无法在单个查询中连接文档/集合，缺乏数据库强制执行要求开发人员自律并对应用程序级别的强制执行保持警惕，并且通常会导致数据重复。

文档存储的主要用例是非结构化或半结构化数据、内容管理、快速原型设计和高流量数据的收集。

图形数据库

当关系或连接是首要任务时，图形数据库（例如 Neo4j、OrientDB 和 TitanDB）是理想的选择。

• 基于数学图论
• 将数据表示为相关节点、边和属性的网络
• 数据库将数据项存储在节点内，将关系存储在连接节点的边中
• 节点通过关系连接并根据标签分组
• 促进数据可视化和图形分析
• 每个节点包含自由格式的数据

图形数据库的优点在于，它拥有关系查询、遍历和跟踪的高级功能，并针对关联数据查询进行了优化，并且避免了行锁定。缺点在于，图形数据库对开发人员来说需要较长的上手时间，简单用例的开销较高，缺乏标准化，聚合查询性能较差，并且开发人员通常需要学习自定义查询语言。

图形数据库非常适合异构数据点分析、欺诈预防、高级企业运营、社交网络、支付系统和地理空间路由/可视化。

时间序列数据库

快到了！接下来是时间序列数据库，例如 InfluxDB、Kdb+ 和 Prometheus，它们是：

• 专注于随时间变化的数据集
• 高度注重写作
• 旨在处理持续的数据流
• 通常仅附加（摄取后不进行修改）
• 汇总/聚合/下采样功能可降低存档数据占用空间

积极的一面是，时间序列数据库专为处理随时间变化的线性数据而设计，能够处理高数据采集率，内置了专门用于处理基于时间的数据的功能、针对时间序列数组优化的模式以及批量删除功能。至于负面方面，时间序列数据库仅处理时间序列数据，不支持完整的 SQL，读取速度不如写入速度，没有事务功能，并且仅支持追加操作（未针对更新进行优化）。

时间序列数据库的主要用例是管理基础设施、物联网传感器收集以及日志监控和警报。

搜索引擎

最后但并非最不重要的是搜索引擎，例如 Elasticsearch、Splunk 和 Apache Solr，它们是：

• 专为非关系型、基于文档的数据构建
• 针对数据存储和快速检索进行安排和优化
• 索引各种来源的数据，包括：文件系统、内联网、文档管理系统、电子邮件和数据库

搜索引擎的优点包括专注于优化搜索、高度可扩展和无模式，并且提供高级搜索选项，例如全文搜索、建议和复杂的搜索操作。缺点是价格昂贵、耐用性低、安全性差、不支持事务、在搜索之外写入和检索数据的效率低，并且难以管理。

当搜索结果、日志、产品目录和博客是首要任务时，搜索引擎非常有用。

多模型考虑

需要注意的是，许多实际应用选择“多语言持久化”，即使用不同的数据存储技术来处理特定软件应用程序中不同的数据存储需求。许多数据库技术在单个软件中实现这一点，称为多模型或数据湖技术。这对于特定用例来说可能是理想的选择，但也存在固有风险，例如不稳定、数据不一致和损坏、成本高昂/资源密集，以及磁盘和内存上的数据复制。

多模型技术的一些示例如下：

• Hadoop：在多个数据库上运行的软件工具
• MongoDB：单一数据库软件平台中的多种数据存储选项
• PostgreSQL：面向行、面向列、键值和面向文档的数据存储选项

最后，作为一家数据库公司……

讨论一下 HarperDB 在其中扮演的角色或许很有意义。
仅仅为了强调这些数据库“类别”并非黑白分明，有些数据库甚至采用了“混合”方法，融合了多种方法论。HarperDB 并非单一类别，而是可以被视为具有 SQL 功能的结构化对象存储。它的特点包括：

• 内置 REST API
• NoSQL 和 SQL 操作（包括连接）
• 动态模式
• 高级发布-订阅数据复制
• 自助管理工作室
• 传统驱动程序/接口
• 自定义函数（无服务器、高度可定制的 API 端点，可与我们的 HarperDB Core 操作交互）

我们从零开始构建了HarperDB ，旨在扩展和融合 SQL、 NewSQL和 NoSQL 产品的最佳功能，因为我们认为某些用例可以通过其他解决方案更好地服务。我们相信，让开发人员能够选择合适的工具来完成工作，可以赋能开发人员并激发创新。我们认为 HarperDB 更适合一些场景，例如需要同时使用 NoSQL 和 SQL、快速应用程序开发、集成、边缘计算、分布式计算和实时运营分析。本质上，有了 HarperDB，SQL 与 NoSQL 之争就变得无关紧要了，因为您不再需要做出选择！

希望这篇数据库架构概述能帮助您找到适合您用例的数据库。如有任何问题或意见，请在下方回复 - 我们很乐意与您讨论！