Elasticsearch，Solr和DSE实时搜索的RealTime是多少？

Question

在过去的几周里，我一直在使用Elasticsearch和Solr，并尝试实时地进行OLTP处理。然而，在我看来，他们声称(特别是ES)是实时的。对我来说，实时的含义看起来很模糊。

如果我们深入研究它，ES和Solr都定义了刷新率或软提交率，在刷新率或软提交率之后，新索引的文档将可用于搜索，从而有效地仅提供接近实时的功能。

它看起来像是实时搜索，它要么是一种营销声明，称之为实时，要么他们通过谈论实时搜索而不是批处理或分析处理来使这个词变得模糊。

我是否正确，或者如果我错了就纠正我，并且在典型的OLTP系统中可以进行实时搜索，其中每个事务都对最后一个文档具有搜索可见性？

Answer 1

Elasticsearch是一个近乎实时的搜索引擎。Elasticsearch对于创建、更新、删除和获取等操作是实时的。

默认情况下，刷新时间为1秒。在某些用例中，它可能显示为实时。例如，我在一家法国政府部门工作，我们每天都在制作统计数据。因此，对于我们的用例，从我们的角度来看，它以某种方式是实时的。

例如，对于日志，在大多数用例中，1秒就足够了。

您可以修改此默认值，但它是有成本的。

如果您确实需要实时，那么您可能希望使用SQL数据库。

我的两分钱。

Answer 2

是的，DSE搜索确实是近乎实时的，并且还没有达到绝对零延迟的神话目标。但是..。即使是传统的real-time也不是实时的，一旦您考虑到进行实际数据库更新的时间，再加上许多传统数据库更新是面向批处理的，或者即使实际的更新操作不是批处理的，也可能会有一些人工过程延迟从原始数据更改源开始的数据库更新。

还要记住，数据库更新的延迟需要包括维护在集群中复制数据更新所需的(可调的)一致性。

如果你想要实时，而不是把你推回SQL，我会挑战你完全证明应用程序的真实延迟需求。例如，对于复杂的分布式应用程序，您需要为偶尔出现的资源中断(如网络延迟)做好准备，以便将现代分布式应用程序设计得比传统的、同步的、脆弱的(想想HealthCare.gov)应用程序体系结构更加灵活和异步，后者不正确地依赖于零延迟分布式操作的感知。

最后，我们正在致力于增强功能，以减少数据库更新的实际延迟，再加上硬件性能的持续改进，进一步缩短了更新延迟窗口。

但最终，所有计算实时度量都将具有一些非零延迟，现代分布式应用程序必须设计为至少在数据库更新和对这些更新的绝对依赖之间实现一定程度的解耦。

最坏的情况是，需要与数据库更新同步的应用程序可能需要实现轮询策略来等待更新完成。

Answer 3

ElasticSearch具有CRUD操作的实时特性。在GET操作中，它检查事务日志，以查找任何未提交的更改并返回最相关的文档。

Percolator功能也支持实时搜索查询。它允许您注册查询(过滤)，这些查询将在索引时用于将匹配的文档返回到那些预定义的查询。

此工作流程如下所示：

Elasticsearch

• Index新内容中的特定于

1. 注册的查询(渗透)(传递一个标志以触发索引操作的percolation)
2. The响应将包含匹配的渗透

这是一个非常好的博客，里面有解释Percolator概念的现场例子：

http://blog.qbox.io/elasticsesarch-percolator