使用和扩展 Titan 图形数据库
Using & Scaling Titan Graph Database
我正在找出存储分层数据（父子关系）的选项。
由于树是图，而（树的）森林在技术上也是图，因此图数据库似乎比 RDBMS esp 更符合要求。因为我关心优化读写操作。
- 优化写入意味着层次结构的更改需要最少的写入。
- 优化读取意味着实现特定节点消耗最少读取操作的完整路径。
我的用例是：
- 每个用户一棵树。我应该为用户存储和使用一张图表 space 还是每个用户一张图表？
- 从任何节点开始并返回到用户树根的路径查询。
- 子节点存储到父节点的链接
由于我所有的资源都在 AWS 中，因此能够使用 Titan DynamoDB 后端似乎是理想的选择。
我真正的问题是了解如何扩展和管理 Titan。
我需要 gremlin 服务器实例吗？换句话说，我需要用 gremlin 服务器建立一个 EC2 实例才能对 Titan 做任何事情吗？或者我可以使用 Java Titan API 直接处理图形数据吗？
我是否需要显式分片数据？换句话说，随着使用量的增加，数据量和操作量的增加，我是否需要架设更多的 gremlin 服务器？当服务器数量扩展时，我是否需要从客户端对这些服务器进行一致的散列以执行操作？
是否需要设置弹性搜索集群才能从任何节点开始遍历？或者在这一点上使用顶点来表示对象和边来表示父关系就足够了吗？我可以保证顶点 ID 在整个 user-space 中是唯一的；我也可以用唯一的用户 ID 装饰每个顶点。在那种情况下，我需要弹性搜索吗？我希望弹性搜索适用于自由形式或更复杂的搜索类型查询，而不是精确查询！
随着前端数量的增加，是否每个前端都可以开图（单图跨用户space）？如果每个用户一个图，那么由于前端没有亲和力，可能会为每个用户打开同一个图；那样行吗？
我找不到关于这些的太多文档。谢谢！
我将尝试在以下方面回答您的问题：
这两种解决方案都是可行的，在很大程度上取决于您的应用程序来决定是选择 gremlin 服务器还是具有通过其他辅助数据存储进行自定义查询的自定义数据访问层。虽然我更喜欢自定义数据访问层，但可以通过 gremlin 服务器响应所有 gremlin 查询要求。
Gremlin 服务器只是您的应用程序和数据存储之间的接口，由于缓存机制，它是内存密集型的。数据可以存储在不同的机器上，例如 DynamoDB 机器集群。这取决于并发用户的数量，但我认为垂直缩放对于大多数应用程序来说已经足够了。如果你打算在高并发环境中使用 titan，超出单机资源，可能你必须在不同机器上创建不同的 gremlin-servers 并处理负载平衡机制。问题是，从缓存效率的角度来看，您必须以类似查询命中同一 gremlin 服务器的方式来控制发送请求。
是的，索引后端只对更复杂的查询有用，而不是简单的检索。如果你想通过相似性进行条件搜索或文本搜索，二级索引后端（如 Solr/Elastic 或 Lucene）很有用。这是因为像 Lucene 这样的索引器可以提供一个反向索引结构，可以帮助类似的搜索。如果您要搜索名称中包含 "foo" 的所有 parents/children，则必须使用索引后端。如果您要搜索年龄小于 40 岁的所有 parents/children，您也必须使用索引后端。
可以通过这些 link 访问有关索引后端的更多信息。
http://s3.thinkaurelius.com/docs/titan/1.0.0/indexes.html
http://s3.thinkaurelius.com/docs/titan/1.0.0/index-parameters.html
强烈建议将整个应用程序的打开图数限制为一个。 Titan 使用一些缓存机制，鼓励您为了性能而在整个应用程序中使用单个图形实例。由于未提交的数据仅在单个图实例和事务上可见，如果您想要实时应用，建议使用单个图实例和单个事务。但是，在整个应用中使用1个以上的图实例进行只读事务并没有错，只是效率不高。
您可以在以下link中找到有关 Titan 图数据库的大量信息：
Titan 主要文档：http://s3.thinkaurelius.com/docs/titan/1.0.0/
关于 Titan 工作原理的古老但非常有用的文档：https://github.com/elffersj/delftswa-aurelius-titan/tree/master/SA-doc
我正在找出存储分层数据（父子关系）的选项。
由于树是图，而（树的）森林在技术上也是图，因此图数据库似乎比 RDBMS esp 更符合要求。因为我关心优化读写操作。
- 优化写入意味着层次结构的更改需要最少的写入。
- 优化读取意味着实现特定节点消耗最少读取操作的完整路径。
我的用例是：
- 每个用户一棵树。我应该为用户存储和使用一张图表 space 还是每个用户一张图表？
- 从任何节点开始并返回到用户树根的路径查询。
- 子节点存储到父节点的链接
由于我所有的资源都在 AWS 中，因此能够使用 Titan DynamoDB 后端似乎是理想的选择。
我真正的问题是了解如何扩展和管理 Titan。
我需要 gremlin 服务器实例吗？换句话说，我需要用 gremlin 服务器建立一个 EC2 实例才能对 Titan 做任何事情吗？或者我可以使用 Java Titan API 直接处理图形数据吗？
我是否需要显式分片数据？换句话说，随着使用量的增加，数据量和操作量的增加，我是否需要架设更多的 gremlin 服务器？当服务器数量扩展时，我是否需要从客户端对这些服务器进行一致的散列以执行操作？
是否需要设置弹性搜索集群才能从任何节点开始遍历？或者在这一点上使用顶点来表示对象和边来表示父关系就足够了吗？我可以保证顶点 ID 在整个 user-space 中是唯一的；我也可以用唯一的用户 ID 装饰每个顶点。在那种情况下，我需要弹性搜索吗？我希望弹性搜索适用于自由形式或更复杂的搜索类型查询，而不是精确查询！
随着前端数量的增加，是否每个前端都可以开图（单图跨用户space）？如果每个用户一个图，那么由于前端没有亲和力，可能会为每个用户打开同一个图；那样行吗？
我找不到关于这些的太多文档。谢谢！
我将尝试在以下方面回答您的问题：
这两种解决方案都是可行的，在很大程度上取决于您的应用程序来决定是选择 gremlin 服务器还是具有通过其他辅助数据存储进行自定义查询的自定义数据访问层。虽然我更喜欢自定义数据访问层，但可以通过 gremlin 服务器响应所有 gremlin 查询要求。
Gremlin 服务器只是您的应用程序和数据存储之间的接口，由于缓存机制，它是内存密集型的。数据可以存储在不同的机器上，例如 DynamoDB 机器集群。这取决于并发用户的数量，但我认为垂直缩放对于大多数应用程序来说已经足够了。如果你打算在高并发环境中使用 titan，超出单机资源，可能你必须在不同机器上创建不同的 gremlin-servers 并处理负载平衡机制。问题是，从缓存效率的角度来看，您必须以类似查询命中同一 gremlin 服务器的方式来控制发送请求。
是的，索引后端只对更复杂的查询有用，而不是简单的检索。如果你想通过相似性进行条件搜索或文本搜索，二级索引后端（如 Solr/Elastic 或 Lucene）很有用。这是因为像 Lucene 这样的索引器可以提供一个反向索引结构，可以帮助类似的搜索。如果您要搜索名称中包含 "foo" 的所有 parents/children，则必须使用索引后端。如果您要搜索年龄小于 40 岁的所有 parents/children，您也必须使用索引后端。 可以通过这些 link 访问有关索引后端的更多信息。 http://s3.thinkaurelius.com/docs/titan/1.0.0/indexes.html http://s3.thinkaurelius.com/docs/titan/1.0.0/index-parameters.html
强烈建议将整个应用程序的打开图数限制为一个。 Titan 使用一些缓存机制，鼓励您为了性能而在整个应用程序中使用单个图形实例。由于未提交的数据仅在单个图实例和事务上可见，如果您想要实时应用，建议使用单个图实例和单个事务。但是，在整个应用中使用1个以上的图实例进行只读事务并没有错，只是效率不高。
您可以在以下link中找到有关 Titan 图数据库的大量信息：
Titan 主要文档：http://s3.thinkaurelius.com/docs/titan/1.0.0/
关于 Titan 工作原理的古老但非常有用的文档：https://github.com/elffersj/delftswa-aurelius-titan/tree/master/SA-doc