OrientDb Live Query功能的可能用例有哪些?

时间:2016-06-08 06:02:43

标签: orientdb graph-databases

如果问题很幼稚,我道歉。我想了解实时查询功能的几个可能用例。

让我们说 - 我的数据库状态发生了变化,但每分钟(或小时)都没有变化。如果我对我的数据库/类/集群执行实时查询,我真的不希望很快就会调用回调。但是,嘿,我还是希望在状态发生变化时得到通知。 我对Orientdb的需求更多的是与发布 - 订阅系统捆绑在一起的ElasticSearch的过滤器。

实时查询是否也适合此类用例?或者我对实时查询的理解非常有限?实时查询功能可能有几个可能的用例?

谢谢!

1 个答案:

答案 0 :(得分:1)

实时查询是否适合您的用例取决于一些事情。实时查询有意义的原因有多种。要问的几个问题是:

  1. 数据的变化频率如何?

  2. 数据更改后多久需要了解一下?

  3. 您需要处理多少个不同的数据组(例如,类,群集)?

  4. 有多少客户端连接到服务器?

  5. 如果数据不经常更改,或者您可以在更新前等待一段时间,或者您没有多个客户端(直接点击数据库),或者您只有一件事情数据库,然后您可能只想进行轮询。保持连接打开,您很少发送消息(实时查询)和过于频繁的轮询之间存在平衡。

    例如。您可能有一个应用程序服务器(tomcat,节点等),并且您的客户端可以通过Web套接字连接。现在假设您的应用服务器对数据库进行一次(或几次池化)实时查询。现在假设您的数据库有更新。它可能只是从数据库到应用服务器(例如节点)。节点现在可以负责在100个Web套接字上扇出该消息(每个连接的客户端1个)。在这种情况下,节点以实时查询打开的持久方式连接到数据库这一事实并不是一件大事。

    问题是。如果您连接了数千个客户端,他们都需要立即更新。如果是这样,你打算让他们在短时间内进行投票吗?如果是这样,您可能会受益于实时查询。很多客户端在短时间内轮询会产生大量不必要的流量和查询。

    不幸的是,在一天结束时,答案取决于它。您可能需要进行原型设计,然后在负载下进行检测以查看您的权衡。但总的来说,它更少涉及更新的频率,更多的是关于客户轮询的频率,以及您拥有的客户数量。如果答案是“短时间间隔和很多客户”,请尝试实时查询。

相关问题