分布式系统 Distributed Systems 第 13 讲 NoSQL Lecture 13 NoSQL 王晓阳、张 奇 复旦大学 计算机科学技术学院

目录 13.1 为什么使用NoSQL 13.2 数据模型 13.3 分布与一致性 13.4 实例 13.4.1 键值数据库 13.4.2 文档数据库 13.4.3 列族数据库 13.4.4 图数据库

13.1 为什么使用NoSQL

13.1 为什么使用NoSQL 从名字说开去 20世纪90年代末，Strozzi NoSQL项目 ASCII文件存储数据表 每个元组占一行，字段以制表符分隔 不以SQL为其查询语言 2009.6.11 Johan Oskarsson 在旧金山举办的一个Meetup Eric Evans 提出了使用 NoSQL Meetup 开源分布式的非关系型数据库 Voldemort, Cassandra, Dynomite, Hbase, Hypertable, Couch DB, MongoDB

13.1 为什么使用NoSQL “SQL” = 传统的 DBMS “NoSQL” = “No SQL” = 不使用传统 DBMS “No SQL”  Don’t use SQL language “NoSQL” = “Not Only SQL”

13.1 为什么使用NoSQL Database Management System (DBMS) provides…. 关系型数据库的价值 Database Management System (DBMS) provides…. … efficient, reliable, convenient, and safe multi-user storage of and access to massive amounts of persistent data.

13.1 为什么使用NoSQL 阻抗失协问题 关系模型和内存中的数据结构之间存在差异 关系模型把数据组织成“表”和“行” 关系型数据库不能包含嵌套记录或列表结构

13.1 为什么使用NoSQL 解决阻抗失协问题 内存数据------硬盘映射数据库 面向对象数据库 对象---关系映射框架（object-relational mapping framework）

13.1 为什么使用NoSQL “集成数据库” Integration Database 不同团队开发的多个应用程序，将数据存储在一个公共的数据库中 应用程序之间通讯由操作内容一致的持久数据完成 “应用数据库”Application Database 一个数据库只能由一个应用程序的代码访问 应用程序间交互用接口完成

13.1 为什么使用NoSQL 采用集成数据库模式，必须使用SQL交互，就必须使用关系型数据 库结构 采用应用数据库模式 可以使用包含嵌套、列表等格式数据结构 XML，JSON 内部数据库与外部通信服务解耦合

13.1 为什么使用NoSQL 随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网 站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经 显得力不从心 纵向扩展（Scale UP）---- 小型机 横向扩展（Scale Out）---- 集群 关系型数据库通常无法应用于集群 分片机制应用受限 许可费高

13.1 为什么使用NoSQL NoSQL主要特征 不使用SQL 通常是开源项目 大多数是为了在集群环境运行开发 不需要使用“模式” 数据模型与关系型数据库不同 不需要使用“模式”

13.2 数据模型

13.2 数据模型 数据模型----数据库组织数据的方式 关系型数据库 NoSQL 元模型（metamodel） 每张表包含若干行（元组） 每行包含相关实体，实体通过列来描述，行列交汇处有单一值 NoSQL 抛弃了原有的关系模型 四大类：键值、文档、列族、图 面向聚合（aggregate orientation）

13.2 数据模型 聚合 一组相关联的对象视为一个整体单元进行操作 与数据存储通信时也以聚合为单位 程序员通过聚合结构来操作数据

13.2 数据模型

13.2 数据模型

13.2 数据模型

13.2 数据模型 如何划分聚合边界没有标准答案 一次性访问客户全部订单 每次只处理一笔订单 关系型数据库中没有“聚合”这一概念-----“聚合无知”(aggregate- ignorant) 聚合的边界一般都很难划分 可以按照不同的方式来查看数据 聚合模型适用于集群环境 集群环境运行时，需要把采集数据时所需的节点数降至最小

13.2 数据模型 键值数据库 包含大量聚合 每个聚合中包含获取数据所用的key或ID 键值数据库聚合不透明 通过键值来搜索聚合内容

13.2 数据模型 文档数据库 包含大量聚合 每个聚合中包含获取数据所用的key或ID 定义了其允许的结构和数据类型 查询词可以基于文档内部结构

13.2 数据模型 键值数据库 加入metadata实现聚合间关联 用Solr实现搜索 文档数据库 将ID放入，用ID进行键值式搜索

