cassandra 工具_Cassandra迁移工具

最新推荐文章于 2024-09-01 08:12:49 发布

danpu0978

最新推荐文章于 2024-09-01 08:12:49 发布

阅读量371

点赞数

文章标签：数据库大数据 python java mysql

原文链接：https://www.javacodegeeks.com/2016/03/cassandra-migration-tool.html

版权

cassandra 工具

Matija Gobec（@ mad_max0204）是大数据咨询公司SmartCat的联合创始人兼CTO，主要致力于解决数据密集型环境中的问题。他通过公开演讲和公司博客来传播自己的知识，还致力于开源工具以帮助Cassandra社区。

SmartCat以低于我们西方国家竞争对手的价格提供一流的，经过认证的大数据系统实施服务。我们是该地区大数据流处理技术的传播者，积极参与了教学，演示和培训新一代数据科学家，NoSQL工程师和大数据集成商的工作。我们是变革的推动力。

问题

开发产品通常意味着在开发期间，您将更改需求和技术，特别是如果它是项目的R＆D类型。作为数据库，Cassandra以其出色的性能而著称，但是这种性能来自数据建模基于查询这一事实，这意味着扩展功能并不像数据模型基于实体的传统关系数据库那样简单。当我们感到需要某种东西来帮助我们将更改应用于方案并处理生产中的实时数据时，我们正在进行第二个R＆D项目。开发和原型制作的早期阶段很容易，因为您可以随时删除并重新创建数据库以反映新的架构，但事实并非如此，因为有些客户已经在测试实现的功能并评估我们正在开发的系统。这对于我们的产品而言确实至关重要，因为它帮助我们塑造了新功能并更改了现有功能。

调查中

使用架构迁移工具的第一步使我们进行了一些研究。有一些项目旨在解决此问题，但实际上并不需要我们真正需要的项目：一个轻量级的框架，该框架可让我们对模式进行更改并处理数据。一个很大的好处是能够在不同的部署阶段以不同的参数执行此工具。您可以在SmartCat博客上找到有关我们调查的更多详细信息。

决断

我们决定构建一个简单的工具来执行数据库模式转换，并跟踪数据库本身中的模式版本。如果我们希望能够在数据库运行时对架构进行更改，并通过代码进行这些更改，以便我们可以在生产中执行之前对其进行测试，则这是必需的。简单的模式更改很容易，因为Cassandra允许添加或删除列，在有一些限制的情况下更改类型和进行其他简单的更新，但是我们还感到有必要对某些表进行大幅度的更改，例如更改主键。由于我们正在开发一个原型项目，该项目也同时为客户提供服务，因此我们不能只是删除并重新创建模式，而必须在更新后保留所有数据。大多数模式和数据迁移都可以使用Spark或任何其他ETL工具完成，并且许多人正在使用它们来解决这些问题，但是Spark带来了很多影响，尤其是在您仅需要处理迁移的情况下。能够编写迁移并在单元测试中执行迁移，使我们在上线之前充满了信心，而使用应用程序模型使这一切变得非常易于使用。

实作

迁移工具起初只是迁移实施的先驱，但后来我们发现要执行迁移有两个阶段。第一步是构建应用程序代码时，我们要将其部署到服务器上。为了使应用程序运行，我们需要更新架构。在这一步中，我们执行了模式类型迁移，对模式进行了更新，并且所有内容都已设置好，以便可以启动应用程序。但是在某些情况下，更新架构后，我们需要处理一定数量的现有数据。为此，我们定义了数据类型迁移。当我们为现有应用程序模型创建新表以服务于新查询时，通常会使用此方法，但是数据库中已经有一定数量的数据，或者添加了新字段时，我们需要根据以下内容计算值一些标准。在部署前阶段执行数据迁移将花费时间并延长应用程序停机时间。我们希望尽快启动并运行该应用程序，因此必须异步完成此工作。在数据迁移完成执行之前，执行新实现的查询不会返回所有结果，但我们仍然能够处理请求并处理传入的数据。在这里，正常运行时间与一致性得到了保证，并且应用程序的停机时间最少。可能性不仅限于此用例，完全由用户决定何时以及如何执行迁移。

