刚在知乎上看到了一个提问，挺有意思，于是乎，贴到这里再简聊一二。
转自知乎提问
当然可以，不过成本问题不容小觑。另外还有性能上的考量。
就在最近，米国国家航空航天局------NASA因为人力成本问题，摒弃了使用了十多年的Neo4j，转而采用了Memgraph，以节省成本。震不震惊？意不意外？！！啧啧。
老夫先把整个news 贴过来，自行看吧，不多废话：
NASA 的人力分析团队因成本问题，将原使用近十年的 Neo4j 图数据库换成 Memgraph。
团队高级数据科学家 David Meza 在最近的网络研讨会上表示，尽管他们使用 Neo4j 已经近十年，但成本问题日益突出。
Meza 曾在接受 The Register 采访时谈到，使用 Neo4j 图数据库系统的好处在于能整合 NASA 各企业应用中的数据，从而理解知识、技能、能力、任务与技术 ( KSATTs ) 与职业、角色及培训之间的关系。
但在最近关于 Memgraph 的网络研讨会上，他解释了转向这种基于内存的图数据库的原因。 他说："使用 Neo4j 最大的问题是成本太高，我当前的环境承受不起这个费用。"
上周，特朗普政府提议将 NASA 的年度预算由 248 亿美元削减 24％，降至 188 亿美元，以削减政府开支。
Memgraph 同样使用与 Neo4j 相同的 Cypher 查询语言。不过，它使用 C++ 编写（赢图也是使用C++ ），并且与 Python 的集成效果优于采用 Java 构建应用的 Neo4j。
他表示："它有很多优点。我们可以使用相同的工具而无需重新学习大量内容，因为我们在 Neo4j 上已经积累了大量经验。而后，Memgraph 展示了其成本优势，这促使我做出了这个决定。这不仅是出于成本考量，更因为转换过程十分便捷。"
NASA 正将 Memgraph 整合进其人力资本智能查询系统，以便为员工更快地检索相关信息。
Meza 在一份声明中表示："它基于图的数据结构使我们能够实时跟踪更新，确保各项政策文件和数据源之间的精确关联。通过将 Memgraph 融入到我们的检索增强生成过程中，我们提升了系统响应速度，并能更好地处理 NASA 的知识提取任务，同时无需进行大量手动数据协调。"
在接受 The Register 采访时，Memgraph 首席执行官 Dominik Tomicevic 表示，Neo4j 依赖于基于磁盘的复杂 B-tree 结构，并辅以内存缓存。"因此，为了运行图算法，需要在图中进行大量的随机跳转。"
由于磁盘设计用于顺序读取而非随机读取，所以其解决方案是复制数据，从只读格式中运行分析工作负载，并在需要时将结果写回原始数据。
Tomicevic 说道："虽然在使用 Neo4j 时可以完成许多任务，尤其是在处理批量工作负载时，但如果需要实时作出决策，那么重建内存索引、重复所有数据、运行算法再将数据写回原始图形的成本将会大大增加。"
他还指出，在 Memgraph 中，数据结构首先为数据科学工作负载而构建。借助 snapshots ( snapshots )，这一内存系统不仅支持事务性工作负载，还能满足实时分析需求。
图2
另外，见上图2，翻译问题，在中文的名词解释中，应该直接称为"图数据库"，而非"图形数据库"。
图(Graph)一词源自图论(Graph Theory)，而图形来自Graphics，两者虽然词根相同，但涵义不同------Graph指的是事物的集合及其拓扑结构与关联关系，而Graphics是平面设计或可视化图像，因此，"图形数据库"这种叫法并不准确，这也是一种典型的Lost-in-Translation（翻译缺失）。也许当时命名这一类的数据库时用Topo Graph（可翻译为拓扑数据库）会更准确一些。
上面一段话，笔者进行了标粗：我们再展开小聊一下:
图3
Neo4j的核心引擎是用Java实现的，也就是说在运行时它是跑在Java虚拟机(Java Virtual Machine，JVM)之上的，整个内存、堆的管理等一系列效率问题由此而生。笔者无意挑起关于Java性能的论战，但是有很多业界的场景值得探讨：
①高性能：在大图中如何做到实时计算或查询。一个基于批处理理念而生的系统如何能提供高性能（实时）的服务呢？Neo4j虽然宣称无索引邻接，但是依然在很多地方需要通过构建索引来实现加速，这些都是架构层面存在性能瓶颈的表现。
②深度查询：在关联度较高的图当中如何实现实时的深度查询（大于或等于5级的查询）。所谓关联度较高，指的是顶点的平均度数值较高，有超级顶点（热点）存在。而热点穿透或遍历会使Neo4j或任何Java类系统的效率大幅降低、运行时耗升高。
③高并发与并行化执行：高并发在图数据库领域中是一个很特别的挑战，这是因为图数据库支持高维查询计算与分析，每个查询的计算复杂度非常高。高并发也包括如何对单一查询通过并行化执行来实现加速，而Neo4j的并行化程度是较低的。大多数查询与计算是通过单线程串行的方式执行，最大并发规模只能做到4线程并行。事实上，在商业化环境部署中，Neo4j系统经常出现上千个查询排队等待处理的问题，这个问题与系统整体性能和架构设计及代码实现的并发规模不够直接相关。
④系统稳定性：当在高负载、高复杂度查询、较高并发条件下，系统保持稳定运行的能力。
⑤系统资源消耗或性价比问题：JVM垃圾集等问题导致系统对内存的需求非常大，回收不及时，并且难以控制。此外，系统在运算每一个查询时所需的时间、空间复杂度的问题也是存在的，因为图查询经常是高维的、递归的、单一的复杂查询请求（例如查询某个顶点的全部多步邻居集合，或两个顶点间的全部最短路径数量），如果每一步的复杂度都较高，那么整体的查询复杂度就会呈指数级升高，直至系统失控（内存溢出、死机或无法返回）。
Neo4j在解决以上几个问题时遇到了很大挑战。当然，一部分原因是因为它有社区版本 （注意并不是开源版本，Neo4j的底层代码从来没有开源过，其社区版中只是服务层的代码可以被访问。拿社区版进行商业化使用的行为实际上是一种侵权行为）和企业级版本之分，而前者毫无疑问并没有（或者是有意而为）去解决以上问题。 当越来越多的企业与开发者在使用Neo4j类的基于批处理理念而构建的图数据库在遇到问题的时候，他们就会转而寻找性能更优异的实时图数据库产品或解决方案，嬴图实时数据库即在这样的背景下应运而生。
这中，还有一个留给大家思考，这也是开源社区都要面对和思考的，一款优异的产品特别是新产品，如果有明确的商业化道路可以遵循，那么还有什么理由去打造一个开源的版本，使其性能、功能与商业版本没有差异呢？？？
开源版本的稳定性不仅滞后于商业版本，而且需要持续的时间不断迭代才可能获得。MySQL在今天能如此之稳定，是因为其走过了20年的发展历程。反观后起之秀MongoDB，虽然它的用户数量在过去几年间快速增长，用户群体亦相当庞大，但它依然存在很多"陷阱"。尤其对于很多在成长中与其绑定的开发团队而言，他们面临着极大的挑战。这个时候反而是商业化的版本更能应对团队当下甚至未来相当长一段时间内的挑战......
嗯，可聊的技术点那是太多了...... 篇幅有限，多不赘述，感兴趣的同学可以私下接聊~88~
88~