13.2 数据模型 列族数据库 大部分数据库以行为单位存储数据 如果写入操作执行的少，需要一次读取若干行中的很多列 带有稀疏列的无模式表结构 “两级映射”（two-level map） 大部分数据库以行为单位存储数据 如果写入操作执行的少，需要一次读取若干行中的很多列 将所有行的某一组列（列族）作为基本数据存储单元效果很更好 Bigtable等数据库都是采用一组列来存储

13.2 数据模型 可以列族模型其视为两级聚合结构（two-level aggregate structure） 第一个键通常代表行标识符，可以用它来获取想要的聚合 “行聚合”（row aggregate）本身又是一个映射，其中包含一些更为详 细的值 这些“二级值”（second-level value）就叫做“列” 可以操作特定的列 get(‘1234’,‘name’)

13.2 数据模型 列族数据库将列组织为列族，每一列必须是列族的一部分 两种数据组织方式 面向行（row-oriented）：每一行都是一个聚合（例如ID为1234的顾客就 是一个聚合），该聚合内部存有一些包含有用数据块（客户信息、订单 记录）的列族。 面向列（column-oriented）：每个列族都定义了一种记录类型（例如客 户信息），其中每行都表示一条记录。可以将数据库中的大“行”理解 为列族中每一个短行记录的串接。

13.2 数据模型 数据库通过这些数据分组方式，可在存储及访问时利用此信息。 即使文档数据库声明了某种结构，每个文档也依然被视作独立单元。 “列族”体现了“列族数据库”二维映射这一特点。 以上术语由BigTable和Hbase使用 Cassandra处理方式略有不同 “行”只能出现在一个列族中 列可以进行嵌套

13.2 数据模型 关系 聚合的有用之处在于可以把经常访问的数据存放在一起 例子： 大部分数据库都提供描述这种关系的手段 一些程序访问客户数据时想要随时访问其订单历史 客户和其所有订单放在一个聚合中 另外一些程序想要分布处理订单 订单存放在单独的聚合中 客户和订单放在两个聚合中，他们之间通过客户ID建立关联 大部分数据库都提供描述这种关系的手段 面向聚合数据库获取数据时以聚合为单元 只保证单一聚合内部内容的原子性，如果一次更新多个聚合，需要应对中途发生的错误

13.2 数据模型 图数据库（Graph Database） 处理相互间关系复杂的一小组记录

13.2 数据模型 图数据库（Graph Database） 基本数据模型：边连接而成的若干节点 属性 针对图专门设计的查询操作 FlockDB之存储节点与边 Neo4J采用无模式的方式将Java对象作为属性，附加到节点和边中 InfiniteGraph将Java对象作为其内建类型的子类对象，存储成节点和边 针对图专门设计的查询操作 大部分操作是沿着网络的边来浏览数据库

13.2 数据模型 无模式数据库 在关系数据中存储数据要先定义模式 NoSQL数据库的数据存储就比较随意 哪些表格，哪些列 键值数据库可以把任何数据存放在一个“键”名下 文档数据库对文档结构没有限制 列族数据库任意列都可以随意存放数据 图数据库中可以新增边，向节点和边添加属性

13.2 数据模型 无模式数据库 更容易处理“格式不一致的数据” 数据访问程序依赖于隐含模式（implicit schema） 每条记录拥有不同字段集（set of field） 数据访问程序依赖于隐含模式（implicit schema） 把模式交由访问其数据的应用程序代码来处理 数据库互动封装为独立应用程序 不同应用程序划分出不同区域

13.2 数据模型 物化视图 “视图” 展示数据的角度与数据库存储的方式有所不同 通过基础表计算得来的关系表 某些视图需要大量时间计算 预先算好并缓存在磁盘上的视图 读取频繁 不介意略有陈旧

13.2 数据模型 物化视图 通常NoSQL数据没有视图，但是可以预先计算查询操作结果，并将 其缓存 构建方法 一旦基础数据更新，立即更新物化视图 定期批处理操作

13.3 分布与一致性

13.3 分布与一致性 分布式是NoSQL的主要特点 数据分布两条途径 复制与分片是“正交的”技术 复制 replication 分片 sharding 复制与分片是“正交的”技术

13.3 分布与一致性 分片 不同用户需要访问数据集中在不同部分

