NoSQL数据建模技术

(8)键组合索引 Composite Key Index

Composite
key键组合是一个很常用的技艺,对此,当大家的数据库补助键排序时能取得大幅度的便宜。Composite
key组合键的拼凑成为第二排序字段可以让您构建出一种多维索引,这很像我们事先说过的 Dimensionality
Reduction降维技术。例如,我们需要存取用户总计。尽管我们需要按照不同的地面来统计用户的遍布情况,大家可以把Key设计成这样的格式 (State:City:UserID),这样一来,就使得我们得以因而State到City来按组遍历用户,特别是我们的NoSQL数据库匡助在key上按区查询(如:BigTable类的连串):

  1. SELECT Values WHERE state=”CA:*” 
  2. SELECT Values WHERE city=”CA:San Francisco*” 

Composite Key Index

**适用性:** BigTable 数据库。

(15)嵌套文档扁平化:有限的字段名Nested Documents Flattening:Numbered 菲尔德(Field)(Field) Names

寻找引擎基本上来说和扁平文档一同工作,如:每一个文档是一个扁平的字段和值的例表。这种数据模型的用来把作业实体映射到一个文本文档上,尽管你的事务实体有很复杂的内部结构,这说不定会变得很有挑衅。一个第一名的挑衅是把一个有层级的文档映映射出来。例如,文档中嵌套另一个文档。让大家看看上面的言传身教:

图片 1

Nested Documents Problem

上边的每一个事务实体代码一种简历。其包括了人名和一个技艺列表。我把这多少个层级文档映射成一个文本文档,一种办法是创建Skill和Level字段。那多少个模型可以透过技术恐怕等级来寻觅一个人,而上图标注的这样的重组查询则会破产。(陈皓注:因为分不清Excellent是否是Math如故Poetry上的)

在引用中的[4.6]付给了一种缓解方案。其为各样字段都标上数字 Skill_i 和 Level_i,这样就能够分离搜索每一个对(下图中应用了OR来遍历查找所有可能的字段):

图片 2

Nested Document Modeling using Numbered Field Names

如此的形式根本未曾扩张性,对于部分扑朔迷离的题材的话只会让代码复杂度和保障工作变大。

适用性:Search Engines全文检索

NoSQL Data Models

  • 最后用户一般更感兴趣于数据的集结突显,而不是分手的数码,这重大通过SQL来成功。
  • 咱俩无能为力透过人手工控制数据的并发性,完整性,一致性,或是数据类型校验这个东西的。这就是干什么SQL需要在作业,二维表结构(schema)和表面联合上做过多事。
  • Key-Value键值对存储是分外简单而强大的。下边的成百上千技巧基本上都是依照这些技能开首上扬的。但是,Key-Value有一个特别沉重的题材,那就是如果我们需要寻找一段范围内的key。(陈皓注:学过hash-table数据结构的人都应有理解,hash-table是非系列容器,其并不像数组,链接,队列那些有序容器,我们得以控制数据存储的次第)。于是,有序键值(Ordered
    Key-Value)数据模型被规划出来解决这一限制,来从根本上提升数据集的题材。
(9)键组合聚合 Aggregation with Composite Keys

Composite
keys键组合技术并不仅仅可以用来做索引,同样可以用来区分不用的连串的数目以支撑数据分组。考虑一个例子,大家有一个海量的日志数组,那些日志记录了互联网上的用户的拜访来源。我们需要统计从某一网站復苏的单身访客的多寡,在关系型数据库中,我们恐怕需要下边那样的SQL查询语句:

  1. SELECT count(distinct(user_id)) FROM clicks GROUP BY site  

我们可以在NoSQL中创造如下的数据模型:

图片 3

Counting Unique Users using Composite Keys

如此,大家就可以把数量按UserID来排序,我们就足以很容易把同一个用户的数码(一个用户并不会暴发太多的event)举行处理,去掉这么些重复的站点(使用hash
table或是其余什么)。另一个可选的技术是,我们能够对每一个用户建立一个数额实体,然后把其站点来源追加到那些数额实体中,当然,这样一来,数据的换代在性质比较之下会有肯定损失。

