fuente original: HTTPS: //www.loggly.com/blog/p ...
En el artículo anterior ( ES VS Solr ) hemos mencionado, ES para construir una gran cantidad de funcionalidad central Loggly En el curso de esta tecnología de búsqueda universal para nuestro sistema de gestión de registros, y más de más de 5.000 clientes con servicios en tiempo casi real crecemos mucho en la tecnología. acuerdo con nuestro respeto por la comunidad de código abierto, con la esperanza de que este conocimiento que hemos aprendido de nuevo a la comunidad.
Este artículo explorará los conceptos clave tiene repercusiones de gran alcance en el rendimiento de los procesos de expansión ES: cluster state.
¿Cuál es el estado del clúster
Una ventaja particular es que el ES sujeta a reglas modelo libre. En un primer momento, se puede añadir una contener cualquier número de campos de un documento en el índice, pero no necesita para avanzar en este tipo de campos definidos en el ES. Estos campos se pueden agregar al índice y, posteriormente, la búsqueda es una cosa emocionante. pero los nombres de estos campos, tipos, y se añaden a la información del índice se añadirán automáticamente a la eS cluster stateinformación (asumiendo que usted está utilizando el valor por defecto la configuración de asignación dinámica . Por supuesto, como eS al igual que la otra configuración, se puede ajustar o desactivar este comportamiento).
Por supuesto, también hay algunos secretos: Si (como número entero) al tratar de alinear los valores de campo de un existentes añadir otro tipo (como cadena), ES se producirá un error. El mismo campo en el mismo índice no puede tener ambas cosas dos tipos diferentes . esto se llama conflicto de asignación eS depende del tipo de procesamiento necesario, por ejemplo, ..:
-
Si se añade el valor entero a un tipo de cadena, un elenco será
-
Si se añade la cadena para el valor de un tipo entero, se encontrará con una excepción, ES rechazar el documento.
Así que los próximos preocupaciones de su respuesta ES, especialmente cuando se utiliza mayor índice de hacerlo por lotes.
estado del clúster es una referencia importante para usted
Al igual que otras índice invertido, al igual que, cuando la búsqueda de datos, ES necesita saber la meta-información y la ubicación de almacenamiento de los datos. Cuando el nodo recibe la petición de consulta, lo primero que debe hacer es el objeto que desea consulta en la que el parche, y luego juez qué campos y sus tipos en el índice. (no se puede realizar una consulta en un rango de números de campo de tipo cadena). y esta información es registrada en el estado del clúster.
Como el nombre sugiere, la información de estado de clúster es global, todo el conjunto que contiene toda la rebanada meta-información (reglas, ubicación, tamaño y otra información), la información de cada sección y el mantenimiento de cada sincronización.
En un clúster que contiene un gran número de nodos, ES es cómo hacerlo sincronizar la información? ES información original estado del clúster es mantenido por el nodo maestro, cuando se recibe un cambio de nodo de actualizaciones de estado de los datos, poner éstos en información de difusión a su vez a otros nodos, y nada más.
Si el estado del clúster se actualiza cada 2 minutos y 300 lbs
Recuerde: estado del clúster es el clúster de todos los campos de información para cada rebanada de cada índice en cada nodo contiene Si usted tiene un gran número de campos, tales como la ES como un gran número de volátiles y tienen documento de normas no fijo. almacenamiento, entonces el estado del clúster será enorme. Loggly exactamente que en el servicio, porque los clientes nos envían el formato de documento, contener un campo único de datos arbitrarios, y el número de la amplitud más grande. nos ocupamos de cientos de miles de peticiones por segundo por lo tanto Loggly el estado del clúster puede llegar a cientos de megabytes de tamaño.
Espero que vea la puerta de la luz
Tal vez ya sonaba un sonido de advertencia en su mente: .. "¿Quieres decir cuando hay algún cambio, ES emisiones cientos de megabytes de datos a diferentes nodos" Tal vez el hecho de que no es tan malo como usted piensa en la gestión de estado del clúster , ES ha hecho varias optimización:
-
Desde ES2.0, los cambios en la información de estado de clúster sólo será transmitido. En comparación con la versión anterior, que trae ganancias significativas en el rendimiento.
-
Antes de la transmisión de los nodos de información antes de ES, ES para estado del clúster hicieron efecto obvio de la compresión.
-
ES muy sabia en las actualizaciones de estado del clúster consolidadas, y el procesamiento por lotes, en particular, la reciente versión ES. (En un artículo posterior tareas pendientes introducirá tiempo de procesamiento interno de versiones anteriores sin hacer estas optimizaciones)
Aun así, a menudo preocupados por el estado del clúster también es necesaria. Además, nos encontramos con que el primero que debe hacer antes de ejecutar a gran escala a principios de Es clúster, índice de grandes cantidades de datos, consiste en poner un límite a la cantidad de datos del cluster estado de ES, para evitar exceder el ES procesamiento de fallo de energía causada por la agrupación de estado del clúster problema más serio - y en Loggly, cómo se resuelve el problema del estado del clúster - será presentado en un artículo futuro, espero que usted puede ayudar .
Ejemplos de estado del clúster
Aquí está teniendo un clúster de dos nodos, que contiene la información de estado del clúster de un índice único documento. Por supuesto, esto es muy diferente con los datos que tenemos en la escena real, porque hay una gran cantidad de máquinas y una gran cantidad de nuestro cluster mapeo ínodo número y más allá de su imaginación. pero el ejemplo suficiente para que pueda entender la información contenida en el estado del clúster.
{
"cluster_name" : "elasticsearch",
"version" : 11,
"master_node" : "-mq1SRuuQoeEq-3S8SdHqw",
"blocks" : { },
"nodes" : {
"sIh5gQcFThCcz3SO6txvvQ" : {
"name" : "Max",
"transport_address" : "inet[/162.245.23.194:9301]",
"attributes" : { }
},
"-mq1SRuuQoeEq-3S8SdHqw" : {
"name" : "Llyron",
"transport_address" : "inet[/162.245.23.194:9300]",
"attributes" : { }
}
},
"metadata" : {
"templates" : { },
"indices" : {
"blog" : {
"state" : "open",
"settings" : {
"index" : {
"uuid" : "UQMz5vbXSBqFU_8U3u4gYQ",
"number_of_replicas" : "1",
"number_of_shards" : "5",
"version" : {
"created" : "1030099"
}
}
},
"mappings" : {
"user" : {
"properties" : {
"name" : {
"type" : "string"
}
}
}
},
"aliases" : [ ]
}
}
},
"routing_table" : {
"indices" : {
"blog" : {
"shards" : {
"4" : [ {
"state" : "STARTED",
"primary" : true,
"node" : "sIh5gQcFThCcz3SO6txvvQ",
"relocating_node" : null,
"shard" : 4,
"index" : "blog"
}, {
"state" : "STARTED",
"primary" : false,
"node" : "-mq1SRuuQoeEq-3S8SdHqw",
"relocating_node" : null,
"shard" : 4,
"index" : "blog"
} ],
"0" : [ {
"state" : "STARTED",
"primary" : true,
"node" : "sIh5gQcFThCcz3SO6txvvQ",
"relocating_node" : null,
"shard" : 0,
"index" : "blog"
}, {
"state" : "STARTED",
"primary" : false,
"node" : "-mq1SRuuQoeEq-3S8SdHqw",
"relocating_node" : null,
"shard" : 0,
"index" : "blog"
} ],
"3" : [ {
"state" : "STARTED",
"primary" : false,
"node" : "sIh5gQcFThCcz3SO6txvvQ",
"relocating_node" : null,
"shard" : 3,
"index" : "blog"
}, {
"state" : "STARTED",
"primary" : true,
"node" : "-mq1SRuuQoeEq-3S8SdHqw",
"relocating_node" : null,
"shard" : 3,
"index" : "blog"
} ],
"1" : [ {
"state" : "STARTED",
"primary" : false,
"node" : "sIh5gQcFThCcz3SO6txvvQ",
"relocating_node" : null,
"shard" : 1,
"index" : "blog"
}, {
"state" : "STARTED",
"primary" : true,
"node" : "-mq1SRuuQoeEq-3S8SdHqw",
"relocating_node" : null,
"shard" : 1,
"index" : "blog"
} ],
"2" : [ {
"state" : "STARTED",
"primary" : true,
"node" : "sIh5gQcFThCcz3SO6txvvQ",
"relocating_node" : null,
"shard" : 2,
"index" : "blog"
}, {
"state" : "STARTED",
"primary" : false,
"node" : "-mq1SRuuQoeEq-3S8SdHqw",
"relocating_node" : null,
"shard" : 2,
"index" : "blog"
} ]
}
}
}
},
"routing_nodes" : {
"unassigned" : [ ],
"nodes" : {
"sIh5gQcFThCcz3SO6txvvQ" : [ {
"state" : "STARTED",
"primary" : true,
"node" : "sIh5gQcFThCcz3SO6txvvQ",
"relocating_node" : null,
"shard" : 4,
"index" : "blog"
}, {
"state" : "STARTED",
"primary" : true,
"node" : "sIh5gQcFThCcz3SO6txvvQ",
"relocating_node" : null,
"shard" : 0,
"index" : "blog"
}, {
"state" : "STARTED",
"primary" : false,
"node" : "sIh5gQcFThCcz3SO6txvvQ",
"relocating_node" : null,
"shard" : 3,
"index" : "blog"
}, {
"state" : "STARTED",
"primary" : false,
"node" : "sIh5gQcFThCcz3SO6txvvQ",
"relocating_node" : null,
"shard" : 1,
"index" : "blog"
}, {
"state" : "STARTED",
"primary" : true,
"node" : "sIh5gQcFThCcz3SO6txvvQ",
"relocating_node" : null,
"shard" : 2,
"index" : "blog"
} ],
"-mq1SRuuQoeEq-3S8SdHqw" : [ {
"state" : "STARTED",
"primary" : false,
"node" : "-mq1SRuuQoeEq-3S8SdHqw",
"relocating_node" : null,
"shard" : 4,
"index" : "blog"
}, {
"state" : "STARTED",
"primary" : false,
"node" : "-mq1SRuuQoeEq-3S8SdHqw",
"relocating_node" : null,
"shard" : 0,
"index" : "blog"
}, {
"state" : "STARTED",
"primary" : true,
"node" : "-mq1SRuuQoeEq-3S8SdHqw",
"relocating_node" : null,
"shard" : 3,
"index" : "blog"
}, {
"state" : "STARTED",
"primary" : true,
"node" : "-mq1SRuuQoeEq-3S8SdHqw",
"relocating_node" : null,
"shard" : 1,
"index" : "blog"
}, {
"state" : "STARTED",
"primary" : false,
"node" : "-mq1SRuuQoeEq-3S8SdHqw",
"relocating_node" : null,
"shard" : 2,
"index" : "blog"
} ]
}
},
"allocations" : [ ]
}