13.3 分布与一致性 分片 要达到理想情况，必须保证需要同时访问的那些数据存在同一节点 “自动分片”Auto-sharding 理想情况下不同服务器节点服务于不同用户 每位用户只需与一台服务器通信 要达到理想情况，必须保证需要同时访问的那些数据存在同一节点 怎么存放数据 负载均衡 “自动分片”Auto-sharding 分片对于提升性能尤其有用，同时提升读取和写入效率 对于改善“故障恢复能力”帮助并不大

13.3 分布与一致性 主从复制 在“主从式分布”中，我们要把数据复制到多个节点上 一个节点是主节点，其余节点是从节点 复制操作就是从主节点到从节点同步

13.3 分布与一致性 主从复制 优点 缺点 需要频繁读取数据集的情况下，主从复制有助于提升访问性能 可以增强“读取操作的故障恢复能力” 数据的不一致性

13.3 分布与一致性 对等复制 所有节点地位相同，都可以接受写入请求 丢失一个副本不影响整个数据库访问

13.3 分布与一致性 对等复制 数据的不一致问题 两个节点可以同时处理写入操作，造成写入冲突 协调机制协调写入操作 相互冲突的写入操作合并

13.3 分布与一致性 结合“分片”与复制技术 同时使用“主从复制”与“分片”

13.3 分布与一致性 结合“分片”与复制技术 同时使用“对等复制”与“分片”

13.3 分布与一致性 更新一致性 乐观方法 悲观方法 写冲突：两人在同一时刻更新同一条数据 服务器收到写入请求后，将其“序列化”，产生更新丢失问题 乐观方法 先让冲突发生，再检测冲突并对发生冲突的操作排序 版本控制 悲观方法 加锁

13.3 分布与一致性 读取一致性 更够保持更新一致性的数据库，未必能保证用户所提交的访问请求总能 得到内容一致的响应 读写冲突 更够保持更新一致性的数据库，未必能保证用户所提交的访问请求总能 得到内容一致的响应 Martin先修改Item，再修改运费 如果2在1和3之后，就没有问题 读写冲突

13.3 分布与一致性 逻辑一致性 面向聚合的数据库支持原子更新，但仅限于单一聚合内部 不同数据项放在一起，其含义符合逻辑 为了避免读写冲突，关系型数据库支持“事务” 面向聚合的数据库支持原子更新，但仅限于单一聚合内部 在执行影响多个聚合的更新操作时，会留下一段时间空档，存在不一致 风险的时间长度就叫“不一致窗口”inconsistency window

13.3 分布与一致性 复制一致性问题

13.3 分布与一致性 复制一致性 最终一致性 存在“不一致窗口”，不同人在同一时刻可能会看到不同的数据 照原样读出所写内容的一致性 要求从不同副本中读取的同一个数据项时，所得到值相同 最终一致性 最终更新还是会传播到全部节点 存在“不一致窗口”，不同人在同一时刻可能会看到不同的数据 照原样读出所写内容的一致性 执行完更新操作后，紧接着必须能看到更新之后的值 会话一致性 黏性会话 版本戳

13.3 分布与一致性 放宽“一致性”约束 单服务器关系型数据库，通过事务加强一致性 性能影响太大 CAP定理

13.3 分布与一致性 CAP定理 分区耐受性

13.3 分布与一致性 X Pramod Mumbai London Martin 对等式分布模型（一致性协调） 一致性 可用性 X

13.3 分布与一致性 X Pramod Mumbai London Martin 主从模式 一致性 可用性 X

13.3 分布与一致性 X Pramod Mumbai London Martin 对等式分布模型 一致性 可用性 X

13.3 分布与一致性 放宽“持久性”约束 大大提高响应请求的速度 一旦服务器发生故障，未写会磁盘的更新数据会丢失 如果数据大部分时间在内存中运行，更新操作直接写入内存 定期将数据变更写回磁盘 大大提高响应请求的速度 一旦服务器发生故障，未写会磁盘的更新数据会丢失

13.4 实例

13.4 实例-键值数据库 键值数据库是一张简单的哈希表（hash table） 所有数据库访问均通过主键（primary key）

13.4 实例-键值数据库 客户端根据键查询值，设置键所对应的值，从数据库删除键 “值”只是数据库存储的一块数据而已，不关心也无知道其中内容 应用程序负责理解所存数据含义 例子 Riak [Riak] Redis (often referred to as Data Structure server) [Redis] Memcached DB and its flavors [Memcached] Berkeley DB [Berkeley DB] HamsterDB (especially suited for embedded use) [HamsterDB] Amazon DynamoDB [Amazon’s Dynamo] (not open-source) Project Voldemort [Project Voldemort]