**适用性:** Ordered Key-Value Store 排序键值对数据库,
BigTable风格的数据库。

第一,大家需要专注的是SQL和关系型数据模型已存在了很长的时光,这种面向用户的自然性意味着:

要起来谈论数量建模技术,我们不得不或多或少地先系统地看一下NoSQL数据模型的成才的可行性,以此我们可以了一部分他们内在的交换。下图是NoSQL家族的进化图,我们得以观看如此的升华:Key-Value时代,BigTable时代,Document时代,全文检索时代,和Graph数据库时代:(陈皓注:注意图中SQL说的这句话,NoSQL再这样前进下去就是SQL了,哈哈。)

一边,SQL可以让软件应用程序在很多动静下不需要关注数据库的数额聚合,和数据完整性和行之有效举办支配。而假诺咱们去除了数量一致性,完整性这一个东西,会对性能和遍布存储有第一的拉扯。正因为这样,大家才有数据模型的上扬:

下边是本文:

NoSQL数据库通常被视作很多非效用性的地点,如,扩大性,性能和一致性的地点。这个NoSQL的特征在争鸣和推行中都正值被群众广泛地研商着,探讨的紧俏正是那一个和属性分布式相关的非效率性的东西,大家都晓得CAP
理论
被很好地利用于了NoSQL系统中(陈皓注:CAP即,一致性(Consistency),可用性(Availability),分区容忍性(Partition
tolerance),在分布式系统中,这六个因素最六只可以同时落实六个,而NoSQL一般放任的是一致性)。但在一面,NoSQL的数码建模技术却因为缺乏像关系型数据库这样的基础理论没有被世人很好地钻研。这篇小说从数据建模方面对NoSQL家族举办了相比较,并钻探多少个广大的数据建模技术。

(17) 图结构批处理 Batch Graph Processing

Graph
databases图数据库,如neo4j是一个独立的图数据库,尤其是利用一个结点来探究邻居结点,或是探索两个或少量结点前的涉及。然而处理大量的图数据是很没有效用的,因为图数据库的属性和增加性并不是其目的。分布式的图数据处理能够被MapReduce
和 Message Passing
pattern来拍卖。如:在自家前一篇的稿子中的这么些示例。那个办法可以让Key-Value
stores, Document databases和BigTable-style databases适合于处理大图。

小说来源:酷壳网

  • Ordered
    Key-Value有序键值
    模型也非凡有力,可是,其也从不对Value提供某种数据模型。通常来说,Value的模型可以由运用负责解析和存取。这种很不便利,于是出现了BigTable类型的数据库,这几个数据模型其实就是map里有map,map里再套map,一层一层套下去,也就是不可多得嵌套的key-
    value(value里又是一个key-value),这种数据库的Value重要通过“列族”(column
    families),列,和岁月截来控制版本。(陈皓注:关于时间截来对数码的版本控制首假设缓解多少存储并发问题,也就是所谓的乐观锁,详见《多版本出现控制(MVCC)在分布式系统中的应用》)
(11)树形聚合Tree Aggregation

树形或是任意的图(需反规格化)可以被直接打成一条记下或文档存放。

  • 当树形结构被一遍性取出时这会非凡有功效(如:我们需要出示一个blog的树形评论)
  • 搜索和其它存取那些实体都会存在问题。
  • 对于大多数NoSQL的落实的话,更新数据都是很不划算的(相相比起独立结点来说)

图片 4

Tree Aggregation

适用性:Key-Value键值对数据库,Document Databases文档数据库

NoSQL数据模型摘要

本文剩下的章节将向你介绍数据建模的技艺实现和血脉相通情势。可是,在介绍那些技术以前,先来一段序言:

  • NoSQL数据模型设计一般从事情应用的现实数量查询动手,而不是数量间的关联:
  • 关系型的数据模型基本上是分析数据间的构造和涉及。其设计理念是:
    What answers do I have?”
  • NoSQL数据模型基本上是从应用对数码的存取模式开首,如:我急需帮助某种数据查询。其设计理念是 ”What
    questions do I have?”
  • NoSQL数据模型设计比关系型数据库需要对数据结构和算法的更深的垂询。在这篇作品中我会和我们说那么些明明的数据结构,这一个数据结构并不只是被NoSQL使用,可是对于NoSQL的数据模型却特别有协助。
  • 数量冗余和反规格化是一等国民。
  • 关系型数据库对于拍卖层级数据和图式数据丰盛的不便于。NoSQL用来缓解图式数据分明是一个充裕好的化解方案,几乎所有的NoSQL数据库可以很强地解决此类问题。这就是怎么这篇作品专门拿出一章来表明层级数据模型。

