在Google AppEngine数据存储中存储有向图
我需要在 google appengine 中存储一个大型动态无向图,最好的方法是什么? 图表示必须能够支持快速拉出一组顶点(用于在页面上渲染)以及来自特定顶点的所有链接,以及跨图的寻路(尽管实际上并不需要最佳路径,只是一个相当大的路径)好)
我对这个问题的想法: 最明显的方法是拥有一个顶点模型和一个引用两个顶点的边缘模型,但这听起来似乎最终会为每个操作使用大量查询,我想知道是否有更好的方法(也许以某种方式将链接信息构建到每个顶点中)
I need to store a large and dynamic undirected graph in google appengine, what's the best way to do this?
The graph representation must be able to support rapidly pulling out a set of vertices (for rendering on a page) and all the links from a specific vertex, and pathfinding across the graph (although the optimal path isn't really needed, just a fairly good one)
My thoughts on the subject:
The most obvious way is to have a vertex model, and an edge model which references two vertices, however that sounds like it's going to end up using an awful lot of queries for every operation, I'm wondering if there is a better way (maybe build the link information into each vertex somehow)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
这是最简单的方法:
现在您可以在没有任何查询的情况下探索图形 - 只需在 1 个或多个键上调用 db.get 即可检索相关顶点:
Here's the simplest way:
Now you can explore the graph without any queries at all - just call db.get on 1 or more keys to retrieve the relevant vertices:
根据顶点/链接的数量,您可能只想使用列表而不是创建一堆新实体。 检查 Google IO 2009 视频后半部分描述的朋友图问题:http:// www.youtube.com/watch?v=AgaL6NGpkB8
如果您认为顶点数量足够多,您可以创建一个带有代表连接的列表的顶点模型。
Depending on the number of vertex/links you might want to just use lists instead of creating a bunch of new entities. Check the friends graph problems described in the second half of this video from Google IO 2009: http://www.youtube.com/watch?v=AgaL6NGpkB8
If you think the number of vertex is high enough you can just create a Vertex model with a list that represents the connections.
考虑到您正在使用谷歌应用程序引擎,最好将信息存储在单独的表中:
一个用于顶点,一个用于来自顶点的链接(正如您已经说过的),另一个表中路径已预先计算。
如果您存储的信息是非规范化的,那么 GAE 效果最佳,因此您无需对其进行任何计算。
Considering you're using the google app engine it would be best if you stored the information in separate tables:
One for the vertices, one for the links from a vertex (as you already said) and an additional one where the paths are already precomputed.
GAE works best if the information you store is denormalized so you don't have to do any calculations on it.