neo4j图形数据库结构（你需要哪个图数据库）
neo4j图形数据库结构（你需要哪个图数据库）上图我们需要关联4张表，用户表--->订单--- >订单产品关联表（或者省略这个） -->产品表在关系数据库中，我们如何实现这个需求呢？抛开网上那些专业性比较强的描述，我们用通俗的话来理解，你一定用过思维导图，类似下面的样式我们看看这两种东西的样式是不是很像，用比较直白的话说，”用图形的方式直观表示事物关联的形式“，那我们为什么要搞出个图来呢？图的形式和我们大脑思考问题的方式非常相似，我们思考事物的关系的顺序是怎么样的呢？就以思考电商场景下的人购买商品为例：我们看看图数据和我们比较熟悉的关系数据库的区别：
引言：
什么是图数据库---图数据库能干什么---你需要什么样的图数据库---如何获取学习资源
一、什么是图数据库：
图数据库就是用来存储图结构的数据库。那什么是图呢？
抛开网上那些专业性比较强的描述，我们用通俗的话来理解，你一定用过思维导图，类似下面的样式
我们看看这两种东西的样式是不是很像，用比较直白的话说，”用图形的方式直观表示事物关联的形式“，那我们为什么要搞出个图来呢？图的形式和我们大脑思考问题的方式非常相似，我们思考事物的关系的顺序是怎么样的呢？就以思考电商场景下的人购买商品为例：
- 首先梳理出我们需要考虑的对象，比如人，商品，在图数据库中叫做节点
- 然后逐个梳理这些对象之间有什么关系，比如浏览、加入购物车、购买等，在图数据库中叫边或者关系
我们看看图数据和我们比较熟悉的关系数据库的区别：
在关系数据库中，我们如何实现这个需求呢？
上图我们需要关联4张表，用户表--->订单--- >订单产品关联表（或者省略这个） -->产品表
也就是说我们在传统的关系型数据中，需要用join关联3-4表，如果表数据量少还好说，如果这个订单和产品表有好几亿，可想而知，性能会有多差，我们只想从中找寻出一条数据，但是也得从众多的block中加载到内存关联然后复杂的计算后得出，而用图数据库是如何进行的呢？
我们仅需要将用户和产品建立一个购买的边就可以，而且这个产品的订单信息天然就是用户数据的一部分，所以查询起来极其快，也就是说越复杂场景下，图数据库的优势越大
二、图数据库能做什么
除了性能比较强进外，图数据库还能做什么：
- 所有涉及关系的场景：比如社交、人物关联场景等
- 金融资产类、法人关系，类似天眼查、企查查的企业信息
- 知识图谱或者关系图谱，天然就很合适
- 推荐和搜索领域
这些领域只是冰山一角，还有更多可以发掘的场景等待我们发现。
三、选用哪个图数据库
先看看DB-ENGINES的关于图数据库的最新排名：截止到2020年5月
可以看到Neo4J依然还是那么坚挺，但较之2019年份额在缓慢降低，说明其他新类型的图数据库在不断发力，我们难道就是谁最热就用谁吗？oh NO!你得知道每种数据库的优势和劣势，才能结合自己的场景选择一个合适的数据库，下面就拿我比较熟悉的Neo4J和Dgraph来进行对比吧：
1.Neo4j优点：
- 最大的优点一定是Cypher，这种类SQL的语言学习起来毫无压力，和SQL习惯和关键词非常相近，比如where limit 等，会有很多惊喜
- 小数据量（是指几十亿节点以下）情况下表现良好，导入和查询非常快，我们使用32GB内存在导入几十GB数据情况下，几分钟就导入处理完毕
- 不用单独生成关联数据，可以使用类似下面的语句直接根据节点生成关系数据（数据得小于30w）
- 前端界面非常成熟：自定义显示字段、颜色、双击自动查询关联节点、账户安全登录，图形不会飘来飘去等等，一句话，前端秒死dgraph
- 文档资料完善，学习快速，可参考案例比较多
USING PERIODIC COMMIT 100
LOAD csv WITH HEADERS FROM "file:/opt/neo4j3.5/import/lawyer.csv" AS row
match (lawyer:Lawyer {law_firm_id:row.law_firm_id}) (firm:Firm{law_firm_id:row.law_firm_id})
merge (lawyer)-[:INFIRM]->(firm);
- Neo4J缺点：
- 查询占用内存稍大，但这不影响使用
- 不是纯分布式架构，社区版只能单机，虽然Neo4J的4.0版本有了集群的概念，说白了就是分库的做法，但是社区版依然限制在1DB
- 实时读写的性能不太好，更多应用场景在读
- 社区版最多支持 320 亿个节点、320 亿个关系和 640 亿个属性（其实也够了）
3.Dgraph优点：
借用dgraph自己官方的图片show一下吧：
一句话，dgraph是纯分布式架构，天然集群部署，性能绝对有保证，好像这也就是dgraph目前最引以自豪的优点了吧。对了，数据分片，dgraph支持，这也是很大的优势，而且在实际测试中，使用了分片后的性能提升比较明显。
4.dgraph缺点：（仅个人感受）
- graphql虽然是facebook主推的，但是很难用，超级难用，一个简单的查询得写一大推代码
- 得单独生成RDF数据，不能像Neo4j直接导出数据后直接导入
- 前端界面可定制化太少，图形飘来飘去的
- 文档缺少，仅官方资料，但是官方资料DOC很不成体系，亟待提升
总结起来：
如果你数据量不是超大，比如几百亿几千亿的，还是推荐用Neo4J，因为比较成熟；
如果数据量很大，或者追求极端性能的，可以考虑Dgraph，但是dgraph2016年才推出，发展势头不错，是一个值得关注的产品，期待未来可以和Neo4J PK一下，但是现在还不够格
四、学习资源
- 首先就是官方文档，这是最权威的，国内也有neo4j.com.cn的中文社区，但是质量一般
- 网上很多视频或者图文的资料，一搜一大把的Neo4J
- dgraph目前国内能看到的是贝壳的公众号的技术文章，他们研究比较早也在内部使用
