读图数据库实战笔记07高级数据建模技能

1. 高级数据建模技能

1.1. 大多数现实生存中的应用步伐（如推荐引擎或个性化应用步伐）所需的模型比社交网络示例的单极点、单边数据模型复杂得多
1.2. 三种高级数据建模技能

• 1.2.1. 使用通用标签提高性能
  
• 1.2.2. 将属性移动到边，以简化遍历
  
• 1.2.3. 对数据举行反规范化处理，以实现更高效的图遍历
  

2. 数据模型

2.1. 四步调

• 2.1.1. 定义问题
  
• 2.1.2. 创建概念数据模型
  
• 2.1.3. 创建逻辑数据模型
  
• 2.1.4. 测试模型
  

2.2. 将概念模型转换为逻辑模型的过程

• 2.2.1. 将实体转换为极点
  
• 2.2.2. 将关系转换为边
  
• 2.2.3. 为这些极点和边指定属性
  
• 2.2.4. 测试模型
  

2.3. 扩展逻辑数据模型

• 2.3.1. 只有一个极点和一条边的模型对于复杂的工作是不够的
  
• 2.3.2. 微观优化加起来就会显著地提高性能
  

2.4. 很少有应用步伐或用例只遍历单个实体和关系

• 2.4.1. 很多时间，需要遍历多种极点和边才气得到所需的结果
  
• 2.4.2. 为社交网络开发的寻路和递归遍历不需要遍历不同的实体范例，但这在复杂的领域中实际上是非常罕见的
  

2.5. 熟路

• 2.5.1. 在图论中，线路（walk）是由一系列边和极点构成的序列
  
• 2.5.2. 路径（path）是一种特别范例的线路，只包含不同的极点
  
• 2.5.3. 熟路（known path）是图应用步伐中的一种模式，在这种模式中，需要事先知道要遍历的极点和边的确切序列才气得到答案
  
• 2.5.4. 在寻路问题中，我们知道要遍历的极点和边的序列，但不知道遍历这些极点和边的次数
  
• 2.5.5. 在熟路问题中，我们知道要遍历的极点和边的序列以及需要遍历的次数
  
• 2.5.5.1. 既知道路径又知道该路径的重复次数，因此可以或许优化数据模型和遍历
  
• 2.5.5.2. 熟路优于递归遍历，因为熟路遍历图所需的操纵数是已知的
  
• 2.5.5.3. 通常会使熟路比迭代次数未知的递归遍历有更稳固的执行时间
  
• 2.5.6. 关于遍历深度的先验知识是区分寻路和熟路这两种模式的因素之一
  
• 2.5.6.1. 是否知道从开始极点到结束极点所需操纵（比方实体和关系）的确切定义？
  
• 2.5.6.2. 是否知道要得到结果所需的遍历次数？
  
• 2.5.6.3. 如果这两个问题的答案都是“是”​，那么这个遍历就是熟路
  

3. 将实体转换为极点

3.1. 使用通用标签

• 3.1.1. 极点或边上的标签紧张旨在为相似项构成的类别提供一个名称
  
• 3.1.2. 最佳实践通常是使用更通用的术语（如user或person）​，而不是使用具体的术语（如reviewer或restaurant_patron）​
  
• 3.1.3. 通用标签可以或许将相关的项分为一组，从而减少实体的范例，简化模型和遍历的编写
  
• 3.1.4. 有利于创建更高性能的遍历
  
• 3.1.5. 通用标签不仅允许将雷同的实体归入最广泛的类别，而且仍然可以或许区分它们
  
• 3.1.6. 所有的遍历都是功能性的
  
• 3.1.7. 通用数据标签使我们可以或许复用标签，通过对雷同的实体举行分组来简化遍历，从而创建性能更高、更可扩展的遍历
  

3.2. 为了实现更多功能（如在街道地图上渲染地点）和更高的复杂性，通常会使用地理空间坐标

• 3.2.1. 采取了将地理位置反规范化为属性的方法，而不是将地理数据作为单独的实体
  

3.3. 反规范化图数据

• 3.3.1. 图数据模型中的反规范化雷同于关系数据模型中的反规范化
  
• 3.3.2. 两者都在写入时将数据复制到多个位置，以提高读取时的性能
  
• 3.3.3. 缺点
  
• 3.3.3.1. 增加了磁盘使用量
  

1. >  3.3.3.1.1. 因为数据被写入多个位置，所以增加了存储数据所需的空间
3. >  3.3.3.1.2. 磁盘空间的成本已经不算什么问题了，但这些成本还是需要考虑的，特别是对于大型项目或易受成本影响的项目而言

复制代码

• 3.3.3.2. 数据同步问题
  

1. >  3.3.3.2.1. 当将数据写入多个位置时，一旦进行更改就必须对每个位置进行更新
3. >  3.3.3.2.2. 如果这些位置中的任何一个没有同步，那么不同的遍历可能会返回不同的结果