13.4 实例-键值数据库 储存的聚合可以是任何数据结构 Redis能够存储list，set，hash等 还包含range, diff, union, intersection Riak 把关键字放在bucket中

13.4 实例-键值数据库 键值数据库特性 一致性 单个键的操作具备“一致性” Riak 采用“最终一致性模型” 更新冲突解决 采纳新数据，拒绝旧数据 将冲突数据返回客户端 Riak在创建“存储区”时设置上述选项

13.4 实例-键值数据库 键值数据库特性 一致性 Riak在创建存储区时，还提供选项确保一致性 执行完写入操作后，只有当存放此数据的全部节点一致将其更新，才认 定该操作生效

13.4 实例-键值数据库 键值数据库特性 事务 不同类型的键值数据库提供“事务”规范也不同 一般来说无法保证写入操作的“一致性” 各数据库实现“事务”的方式各异 Riak采用“仲裁” 如果某个Riak集群的复制因子是5，而W值为3 写入数据时，必须有至少3个节点写入完成，数据库才认为操作执行完毕

13.4 实例-键值数据库 键值数据库特性 查询功能 如果不知道键值怎么办？ 键值查询 不提供根据“值列”的属性进行查询 某些键值数据库支持数值搜索 Riak Search支持以Lucene全文检索来查询数据

13.4 实例-键值数据库 Riak还提供HTTP协议接口

13.4 实例-键值数据库 可扩展性 大部分键值数据库都可用“分片”技术扩展 Riak N—存放键值对的副本节点数 W—顺利完成写入操作所需的最小节点数

13.4 实例-键值数据库 适用案例 不适用场合 存放会话信息 用户配置信息 购物车信息 数据间关系 含有多项操作的事务 查询数据 操作关键字集合

13.4 实例-文档数据库 文档是文档数据库中的主要概念 文档具备自述性 文档彼此相似，但是不必完全相同