例

在此示例中，我们有一个数据模型，用于通过项目的系统标识符以及有关编号和外部系统ID的信息来存储项目。该表如下所示：

CREATE TABLE items_by_id (
	id uuid,
	number text,
	external_id uuid,
	PRIMARY KEY (id)
) WITH COMMENT='Items by item ID';">

如果我们需要更改数据模型以提供按号码和外部系统ID的查询，则会出现问题。此模型不支持此功能，如果此表中有数据，我们也需要处理数据。

我们可以通过使用execute方法创建模式迁移来解决此问题，如下所示：

@Override
public void execute() throws MigrationException {
    try {
        final String statement =
                "CREATE TABLE IF NOT EXISTS items_by_number_external_id (" +
                        "id uuid," +
                        "number text," +
                        "external_id uuid," +
                        "PRIMARY KEY ((number, external_id))" +
                ") WITH COMMENT='Items by item number and external id';";
        executeWithSchemaAgreement(new SimpleStatement(statement));
 
    } catch (final Exception e) {
        throw new MigrationException("Failed to execute CreateItemsByNumberAndExternalIdMigration migration", e);
    }
}

在此示例中，我们正在执行架构迁移，并且迁移工具会自动更新架构数据库版本。如果仔细观察，在执行模式更改语句时，我们将使用executeWithSchemaAgreement方法。此方法在抽象类Migration中实现，并在所有节点上执行有关模式传播的语句。如果您已链接了需要此模式的迁移，则这是必需的。

接下来，我们执行数据迁移，该数据迭代遍历原始表中的行并将其插入到新创建的行中：

@Override
public void execute() throws MigrationException {
    try {
        final PreparedStatement preparedStatement =
                session.prepare("INSERT INTO items_by_number_external_id (id, number, external_id) VALUES (?, ?, ?);");
 
        final List<Row> rows = session.execute(QueryBuilder.select().from("items_by_id").setFetchSize(1000)).all();
        for (Row row : rows) {
            session.execute(preparedStatement.bind(row.getUUID("id"), row.getString("number"), row.getUUID("external_id")));
        }
    } catch (final Exception e) {
        throw new MigrationException("Failed to execute PopulateItemByNumberAndExternalId migration", e);
    }
}

通过使用其中一种持续部署工具，可以使用以下代码在成功的构建上执行模式迁移：

final MigrationResources resources = new MigrationResources();
resources.addMigration(new CreateItemByNumberAndExternalIdMigration(1));
MigrationEngine.withSession(session).migrate(resources);

应用程序启动代码可以执行如下数据迁移：

final MigrationResources resources = new MigrationResources();
resources.addMigration(new PopulateItemByNumberAndExternalIdMigration(2));
MigrationEngine.withSession(session).migrate(resources);

在执行迁移结束时，我们的数据库将具有更新的架构，并且将支持表和按编号和外部ID查询的所有可用数据。

如果生产应用程序需要此更改，我们可以选择何时执行哪个迁移。架构迁移可以作为构建和部署过程的一部分执行，当应用程序启动时，它可以触发数据迁移，这将在后台填充数据。

结论

这里重要的是升级架构和处理历史数据有多么容易。在这里方便的是，这是一个Java应用程序，对于迁移中可以执行的内容基本上没有限制。例如，我们可以通过从迁移执行方法中实现服务调用，并使用从第三方服务接收的数据来更新现有数据，并在后台运行它。另一方面，可以提供专用服务来执行通过API或某些消息传递系统触发的迁移，并且我们还使用此工具将数据从MySql迁移到Cassandra。

在三个生产项目中成功使用此工具后，我们的经验是，它使我们处理数据模型更新的工作变得更加容易。所有更新都存储在此工具创建的架构表中，既提供了跟踪版本的功能，又可以充当审核跟踪。