在本文开始前，先给大家分享几个好用的IDEA激活码
这里提供几个最新的激活码，有需要的朋友可以试试，先到先用：
2022Intellij IDEA最新激活码,IDEA稳定专属激活码(持续更新）
2022Pycharm激活码,Pycharm稳定专属激活码(持续更新）
2022Webstorm激活码,Webstorm稳定专属激活码(持续更新）
选择索引策略很困难。Elasticsearch文档确实有一些一般性的建议，也有来自其他公司的一些提示，但这也取决于特定的用例。在典型的场景中，你有一个数据库作为事实的来源，你有一个索引可以让事情变得可搜索。你可以有以下策略：
- 数据来时索引——您同时插入数据库和索引。如果没有太多数据是有道理的；否则索引变得非常低效。
- 存储在数据库中，使用计划作业进行索引——这可能是最常见的方法，也很容易实现。但是，如果要索引的数据很多，则可能会出现问题，因为必须使用（从，到）标准从数据库中精确地获取它，并且您的索引会滞后于实际数据的秒数（或分钟数）在计划的作业运行之间
- 推送到消息队列并编写索引消费者——您可以运行 RabbitMQ 之类的东西，并让多个消费者轮询数据并为其编制索引。这并不容易实现，因为您必须轮询多个项目以利用批量索引，然后仅在成功批量执行时将它们标记为已使用——有点事务行为。
- 在内存中排队并定期刷新它们——这可能是好的和高效的，但是如果一个节点死了，你可能会丢失数据，所以你必须根据数据库中的数据进行某种健康检查
- 混合 – 做以上的组合；例如，如果您需要在稍后阶段丰富原始数据并更新索引，您可以在内存中排队项目，然后使用“存储在数据库中，索引与计划作业”来更新索引并填充任何缺失的项目。或者您可以在数据的某些部分到来时进行索引，并对更活跃的数据类型使用另一种策略
我们最近决定实施“内存中的队列”方法（结合另一种方法，因为无论如何我们都必须进行一些预定的后处理）。第一次尝试是使用 Elasticsearch 客户端提供的一个类—— BulkProcessor。逻辑很清楚——在内存中累积索引请求，如果达到某个限制，或者以固定的时间间隔将它们批量刷新到 Elasticsearch。所以最多每 X 秒，最多每 Y 条记录都会有一个批量索引请求。这实现了近乎实时的索引，而不会给 Elasticsearch 带来太大压力。根据 Elasticsearch 的建议，它还允许同时进行多个批量索引请求。
但是，我们使用的是 BulkProcessor 不支持的 REST API（通过Jest ）。我们尝试插入一个 REST 索引逻辑而不是当前的原生逻辑，虽然它几乎可以工作，但在此过程中我们注意到一些令人担忧的事情 –internalAdd每次将索引请求添加到批量时都会调用的方法是synchronized. 这意味着线程将阻塞，等待彼此向批量添加内容。这对于生产环境来说听起来不是最理想的并且有风险，因此我们进行了单独的实施。可以在这里看到 – ESBulkProcessor。
它允许多个线程同时刷新到 Elasticsearch，但只有一个线程（使用锁）从队列中消耗以形成批次。由于这是一个快速操作，因此可以将其序列化。并不是因为并发队列不能处理从它读取的多个线程——它可以；但是达到多个线程同时形成bulk的条件将导致几个小批量而不是一个大批量，因此一次只需要一个消费者。这不是一个大问题，因此可以移除锁。但重要的是要注意它没有阻塞。
这已经生产了一段时间，似乎没有任何问题。如果由于负载增加或边缘情况而发生任何变化，我将报告任何变化。
如果这是唯一的索引逻辑，那么重申这个问题很重要——您的应用程序节点可能会失败，并且您最终可能会在 Elasticsearch 中丢失数据。我们不在那种情况下，我不确定哪种方法是最好的补救方法——无论是在服务器出现故障的情况下对最近的数据进行部分重新索引，还是在没有服务器的情况下进行批处理检查数据库和索引之间的不匹配。当然，我们还应该说，您可能并不总是拥有数据库——有时 Elasticsearch 就是您用于数据存储的全部，在这种情况下，需要某种队列持久性。
最终目标是拥有近乎实时的索引，因为用户希望尽快看到他们的数据，同时不会压倒 Elasticsearch 集群。
“什么是索引数据的最佳方式”这个话题很大，我希望我至少已经澄清了一点，并且我们的贡献也适用于其他场景。
发布者：admin，转转请注明出处：https://www.ajihuo.com/soft/5008.html