复制代码

• 3.3.3.3. 降低了写入性能
  

1. >  3.3.3.3.1. 因为必须在多个位置更新值，所以需要更多的写入操作
3. >  3.3.3.3.2. 写入放大（write amplification）​

复制代码

• 3.3.3.4. 反规范化不应该是办理性能问题的首选
  

1. >  3.3.3.4.1. 只有在进行了适当的数据建模和横向优化之后都未能达到预期性能时，才应该考虑使用反规范化

复制代码

• 3.3.4. 读取性能差通常是由于检索信息所需的操纵次数过多
  
• 3.3.4.1. 在所有范例的分布式系统中还会被放大，因为读取数据时除了访问内存和磁盘之外，还有额外的网络访问
  
• 3.3.5. 在图数据库中，反规范化只是为了减少从起始点到结束数据所需的遍历长度
  
• 3.3.6. 索引也是反规范化的一种形式，尽管我们并不总是如许以为
  
• 3.3.6.1. 无论使用哪种数据库引擎，只要添加了索引，就在使用一种反规范化形式
  
• 3.3.6.2. 数据库引擎针对索引专门设计的简单语法并不能改变如许一个究竟：索引是为了提高读取性能而对现有数据的复制
  
• 3.3.7. 通过预计算字段或重复数据来对数据举行反规范化，可以在遍历过程中更早地使用数据，从而降低遍历的复杂性
  
• 3.3.8. 预计算字段
  
• 3.3.8.1. 预计算字段是极点或边的属性，存储了写入时就计算出的结果，以便在读取时可以或许快速检索数据
  
• 3.3.8.2. 热门电影的检索时间比冷门电影的检索时间长
  

1. >  3.3.8.2.1. 这种类型的性能问题在图数据库中很常见，因为被连接最多的顶点通常是遍历中最常接触的顶点
3. >  3.3.8.2.2. 通过预先计算该值，根据watched_count查找答案的时间是恒定的，不管这部电影有多热门

复制代码

• 3.3.8.3. 随着时间的推移，数据库记录越来越多，但是预计算字段并不会受到影响
  
• 3.3.8.4. 当有聚合（sum、average和count）值并且执行遍历的频率明显高于更新极点的频率时，预计算字段是一个很好的选择
  
• 3.3.8.5. 当待计算字段的读取频率比写入频率高得多时，预计算字段是一个很好的选择
  
• 3.3.9. 使用重复数据
  
• 3.3.9.1. 将属性从一个极点或边复制到另一个极点或边
  
• 3.3.9.2. 将属性复制到图中的多个位置允许我们以保持数据同步为代价来优化多个不同的遍历路径
  
• 3.3.9.3. 重复数据（通过将数据写入多个位置）也是捐躯写入性能来优化读取性能的一个例子
  
• 3.3.9.4. 当有多个遍历模式并且需要通过移动遍历操纵之前的所需数据来优化它们时，将数据复制到图中的多个位置是一个很好的选择
  
• 3.3.9.5. 重复数据涉及将属性复制到图中的多个位置，以优化多个不同的遍历路径，但要以保持数据同步为代价
  
• 3.3.10. 在量化了应用步伐的性能之后，确定是否值得对数据反规范化是一件很容易的事变
  

3.4. 将关系转换为边

• 3.4.1. 需要决定每一类边的唯一性
  

3.5. 查找和分配属性

• 3.5.1. 随着模型的结构元素的就位，是时间开始添加属性了
  
• 3.5.2. 常见的方法是将属性从极点移到相邻边
  

3.6. 将属性移到边

• 3.6.1. 将属性从极点移动到相邻边，以减少遍历需要处理的步数
  
• 3.6.2. 越早筛选遍历，遍历的性能就越好
  
• 3.6.3. Neo4j和Amazon Neptune，已经优化了其底层数据模型，以在磁盘表现中把边信息配置在相关极点上。这意味着在这些系统中，将属性移边并不是一种优化
  
• 3.6.4. 这种单操纵优化在单个遍历器上看起来微不足道，但在运行多个遍历器时，它会带来巨大的性能提升
  
• 3.6.5. 这是提高整体遍历性能的最佳方法之一，就像关系数据库中，如果在join操纵之前筛选数据，那么性能就会提高
  
• 3.6.6. 将属性从极点移动到边可以减少遍历必须执行的操纵数来降低遍历的复杂性
  

3.7. 检查模型

• 3.7.1. 验证其构造
  

4. 比力结果

4.1. 极点和边的名称形成了人类可读的句子，并且实体之间的关系是可以明白的

• 4.1.1. 这是图数据建模的最大好处之一
  

4.2. 与关系数据模型不同，技能用户和非技能用户都可以明白图数据模型

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。