上面是NoSQL的分类表,也是自己用来写这篇小说时做执行的出品:

  • Key-Value 存储: Oracle Coherence, Redis, Kyoto Cabinet
  • 类BigTable存储: Apache HBase, Apache Cassandra
  • 文档数据库: MongoDB, CouchDB
  • 全文索引: Apache Lucene, Apache Solr
  • 图数据库: neo4j, FlockDB
(7)索引表 Index Table

Index
Table索引表是一个相当直白的技艺,其得以你在不扶助索引的数据库中获取索引的补益。BigTable是这类最要紧的数据库。这亟需我们保安一个有对应存取形式的特别表。例如,我们有一个主表存着用户帐号,其得以被UserID存取。某询问需要查出某个城市里有着的用户,于是我们得以参与一张表,这张表用城市做主键,所有和那一个都市有关的UserID是其Value,如下所示:

图片 5

Index Table Example

看得出,城市索引表的需要和对主表用户表保持一致性,因而,主表的每一个翻新可能需要对索引表进行翻新,不然就是一个批处理更新。无论哪个情势,这都会损伤一些性能,因为需要保持一致性。

Index Table索引表可以被认为是关系型数据库中的视图的等价物。

适用性:BigTable数据库。

  • Graph data models图式数据库 可以被认为是以此发展过程中从Ordered
    Key-Value数据库发展过来的一个拨出。图式数据库允许构指出图结构的数据模型。它和文档数据库有关系的来由是,它的无数落实允许value可以是一个map或是一个document。
(4)原子聚合Atomic Aggregates

诸多NoSQL的数据库(并不是兼备)在事务处理上都是短板。在好几情况下,他们得以由此分布式锁技术恐怕应用层管理的MVCC技术来贯彻其事务性(陈皓注:可参看本站的“多版本出现控制(MVCC)在分布式系统中的应用”)但是,平常来说只可以拔取聚合Aggregates技术来担保一些ACID原则。

这就是怎么大家的关系型数据库需要有强大的事务处理机制——因为关系型数据库的数量是被规格化存放在了不同的地方。所以,Aggregates聚合允许我们把一个政工实体存成一个文档、存成一行,存成一个key-value,这样就可以原子式的翻新了:

图片 6

Atomic Aggregates

当然,原子聚合Atomic
Aggregates这种数据模型并无法兑现完全意义上的事务处理,然而假若帮忙原子性,锁,或test-and-set指令,那么,Atomic
Aggregates是足以适用的。

**适用性: **Key-Value Store键值对数据库,Document
Databases文档数据库,BigTable风格的数据库。

  • Document databases
    文档数据库
     立异了BigTable模型,并提供了五个有意义的改善。第一个是同意Value中有主观的情势(scheme),而不是map套map。第二个是索引。Full
    Text Search
    Engines全文检索引擎
    可以被看做是文档数据库的一个变种,他们得以提供灵活的可变的多少形式(scheme)以及机关索引。他们之间的不同点重假若,文档数据库用字段名做索引,而全文检索引擎用字段值做索引。
(1)反规格化Denormalization

反规格化Denormalization可以被认为是把相同的多寡拷贝到不同的文档或是表中,这样就足以简化和优化查询,或是正好吻合用户的某中特地的数据模型。这篇作品中所说的大多数技能都或多或少地导向了这一技巧。

