NoSQL 也称为“not only SQL”或“non-SQL”，它是一种数据库设计方法，可以在关系数据库中的传统结构之外存储和查询数据。
虽然 NoSQL 仍然可以存储关系数据库管理系统 (RDBMS) 中的数据，但与 RDBMS 相比，数据存储方式有所不同。决定使用关系数据库还是非关系数据库在很大程度上取决于上下文，并且因用例而异。
NoSQL 数据库并非采用关系数据库的典型表结构，而是将数据存储在一个数据结构中，例如 JSON 文档。由于这种非关系数据库设计不需要使用架构，因此，它提供快速可扩展性以管理通常为非结构化的大型数据集。
NoSQL 也是一种分布式数据库类型，这意味着将信息复制并存储在不同的服务器上，这些服务器可能是远程服务器或本地服务器。这确保了数据的可用性和可靠性。如果一些数据脱机，数据库的其他部分可以继续运行。
如今，几乎各个行业的公司都需要高速管理大量数据，并能够快速扩展以运行现代 Web 应用程序。在这个云、大数据以及移动和 Web 应用程序不断发展的时代，NoSQL 数据库提供了这样的速度和可扩展性，使其因卓越的性能和易用性而备受青睐。
NoSQL 通常与结构化查询语言 (SQL) 相对。为了更好地理解 NoSQL 和 SQL 之间的区别，了解 SQL（用于从数据库中检索特定信息的编程语言）的发展历史可能会有所帮助。
在关系数据库出现之前，公司使用具有树状数据表结构的分层数据库系统。这些早期的数据库管理系统 (DBMS) 使用户能够组织大量的数据。然而，这些系统非常复杂，通常是特定应用程序专有的，并且挖掘数据中的信息的方法也受到限制。这些限制最终导致开发了关系数据库管理系统，这些系统将数据以表形式进行排列。SQL 提供一个与关系数据进行交互的接口，从而允许分析师合并通用字段以连接表。
随着时间的推移，对于电子商务应用程序等新兴技术而言，更快并更分散地使用大型数据集的要求变得越来越重要。程序员需要使用比 SQL 数据库（即关系数据库）更灵活的数据库。NoSQL 成为了这种替代方案。
虽然 NoSQL 提供了 SQL 的替代方案，但这一进步绝不会取代 SQL 数据库。例如，假设您在一家公司管理零售订单。在关系模型中，各个表分别管理客户数据、订单数据和产品数据，它们通过唯一的通用键（例如客户 ID 或订单 ID）联接在一起。虽然这对快速存储和检索数据非常有用，但需要使用大量的内存。当您要添加更多内存时，SQL 数据库只能垂直扩展，而不能水平扩展，这意味着您能否添加更多内存受限于您拥有的硬件。结果是，垂直扩展最终会限制公司的数据存储和检索。
相比之下，NoSQL 数据库是非关系型的，从而不再需要连接表。借助内置的分片和高可用性功能，这种数据库可以轻松进行水平扩展。如果单个数据库服务器不足以存储所有数据或处理所有查询，则可以将工作负载拆分到两个或多个服务器上，从而允许公司水平扩展数据。
虽然每种类型的数据库具有自己的优势，但公司通常在单个应用程序中同时使用 NoSQL 数据库和关系数据库。当今的云供应商可以支持 SQL 数据库或 NoSQL 数据库。选择哪个数据库取决于您的目标。
要更深入地了解这两个选项之间的区别，请参阅“SQL 数据库与 NoSQL 数据库：有什么区别？”。
了解生成式 AI 的主要优势，以及组织如何将生成式 AI 和机器学习融入到业务中。
在 Presto 上注册以获取电子书
NoSQL 提供了其他选项以使用多种方式组织数据。通过提供多样化的数据结构，NoSQL 可以应用于数据分析、大数据管理、社交网络以及移动应用程序开发。
NoSQL 数据库使用任何以下主要数据模型管理信息：
键值存储
这通常被认为是最简单形式的 NoSQL 数据库。这种无架构数据模型被组织成一个键值对字典，其中的每一项具有键和值。键可能与 SQL 数据库中的键类似（例如，购物车 ID），而值是一个数据数组（例如，该用户的购物车中的每件物品）。该模型通常用于缓存和存储用户会话信息，例如购物车。不过，在您需要一次提取多条记录时，该模型不太理想。Redis 和 Memcached 是开源键值数据库示例。
文档存储
顾名思义，文档数据库将数据存储为文档。它们可以帮助管理半结构化数据，通常以 JSON、XML 或 BSON 格式存储数据。在应用程序中使用数据时，这会将数据放在一起，从而减少使用数据所需的转换工作量。开发人员还获得了更大的灵活性，因为不需要在文档之间匹配数据架构（例如 name 与 first_name）。然而，对于复杂事务来说，这可能会造成问题，从而导致数据损坏。文档数据库的常见用例包括内容管理系统和用户档案。一个面向文档的数据库示例是 MongoDB，它是 MEAN 堆栈的数据库组件。
想要进一步了解 MongoBD 吗？查看有关 IBM Cloud Databases for MongoDB 使用入门的 IBM 教程。
宽列存储
这些数据库将信息存储在列中，使用户能够仅访问他们所需的特定列，而不会为不相关的数据分配额外的内存。该数据库试图弥补键值存储和文档存储的不足之处，但由于它可能是更复杂的系统而难以管理，建议较新的团队和项目不要使用该数据库。Apache HBase 和 Apache Cassandra 是开源宽列数据库示例。Apache HBase 建立在 Hadoop 分布式文件系统之上，它提供一种存储稀疏数据集的方法，并广泛用于许多大数据应用程序。另一方面，Apache Cassandra 旨在管理跨多个服务器和涵盖多个数据中心的集群的大量数据。它已用于各种用例，例如社交网络网站和实时数据分析。
图形存储
这种类型的数据库通常存储来自知识图谱的数据。数据元素以节点、边缘和属性的形式存储。任何对象、地点或人物都可能是节点。边缘定义节点之间的关系。例如，节点可能是客户（如 IBM）和代理机构（如 Ogilvy）。边缘是将关系归类为 IBM 与 Ogilvy 之间的客户关系。
图形数据库用于存储和管理图形中的元素之间的连接网络。Neo4j（IBM 外部链接）是一种基于 Java 的图形数据库服务，具有开源社区版本（用户可以购买联机备份和高可用性扩展许可证）或包含备份和扩展的预打包许可版本。
内存存储
对于这种类型的数据库（如 IBM solidDB），数据存储在主内存中而不是磁盘上，这使数据访问速度比基于磁盘的传统数据库更快。
NoSQL 数据库示例
许多公司已开始采用 NoSQL。除了上述数据库以外，还有一些流行的 NoSQL 数据库：
- Apache CouchDB，这是一种基于 JSON 文档的开源数据库，它将 JavaScript 作为查询语言。
- Elasticsearch，这是一种基于文档的数据库，其中包含全文搜索引擎。
- Couchbase，这是一种键值和文档数据库，使开发人员能够为云、移动和边缘计算构建响应速度快且非常灵活的应用程序。
要了解有关数据库状态的更多信息，请参阅“数据库领域简介”。
每种类型的 NoSQL 数据库具有自己的优势，使其更适合特定的用例。然而，它们都为开发人员提供了以下优势，并搭建了为客户提供更好服务的框架，包括：
- 经济高效：维护高端商用 RDBMS 的成本很高。他们需要购买许可证，培训数据库管理员以及使用强大硬件进行垂直扩展。NoSQL 数据库允许您快速水平扩展，从而更好地分配资源以最大限度降低成本。
- 灵活性：能够水平扩展并且非常灵活的数据模型还意味着，NoSQL 数据库可以处理大量快速变化的数据，使其非常适合敏捷开发、快速迭代和频繁代码推送。
- 复制：NoSQL 复制功能在多个服务器之间复制和存储数据。这种复制提供了数据可靠性，从而确保停机期间的数据访问，并防止服务器脱机时丢失数据。
- 速度：NoSQL 为所有用户（开发人员、销售团队和客户）提供更快且更敏捷的存储和处理。由于具有较快的速度，还使 NoSQL 数据库通常更适合复杂的现代 Web 应用程序、电子商务网站或移动应用程序。
简而言之，NoSQL 数据库具有高性能、可用性和可扩展性。
您选择的 NoSQL 数据库的结构和类型取决于您的组织计划如何使用该数据库。以下是不同类型的 NoSQL 数据库的一些具体用途。
- 管理数据关系：管理复杂的数据聚合以及这些点之间的关系通常是使用基于图形的 NoSQL 数据库处理的。这包括推荐引擎、知识图谱、欺诈检测应用程序和社交网络，在这些应用场景中，人们使用不同的数据类型建立联系。
- 低延迟性能：游戏、家庭健身应用程序和广告技术都需要高吞吐量以进行实时数据管理。无论是市场竞价更新还是返回最相关的广告，这种基础设施都为消费者提供最大的价值。Web 应用程序需要使用内存中的 NoSQL 数据库以提供快速响应并应对使用高峰，而不会出现磁盘存储可能带来的延迟。
- 扩展和大数据量：无论是单日销售还是假日购物季，电子商务都要求能够应对巨大使用高峰。键值数据库经常用于电子商务应用程序，因为在流量较大时很容易扩展其简单结构。这种敏捷性对于游戏、广告技术和物联网 (IoT) 应用程序非常有价值。
大公司需要提供无延迟的服务并更快地扩展，这推动了微服务的发展，并促使公司研究将哪种类型的数据库用于不同的应用程序。
公司发现，对应用程序的每个组件使用单一关系数据库存在局限性，尤其是在特定组件具有更好的替代方案时。微服务是一个有吸引力的选项，部分原因是它们不再要求整个应用程序使用单一共享数据存储。相反，应用程序具有许多松散耦合且可独立部署的服务，每个服务具有自己的数据模型和数据库，并通过 API 网关或 iPaaS 进行集成。
在单个应用程序中使用多个数据库的模式（也被称为多语言持久性）有助于为 NoSQL 数据库的蓬勃发展创造市场空间。如今，开发人员可以将正确的数据库用于正确的微服务，而不是尝试让所有服务使用单一关系数据库。