原文:https://www.cnblogs.com/mantoudev/p/10414495.html
随着社交、电商、金融、零售、物联网等行业的快速发展,现实社会织起了了一张庞大而复杂的关系网,传统数据库很难处理关系运算。大数据行业需要处理的数据之间的关系随数据量呈几何级数增长,亟需一种支持海量复杂数据关系运算的数据库,
图数据库
应运而生。
世界上很多著名的公司都在使用图数据库。比如:
- 社交领域:Facebook, Twitter,Linkedin用它来管理社交关系,实现好友推荐
- 零售领域:eBay,沃尔玛使用它实现商品实时推荐,给买家更好的购物体验
- 金融领域:摩根大通,花旗和瑞银等银行在用图数据库做风控处理
- 汽车制造领域:沃尔沃,戴姆勒和丰田等顶级汽车制造商依靠图数据库推动创新制造解决方案
- 电信领域:Verizon, Orange和AT&T 等电信公司依靠图数据库来管理网络,控制访问并支持客户360
- 酒店领域:万豪和雅高酒店等顶级酒店公司依使用图数据库来管理复杂且快速变化的库存
既然图数据库应用这么广泛,越来越多的企业和开发者开始使用它,那它究竟什么过人之处呢,下面我们来揭开它的神秘面纱。
1. Why Graph DB?
学过数据结构这么课程的同学脑海中应该或多或少有ͼ
的概念。
图由两个元素组成:节点
和关系
。
每个节点代表一个实体(人,地,事物,类别或其他数据),每个关系代表两个节点的关联方式。这种通用结构可以对各种场景进行建模 - 从道路系统到设备网络,到人口的病史或由关系定义的任何其他事物。
图数据库(Graph database)
并非指存储图片的数据库,而是以ͼ
这种数据结构存储和查询数据。
图形数据库
是一种在线数据库管理系统,具有处理图形数据模型的创建,读取,更新和删除(CRUD)操作。
与其他数据库不同,关系
在图数据库中占首要地位。这意味着应用程序不必使用外键或带外处理(如MapReduce)来推断数据连接。
与关系数据库或其他NoSQL数据库相比,图数据库的数据模型也更加简单,更具表现力。
图形数据库是为与事务(OLTP)系统一起使用而构建的,并且在设计时考虑了事务完整性和操作可用性。
根据存储和处理模型不同,市面上图数据库也有一些区分。
比如:Neo4J
就是属于原生图数据库,它使用的后端存储是专门为Neo4J这种图数据库定制和优化的,理论上说能更有利于发挥图数据库的性能。
而JanusGraph
不是原生图数据库,而将数据存储在其他系统上,比如Hbase。
一些图数据库使用原生图存储
,这类存储是经过优化的,并且是专门为了存储和管理图而设计的。并不是所有图数据库都是使用原生图存储,也有一些图数据库将图数据序列化,然后保存到关系型数据库或者面向对象数据库,或其他通用数据存储中。
原生图处理(也称为无索引邻接
)是处理图数据的最有效方法,因为连接的节点在数据库中物理地指向彼此。非本机图处理使用其他方法来处理CRUD操作。
NoSQL数据库大致可以分为四类:
- 键值(key/value)数据库
- 列存储数据库
- 文档型数据库
- 图数据库
分类 | 数据模型 | 优势 | 劣势 | 举例 |
---|---|---|---|---|
键值数据库 | 哈希表 | 查找速度快 | 数据无结构化,通常只被当作字符串或者二进制数据 | Redis |
列存储数据库 | 列式数据存储 | 查找速度快;支持分布横向扩展;数据压缩率高 | 功能相对受限 | HBase |
文档型数据库 | 键值对扩展 | 数据结构要求不严格;表结构可变;不需要预先定义表结构 | 查询性能不高,缺乏统一的查询语法 | MongoDB |
图数据库 | 节点和关系组成的图 | 利用图结构相关算法(最短路径、节点度关系查找等) | 可能需要对整个图做计算,不利于图数据分布存储 | Neo4j、JanusGraph |
关系型数据库实际上是不擅长处理关系的。很多场景下,你的业务需求完全超出了当前的数据库架构。
举个栗子:假设某关系型数据库中有这么几张用户、订单、商品表:
当我们要查询:“用户购买了那些商品?” 或者 “该商品有哪些客户购买过?” 需要开发人员JOIN几张表,效率非常低下。
而“购买该产品的客户还购买了哪些商品?”类似的查询几乎不可能实现。
关系查询性能对比
在数据关系中心,图形数据库在查询速度方面非常高效,即使对于深度和复杂的查询也是如此。在《Neo4j in Action》这本书中,作者在关系型数据库
和图数据库(Neo4j)之间进行了实验。
他们的实验试图在一个社交网络里找到最大深度为5的朋友的朋友。他们的数据集包括100万人,每人约有50个朋友。实验结果如下:
深度 | MySQL执行时间(s) | Neo4J执行时间(s) | 返回记录数 |
---|---|---|---|
2 | 0.016 | 0.01 | ~2500 |
3 | 30.267 | 0.168 | ~110 000 |
4 | 1543.505 | 1.359 | ~600 000 |
5 | 未完成 | 2.132 | ~800 000 |
在深度为2时(即朋友的朋友),两种数据库性能相差不是很明显;深度为3时(即朋友的朋友的朋友),很明显,关系型数据库的响应时间30s,已经变得不可接受了;深度到4时,关系数据库需要近半个小时才能返回结果,使其无法应用于在线系统;深度到5时,关系型数据库已经无法完成查询。而对于图数据库Neo4J,深度从3到5,其响应时间均在3秒以内。
可以看出,对于图数据库来说,数据量越大,越复杂的关联查询,约有利于体现其优势。从深度为4/5的查询结果我们可以看出,图数据库返回了整个社交网络一半以上的人数。
根据DB-Engines最新发布的图数据库排名,Neo4J仍然大幅领先排在第一位:
Neo4J
Neo4J是由Java实现的开源图数据库。自2003年开始开发,直到2007年正式发布第一版,并托管于GitHub上。
Neo4J支持ACID,集群、备份和故障转移。目前Neo4J最新版本为3.5,分为社区版和企业版,社区版只支持单机部署,功能受限。企业版支持主从复制和读写分离,包含可视化管理工具。
JanusGraph
JanusGraph是一个Linux基金会下的开源分布式图数据库 。JanusGraph提供Apache2.0软件许可证。该项目由IBM、Google、Hortonworks支持。JanusGraph是由TitanDB 图数据库修改而来,TitanDB从2012年开始开发。目前最新版本为0.3.1。
JanusGraph支持多种储存后端(包括Apache Cassandra、Apache HBase、Bigtable、Berkeley DB)。JanusGraph的可扩展性取决于与JanusGraph一起使用的基础技术。例如,通过使用Apache Cassandra作为存储后端,可以将JanusGraph简单地扩展到多个数据中心。
JanusGraph通过与大数据平台(Apache Spark,Apache Giraph,Apache Hadoop)集成,支持全局图数据的分析、报告和ETL。
JanusGraph通过外部索引存储(Elasticsearch,Solr,Lucene)支持地理、数字范围和全文搜索。
- 节点是主要的数据元素
- 节点通过关系连接到其他节点
- 节点可以具有一个或多个属性(即,存储为键/值对的属性)
- 节点有一个或多个标签,用于描述其在图表中的作用
- 示例:人员节点与Car节点
- 关系连接两个节点
- 关系是方向性的
- 节点可以有多个甚至递归的关系
- 关系可以有一个或多个属性(即存储为键/值对的属性)
- 属性是命名值,其中名称(或键)是字符串
- 属性可以被索引和约束
- 可以从多个属性创建复合索引
- 标签用于将节点分组
- 一个节点可以具有多个标签
- 对标签进行索引以加速在图中查找节点
- 本机标签索引针对速度进行了优化
Cypher是Neo4j的图形查询语言,允许用户存储和检索图形数据库中的数据。
举例,我们要查找Joe的所以二度好友:
查询语句如下:
MATCH (person:Person)-[:KNOWS]-(friend:Person)-[:KNOWS]- (foaf:Person) WHERE person.name = "Joe" AND NOT (person)-[:KNOWS]-(foaf) RETURN foaf
Joe认识Sally,Sally认识Anna。 Bob被排除在结果之外,因为除了通过Sally成为二级朋友之外,他还是一级朋友。
图数据库应对的是当今一个宏观的商业世界的大趋势:凭借高度关联、复杂的动态数据,获得洞察力和竞争优势。国内越来越多的公司开始进入图数据库领域,研发自己的图数据库系统。对于任何达到一定规模或价值的数据,图数据库都是呈现和查询这些关系数据的最好方式。而理解和分析这些图的能力将成为企业未来最核心的竞争力。
来源:博客园
作者:奋斗终生
链接:https://www.cnblogs.com/ajianbeyourself/p/11425929.html