完整来说,反规格化需要权衡下面这些东西:

  • 查询数据量
    /查询IO 
    VS 总和据量。使用反规格化,一方面可以把一条查询语句所需要的有所数据整合起来放到一个地点贮存。这意味,其余不同不同查询所需要的均等的数目,需要放在别不同的地点。因而,这暴发了众多冗余的数码,从而致使了数据量的叠加。

  • 处理千头万绪度 VS 总数据量.
    在适合范式的数额形式上实行表连接的询问,很彰着会扩大了询问处理的复杂度,尤其对于分布式系统来说更是。反规格化的数据模型允许我们以有利于查询的法子来存构造数据结构以简化查询复杂度。

适用性:Key-Value Store 键值对数据库,Document
Databases文档数据库,BigTable风格的数据库。

通用建模技术General Modeling Techniques

在本书中,我们将钻探NoSQL中各类不同的通用的数目建模技术。

图片 7

层级式模型Hierarchy Modeling Techniques

(14)嵌套集 Nested Sets

Nested
sets
嵌套集是树形结构的正统技术。它被普遍地用在了关系性数据库中,它完全地适用于Key-Value键值对数据库和Document
Databases文档数据库。这些技术的想法是把叶子结点存储成一个数组,并经过行使索引的发端和截止来映射每一个非叶子结点到一个叶子结点集,就如下图所示一样:

图片 8

Modeling of eCommerce Catalog using Nested Sets

这般的数据结构对于immutable
data不变的数额有十分不利的效用,因为其点内存空间小,并且可以飞速地找出装有的纸牌结点而不需要树的遍历。即便如此,在插入和翻新上急需很高的性能成本,因为新的叶子结点需要广大地立异索引。

适用性:Key-Value Stores键值数据库,Document Databases文档数据库

概念技术Conceptual Techniques

这一节关键介绍NoSQL数据模型的中坚规则。

(5)可枚举键Enumerable Keys

兴许,对于无顺序的Key-Value最大的好处是业务实体可以被容易地hash以分区在五个服务器上。而排序了的key会把工作搞复杂,不过多少时候,一个选用能从排序key中获取众多益处,就到底数据库本身不提供这多少个效应。让我们来想想下email音讯的数据模型:

  1. 有的NoSQL的数据库提供原子计数器以允许生一些连连的ID。在这种情状下,大家得以应用 userID_messageID 来做为一个重组key。若是大家领略最新的message
    ID,就可以通晓前一个message,也可能领悟再前边和前边的Message。
  2. Messages可以被包裹。比如,每一日的邮件包。这样,大家就可以对邮件按指定的年月段来遍历。

**适用性: **Key-Value Store键值对数据库

(13) Materialized Paths

Materialized
Paths可以援救制止递归遍历(如:树形结构)。这个技术也足以被认为是反规格化的一种变种。其想尽是为各种结点加上父结点或子结点的标识属性,这样就足以不需要遍历就知道所有的后代结点和祖先结点了:

图片 9

Materialized Paths for eShop Category Hierarchy

这一个技术对于全文检索引擎来说非凡有帮扶,因为其可以允许把一个层级结构转成一个文档。下面的示图中我们得以看出有着的货物或Men’s
Shoes
下的子分类可以被一条很短的查询语句处理——只需要给定个分类名。

Materialized
Paths可以储存一个ID的集合,或是一堆ID拼出的字符串。后者允许你通过一个正则表明式来查找一个一定的分段路径。下图展现了那么些技术(分支的不二法门不外乎了结点本身):

图片 10

Query Materialized Paths using RegExp

适用性:Key-Value键值对数据库,Document Databases文档数据,Search
Engines搜索引擎

(2)聚合Aggregates

怀有序列的NoSQL数据库都会提供灵活的Schema(数据结构,对数据格式的限量):

  • Key-Value Stores 和 Graph
    Databases基本上来说不会Value的形式,所以Value可以是任意格式。这样一来,那使得大家得以随心所欲组合一个业务实体的keys。比如,我们有一个用户帐号的工作实体,其得以被如下这一个key组合起来: UserID_name,UserID_email,
    UserID_messages
    等等。如果一个用户并未email或message,那么相应也不会有这般的记录。

  • BigTable模型通过列集合来扶助灵活的Schema,大家誉为列族(column
    family
    )。BigTable还足以在同样记录上冒出不同的版本(通过时间截)。

  • Document
    databases文档数据库是一种层级式的“去Schema”的贮存,尽管有点这样的数据库允许检验需要保留的数码是否满意某种Schema。