13.4 实例-文档数据库 { "firstname": "Pramod", "citiesvisited": [ "Chicago", "London", "Pune", Bangalore" ], "addresses": [ { "state": "AK", "city": "DILLINGHAM", "type": "R" }, { "state": "MH", "city": "PUNE", "type": "R" } ], "lastcity": "Chicago" } { "firstname": "Martin", "likes": [ "Biking", "Photography" ], "lastcity": "Boston", "lastVisited": }

13.4 实例-文档数据库 文档的“数据模式”可以不同 关系型数据库中若某列没有数据，要将其留空 文档数据库的文档没有空属性，向文档中增加新元素时无需定义 常见文档数据库： MongoDB, CouchDB, Terrastore, OrientDB, RavenDB, Lotus Notes

13.4 实例-文档数据库 一致性 MongoDB数据库的“一致性”强度可以通过命令控制 提升w的值可以增强一致性，但是降低写入效率 db.runCommand({ getlasterror : 1 , w : "majority"}) 如果有三台服务器，至少2个节点执行完毕 提升w的值可以增强一致性，但是降低写入效率 可以增加“副本集”提高读取效率

13.4 实例-文档数据库 可用性 MongoDB通过“副本集”实现“复制”，提高可用性 副本集中至少有两个节点参与“异步主从式复制” 副本集内部选取主节点 所有请求都由主节点处理，数据会复制到从节点 若主节点故障，则副本集中剩余的节点就会在选取新的主节点

13.4 实例-文档数据库 data redundancy, automated failover, read scaling, server maintenance without downtime, and disaster recovery

13.4 实例-文档数据库 查询功能 各种文档数据库提供了不同的查询功能 CouchDB可通过视图查询实现复杂文档查询 文档数据库中可以查询文档中的数据 键值数据库必须根据关键字获取整个文档，再检视其内容 MongoDB支持JSON格式的查询语言

13.4 实例-文档数据库 Mongo查询 SQL：SELECT * FROM order db.order.find() SELECT * FROM order WHERE customerId = "883c2c5b4e5b“ db.order.find({"customerId":"883c2c5b4e5b"}) SELECT orderId,orderDate FROM order WHERE customerId = "883c2c5b4e5b“ db.order.find({customerId:"883c2c5b4e5b"},{orderId:1,orderDate:1}) SELECT * FROM customerOrder, orderItem, product WHERE customerOrder.orderId = orderItem.customerOrderId AND orderItem.productId = product.productId AND product.name LIKE '%Refactoring%‘ db.orders.find({"items.product.name":/Refactoring/})

13.4 实例-文档数据库 可扩展性 通过添加read slave，可以将读取操作引导到从节点 rs.add("mongod:27017");

13.4 实例-文档数据库 可扩展性 通过数据“分片”来扩展写入能力 分片操作根据特定字段来划分数据，数据要移动到不同的节点上 分片的关键字很重要

13.4 实例-文档数据库 适用案例 不适用场合 事件记录 内容管理系统及博客平台 网站分析和实时分析 电子商务应用程序 包含多项操作的复杂事务 查询持续变化的聚合结构

13.4 实例-列族数据库 关键字到值的映射，值分成多个列族 每个列族代表一张数据映射表（map of data） Cassandra, HBase, Hypertable, and Amazon SimpleDB

13.4 实例-列族数据库 列族数据库将数据存储在列族中 列族里的行则把许多列数据与本行的“行键（row key）”关联起来 列族把通常需要一并访问的相关数据分成组

13.4 实例-列族数据库 基本存储单元叫做“列” Cassandra的列由name-value pair组成 名字也充当关键字 每个键值对都占据一列 存有“时间戳”值 { name: "fullName", value: "Martin Fowler", timestamp: 12345667890 }

13.4 实例-列族数据库 行是列的集合 相似行构成的集合就是列族 列都附在某个关键字名下 //column family { //row "pramod-sadalage" : { firstName: "Pramod", lastName: "Sadalage", lastVisit: "2012/12/12" } //row "martin-fowler" : { firstName: "Martin", lastName: "Fowler", location: "Boston"

13.4 实例-列族数据库 列族数据库中的各行不一定具有完全相同的列 超列 super column 可以随时向其中某个行加入一列 列包含了一个由小列组成的映射表 { name: "book:978-0767905923", value: { author: "Mitch Albon", title: "Tuesdays with Morrie", isbn: "978-0767905923“ }

13.4 实例-列族数据库 超列组成的是超列族 Cassandra将列族放入键空间（keyspace） 键空间与RDBMS中“数据库”类似

13.4 实例-列族数据库 一致性 Cassandra收到请求后会先将写数据记录到“提交日志”，然后将其 写入内存里一个名为内存表的结构中 写入操作在写入“提交日志”及“内存表”后就算成功了 写入请求定期写入“SSTable”的结构中

13.4 实例-列族数据库 一致性 如果将一致性设置为ONE，并以此作为所有读取操作的默认值 当Cassandra收到读请求后，会返回第一个副本中的数据（即便其是陈旧 数据） 如果此数据陈旧，则启动“读取修复”过程，使后续读取操作结果最新 数据 适用于不关心数据是否陈旧，或是需要高效执行读取操作的任务

13.4 实例-列族数据库 一致性 如果最低的一致性执行写入操作，那么Cassandra只将其写入一个节 点的提交日志中，就会向客户端返回相应 如果此时某节点尚未将写入数据复制到其他节点前就出现了故障，那些 这些数据可能会丢失 适用于需要极高写入速度，并且不介意丢失某些数据的情况

13.4 实例-列族数据库 一致性 将读写一致性都设置为QUORUM 将读写一致性都设置为ALL 读取操作将在过半数的节点响应后，根据时间戳返回最新的列数据给客 户端，并且通过“读取修复”操作把最新数据复制到那些陈旧的副本中 写入操作要等待所写入数据传播到超过半数的节点后，才能结束其工作 并通知客户端 将读写一致性都设置为ALL 全部节点就必须相应读取或写入操作

13.4 实例-列族数据库 事务 可用性 Cassandra没有传统意义上的“事务” 写入操作在“行”级别是“原子的” （R+W）> N 公式 R 顺利执行读取操作所需获取的最小应答节点数 W顺利执行写入操作所需获取的最小节点数 N参与数据复制的节点数 N=3，W=2，R=2 N=3，W=1，R=2 N=3，W=2，R=1

13.4 实例-列族数据库 查询功能 Cassandra查询功能较弱，因此需要仔细设计数据模型 列族中插入数据后，每行中的数据都会按列名排序 基本查询 GET, SET, DEL SET Customer['mfowler']['city']='Boston'; SET Customer['mfowler']['name']='Martin Fowler'; SET Customer['mfowler']['web']='www.martinfowler.com'; GET Customer['mfowler']; GET Customer['mfowler']['web']; DEL Customer['mfowler']['city']; DEL Customer['mfowler']; CREATE COLUMN FAMILY Customer WITH comparator = UTF8Type AND key_validation_class=UTF8Type AND column_metadata = [ {column_name: city, validation_class: UTF8Type} {column_name: name, validation_class: UTF8Type} {column_name: web, validation_class: UTF8Type} ];

13.4 实例-列族数据库 高级查询与索引编订 Cassandra可以利用关键字之外的其他列当作索引 UPDATE COLUMN FAMILY Customer WITH comparator = UTF8Type AND column_metadata = [{column_name: city, validation_class: UTF8Type, index_type: KEYS}]; GET Customer WHERE city = 'Boston';

13.4 实例-列族数据库 Cassandra Query Language（CQL）

13.4 实例-列族数据库 适用案例 不适用情况 事件记录 内容管理和博客服务 计数器 限期使用 ACID事务 Time To Live （Cassandra自动删除） 不适用情况 ACID事务

13.4 实例-图数据库 Neo4J，Infinite Graph, OrientDB, FlockDB

13.4 实例-图数据库 图数据库遍历连接及关系非常快 节点间关系不在查询时计算，创建时已经持久化了 节点间可有多种不同的关系类型 遍历持久化之后的关系，要比每次查询时计算关系要快 节点间可有多种不同的关系类型 领域实体之间的关系 辅助关系：类别、路径、时间树

13.4 实例-图数据库 Neo4J 创建图 创建关系 图数据库中的大多数值来源于关系 关系不仅包含类型、起始节点和终止节点，还包含属性 Node martin = graphDb.createNode(); martin.setProperty("name", "Martin"); Node pramod = graphDb.createNode(); pramod.setProperty("name", "Pramod"); 创建关系 martin.createRelationshipTo(pramod, FRIEND); pramod.createRelationshipTo(martin, FRIEND); 图数据库中的大多数值来源于关系 关系不仅包含类型、起始节点和终止节点，还包含属性 例如：两人之间何时成为朋友，两点之间距离多远等

13.4 实例-图数据库

13.4 实例-图数据库 一致性 由于图数据操作互相连接的节点，大部分图数据库通常不支持把节点分 布在不同机器上 由于图数据操作互相连接的节点，大部分图数据库通常不支持把节点分 布在不同机器上 Infinite Graph可以部署于分布式集群 Neo4J完全兼容ACID事务数据库 仅支持replicated salve 图数据库通过事务保证一致性 不允许出现dangling relationship 删除节点前，必须先移除其上的关系

13.4 实例-图数据库 Neo4J是兼容ACID事务的数据库 修改节点或向现有节点新增关系前，必须先启动事务 读取操作可以不通过事务执行

13.4 实例-图数据库 可用性 Neo4J 自1.8版本起，支持Replicated Slave 从节点接收到写入请求后，会先将数据同步至当前主节点 其他从节点将逐渐获得更新数据 Infinite Graph和FlockDB支持分布式节点存储

13.4 实例-图数据库 查询功能 图数据库使用Gremlin查询语言 Gremlin是遍历图的领域特定语言 domain-specific language Neo4J 也可以使用 Cypher查询语言和Language Binding 可以用“索引服务”来编订节点属性、关系或边的属性索引 通过属性值进行查找 便利之前通常也会先查找索引

13.4 实例-图数据库 IndexManager为节点创建索引 创建新节点后，将其加入索引 检索名为Barbra的节点

13.4 实例-图数据库 获取Incoming和Outgoing关系 查询关系时，也可以按照方向过滤搜索结果

13.4 实例-图数据库 从指定起始点开始，以任意深度遍历图 Traverser 遍历时可指明关系类型是INCOMING、OUTGOING、BOTH 可以用BREADTH_FIRST或者DEPTH_FIRST为Order值

13.4 实例-图数据库 两点之间的最短或全部路径 Barbara和Jill之间的路径及其距离 Barbara和Jill之间的最短路径

13.4 实例-图数据库 可扩展性 分片技术 增加仅读从节点，改善数据库读取能力 领域特定知识在应用程序端分片 相关节点放在同一个服务器上，遍历图时会方便 增加仅读从节点，改善数据库读取能力 领域特定知识在应用程序端分片

13.4 实例-图数据库 适用案例 不适用场合 互联数据 安排运输路线、分派货物和基于位置的服务 推荐引擎 全图操作 更新所有节点中的某个属性