网站维护一般要几天,百度集团官网,视频模板网站,网络推广具体方式有哪些apache luceneApache Lucene是一个出色的并发纯Java搜索引擎#xff0c;如果您愿意#xff0c;它可以轻松地使服务器上的可用CPU或IO资源饱和。 “典型” Lucene应用程序的并发模型在搜索时每个查询一个线程#xff0c;但是您是否知道Lucene也可以使用多个线程同时执行一个查… apache lucene Apache Lucene是一个出色的并发纯Java搜索引擎如果您愿意它可以轻松地使服务器上的可用CPU或IO资源饱和。 “典型” Lucene应用程序的并发模型在搜索时每个查询一个线程但是您是否知道Lucene也可以使用多个线程同时执行一个查询以大大减少最慢查询的时间 Lucene的IndexSearcher类负责执行传入的查询以从索引中查找最匹配的匹配项它接受一个可选 施工期间执行器 例如线程池。 如果您通过Executor并且CPU足够闲置即服务器远低于其红线QPS吞吐能力Lucene将使用多个并发线程来查找每个查询的总点击率最高。 它是如何做到的 Lucene索引是分段的 这使得搜索成为一个棘手的并行问题每个查询都必须访问索引中的所有细分并收集其具有全球竞争力的点击量。 当查询为单线程时因为您没有将Executor传递给IndexSearcher 所以一个查询线程必须顺序访问所有段。 如果索引很大并且您的查询成本很高那么这些查询自然会需要较高的CPU成本和挂钟时间才能找到热门广告。 即使您在远远低于其红线QPS吞吐量容量的情况下运行服务器这也会导致长杆P90 查询延迟。 相反当您将Executor传递给IndexSearcher 索引中的段首先被IndexSearcher分组为单个线程工作单元称为 螺纹片 。 默认情况下 大段属于它们自己的线程片最多5个较小的段最多250K总文档将合并为一个线程片因为它们大概可以通过单个线程快速地顺序搜索。 通过将IndexSearcher子类化并覆盖其受保护的slices方法可以轻松地自定义将段合并为线程片的方式。 只要服务器闲置到足以在一个查询上花费多个CPU内核并且该查询的每个线程片上都有一个线程那么每个并发查询就会同时执行。 这个强大的功能最初是由Jean-FrançoisHalleux于16年前提出的 然后由Doug Cutting自己 您好Doug提出并于大约9年前最终重构为IndexSearcher 此后进行了许多迭代的改进许多改进现已展开感谢Atri Sharma 最近添加了新的Lucene / Solr提交者 。 这就是热情的开源软件开发的分布式力量 并发查询执行是Lucene中令人惊讶的很少使用的sleeper功能因为它尚未在基于Lucene构建的两个流行的分布式搜索应用程序Elasticsearch和Solr中公开。 他们的并发模型是跨索引分片通常在不同的服务器上针对单个查询的并发搜索而是在每个分片内使用单线程搜索。 这意味着需要许多并发的独立查询才能使集群范围的CPU或IO资源饱和。 直到群集至少看到最低最低QPS才能使用全部硬件资源。 对于经常看到高查询率的用例此限制是可以接受的。 但是如果Elasticsearch或Solr使用此功能则具有较大索引和较低查询率的其他常见用例将从单个群集节点内的并发查询执行中受益匪浅。 摩尔定律在现实世界中的影响已经发生了变化现代服务器级计算机是用惊人且Swift增长的并发硬件构建的不仅在它们的CPU中我们现在在最新的c5.24xlarge AWS EC2实例中还可以看到96个内核图形处理单元GPU内存总线DIMM和固态磁盘SSD实际上是底层的大型并发RAID 0阵列。 最近的趋势是CPU和GPU获得更多的并发内核而每个单独的内核获得的并发速度则更快。 为什么不使用所有这些增加的并发性来提高所有查询的速度甚至在低查询负载时也使CPU / IO饱和 棘手的权衡 不幸的是尽管搜索Lucene索引是一个自然而尴尬的并行问题但是对一个查询使用多个线程会产生固有的协调开销。 要了解原因请考虑一个简单的类比假设您需要苹果然后将孩子送到当地的杂货店购买。 如果您只有一个孩子则将其送给她她会在整个农产品区域四处走走并挑选十个最好的苹果然后带回家。 但是如果您有五个孩子然后将所有孩子都发送到商店他们会更快地回来五次而忽略了他们往返商店的“联网”时间吗 他们如何有效地分割工作 也许您的孩子很聪明他们首先将商店中的所有苹果部分如今有很多苹果选择 分成五个大致相等的部分。 每个人都围绕着自己的苹果区运行挑选她能找到的十个最好的苹果然后他们都在结帐柜台集合密切合作从现在拥有的五十个苹果中选出十个最好的苹果 这有点浪费因为孩子们总共收集了五十个苹果只是为了最终选择实际的十个最佳苹果但确实比一个孩子选出十个最佳苹果要快。 这实际上是Lucene今天实现并发搜索的方式每个搜索器线程单独工作以从一个线程切片“映射”阶段中找到自己的前N个最佳匹配然后在所有查询线程结束并重新加入主线程之后在主线程中主线程使用部分合并排序从每个线程切片收集的匹配中找到总前N个最佳匹配“减少”阶段。 Lucene的CollectorManager Collector和LeafCollector抽象都协同工作以实现此目的。 从现在开始这意味着与单线程案例相比完成了更多的工作 收集了M * N总匹配然后最后减少到前N 其中M是并发搜索线程的数量 N是请求检索的顶级匹配的数量。 并发运行每个查询时增加的协调成本必然会损害搜索节点的红线QPS容量吞吐量因为Lucene会花费更多的总CPU周期来查找最热门。 但是与此同时当搜索节点具有大量备用CPU资源时它可以大大提高长杆查询的等待时间因为最困难的查询现在可以同时运行。 此外收集更多匹配并最终合并它们的额外成本通常对总体影响不大因为通常是每个匹配的匹配和排名决定了总查询成本尤其是随着索引的增长该成本是有效地跨线程拆分。 您可以通过限制可以同时运行的查询数来进一步“扩大”这种折衷从而最大化每个查询将使用多少个CPU内核。 您还可以预先估算每个查询的成本并仅在其成本足够大时并发执行该查询这样可以在单个线程中快速运行的简单查询不会承担跨多个线程同步的开销。 这种吞吐量与延迟之间的折衷令人沮丧这意味着在您的Lucene应用程序中使用模式方法可能很有意义。 集群负载较轻时通过限制可以同时运行的查询数来减少每个查询的多个线程从而减少长杆延迟。 但是当群集正在运行时接近其红线容量时每个查询将转移到单个线程以最大化吞吐量。 确保您正确地测量了等待时间并且负载测试客户端没有遭受普遍常见的协调遗漏错误 确认您的负载测试客户端正在使用开环测试以便您看到真正的延迟影响例如长时间的垃圾收集暂停I / O打ic或交换。 持续的和未来的改进 幸运的是最近进行了一些激动人心的改进以减少多线程查询的额外开销。 Lucene现在还使用传入调用线程来帮助并发搜索 。 用于将小段分组为片线程工作单元的算法已得到改进 。 现在提前终止可以在多个搜索线程中使用一个共享的全局命中计数器来查询一个查询从而降低了查询的总成本。 查询缓存将很快使用Executor进行并发缓存并且在某些情况下使用Executor时甚至可以更高效。 与其让每个搜索线程完全独立地工作并仅在最后合并热门匹配不如让它们在同时收集时共享信息例如到目前为止收集的最差得分热门匹配甚至在所有线程中使用单个共享优先级队列 。 共享优先级队列可能会导致过多的锁定因此作为一种折衷现在搜索可以高效地共享搜索者线程中收集到的最差命中值中的最好值 这显示了令人印象深刻的luceneutil 基准测试结果 。 这些改进减少了并发搜索的额外成本但是该成本永远不可能为零因为更频繁的线程上下文切换共享优先级队列的锁争用命中计数器和优先级队列底部以及潜在的困难后果都会带来固有的自然成本。现代非均匀内存架构NUMA 。 Lucene并发搜索的一个令人惊讶且令人失望的局限性在于完全合并的索引直至单个段会丢失所有并发性 这就是Bizarro World 因为通常可以将其索引合并到一个段中以提高查询性能 但是当您查看长杆查询延迟时不幸的是完全合并的索引会变慢因为即使您将Executor传递给IndexSearcher所有查询现在都将再次成为单线程。 即使单个新近完成的大型合并也会在您的长极点延迟中引起锯齿状因为它会减少净查询并发尽管通过这种合并红线群集的吞吐能力仍然有所提高。 解决这个问题的一个简单想法是允许多个线程搜索一个大的段 这应该很好用因为Lucene具有自然的API可以在段的“ docid空间”中搜索单独的区域。 自让-弗朗索瓦·哈勒克斯Jean-FrançoisHalleux首次为Lucene提出并行搜索以来并发搜索已经走了很长一段路我希望它还有很长的路要走以使我们真正减少使用多线程进行昂贵查询的额外开销。 随着Lucene改进其查询计划和优化我们将达到轻松查询运行单线程但代价高昂的查询同时高效运行的地步。 这些改进必须归功于Lucene现代服务器继续添加越来越多的内核但并没有使这些内核变得太快因此不可避免的是包括Lucene在内的现代软件必须找到有效利用所有这些并发性的方法。 [我在亚马逊工作并且本网站上的帖子属于我本人不一定代表亚马逊的职位] 翻译自: https://www.javacodegeeks.com/2019/10/concurrent-query-execution-apache-lucene.htmlapache lucene
