從最近幾周起，我一直在圍繞Elasticsearch和Solr進行工作，並試圖實時進行OLTP處理。然而，他們聲稱（尤其是ES）是實時的。實時的意義看起來很模糊。Elasticsearch，Solr和DSE實時搜索有多少RealTime？
如果我們深入研究，ES和Solr定義了刷新率或軟提交率，之後新索引的文檔將可用於搜索，從而只提供近實時功能。
它看起來像是實時搜索，它或者是一個營銷聲明，稱之爲實時，或者他們通過談論實時搜索而不是批量或分析處理來使該詞變得模糊。
我是否正確或糾正了我的錯誤，並且在典型的OLTP系統中可以進行實時搜索，每個事務都具有對最後文檔的搜索可見性？
Elasticsearch是一個用於搜索的近實時搜索引擎。 Elasticsearch是創建，更新，刪除和獲取操作的實時。
默認情況下，刷新爲1秒。在某些使用情況下，它可能顯示爲實時。例如，我在爲法國政府服務工作，我們每天都在製作統計數據。所以對於我們的用例來說，從我們的角度來看，這是某種實時的。
對於例如日誌，在大多數使用情況下1秒就足夠了。
您可以修改此默認值，但它帶有成本。
如果您真的需要實時，那麼您可能想要使用SQL數據庫。
我的2美分。
是的，DSE Search確實接近實時並且還沒有實現絕對零延遲的神話目標。但是......即使是傳統的Real實時並不是實時的，一旦你考慮進行實際的數據庫更新的時候，加上很多傳統的數據庫更新是批處理的，或者即使實際的更新操作沒有批處理，可能會有一些人爲過程延遲數據庫更新的開始，從數據更改的原始來源開始。
還請記住，數據庫更新的延遲需要包括維護用於在羣集中複製數據更新所需的（可調整）一致性。
如果你想要實時的話，你不要把你推回SQL，我會挑戰你完全證明應用程序真正的延遲需求。例如，對於複雜的分佈式應用程序，您需要爲偶爾的資源中斷（如網絡延遲）做好準備，因此設計現代分佈式應用程序比傳統的同步的易碎性更加靈活和異步通常好得多（認爲HealthCare.gov）應用程序體系結構不正確地依賴於零延遲分佈式操作的感知。最後，我們正在研究增強功能以減少數據庫更新的實際延遲，同時還會進一步縮小硬件性能，進一步縮短更新延遲時間窗口。但最終，所有計算實時度量都將具有一些非零延遲，並且現代分佈式應用程序必須至少在某種程度上與數據庫更新和對這些更新的絕對依賴之間的解耦合來設計。
最糟糕的情況是，需要與數據庫更新同步的應用程序可能需要實施輪詢策略以等待更新完成。
ElasticSearch具有CRUD操作的實時特徵。在GET操作中，它會檢查事務日誌，查找任何未提交的更改並返回最相關的文檔。
Percolator功能還支持實時搜索查詢。它允許您註冊查詢（滲透），這將用於索引時間以將匹配的文檔返回到那些預定義的查詢。
這個工作流程是這樣的：在Elasticsearch
一個非常好的博客與現場的例子，解釋了過濾器的概念：