Elasticsearch (ES) 和它的困难之处

最新推荐文章于 2024-07-30 14:29:52 发布

cunxiedian8614

最新推荐文章于 2024-07-30 14:29:52 发布

阅读量943

点赞数

文章标签： es

我一直在一个CRM行业做后端开发，在那里一切都是关于搜索:)。是的，你是对的，它是一个有很多数据表列的系统。因此，选择支持这种高度可定制搜索的后端框架是Java with spring integration。是的，你的想法是对的，我们选择了Elasticsearch(ES)作为我们的数据存储。和往常一样，有赞成票也有反对票，但最终这是一个正确的决定。那是4年前的事了，最新的稳定版是1.7。哦，我完全忘记了，现在让我来谈谈ES。

ES是基于Lucene的开源搜索引擎。当然，这不是主要的数据存储，但是对于随处可见的系统而言都是有效的。ES易于扩展。Elasticsearch将有关索引的元数据信息（在SQL中将其视为表）存储在文件中，并将其他数据信息存储在文件中。节点不过是您的服务器，它们可以一起称为集群。节点有助于保留数据的副本。ES以JSON形式保存数据，并且特别要遵循所谓的JSON定律。如果您想了解有关ES术语基础的更多信息，请访问此处。

让我们回到我实际上应该说的地方。维护ES确实很困难且成本很高。我的意思是，由于大多数初创企业都没有所谓的DevOps自动缩放机制和诸如此类的东西，随着数据的增加，我们需要启动机器或节点以保持ES稳定。否则将看到“堆空间错误”，因为这是完全使用Java构建的，是的，JAVA开发人员会喜欢此错误:)。

真正的开发者困难

欢迎来到索引的真实世界。在elasticsearch中，您将永远听到有关索引的信息。索引不过是将您的所有数据写入ES。索引编制也是系统中的创建/更新操作。有索引的策略，应在ES中仔细配置。这意味着读/写繁重的系统应在ES中进行适当的配置。索引就像印度人吃辛辣的食物一样吃系统RAM（我就是喜欢它）。由于操作繁重，因此在高峰时段应仔细进行完全索引。
1.7版本中没有父子关系。是的，您可以在更高版本的索引之间维护ES之间的关系。我们该如何解决呢？我们还必须在父级内部存储子级JSON数据。这有点重复，因为我们拥有用于子数据的单独索引，但仍需要保留在父索引中。那么问题可能是为什么又在父索引中？因为系统搜索是通过过滤子数据在您的父页面中进行的。替代方法确实在每个索引中分离查询，然后将它们链接在一起。但是随后需要自定义分页，并且您的MVP模型策略将无法正常工作（由于到处都存在问题，因此无法很快发布）。
然后是场分析仪和指数分析仪。谁说是的ES容易，那就把它们拧紧。不，我只是在开玩笑。但是我们在元数据配置方面遇到了困难。因此，在ES中存储数据或不分析它们。例如，如果要使用通配符支持搜索字段，则需要将它们存储在小写字符串中。如果要使搜索与空格一起使用，则需要其他一些分析器，列表将继续。最糟糕的部分是您不能直接在现有索引中进行更改，只能将其添加到新索引中。因此，我们需要重新索引数据。
假设您的客户提出了一些新建议。他们希望搜索特殊字符，现在您需要创建特殊分析器并将其添加到元数据中。是的，您可以关闭索引并添加它。但是，如果要在任何字段中指定新创建的分析器，则无法执行。因此，再次回到第一步，创建新索引并重新索引数据。
现在，为什么不能先将分析器本身存储在每个字段中。您不应该这样做，因为在使用分析器的字段中搜索和索引将花费更多时间。因此，始终在将分析器分配给字段时务必小心。
聚合是ES的最佳组成部分。分组依据是我能找到的最好的同义词。人们喜欢在ES中进行汇总。是的，但是它甚至可能会破坏系统。自此以来，在ES上执行非常繁重的操作会占用大量RAM。应仔细构建和使用。如今，大多数推荐系统都喜欢使用此功能。
Elasticdump是用于平稳发布和重新索引的最好的库。我记得每个月至少使用3次。
更喜欢查询构建器而不是过滤器。仅在从节点获取数据之后才应用过滤器。是的，您是对的，这很耗时。