indexación de Solr: replicación maestro/esclavo, cómo manejar un gran índice y alto tráfico?

Actualmente estoy enfrentando un problema con SOLR (más exactamente con la réplica de los esclavos) y después de haber pasado bastante tiempo leyendo en línea, tengo que pedir algo de iluminación.indexación de Solr: replicación maestro/esclavo, cómo manejar un gran índice y alto tráfico?

- ¿Tiene Solr alguna limitación de tamaño para su índice?

Cuando se trata de un solo maestro, ¿cuándo es el momento adecuado para decidir utilizar múltiples núcleos o múltiples índices? ¿Hay alguna indicación sobre cuándo alcanzar un determinado tamaño de índice, se recomienda la partición?

- ¿Hay algún tamaño máximo al replicar segmentos de maestro a esclavo?

Al replicar, ¿hay un límite de tamaño de segmento cuando el esclavo no podrá descargar el contenido e indexarlo? ¿Cuál es el umbral al que un esclavo no podrá replicar cuando hay mucho tráfico para recuperar información y muchos documentos nuevos para replicar.

Para ser más fáctico, este es el contexto que me llevó a estas preguntas: Queremos indexar una buena cantidad de documentos, pero cuando la cantidad llega a más de una docena de millones, los esclavos no pueden manejarlo y comienza a fallar la replicación con un error de SnapPull. Los documentos están compuestos por unos pocos campos de texto (nombre, tipo, descripción, ... aproximadamente 10 campos diferentes, digamos 20 caracteres como máximo).

Tenemos un maestro y 2 esclavos que replican los datos del maestro.

Esta es la primera vez que trabajo con Solr (normalmente trabajo en webapps usando Spring, hibernate ... pero no uso Solr), así que no estoy seguro de cómo abordar este problema.

Nuestra idea es, por el momento, agregar múltiples núcleos al maestro y tener un esclavo replicando desde cada uno de estos núcleos. ¿Es el camino correcto a seguir?

Si lo es, ¿cómo podemos determinar la cantidad de núcleos necesarios? En este momento solo vamos a tratar de ver cómo se comporta y ajustar si es necesario, pero me preguntaba si había algunas mejores prácticas o algunos puntos de referencia que se han hecho sobre este tema específico.

Para esta cantidad de documentos con este tamaño medio, x se necesitan núcleos o índices ...

Gracias por cualquier ayuda en cómo podría hacer frente a una gran cantidad de documentos de tamaño medio!

Aquí es una copia del error que se produce cuando un esclavo está tratando de replicar:

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

EDITAR: Después de la respuesta de Mauricio, las bibliotecas Solr se han actualizado a 1.4. 1 pero este error aún se planteó. he aumentado la commitReserveDuration e incluso si el "SnapPull falló" error parece haber desaparecido, comenzó a ser levantado otra, sin saber por qué, ya que parece que no puede encontrar mucha respuesta en la web:

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)

Todavía me pregunto cuáles son las mejores prácticas para manejar un gran índice (más de 20G) que contiene una gran cantidad de documentos con solr. ¿Me faltan algunos enlaces obvios en alguna parte? Tutoriales, documentaciones?

Fuente

2010-11-13 Fanny H.

qué mecanismo de replicación usaste? java o basado en script? – Karussell

Todo se hace en Java (solr http replicación). El maestro es el cargador de datos e indexa todo, y los esclavos replican el maestro. El primer error "Falló SnapPuller" ocurrió cuando agregamos un grupo de documentos. El maestro lo manejó muy bien, pero los esclavos comenzaron a fallar, supuestamente debido a los segmentos repentinamente más grandes para replicar. Esta es la razón por la que estaba pidiendo algunos consejos sobre cuál era la mejor manera de escalar Solr, este documento ha sido útil: http://www.lucidimagination.com/Community/Hear-from-the-Experts/Articles/Scaling-Lucene -and-Solr # d0e410 –

Los núcleos son una herramienta utilizada principalmente para tener diferentes esquemas en una única instancia de Solr. También se usa como índices en cubierta. Sharding y replicación son cuestiones ortogonales.
Usted menciona "mucho tráfico". Esa es una medida altamente subjetiva. En su lugar, intente determinar cuántos QPS (consultas por segundo) necesita de Solr. Además, ¿una sola instancia de Solr responde tus consultas lo suficientemente rápido? Solo entonces puede determinar si necesita escalar. Una sola instancia de Solr puede manejar mucho tráfico, tal vez ni siquiera necesite escalar.
Asegúrese de ejecutar Solr en un servidor con mucha memoria (y asegúrese de que Java tenga acceso a él). Solr está bastante hambriento de memoria, si lo pones en un servidor con memoria limitada, el rendimiento sufrirá.
Como explica el wiki de Solr, utilice la fragmentación si una sola consulta tarda demasiado en ejecutarse, y la replicación si una sola instancia de Solr no puede manejar el tráfico. "Demasiado tiempo" y "tráfico" dependen de su aplicación particular. Mídelos.
Solr tiene una gran cantidad de configuraciones que afectan el rendimiento: caché de autocalentamiento, campos almacenados, factor de fusión, etc. Check out SolrPerformanceFactors.
Aquí no hay reglas estrictas. Cada aplicación tiene diferentes necesidades de búsqueda. Simula y mide para tu escenario particular.
Acerca del error de replicación, asegúrese de estar ejecutando 1.4.1 dado que 1.4.0 tenía un error con la replicación.

Fuente

2010-11-13 03:44:35

Gracias por estas explicaciones. Usamos 1.4.0 si recuerdo correctamente, así que intentaré el lunes cuando regrese al trabajo con 1.4.1 y veré si esto resuelve el problema. Estoy bastante seguro de que hemos agotado al máximo la memoria en el servidor donde se ejecuta Solr, por lo que no podemos obtener muchas más mejoras en este lado. De ahí la pregunta sobre cuándo tratar con más de docenas de millones de documentos, el diseño que elegimos (1 maestro que procesa e indexa los documentos y 2 esclavos para la replicación y el manejo del tráfico) es el ideal. –

¿Se consideran suficientes las 8G de memoria asignadas para la JVM? (en una cuchilla que tiene 10G en total). Con respecto al QPS, no es tan alto, de 5 a 10 QPS dependiendo de la hora del día, pero se agregan nuevos documentos al índice cada segundo. Quizás no sea necesario escalar, pero si lo necesitamos (ya que actualmente falla debido al error de SnapPull), ¿cómo se manejaría esto si los núcleos no son el camino correcto a seguir? –

@ Fanny: 5-10 QPS no es mucho. Pero las confirmaciones demasiado frecuentes matarán el rendimiento. –

indexación de Solr: replicación maestro/esclavo, cómo manejar un gran índice y alto tráfico?

Respuesta

Cuestiones relacionadas