原生分布式图数据库
使用TigerGraph原生分布式图数据库
企业为何要使用原生分布式图数据库？
图数据库擅长解决有关大数据集内关系的复杂问题。但当数据量变得非常巨大，或问题需要深度关联分析，又或者必须实时提供答案时，大多数图数据库都会在性能和分析能力上碰壁。 这是因为前几代图数据库缺乏能满足当今速度和规模需求的技术和设计。有的不是以并行性或分布式数据库概念为核心构建的。有的则是在 NoSQL 存储之上创建图视图，虽然可以扩展到巨大的规模，但这一附加层使之丧失了巨大的潜在性能。
如果没有原生图设计，执行多步查询的代价会很高，因此许多 NoSQL 平台只能提供很高的读取性能，而不支持实时更新。原生分布式图可实现深度关联分析，加快数据加载速度以快速构建图，加快图算法执行速度 ，能够实时流式处理更新和插入，能够将实时分析与大规模离线数据处理统一起来，能够纵向扩展和横向扩展分布式应用。
基于键值数据库的分布式方案可行吗？
由于关系型数据库太慢太僵化，才掀起了 NoSQL 革命。大数据用户需要大容量、高速度地吸收各种不同结构化的数据，并以最少的麻烦横向扩展物理基础设施。键值存储作为最简单因而也是最快速的 NoSQL 架构应运而生。 键值数据库基本上是一个两列哈希表，每行有一个唯一键 (ID) 和一个与该键关联的值。搜索键域可以非常快速地返回单数据值，比关系型数据库快得多。键值存储也能很好地扩展到非常大型的数据集。
但在键值存储之上设计应用级图是一项代价高昂且复杂的工作，不会产生高性能的结果。虽然键值存储在单键值事务中表现优异，但它们缺少 ACID 特性以及图更新所需的复杂事务功能。因此，在键值存储之上构建图数据库会导致数据不一致、查询结果错误、多步查询速度缓慢而且部署成本高而且机制僵化。
TigerGraph为企业提供什么样的原生分布式图数据库？
. 原生分布式图
TigerGraph是彻头彻尾的图数据库。它的数据存储中有点、关联及其属性。市场上的某些图数据库产品实际上是在较一般化的 NoSQL 数据存储上打包而来。这种虚拟图战略在性能上受到双重打击。首先，从虚拟图操作转化为物理存储操作增加了工作量。其次，没有为图操作优化底层结构。此外，TigerGraph从一开始就是为支持横向扩 展而设计的。
. 存储紧凑，访问快速
存储数据值的编码格式可有效压缩数据。压缩系数因图结构和数据而异，但一般的压缩系数介于 2 倍到 10 倍 之间。压缩有两种优势 ：
- 第一，更大量的图数据可以放入内存和 CPU 缓存。这种压缩不仅减少内存占用量，还提高 CPU 缓存命中率，从而加快整体查询性能。
- 第二，减少巨大图用户的硬件成本。例如，压缩系数是2倍，那么一个组织可以将所有数据放到二台计算机中，而非四台。
. 并行和共享数据
当速度成为您的目标时，有两条基本路线可选 ：加快每项任务的执行速度，或一次完成多个任务。后一条路就是并行。TigerGraph 在竭力快速执行每项任务的同时，还擅长并行处理，TigerGraph图引擎使用多个工作线程遍历一个图，而且可利用多核 CPU 中的每个核。
. 自动划分
TigerGraph 能够将图数据自动划分到一个服务器集群中，并且仍然运行迅速。哈希索引不仅用于确定服务器内的数据位置，还用于确定哪个服务器。从给定点连出的所有关联都 储在同一服务器上。
. 分布式计算模式
TigerGraph 有一种分布式计算模式，可显著提升遍历大部分图的分析查询性能。在分布式查询模式下，要求所有服务器都参与查询；每个服务器的实际参与根据需求而定。当遍历路径从服务器 A 跨入服务器 B 时，将向服 务器 B 传递它需要知道的最少量信息。在服务器 B 已经得知整个查询请求后，便可以轻松地参与分工。
