Solr索引 - 主/从复制,如何处理巨大的索引和高流量?
我目前正面临一个SOLR问题(更确切地说是与奴隶复制),并花了很多时间在网上阅读后,我发现自己不得不寻求一些启发。Solr索引 - 主/从复制,如何处理巨大的索引和高流量?
- Solr的索引大小是否有限制?
在处理单个主设备时,何时决定使用多核还是多索引? 有什么迹象表明在达到一定大小的索引时,建议进行分区?
- 从主控制器到从属控制器复制段时是否有最大尺寸?
复制时,从站是否无法下载内容并对其进行索引时是否存在段大小限制?当大量流量检索信息和许多新文档复制时,从属将无法复制的阈值是多少。
事实上,下面是导致我遇到这些问题的上下文: 我们想索引大量的文档,但是当数量达到十几百万时,奴隶无法处理它,用SnapPull错误开始失败复制。 这些文档由几个文本字段组成(名称,类型,描述,...约10个其他字段,比如说最多20个字符)。
我们有一个master和2个从master复制数据的slave。
这是我第一次使用Solr(我通常在使用spring,hibernate的webapps上工作,但没有使用Solr),所以我不知道如何解决这个问题。
我们的想法是,现在向主控添加多个内核,并从每个内核复制一个从控制器。 这是正确的路吗?
如果是这样,我们如何确定需要的内核数量?现在我们只是试图了解它的行为和必要性,但我想知道是否有关于这个特定主题的最佳实践或某些基准。
对于这一数额与该平均大小的文件,X需要内核或索引...
感谢您对我怎么能应付庞大的平均大小的文件量的任何帮助!
以下是错误的副本被抛出时,从试图复制:
ERROR [org.apache.solr.handler.ReplicationHandler] - <SnapPull failed >
org.apache.solr.common.SolrException: Index fetch failed :
at org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:329)
at org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:264)
at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:159)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException: java.io.IOException: read past EOF
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1068)
at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:418)
at org.apache.solr.handler.SnapPuller.doCommit(SnapPuller.java:467)
at org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:319)
... 11 more
Caused by: java.io.IOException: read past EOF
at org.apache.lucene.store.BufferedIndexInput.refill(BufferedIndexInput.java:151)
at org.apache.lucene.store.BufferedIndexInput.readByte(BufferedIndexInput.java:38)
at org.apache.lucene.store.IndexInput.readInt(IndexInput.java:70)
at org.apache.lucene.index.SegmentInfos$2.doBody(SegmentInfos.java:410)
at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:704)
at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:538)
at org.apache.lucene.index.SegmentInfos.readCurrentVersion(SegmentInfos.java:402)
at org.apache.lucene.index.DirectoryReader.isCurrent(DirectoryReader.java:791)
at org.apache.lucene.index.DirectoryReader.doReopen(DirectoryReader.java:404)
at org.apache.lucene.index.DirectoryReader.reopen(DirectoryReader.java:352)
at org.apache.solr.search.SolrIndexReader.reopen(SolrIndexReader.java:413)
at org.apache.solr.search.SolrIndexReader.reopen(SolrIndexReader.java:424)
at org.apache.solr.search.SolrIndexReader.reopen(SolrIndexReader.java:35)
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1049)
... 14 more
编辑: 毛的回答后,Solr的库已更新到1.4。 1但这个错误仍然被提出。 我增加了commitReserveDuration而且即使“SnapPull失败”的错误似乎已经消失,一个又一个开始被提出,不知道为什么看起来,我不能在网上找到很多答案:
ERROR [org.apache.solr.servlet.SolrDispatchFilter] - <ClientAbortException: java.io.IOException
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:370)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:323)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:396)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:385)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:89)
at org.apache.solr.common.util.FastOutputStream.flushBuffer(FastOutputStream.java:183)
at org.apache.solr.common.util.JavaBinCodec.marshal(JavaBinCodec.java:89)
at org.apache.solr.request.BinaryResponseWriter.write(BinaryResponseWriter.java:48)
at org.apache.solr.servlet.SolrDispatchFilter.writeResponse(SolrDispatchFilter.java:322)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.jstripe.tomcat.probe.Tomcat55AgentValve.invoke(Tomcat55AgentValve.java:20)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:837)
at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:640)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1286)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.IOException
at org.apache.coyote.http11.InternalAprOutputBuffer.flushBuffer(InternalAprOutputBuffer.java:703)
at org.apache.coyote.http11.InternalAprOutputBuffer$SocketOutputBuffer.doWrite(InternalAprOutputBuffer.java:733)
at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:124)
at org.apache.coyote.http11.InternalAprOutputBuffer.doWrite(InternalAprOutputBuffer.java:539)
at org.apache.coyote.Response.doWrite(Response.java:560)
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:365)
... 22 more
>
ERROR [org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/].[SolrServer]] - <Servlet.service() for servlet SolrServer threw exception>
java.lang.IllegalStateException
at org.apache.catalina.connector.ResponseFacade.sendError(ResponseFacade.java:405)
at org.apache.solr.servlet.SolrDispatchFilter.sendError(SolrDispatchFilter.java:362)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.jstripe.tomcat.probe.Tomcat55AgentValve.invoke(Tomcat55AgentValve.java:20)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:837)
at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:640)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1286)
at java.lang.Thread.run(Thread.java:595)
我仍然想知道如何处理包含大量solr文档的大型索引(超过20G)的最佳实践。我在某处丢失了一些明显的链接吗?教程,文件?
- 内核是主要用于在单个Solr实例中具有不同架构的工具。也用作甲板上索引。分片和复制是正交的问题。
- 你提到“很多交通”。这是一个非常主观的措施。相反,尝试确定您需要从Solr获得多少QPS(每秒查询)。另外,单个Solr实例是否足够快地回答您的查询?只有这样你才能确定是否需要向外扩展。一个Solr实例可以处理很多流量,也许你甚至不需要扩展。
- 请确保您在具有大量内存的服务器上运行Solr(并确保Java有权访问它)。 Solr的内存很大,如果将其放在内存受限的服务器上,性能将受到影响。
- 正如Solr wiki解释的那样,如果单个查询花费太长时间运行,则使用分片,如果单个Solr实例无法处理流量,则使用分片。 “太长”和“流量”取决于您的特定应用。衡量他们。
- Solr有很多影响性能的设置:缓存自动加温,存储字段,合并因子等。检出SolrPerformanceFactors。
- 这里没有硬性规定。每个应用都有不同的搜索需求。针对您的特定场景进行模拟和测量。
- 关于复制错误,请确保您正在运行1.4.1,因为1.4.0有复制错误。
感谢您的这些解释。如果我没有记错的话,我们使用1.4.0,所以当我回到1.4.1的时候,我会在星期一尝试一下,看看是否能解决这个问题。我很确定我们在solr运行的服务器上清除了内存,所以我们无法在这方面获得更多的改进。因此,在处理超过几十万个文档时,我们选择的设计(1个用于处理和索引文档以及2个用于复制和处理流量的从属主机)是最理想的设计。 – 2010-11-13 04:27:32
为JVM分配的内存8G是否足够? (在总共10G的刀片上)。关于QPS,它不是那么高,取决于一天中的时间大约5到10个QPS,但是每秒都有新的文件被添加到索引中。也许没有必要扩大规模,但如果我们确实需要(因为SnapPull错误导致目前失败),如果内核不是正确的路要走,这将如何处理? – 2010-11-15 18:16:03
@Fanny:5-10 QPS并不多。但过于频繁的提交会导致性能下降。 – 2010-11-15 21:00:55
您使用了哪种复制机制?基于java还是脚本? – Karussell 2010-11-17 08:41:29
一切都在Java中完成(solr http复制)。主设备是数据加载器并索引所有内容,而从设备则复制主设备。当我们添加一堆文档时,发生了第一个错误“SnapPuller失败”。大师处理它很好,但奴隶开始失败,据说由于突然更大的细分市场复制。这就是为什么我要问什么是最好的方法来扩大solr,这个文件是有帮助的:http://www.lucidimagination.com/Community/Hear-from-the-Experts/Articles/Scaling-Lucene - 和 - Solr#d0e410 – 2010-11-19 21:51:43