我听说图形数据库在 CRUD 操作方面天生就比关系数据库差。这是真的？如果是，那是为什么？
一些想法：
要在真实数据库中执行 crud 操作，您基本上必须处理一行（最好的情况）。只要它不是面向列的格式 (OLAP)，这应该是非常有效的。
据我所知，有两种流行的方式来存储图形：
要么实际存储“指向彼此的对象”。这将是图形的自然表示。
或者存储一个表，其中列出了关系。这将是图形的非自然表示。
在第二种情况下，我理解为什么 crud 操作很慢：您可能必须接触很多表来表示关系模式中单行的更新。
为什么在第一种情况下它很慢？要更新或删除，您可能只需要创建/读取/更新/删除单个对象。
我认为该软件太复杂了，无法对这个问题给出简单的是/否答案。它还取决于您如何定义 CRUD。
我们以“下单”功能为例。从业务角度来看，这是一个单一的原子操作。然而，在规范化的关系数据库中，它可能会触及许多表。订单会有一个插页；可能更新客户或购物车表；读取许多相关表以确保引用正确性。所有这些语句都将（应该？）包装在数据库事务中。因此，单个业务操作变成了包含在单个数据库事务中的许多数据库语句。
如果使用文档数据库而不是关系数据库，则很可能只有一次写入。图 DBMS 介于这两者之间，或多或少地根据特定应用程序的架构进行规范化。
只看磁盘结构，讨论也更加微妙。向表中插入一行看起来很简单。如果有索引，那么很可能会有写放大。如果存在索引拆分，则更是如此。如果该行包含 BLOB，则这些 BLOB 可能存储在单独的数据结构或不同的文件中。可以通过触发器或物化视图进行级联操作。压缩和加密可能会导致大量 CPU 消耗。
有许多磁盘结构来支持类图处理。在一个节点中是基本对象，边成为节点的属性。边以指针列表的形式存储在边两端的节点中。因此，创建一个节点将是一次写入。创建边缘将是两个。插入具有外键约束（最接近边）的行将是读取和写入。
在阅读方面也有秋千和回旋处。按父级计算子行将是关系世界中的双表连接。如果边缘指针存储为节点内的列表，则它是单个节点列表扫描。在图 DB 中做“是那个连接到这个”查询（朋友的朋友认识住在同一个城市的人可以在一小时内乘火车到达）很容易；这在关系世界中是可怕的。对于 CRUD 的“R”位，对于传递查询，图形每次都轻而易举地获胜。
总之，我质疑标题的前提。如果毫秒在您的上下文中很宝贵，那么请在生产等效硬件上进行大规模测试。