灵活的Schema允许你可以用一种嵌套式的中间数据格局来储存一组有涉及的作业实体(陈皓注:类似于JSON这样的数目封装格式)。这样可以为我们带来四个便宜。

  • 最小化“一对多”关系——可以通过嵌套式的法子来储存实体,那样可以少一些表联结。

  • 可以让里面技术上的数额存储更接近于事情实体,特别是这种混合式的事体实体。可能存于一个文档集或是一张表中。

下图表示了这二种利益。图中描给了电子商务中的商品模型(陈皓注:我记念我在“挑衅无处不在”一文中说到过电商中产品分类数据库设计的挑衅)

  • 率先,所有的商品Product都会有一个ID,普赖斯(Price)(Price)和Description。

  • 下一场,我们得以通晓不同的门类的货色会有两样的性能。比如,作者是书的性能,长度是紧身裤的性质。其些属性可能是“一对多”或是“多对多”的关系,如:唱片中的曲目。

  • 接下去,大家领悟,某些事情实体不能利用固定的项目。如:羊绒裤的性能并不是怀有的牌子都有些,而且,有些名牌还会搞非凡特别的习性。

对于关系型数据库来说,要统筹这样的数据模型并不简单,而且设计出来的绝对化离优雅很远很远。而我辈NoSQL中灵活的Schema允许你利用一个聚合Aggregate
(product) 可以建出所有不同类其它商品和他们的两样的习性:

图片 11

Entity Aggregation

上图中我们可以相比较关系型数据库和NoSQL的异样。只是我们可以看出在多少更新上,非规格化的数额存储在性能和一致性上会有很大的影响,这就是大家需要着重注意和不得不牺牲的地点

适用性: Key-Value Store键值对数据库,Document
Databases文档数据库,BigTable风格的数据库。

原文来自“NoSQL Data Modeling
Techniques
”,由酷壳网陈皓编译《NoSQL数据建模技术》。这篇著作看完未来,你恐怕会对NoSQL的数据结构会微微觉得。我的感觉到是,关系型数据库想把一致性,完整性,索引,CRUD都干好,NoSQL只干某一种事,可是牺牲了过多另外东西。总体来说,我觉着NoSQL更契合做Cache。

(16)嵌套文档扁平化:邻近查询 Nested Documents Flattening: Proximity Queries

在附录[4.6]中付出了那一个技能用来化解扁平层次文档。它用靠近的查询来限制可被询问的单词的限定。下图中,所有的技巧和级差被放在一个字段中,叫
SkillAndLevel,查询中冒出的“Excellent”和“Poetry”必需一个紧跟另一个:

图片 12

Nested Document Modeling using Proximity Queries

附录[4.3]中描述了这么些技能被用在Solr中的一个成功案例。

适用性:Search Engines全文检索

(6)降维Dimensionality Reduction

Dimensionality
Reduction降维是一种技术可以允许把一个多维的数目映射成一个Key-Value或是另外非多给的数据模型。

历史观的地理地点音讯序列使用部分如“四分树QuadTree”或“R-Tree”来做地理地方索引。那个数据结构的始末需要被在适龄的岗位更新,并且,假若数据量很大的话,操作成本会很高。另一个主意是我们可以遍历一个二维的数据结构并把其扁平化成一个列表。一个分明的例子是Geohash(地理哈希)。一个Geohash使用“之字形”的门道扫描一个2维的长空,而且遍历中的移动可以被概括地用0和1来表示其大方向,然后在活动的过程中暴发0/1串。下图展现了这一算法:(陈皓注:先把地图分成四份,经度为率先位,纬度为第二位,于是左侧的经度是0,左侧的是1,纬度也同等,下面是为1,下边的为0,这样,经纬度就足以组合成01,11,00,10这五个值,其标识了四块区域,大家得以这么不断的递归地对各样区域举行四分,然后可以取得一串1和0构成的字串,然后使用0-9,b-z去掉(去掉a,
i, l,
o)这32个假名举行base32编码得到一个8个长度的编码,那就是Geohash的算法)

