我正在做一个类似于社交网络的系统。最大用户数必须最终为50000或最多为70000。
目前，我使用的是mysqli+prepared statements。ERD现在有30张桌子，最终可能达到40张。
所以，我的问题是：我从未使用过图形数据库……我已经用mysql工作台完成了erd，并且已经开发了一些代码。对于此项目中预期的用户数，是否建议将mysql更改为图形数据库？我的SQL代码和数据库模型是否可用？这种改变有什么好处吗？
你怎么认为？
谢谢
最佳答案
如果您可以访问递归查询（mysql中不是这种情况，但PostgreSQL中提供了递归查询），并且查询涉及最大深度条件（在社交网络中可能是这种情况），或者如果它们的索引正确，那么图形在sql中存储时会很好且快速。
索引图有多种方法。在您的例子中，您的图形可能并不密集，因为您处理的是几乎独立的多个林（您通常要处理紧密聚集的用户组），所以您有很多选项。
最容易实现的是传递闭包（基本上，这是预先计算所有潜在路径的调用）。在你的情况下，它很可能是部分的（比如说，深度-2或深度-3）。这允许在单独的表中对相关节点进行完全索引，以便进行非常快速的图形查询。使用触发器或存储过程使其保持同步。
如果你的图形比这个密度更大，你可能需要使用GRIPP index来查看。与嵌套集非常相似，如果删除(rgt - lft - 1) / 2=number of children属性，并对lft/rgt使用浮点值而不是整数，则后者的效果最好（如更新最快）。（这样做可以避免在插入/移动节点时重新索引整个图块。）
关于mysql - 社交网络的图形数据库，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/6269387/