评估NoSQL数据库时的5大考虑事项


  • 管理員

    介绍

    关系数据库在大多数组织中具有长期的立场,并且有充分的理由。 关系数据库支持满足当前业务需求的现有应用程序; 它们得到广泛的工具生态系统的支持; 而且有大量的劳动力可以实施和维护这些系统。

    但是组织正逐渐考虑传统关系基础架构的替代方案,在某些情况下,动机是技术性的,例如需要处理新的、多结构化的数据类型或超出现有系统容量限制的规模;而在其他情况下,动机是寻找昂贵专有数据库的可行替代方案,包含软硬件;第三种动机是敏捷性或开发速度,因为公司希望更快适应市场并采用敏捷开发方法。

    这些动机适用于分析和运营应用,各公司正在将工作负载转移到Hadoop上进行批量分析工作,他们正在用新一类所谓的“NoSQL”或非关系数据库构建在线操作应用程序。

    开发团队在技术选择过程中发挥强大的影响力,这个社群往往会发现关系数据模型与其应用程序的需求并不完全一致。

    考虑:

    • 开发人员正在与应用程序一起创建新的、快速变化的数据类型,如结构化、半结构化、非结构化和多态数据,以及大量的数据类型。
    • 十二至十八个月的瀑布开发周期已经过去了,现在小团队开展敏捷冲刺、快速迭代,每周或每两周推出一些代码,甚至每天多次推出代码。
    • 曾经服务于有限观众的应用程序现在作为服务提供,必须一直开启,以便可以从许多不同的设备访问并在全球范围内扩展。
    • 现在企业正转向采用开源软件、商品服务器和云计算的横向扩展架构,而不是大型的单片服务器和存储基础架构。
    • 不同的一致性模型对于一致性和可用性方面的应用程序提出了不同的权衡考虑。
    • MongoDB的惯用驱动程序最大限度地减少了新开发人员的培训时间,并简化了应用程序开发。
    • 表达式查询语言和二级索引。 用户应该能够以复杂的方式访问和操作其数据,以支持运营和分析应用程序。 索引在提供有效的数据访问方面发挥着至关重要的作用,数据库本身支持索引,而不是在应用程序代码中维护。
    • 强一致性。 应用程序应该能够立即读取已写入数据库的内容。 以最终一致的模型为基础构建应用程序要复杂得多,即使对于最复杂的工程团队来说,也要为开发人员提供重要的工作。
    • 企业管理和集成。 数据库只是应用程序基础架构的一部分,需要无缝配合到企业IT堆栈中。 组织需要一个可以保护,监控,自动化并与现有技术基础架构,流程和员工(包括运营团队,DBA和数据工程师)相集成的数据库。
    • 灵活的数据模型。 NoSQL数据库的出现是为了解决我们看到的主导现代应用程序的数据需求。 无论文檔,图形,键值还是宽列,它们都提供了灵活的数据模型,可以轻松地存储和合并任何结构的数据,并允许动态修改架构,而不会造成停机或性能影响。
    • 可扩展性和性能。 NoSQL数据库都是专注于可伸缩性而构建的,因此它们都包含某种形式的分片或分区。 这使得数据库能够在部署在本地或云中的商用硬件上扩展,实现几乎无限制的增长,具有比关系数据库更高的吞吐量和更低的延迟。
    • 始终在线的全球部署。 NoSQL数据库专为持续可用的系统而设计,为全球用户提供一致的高质量体验。 它们旨在跨越多个节点运行,包括复制以自动同步跨服务器,机架和分散在不同地理位置的数据中心中的数据。

    与关系数据库相比,许多NoSQL系统共享几个关键特性,包括更灵活的数据模型、更高的可伸缩性和出色的性能。但是这些NoSQL数据库大部分也放弃了使关系数据库对于多代应用程序非常有用的基础 – 如表达式查询语言、二级索引和强一致性。 实际上,“NoSQL”这个术语通常被用作所有非关系数据库的一个总括类别,正如我们将看到的那样,这个术语太广泛而且定义松散,它往往忽略了NoSQL数据库为实现可扩展性、可伸缩性和性能所做的权衡。

    在本文中,我们希望能够帮助您浏览NoSQL和非关系数据库复杂且快速发展的领域,我们描述了组织应该用来评估这些数据库的五个关键维度,因为它们确定了应用程序及其业务的正确选择。

    数据模型

    数据模型是非关系数据库与关系数据库不同的主要地方,虽然有数十个非关系数据库,但它们主要分为以下三类:

    1.  文件模型

    关系数据库将数据存储在行和列中,而文檔数据库则将数据存储在文檔中,这些文档通常使用类似JSON(JavaScript对象表示法)的结构,这是开发人员普遍使用的格式。文档提供了一种直观和自然的方式来仿真与面向对象编程紧密结合的数据。每个文檔实际上都是一个对象,文檔包含一个或多个字段,其中每个字段都包含一个类型值,如字符串,日期,二进制或数组。每个记录及其相关数据通常一起存储在单个文档中,而不是在与外键相关联的多个列和表中分散记录。这简化了数据访问,并且在许多情况下,不需要昂贵的JOIN操作和复杂的多记录事务。

    在文文件数据库中,模式的概念是动态的:每个文档可以包含不同的字段,这种灵活性对建模非结构化和多态数据特别有用。它还使开发过程中更容易发展应用程序,例如添加新字段。另外,文檔数据库通常提供了开发人员对关系数据库期望的查询健壮性,具体而言,可以基于文档中任何字段的组合来查询数据。

    应用:由于数据模型的灵活性,在任何字段上查询的能力以及将文文件数据模型自然映像到现代编程语言中对象的能力,文档数据库是通用的,可用于各种应用程序。

    例如:MongoDB和CouchDB

    2.  图形模式

    图形数据库使用具有节点、边和属性的图形结构来表示数据,实质上,数据被建模为特定元素之间关系的网络,尽管图形模型可能与直觉相反并需要一些时间来理解,但它对于特定类型的查询可能很有用。它的主要吸引力在于它可以更容易地对应用程序中实体之间的关系进行建模和导航。

    应用:图表数据库适用于遍历关系是应用程序核心的情况,例如导航社交网络连接、网络拓扑或供应链。

    例如:Neo4j and Giraph

    3.  关键值和宽列模型

    从数据模型的角度来看,键值存储是非关系数据库的最基本类型。 数据库中的每个项目都以属性名称或密钥及其值存储,但是,这个价值对体系完全不透明,数据只能通过密钥查询。此模型对于表示多态和非结构化数据非常有用,因为数据库不会在键值对之间强制执行设置的模式。

    宽列商店或专栏商店使用稀疏的分布式多维排序地图来存储数据。 每个记录可以在存储的列数上有所不同。列可以分组在一起以便在列族中访问,或者列可以分布在多个列族中,数据由每列家族的主键来检索。

    应用:关键值存储和宽列存储对于只能通过单个键值查询数据的小组应用程序非常有用。这些系统的吸引力在于它们的性能和可扩展性,由于数据访问模式的简单性和数据本身的不透明性,可以高度优化这些系统。

    例如:Riak和Redis(Key-Value);HBase和Cassandra(Wide Column)

    结论

    • 这些数据模型都提供了架构灵活性。
    • 键值和宽列数据模型在系统中是不透明的,只有主键可以被查询。
    • 文文件数据模型具有最广泛的适用性。
    • 文文件数据模型是最自然和最有成效的,因为它直接映像到现代对象语言中的对象。
    • 宽列模型比关键值模型提供更多的粒度访问数据,但比文文件数据模型的灵活性要低。

    查询模型

    每个应用程序都有自己的查询要求,在某些情况下,拥有一个非常基本的查询模型是可以接受的,其中应用程序只能根据主键访问记录。 但是,对于大多数应用程序而言,基于每条记录中的几个不同值进行查询的能力非常重要,例如,存储有关客户数据的应用程序可能不仅需要查找特定客户,而且还需要按特定大小查找特定公司或客户,或者通过邮政编码或州查询客户销售额的总和。

    更新记录的应用程序也很常见,包括一个或多个单独的字段,为了满足这些要求,数据库需要能够基于二级索引来查询数据,在这些情况下,文檔数据库通常是最合适的解决方案。

    1.  文件数据库

    文檔数据库提供了查询文档中任何字段的功能。有些产品(如MongoDB)提供了一组丰富的索引选项,以优化各种查询,包括文本索引、地理空间索引、复合索引、稀疏索引、生存时间(TTL)索引、唯一索引等。此外,某些产品提供了分析数据的能力,而不需要将其复制到专用的分析或搜索引擎,例如,MongoDB提供了用于提供实时分析(按照SQL GROUP BY功能)的聚合框架以及用于其他类型的复杂分析,如本地MapReduce实现。为了更新数据,MongoDB提供了一个查找和修改方法,以便文档中的值可以在单个语句中更新到数据库,而不是进行多次往返。

    2.  图形数据库

    这些系统倾向于提供丰富的查询模型,可以查询简单和复杂的关系,以直接和间接推断系统中的数据。关系类型分析在这些系统中非常有效,而其他类型的分析可能不太理想,因此,图形数据库很少用于更通用的操作应用程序。

    为了尝试和驯服使用多种存储技术所带来的复杂性,业界正在朝着“多模式”数据库的概念发展,这样的设计基于在同一平台内呈现多个数据模型的前提,从而满足不同的应用需求,例如:MongoDB 3.4在数据库本地中引入了图形计算,支持横跨图、树和分层数据的高效遍历,以揭示模式并显示先前未识别的连接。

    3.  关键值和宽列数据库

    这些系统提供了仅基于单个或有限范围的主键来检索和更新数据的能力,为了查询其他值,鼓励用户构建和维护自己的索引,有些产品对二级索引提供有限的支持,但有几点需要注意,要在这些系统中执行更新,可能需要多次往返:首先查找记录,然后更新它,然后更新索引。在这些系统中,更新可以被实现为整个记录的完全重写,而不管单个属性是否已经改变或是整个记录。

    结论

    • 非关系数据库之间最大的区别在于有效查询数据的能力。
    • 文檔数据库提供了最丰富的查询功能,使他们能够处理各种各样的操作和实时分析应用程序。
    • 键值存储和宽列存储提供了一种访问数据的方法:通过主键。这可能很快,但它们提供的查询功能非常有限,并且可能会增加额外的开发成本和应用程序级别的要求,以支持除基本查询模式以外的任何内容。

    一致性模型

    为了实现可用性和可扩展性,大多数非关系系统通常会维护数据的多个副本,这些数据库可以对复制数据的一致性施加不同的保证,非关系数据库往往被分类为一致或最终一致。

    使用一致的系统,应用程序的写入会在随后的查询中立即显示;最终一致的系统写入不会立即可见。例如,当为产品目录中的产品库存量进行更新时,如果系统一致,则每个查询都将看到当前库存,因为应用程序会更新库存量,而对于最终一致的系统,在给定的时间查询,库存量可能不准确,但最终会变得准确。出于这个原因,对于最终一致的系统,应用程序代码往往有所不同,而不是通过采用当前库存和减去库存来更新库存,例如,鼓励开发人员发出明确设置库存级别的幂等查询。

    1.  一致的系统

    每个应用程序对数据一致性有不同要求。对于许多应用而言,数据必须始终保持一致,由于开发团队数十年来一直在与关系数据库保持一致的模式下工作,这种方法更加自然和熟悉。而在其他情况下,最终的一致性是系统可用性下所接受的灵活性。

    文檔数据库和图形数据库可以是一致的或最终一致的。MongoDB提供可调整一致性,默认情况下,数据是一致的,所有写入和读取访问数据的主要副本,作为一种选择,读取查询可针对次要副本发布,其中如果写入操作尚未与次要副本同步,则数据可能最终一致; 一致性选择在查询级别进行。

     

    2.  最终一致的系统

    最终一致的系统,有一段时间所有数据副本不同步。 对于历史档案等不经常更改的只读应用程序和数据存储区,这可能是可以接受的。 出于同样的原因,对于写入密集的用例来说,数据库捕获像日志这样的信息也是适当的,这些日志只能在稍后的时间点读取。 关键值和列存储通常最终一致。

    最终一致的系统必须能够适应个别记录中的冲突更新。 因为写入可以应用于任何数据副本,所以写入操作可能并且并不罕见。 像Riak这样的系统使用向量时钟算法来确定事件的顺序,并确保最近的操作在冲突情况下获胜。 其他系统如CouchDB保留所有冲突的值,并将解决冲突的责任推回给用户。 另一种方法,跟随Cassandra,就是假设最新的值是正确的。 由于这些原因,插入往往在最终一致的系统中表现良好,但更新和删除可能涉及权衡,从而使应用程序显着复杂化。

    结论

    •  大多数应用程序和开发团队都期望系统一致
    •  MongoDB提供了在查询级别定义的可调整一致性。
    • 最终一致的系统以读取,更新和删除更为复杂为代价提供了插入的一些优点,同时通过读取修复和压缩导致性能开销。

    本帖部分内容已隐藏,请登入并回覆,以查看隐藏内容!


登录后回复
 

与 萌阔论坛 的连接断开,我们正在尝试重连,请耐心等待