java - tools - para que sirve flyway

Alternativa de migración de base de datos Liquibase o Flyway para Elasticsearch (1)

Soy bastante nuevo en ES. He estado tratando de buscar una herramienta de migración de db por mucho tiempo y no pude encontrar una. Me pregunto si alguien podría ayudarme a señalarme la dirección correcta.

Estaría usando Elasticsearch como un almacén de datos principal en mi proyecto. Me gustaría la versión de todos los scripts de cambios de configuración y configuración / importación de datos / actualizaciones de datos que ejecuto mientras desarrollo nuevos módulos en mi proyecto.

En el pasado usé herramientas de versionamiento de bases de datos como Flyway o Liquibase.

¿Existen marcos / scripts o métodos que podría usar con ES para lograr algo similar?

¿Alguien tiene experiencia en hacer esto manualmente usando scripts y ejecutando scripts de migración al menos actualizando scripts?

¡Gracias por adelantado!

Desde este punto de vista / necesidad, los ES tienen una gran limitación:

A pesar de tener mapeo dinámico, ES no es esquemático sino que requiere un uso intensivo del esquema. Las asignaciones no se pueden cambiar en caso de que este cambio entre en conflicto con los documentos existentes (prácticamente, si alguno de los documentos tiene un campo no nulo al que afecta la nueva asignación, esto resultará en una excepción)
Los documentos en ES son inmutables: una vez que haya indexado uno, puede recuperar / eliminar solo. El azúcar sintáctico en torno a esto es una actualización parcial, lo que hace que la eliminación segura de subprocesos + índice (con la misma identificación) en el lado ES

¿Qué significa eso en el contexto de tu pregunta? Básicamente, usted no puede tener herramientas de migración clásicas para ES. Y esto es lo que puede hacer que su trabajo con ES sea más fácil:

utilice la asignación estricta ( "dynamic": "strict" y / o index.mapper.dynamic: false , eche un vistazo a la documentación de asignación ). Esto protegerá sus índices / tipos de
- ser accidentalmente asignado dinámicamente con el tipo incorrecto
- obtén un error explícito en caso de que pierdas algún error en la relación de mapeo de datos
puede obtener la asignación de ES real y compararla con sus modelos de datos. Si su PL tiene una biblioteca de nivel suficientemente alto para ES, esto debería ser bastante fácil
Puede aprovechar los alias de índice para las migraciones

Entonces, un poco de experiencia. Para mí, actualmente el flujo razonable es este:

Todas las estructuras de datos descritas como modelos en código. Estos modelos realmente proporcionan la abstracción ORM también.
Llamada de creación de índice / mapeo es el método del modelo simple.
Cada índice tiene un alias (es decir, news ) que apunta al índice real (es decir, news_index_{revision}_{date_created} ).

Cada vez que se implementa el código, usted

Trate de poner mapeo modelo (tipo). Si se hace sin error, esto significa que has
- poner el mismo mapeo
- Coloque el mapeo que es un superconjunto puro del antiguo (solo se proporcionaron nuevos campos, los antiguos no se han tocado)
- Ningún documento tiene valores en los campos afectados por la nueva asignación
Todo esto en realidad significa que es bueno ir con el mapeo / datos que tiene, solo trabaje con datos como siempre
Si ES proporciona una excepción sobre la nueva asignación,
- crear nuevo índice / tipo con nueva asignación (llamada como name_{revision}_{date}
- redirige tu alias al nuevo índice
- inicie el código de migración que realiza solicitudes bulk de reindexación rápida Durante esta reindexación, puede indexar nuevos documentos de manera segura a través del alias. El inconveniente es que los datos históricos están parcialmente disponibles durante la reindexación.

Esta es una solución probada en producción. Advertencias en torno a este enfoque:

Usted no puede hacer eso, si sus solicitudes de lectura requieren datos históricos consistentes
estás obligado a reindexar todo el índice. Si tiene 1 tipo por índice (solución viable), entonces está bien. Pero a veces necesitas índices multitipo.
red de datos de ida y vuelta. A veces puede ser dolor

Para resumir esto:

Intenta tener una buena abstracción en tus modelos, esto siempre ayuda.
intente mantener los datos históricos / campos obsoletos. Solo construye tu código con esta idea en mente, eso es más fácil que los sonidos al principio
Recomiendo encarecidamente que evite confiar en las herramientas de migración que aprovechan las herramientas experimentales de ES. Se pueden cambiar en cualquier momento, como lo hicieron las herramientas de river-* .