在 MySQL 中存储图表是个好主意吗？
我正在使用 MySQL 来存储来自工具的报告。我对用户查询数据的速度和灵活性感到非常满意。该工具还有一些数据，即图表。我的问题是，将图表存储在 MySQL 中是个好主意吗？图中的节点和边的数量为数百万，查询通常是图遍历。
I am using MySQL to store reports from a tool. I am extremely happy with the speed and flexibility with which users can query data. The tool also has some data which is a graph. My question is, is it a good idea to store the graph in MySQL? The number of nodes and edges in the graph is in the millions and queries are usually graph traversals.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
MySQL 并不是专门作为图形数据库创建和优化的。您可能想尝试 Neo4J，这是一个很好的图形数据库。
MySQL is not created and optimized as a graph database in particular. You might want to try Neo4J which is a good graph database.
普通 SQL 通常不适合操作图数据结构。然而，有一些技术可以对其进行索引。
例如，如果您的不经常更新，请使用 GRIPP index 将使您能够非常好地处理图遍历查询。后者可以让您在或多或少的固定时间内回答父子和与深度相关的查询——无论图表的节点数量或链接密度如何。
Plain SQL is usually unfit for manipulating a graph datastructure. There are techniques to index it, however.
For instance, if yours is not frequently updated, using a GRIPP index will let you handle graph traversal queries extremely well. The latter lets you answer parent-child and depth-related queries in more or less fixed time -- irrespective of the graph's number of nodes or density of links.
一般来说，SQL 数据库不能很好地处理图形数据。问题是，要进行图遍历，您要么必须在单个查询中将整个图拉入内存，然后对其进行操作并存储更改，要么必须执行大量联接以一次遍历一个节点，这变得非常慢。对于您正在查看的规模的图形，最好使用图形数据库或使用像 REDIS 这样的内存数据库作为快速缓存层，然后将其保留在后台。
SQL databases don't handle graph data very well in general. The problem is that to do a graph traversal you either have to pull the entire graph into memory in a single query, then manipulate it and store the changes, or you have to perform huge amounts of joins to traverse the graph one node at a time, which becomes prohibitively slow. With graphs of the scale you are looking at it would probably be better to use a graph database or to use a memory database like REDIS as a fast caching layer and then persist it in the background.