【问题标题】:Optimizing performance of Postgresql database writes in Django?在 Django 中优化 Postgresql 数据库写入的性能?
【发布时间】:2012-03-14 11:27:37
【问题描述】:

我有一个 Django 1.1 应用程序,它需要每天从一些大的 json 文件中导入数据。举个例子,其中一个文件超过 100 Mb,并且有 90K 条目被导入到 Postgresql 数据库。

我遇到的问题是导入数据需要很长时间,即数小时。我本来预计将这么多条目写入数据库需要一些时间,但肯定不会那么长,这让我觉得我做的事情本质上是错误的。我读过类似的 stackexchange 问题,建议的解决方案建议使用 transaction.commit_manuallytransaction.commit_on_success 装饰器分批提交,而不是在每个 .save() 上提交,我已经在这样做了。

正如我所说,我想知道我是否做错了什么(例如要提交的批次太大?外键太多?...),或者我是否应该为此放弃 Django 模型函数并直接使用 DB API。有什么想法或建议吗?

这是我在导入数据时处理的基本模型(为简单起见,我删除了原始代码中的一些字段)

class Template(models.Model):
    template_name = models.TextField(_("Name"), max_length=70)
    sourcepackage = models.TextField(_("Source package"), max_length=70)
    translation_domain = models.TextField(_("Domain"), max_length=70)
    total = models.IntegerField(_("Total"))
    enabled = models.BooleanField(_("Enabled"))
    priority = models.IntegerField(_("Priority"))
    release = models.ForeignKey(Release) 

class Translation(models.Model):
    release = models.ForeignKey(Release)
    template = models.ForeignKey(Template)
    language = models.ForeignKey(Language)
    translated = models.IntegerField(_("Translated"))

这是一段似乎需要很长时间才能完成的代码:

@transaction.commit_manually
def add_translations(translation_data, lp_translation):

    releases = Release.objects.all()

    # There are 5 releases
    for release in releases:

        # translation_data has about 90K entries
        # this is the part that takes a long time
        for lp_translation in translation_data:
            try:
                language = Language.objects.get(
                    code=lp_translation['language'])
            except Language.DoesNotExist:
                continue

            translation = Translation(
                template=Template.objects.get(
                            sourcepackage=lp_translation['sourcepackage'],
                            template_name=lp_translation['template_name'],
                            translation_domain=\
                                lp_translation['translation_domain'],
                            release=release),
                translated=lp_translation['translated'],
                language=language,
                release=release,
                )

            translation.save()

        # I realize I should commit every n entries
        transaction.commit()

        # I've also got another bit of code to fill in some data I'm
        # not getting from the json files

        # Add missing templates
        languages = Language.objects.filter(visible=True)
        languages_total = len(languages)

        for language in languages:
            templates = Template.objects.filter(release=release)

            for template in templates:
                try:
                    translation = Translation.objects.get(
                                    template=template,
                                    language=language,
                                    release=release)
                except Translation.DoesNotExist:
                    translation = Translation(template=template,
                                              language=language,
                                              release=release,
                                              translated=0,
                                              untranslated=0)
                    translation.save()

            transaction.commit()

【问题讨论】:

标签: python django postgresql django-models


【解决方案1】:

浏览您的应用程序并处理每一行会很多将数据直接加载到服务器的速度较慢。即使使用优化的代码。此外,一次插入/更新一行比一次处理所有数据要慢很多。

如果导入文件在服务器本地可用,您可以使用COPY。否则,您可以在标准接口psql 中使用元命令\copy。您提到 JSON,要使其正常工作,您必须将数据转换为合适的平面格式,如 CSV。

如果您只想向表中添加新行:

COPY tbl FROM '/absolute/path/to/file' FORMAT csv;

或者如果你想插入/更新一些行:

首先:为temp_buffers 使用足够的RAM(至少暂时,如果可以的话),这样临时表就不必写入磁盘。请注意,这必须在访问 this 会话中的任何临时表之前完成。

SET LOCAL temp_buffers='128MB';

内存中表示比 on.disc 数据表示占用更多空间。因此,对于一个 100 MB 的 JSON 文件 .. 减去 JSON 开销,再加上一些 Postgres 开销,128 MB 可能不够,也可能不够。但您不必猜测,只需进行测试运行并测量即可:

select pg_size_pretty(pg_total_relation_size('tmp_x'));

创建临时表:

CREATE TEMP TABLE tmp_x (id int, val_a int, val_b text);

或者,只是复制现有表的结构:

CREATE TEMP TABLE tmp_x AS SELECT * FROM tbl LIMIT 0;

复制值(应该花费 ,而不是小时):

COPY tmp_x FROM '/absolute/path/to/file' FORMAT csv;

从那里使用普通的旧 SQL 进行 INSERT / UPDATE。当您计划一个复杂的查询时,您甚至可能想要在临时表上添加一个或两个 index 并运行 ANALYZE:

ANALYZE tmp_x;

例如,更新现有行,匹配id

UPDATE tbl
SET    col_a = tmp_x.col_a
USING  tmp_x
WHERE  tbl.id = tmp_x.id;

最后,删除临时表:

DROP TABLE tmp_x;

或者让它在会话结束时自动删除。

【讨论】:

  • 谢谢,COPY 看起来很有趣!关于一次插入一行,我原以为@transaction.commit_manually 会在调用transaction.commit() 时负责批量插入。无论如何,源 JSON 文件确实可用于服务器,我可以轻松地将它们转换为 CSV,所以我应该能够使用它。但是,在阅读了COPY 文档后,我不确定如何使用COPY 和普通 SQL 来复制我在循环中所做的功能,特别是为“模板”添加外键值' 到 '翻译' 表。
  • 我可以想到:1) 使用COPY 将所有数据导入临时表 2) 使用单独的 SQL 查询将非外键相关数据从临时表复制到主'translation'表,同时在临时表中从'sourcepackage'、'template_name'、'translation_domain'值中找出'template'外键,并将适当的'template'对象写入主表.我仍然不确定如何在 2) 上编写 SQL 查询,但这听起来像一个明智的方法吗?
  • 是的,确实如此。应该可以在带有 JOIN 的 SQL 语句中使用。我添加了更多信息以优化性能。
  • 我仍然不确定如何使用 JOIN 准确编写 SQL 查询,但这可能是一个单独问题的主题。我接受答案,因为它为我指明了正确的方向并包含非常有用的信息。谢谢!
猜你喜欢
  • 1970-01-01
  • 2014-09-06
  • 2013-05-08
  • 2012-08-24
  • 2019-08-23
  • 2021-12-06
  • 1970-01-01
  • 2011-06-14
  • 1970-01-01
相关资源
最近更新 更多