图片 13

Geohash Index

Geohash的最精锐的功能是行使简易的位操作就足以领会五个区域间的相距,就像图中所示(陈皓:proximity框着的这五个,这一个很像IP地址了)。Geohash把一个二维的坐标生生地改成了一个一维的数据模型,这就是降维技术。BigTable的降维技术参考到随笔前边的[6.1]。更多的关于Geohash和另外技术可以参见[6.2]
和 [6.3]。

**适用性:** Key-Value Store键值对数据库,Document
Databases文档数据库,BigTable风格的数据库。

(12)邻接列表 Adjacency Lists

Adjacency
Lists邻接列表是一种图–每一个结点都是一个独立的记录,其包含了富有的父结点或子结点。这样,我们就足以经过给定的父或子结点来拓展查找。当然,大家需要经过hop查询遍历图。这么些技能在广度和深度查询,以及取得某个结点的子树上未曾效率。

适用性:Key-Value键值对数据库,Document Databases文档数据库

(10)反转搜索 Inverted Search – 直接聚合 Direct Aggregation

其一技能更多的是数量处理技术,而不是数码建模技术。虽然如此,这么些技能如故会影响数据模型。这么些技术最首要的想法是应用一个目录来找到满足某条件的数码,可是把数据聚合起需要接纳全文检索。如故让大家的话一个示范。依然用地点至极例子,大家有众多的日志,其中包括互联网用户和她俩的走访来源。让大家只要每条记下都有一个UserID,还有用户的体系 (Men,Women,Bloggers,等),以及用户所在的都会,和做客过的站点。我们要干的事是,为各样用户类别找到满意某些原则(访问源,所在城市,等)的的独门用户。

很显明,我们需要寻找那个满足条件的用户,假如我们应用反转搜索,这会让我们把这事干得很容易,如: {Category
-> [user IDs]}
 或 {Site -> [user
IDs]}
。使用这样的目录,我们能够取两个或四个UserID要的搅和或并集(那一个事很容易干,而且可以干得很快,假若那多少个UserID是排好序的)。可是,大家要按用户序列来生成报表会变得有些麻烦,因为我们用讲话可能会像下面这样

  1. SELECT count(distinct(user_id)) … GROUP BY category  

但如此的SQL很没有效用,因为category数据太多了。为了应对这些题目,大家可以建立一个间接索引 {UserID
-> [Categories]}
下一场大家用它来生成报表:

图片 14

Counting Unique Users using Inverse and Direct Indexes

最终,我们需要了然,对各种UserID的即兴询问是很没有效能的。大家得以通过批查询处理来解决这么些题材。这代表,对于有些用户集,我们可以展开预处理(不同的查询条件)。

适用性: Key-Value Store键值对数据库,Document
Databases文档数据库,BigTable风格的数据库。

(3)应用层联结Application Side Joins

表联结基本上不被NoSQL襄助。正如我们后边所说的,NoSQL是“面向问题”而不是“面向答案”的,不匡助表联结就是“面向问题”的结果。表的会合是在规划时被协会出来的,而不是在实施时建造出来的。所以,表联结在运作时是有很大支出的(陈皓注:搞过SQL表联结的都了然笛卡尔(Carl)积是怎么东西,大可以在参考从前酷壳的“图解数据库表Joins”),然而在应用了Denormalization和Aggregates技术后,我们着力不用举行表联结,如:你们使用嵌套式的数额实体。当然,如若您需要联合数据,你需要在应用层完成这么些事。上边是多少个重要的Use
Case:

  • 多对多的数目实体关系——通常需要被连续或合并。

  • 聚合Aggregates并不适用于数据字段平日被更改的情景。对此,我们需要把这些通常被改动的字段分到另外的表中,而在查询时我们需要统一数据。例如,大家有个Message系统可以有一个User实体,其包括了一个内嵌的Message实体。不过,假使用户不断在叠加message,那么,最好把message拆分到另一个单独的实体,但在查询时联结这User和Message这多少个实体。如下图:

适用性: Key-Value Store键值对数据库,Document
Databases文档数据库,BigTable风格的数据库,Graph Databases图数据库。

网站地图xml地图