Индексирование Solr - репликация Master / Slave, как справиться с огромным индексом и высоким трафиком?

В настоящее время я столкнулся с проблемой с SOLR (точнее с репликацией ведомых устройств), и, потратив немало времени на чтение в Интернете, я обнаружил, что мне нужно попросить некоторого просветления.

- Есть ли у Solr ограничения по размеру индекса?

Когда вы имеете дело с одним мастером, когда наступает подходящий момент для принятия решения об использовании многоядерных процессоров или нескольких индексов? Есть ли какие-либо указания на то, что при достижении определенного размера индекса рекомендуется секционирование?

- Есть ли максимальный размер при репликации сегментов от главного устройства к подчиненному?

Есть ли ограничение на размер сегмента при репликации, когда ведомое устройство не сможет загрузить контент и проиндексировать его? Каков порог, до которого ведомое устройство не сможет выполнить репликацию, когда имеется большой трафик для получения информации и много новых документов для репликации.

Чтобы быть более точным, вот контекст, который привел меня к этим вопросам: мы хотим проиндексировать изрядное количество документов, но когда количество достигает более десятка миллионов, ведомые устройства не могут справиться с этим и начинают сбоить репликацию с помощью Ошибка SnapPull. Документы состоят из нескольких текстовых полей (имя, тип, описание, ... около 10 других полей, скажем, максимум 20 символов).

У нас есть один мастер и 2 подчиненных устройства, которые реплицируют данные от мастера.

Я впервые работаю с Solr (обычно я работаю с веб-приложениями, используя spring, hibernate ... но не использую 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 Failed», кажется, исчезла, возникла еще одна ошибка, не знаю почему, поскольку я не могу найти много ответа в Интернете:

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)

Мне все еще интересно, как лучше всего обрабатывать большой индекс (более 20 ГБ), содержащий много документов, с помощью solr. Я где-то упускаю какие-то очевидные ссылки? Учебники, документация?


person Fanny H.    schedule 13.11.2010    source источник
comment
какой механизм репликации вы использовали? на основе java или сценария?   -  person Karussell    schedule 17.11.2010
comment
Все сделано на Java (репликация solr http). Мастер является загрузчиком данных и все индексирует, а подчиненные устройства копируют мастер. Первая ошибка SnapPuller не удалось, когда мы добавили кучу документов. Мастер справился с этим отлично, но подчиненные начали отказываться, предположительно из-за внезапно появившихся больших сегментов для репликации. Вот почему я просил совета о том, как лучше всего масштабировать solr, этот документ был мне полезен: lucidimagination.com/Community/Hear-from-the-Experts/Articles/   -  person Fanny H.    schedule 20.11.2010


Ответы (1)


  • Ядра - это инструмент, который в основном используется для создания разных схем в одном экземпляре Solr. Также используется в качестве палубных указателей. Шардинг и репликация - ортогональные проблемы.
  • Вы упомянули "большой трафик". Это очень субъективный показатель. Вместо этого попробуйте определить, сколько QPS (запросов в секунду) вам нужно от Solr. Кроме того, достаточно ли быстро отвечает один экземпляр Solr на ваши запросы? Только после этого вы сможете определить, требуется ли масштабирование. Один экземпляр Solr может обрабатывать большой трафик, возможно, вам даже не нужно масштабировать.
  • Убедитесь, что вы запускаете Solr на сервере с большим объемом памяти (и убедитесь, что у Java есть к нему доступ). Solr довольно требователен к памяти, если вы поместите его на сервер с ограниченным объемом памяти, производительность снизится.
  • Как объясняется в вики Solr, используйте сегментирование, если один запрос занимает слишком много времени для выполнения, и репликацию, если один экземпляр Solr не может обрабатывать трафик. "Слишком длинный" и "трафик" зависят от вашего конкретного приложения. Измерьте их.
  • Solr имеет множество настроек, которые влияют на производительность: автоматическое нагревание кеша, сохраненные поля, коэффициент слияния и т. Д. Ознакомьтесь с SolrPerformanceFactors.
  • Здесь нет жестких правил. У каждого приложения разные потребности в поиске. Моделируйте и измеряйте для вашего конкретного сценария.
  • Что касается ошибки репликации, убедитесь, что вы используете 1.4.1, поскольку в 1.4.0 была ошибка репликации.
person Mauricio Scheffer    schedule 13.11.2010
comment
Спасибо за эти объяснения. Мы используем 1.4.0, если я правильно помню, поэтому я попробую в понедельник, когда вернусь к работе с 1.4.1, и посмотрю, решит ли это проблему. Я почти уверен, что мы максимально исчерпали память на сервере, на котором работает solr, поэтому мы не можем получить больше улучшений на этой стороне. Следовательно, при работе с более чем десятками миллионов документов возникает вопрос, является ли выбранный нами дизайн (1 ведущее устройство, которое обрабатывает и индексирует документы, и 2 ведомых устройства для репликации и обработки трафика), является идеальным. - person Fanny H.; 13.11.2010
comment
Считается ли 8 ГБ памяти, выделенной для JVM, достаточным? (на лезвии, у которого всего 10G). Что касается QPS, то он не такой высокий, от 5 до 10 QPS в зависимости от времени суток, но новые документы добавляются в индекс каждую секунду. Возможно, нет необходимости в масштабировании, но если нам это нужно (поскольку в настоящее время он не работает из-за ошибки SnapPull), как это будет обрабатываться, если ядра - это неправильный путь? - person Fanny H.; 15.11.2010
comment
@Fanny: 5-10 QPS - это немного. Но слишком частые коммиты убьют производительность. - person Mauricio Scheffer; 16.11.2010
comment
К сожалению, обновление наших библиотек до версии 1.4.1 не помогло. Исключение с ошибкой SnapPull все еще генерируется (невозможно полностью загрузить сегменты_xxx ...). - person Fanny H.; 16.11.2010
comment
@MauricioScheffer извините за повторное открытие старого сообщения, но, как описано на stackoverflow.com/questions/47771564/keep-solr-slaves-in-sync/ у нас возникла ситуация, когда нам нужно несколько реплицированных (не совместно используемых!) ведомых устройств, подключенных к одному мастеру. Как мы можем гарантировать, что все подчиненные устройства имеют одинаковую версию индекса каждый раз, потому что репликация / опрос обрабатывается специально для каждого подчиненного устройства? - person rabudde; 13.12.2017