Elasticsearch 的 Liquibase 或 Flyway 数据库迁移替代方案 [英] Liquibase or Flyway database migration alternative for Elasticsearch

问题描述

我对 ES 还很陌生.我一直在尝试搜索数据库迁移工具，但找不到.我想知道是否有人可以帮助我指出正确的方向.

I am pretty new to ES. I have been trying to search for a db migration tool for long and I could not find one. I am wondering if anyone could help to point me to the right direction.

我将使用 Elasticsearch 作为我项目中的主要数据存储.我想对我在项目中开发新模块时运行的所有映射和配置更改/数据导入/数据升级脚本进行版本控制.

I would be using Elasticsearch as a primary datastore in my project. I would like to version all mapping and configuration changes / data import / data upgrades scripts which I run as I develop new modules in my project.

过去我使用过数据库版本控制工具，如 Flyway 或 Liquibase.

In the past I used database versioning tools like Flyway or Liquibase.

是否有任何框架/脚本或方法可以与 ES 一起使用来实现类似的目标?

Are there any frameworks / scripts or methods I could use with ES to achieve something similar ?

有没有人有任何使用脚本手动执行此操作的经验，并且至少运行迁移脚本升级脚本.

Does anyone have any experience doing this by hand using scripts and run migration scripts at least upgrade scripts.

提前致谢！

推荐答案

从这个角度/需求来看，ES有很大的局限性:

From this point of view/need, ES have a huge limitations:

• 尽管具有动态映射，但 ES 不是无模式，而是模式密集型.如果此更改与现有文档冲突，则无法更改映射(实际上，如果任何文档具有受新映射影响的非空字段，这将导致异常)
• ES 中的文档是不可变的:一旦你索引了一个，你只能检索/删除.围绕这个的语法糖是部分更新，这使得 ES 端的线程安全删除 + 索引(具有相同的 id)

• despite having dynamic mapping, ES is not schemaless but schema-intensive. Mappings cant be changed in case when this change conflicting with existing documents (practically, if any of documents have not-null field which new mapping affects, this will result in exception)
• documents in ES is immutable: once you've indexed one, you can retrieve/delete in only. The syntactic sugar around this is partial update, which makes thread-safe delete + index (with same id) on ES side

在您的问题中，这意味着什么?基本上，您无法拥有用于 ES 的经典迁移工具.以下是可以让您更轻松地使用 ES 的方法:

What does that mean in context of your question? You, basically, can't have classic migration tools for ES. And here's what can make your work with ES easier:

• 使用严格映射(dynamic":strict"和/或index.mapper.dynamic:false，看看映射文档).这将保护您的索引/类型免受

• use strict mapping ("dynamic": "strict" and/or index.mapper.dynamic: false, take a look at mapping docs). This will protect your indexes/types from

不小心被错误的类型动态映射

being accidentally dynamically mapped with wrong type

如果您在数据映射关系中遗漏了一些错误，则获得显式错误

get explicit error in case when you miss some error in data-mapping relation

您可以获取实际的 ES 映射并将其与您的数据模型进行比较.如果你的 PL 有足够高级别的 ES 库，这应该很容易

you can fetch actual ES mapping and compare it with your data models. If your PL have high enough level library for ES, this should be pretty easy

您可以利用索引别名 用于迁移

所以，一点经验.对我来说，目前合理的流程是这样的:

So, a little bit of experience. For me, currently reasonable flow is this:

• 在代码中描述为模型的所有数据结构.这个模型实际上也提供了 ORM 抽象.
• 索引/映射创建调用是简单的模型方法.
• 每个索引都有指向实际索引的别名(即news)(即news_index_{revision}_{date_created}).

每次部署代码时，您

1. 尝试放置模型(类型)映射.如果它没有错误地完成，这意味着你要么

• 放置相同的映射
• 放置旧映射的纯超集(仅提供新字段，旧字段保持不变)
• 没有文档在受新映射影响的字段中具有值

所有这些实际上意味着您可以很好地使用您拥有的映射/数据，只需像往常一样处理数据.

All of this actually means that you're good to go with mappping/data you have, just work with data as always.

1. 如果 ES 提供有关新映射的异常，您
• 使用新映射创建新索引/类型(命名为 name_{revision}_{date}
• 将您的别名重定向到新索引
• 启动迁移代码，使bulk 请求快速重新索引在此重新索引期间，您可以通过别名安全地正常索引新文档.缺点是历史数据在重新编制索引期间部分可用.

这是经过生产测试的解决方案.围绕这种方法的注意事项:

This is production-tested solution. Caveats around such approach:

• 您不能这样做，如果您的读取请求需要一致的历史数据
• 您需要重新索引整个索引.如果每个索引有 1 种类型(可行的解决方案)，那就没问题了.但有时你需要多类型索引
• 数据网络往返.有时会痛

总结一下:

• 尝试在您的模型中具有良好的抽象性，这总是有帮助的
• 尽量保持历史数据/字段过时.记住这个想法来构建你的代码，这比一开始听起来容易
• 我强烈建议避免依赖利用 ES 实验工具的迁移工具.这些可以随时更改，就像 river-* 工具所做的那样.
• try to have good abstraction in your models, this always helps
• try keeping historical data/fields stale. Just build your code with this idea in mind, that's easier than sounds at first
• I strongly recommend to avoid relying on migration tools that leverage ES experimental tools. Those can be changed anytime, like river-* tools did.

这篇关于Elasticsearch 的 Liquibase 或 Flyway 数据库迁移替代方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！