在大型Django选项卡上进行高效的数据迁移

Question

我需要向一个大的（5m行）django表添加一个新列。我有一个south schemamigration创建新列。现在我正在编写一个datamigration脚本来填充新列。看起来像这样。（如果您不熟悉south迁移，只需忽略模型名前面的orm.。）

print "Migrating %s articles." % orm.Article.objects.count()
cnt = 0
for article in orm.Article.objects.iterator():            
    if cnt % 500 == 0:
        print "    %s done so far" % cnt
    # article.newfield = calculate_newfield(article)
    article.save()
    cnt += 1

我从objects.all切换到{}，以减少内存需求。但当我运行这个脚本时，仍有一些东西在吞噬大量的内存。即使上面注释掉了实际有用的一行，脚本仍然会增长到使用10+GB的ram，然后我就放弃了。在

好像有什么东西在记忆中抓住了这些东西。我怎么能运行它，这样它就不会占用内存了？在

FWIW，我使用的是python2.6、django 1.2.1、south 0.7.2、mysql 5.1。在

Answer 1

确保settings.DEBUG设置为False。DEBUG=True使用数据库密集型操作填充内存，因为它将发送到RDBMS的所有查询存储在一个视图中。在

随着django1.8的推出，它不应该是必需的，因为现在存储的是硬编码的最多9000个查询，而不是之前的无限数量。在

Answer 2

或者，如果您在原位创建一个实现基本resultset大小限制的原始查询，会发生什么情况？在

阿拉：https://docs.djangoproject.com/en/1.3/topics/db/sql/#index-lookups

while min < rowcount:
  min += 500
  max = min + 500
  articles = Article.objects.raw('SELECT * from article where id > %s and id < %s' % (min, max))
  for old_article in articles:
    # create the new article
    article.save()

Answer 3

欢迎来到Django的ORM。我认为这是一个固有的问题。在

我也遇到过大型数据库、dumpdata、loaddata等问题。在

你有两个选择。在

1. 停止尝试使用south编写自己的ORM迁移。设置中可以有多个数据库定义。创造“旧”和“新”。编写从旧数据库到新数据库的一次性迁移程序。一旦测试并运行，最后运行一次，然后切换数据库定义并重新启动Django。

2. 抛弃south和ORM，编写自己的SQL迁移。使用原始SQL将数据从旧结构复制到新结构。单独调试。好的时候，最后运行一次，然后切换设置并重新启动Django。

并不是说南部或是ORM特别糟糕。但是，对于大型数据库中的批量处理，它们在内存中缓存过多。在