【问题标题】:run migrations in parallel django?在并行 django 中运行迁移?
【发布时间】:2018-05-04 05:51:28
【问题描述】:

当前项目有大约 620 个 django 模型,迁移大约需要 1 小时。 . (迁移时仅在 gcloud 上使用 12.x% 的 8 核英特尔 skylake 和 1.2gigs 的 30gigs ram)此指标结合了 pg 和 python 2 (cpython)。我假设迁移时只使用一个内核。 [celery 进程使用 100% CPU + 50% 内存。 ]

每次迁移都像,

class Migration(migrations.Migration):

    initial = True

    dependencies = [
        ('dist', '0001_initial'),
    ]

    operations = [
        migrations.CreateModel(
            name='model name',
            fields=[
                ...
                ...
                60 fields
                ...
                ...
            ],
            options={
                'abstract': False,
            },
        ),
    ]

它们是相同的,但字段有一些细微的变化。

有什么方法可以更快地迁移这个数据库?我可以并行运行迁移吗?由于 30 之后的迁移(内部应用程序和 dist)彼此不相关,我可以并行运行这些迁移吗?

谢谢

【问题讨论】:

    标签: python django parallel-processing django-migrations


    【解决方案1】:

    不,迁移(出于充分的理由)设计为按顺序应用(例如,考虑一个迁移创建模型而另一个迁移修改它的场景 - 并行运行它们可能会使 Django 尝试修改不存在的模型然而)。在您的情况下,压缩迁移可以加快速度 - 引用文档:

    压缩是将一组现有的许多迁移减少到一个(或有时是几个)迁移仍然代表相同更改的行为。

    Django 通过获取所有现有迁移,提取它们的 Operation 并将它们全部按顺序排列,然后在它们上运行优化器以尝试减少列表的长度来做到这一点 - 对于例如,它知道 CreateModelDeleteModel 相互抵消,它知道 AddField 可以滚入 CreateModel.

    一旦尽可能减少操作序列 - 可能的数量取决于模型的紧密程度以及是否有任何 RunSQLRunPython 操作(除非它们被标记为 elidable,否则无法对其进行优化) - 然后 Django 会将其写回到一组新的迁移文件中。

    阅读有关压缩迁移的更多信息here

    【讨论】:

    • 我说前30s之后的迁移是相同的,相互独立的。如果我中断了迁移过程,我可以从中断的地方继续返回,那么并行应用它们是否有意义?
    • 它们确实相互依赖 - 查看 Migration 类中的 dependencies 字段。由于系统的设计方式,没有内置方法可以并行应用迁移 - 您必须自己编写这样的方法,很可能会在此过程中破坏迁移系统。
    猜你喜欢
    • 2018-07-20
    • 2015-07-26
    • 1970-01-01
    • 1970-01-01
    • 2015-12-08
    • 2018-11-06
    • 1970-01-01
    • 2015-11-04
    • 1970-01-01
    相关资源
    最近更新 更多