【问题标题】:Django: Random query slow - despite optimizationsDjango:随机查询缓慢 - 尽管进行了优化
【发布时间】:2018-07-21 21:22:45
【问题描述】:

我构建了一个 API,它应该从一个大型查询集中返回 10 个随机选择的结果。

我有以下4个型号:

class ScrapingOperation(models.Model):
    completed = models.BooleanField(default=False)
    (...)

    indexes = [
        models.Index(fields=['completed'], name='completed_idx'),
        models.Index(fields=['trusted'], name='trusted_idx'),
    ]

    @property
    def ads(self):
        """returns all ads linked to the searches of this operation"""
        return Ad.objects.filter(searches__in=self.searches.all())


class Search(models.Model):
    completed = models.BooleanField(default=False)
    scraping_operation = models.ForeignKey(
            ScrapingOperation,
            on_delete=models.CASCADE,
            related_name='searches'
    )
    (...)


class Ad(models.Model):
    searches = models.ManyToManyField('scraper.Search', related_name='ads')
    (...)


class Label(models.Model):
     value = models.Integerfield()
     linked_ad = models.OneToOneField(
         Ad, on_delete=models.CASCADE, related_name='labels'
     )

该数据库目前有 400.000 + Ad 对象,但平均 ScrapingOperation 有 14000 个 Ad 对象链接到它。我希望 API 从这些 +/- 14000 个中返回 10 个随机结果,这些结果还没有链接的 Label 对象(每个操作最多只有几百个)

因此,必须从包含 14.000 个对象的查询中返回 10 个随机结果。

早期版本只能返回 1 个结果,但使用了更慢的 sort_by('?') 方法。当我不得不扩大它以返回随机的 10 个 Ad 对象时,我使用了一种部分基于 this stackoverflow answer 的新方法

这是选择(并返回)10 个随机对象的代码:

# Get all ads linked to the last completed operation
last_op_ads = ScrapingOperation.objects.filter(completed=True).last().ads

# Get all ads that don't have an label yet
random_ads = last_op_ads.filter(labels__isnull=True)

# Get list ids of all potential ads
id_list = random_ads.values_list('id', flat=True)
id_list = list(id_list)

# Select a random sample of 10, get objects with PK matches
samples = rd.sample(id_list, min(len(id_list), 10))
selected_samples = random_ads.filter(id__in=samples)

return selected_samples

但是,尽管我进行了优化,但此查询需要 10 多秒才能完成,从而创建了一个非常慢的 API。

这种长延迟是随机查询所固有的吗? (如果是这样,其他程序员如何处理这个限制?)或者我的代码中是否存在我遗漏的错误/效率低下?

编辑:根据回复,我在下面包含了原始 sql 查询 (注意:这些在我的本地环境中运行,其中仅包含我的生产环境包含的数据的 5%)

{'sql': 'SELECT "scraper_scrapingoperation"."id", 
"scraper_scrapingoperation"."date_started", 
"scraper_scrapingoperation"."date_completed",
"scraper_scrapingoperation"."completed", 
"scraper_scrapingoperation"."round", 
"scraper_scrapingoperation"."trusted" FROM "scraper_scrapingoperation" 
WHERE "scraper_scrapingoperation"."completed" = true ORDER BY 
"scraper_scrapingoperation"."id" DESC LIMIT 1', 'time': '0.001'}


{'sql': 'SELECT "database_ad"."id" FROM "database_ad" INNER JOIN 
"database_ad_searches" ON ("database_ad"."id" = 
"database_ad_searches"."ad_id") LEFT OUTER JOIN "classifier_label" ON
("database_ad"."id" = "classifier_label"."ad_id") WHERE 
("database_ad_searches"."search_id" IN (SELECT U0."id" FROM 
"scraper_search" U0 WHERE U0."scraping_operation_id" = 6) AND 
"classifier_label"."id" IS NULL)', 'time': '1.677'}

编辑 2:我尝试了另一种方法,使用更深的 select_related 参数

        random_ads = ScrapingOperation.objects.prefetch_related(
            'searches__ads__labels',
        ).filter(completed=True).last().ads.exclude(
            labels__isnull=True
        )

        id_list = random_ads.values_list('id', flat=True)
        id_list = list(id_list)

        samples = rd.sample(id_list, min(
            len(id_list), 10))

        selected_samples = random_ads.filter(
            id__in=samples)

        return selected_samples

产生以下 SQL 查询:

{'time': '0.008', 'sql': 'SELECT "scraper_search"."id", 
"scraper_search"."item_id", "scraper_search"."date_started", 
"scraper_search"."date_completed", "scraper_search"."completed", 
"scraper_search"."round", "scraper_search"."scraping_operation_id", 
"scraper_search"."trusted" FROM "scraper_search" WHERE 
"scraper_search"."scraping_operation_id" IN (6)'}


 {'time': '0.113', 'sql': 'SELECT ("database_ad_searches"."search_id")
 AS "_prefetch_related_val_search_id", "database_ad"."id", 
 "database_ad"."item_id", "database_ad"."item_state", 
 "database_ad"."title", "database_ad"."seller_id", 
 "database_ad"."url", "database_ad"."price", 
 "database_ad"."transaction_type", "database_ad"."transaction_method",
 "database_ad"."first_seen", "database_ad"."last_seen", 
 "database_ad"."promoted" FROM "database_ad" INNER JOIN 
 "database_ad_searches" ON ("database_ad"."id" = 
 "database_ad_searches"."ad_id") WHERE 
 "database_ad_searches"."search_id" IN (130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160)'}


{'time': '0.041', 'sql': 'SELECT "classifier_label"."id", 
"classifier_label"."set_by_id", "classifier_label"."ad_id", 
"classifier_label"."date", "classifier_label"."phone_type", 
"classifier_label"."seller_type", "classifier_label"."sale_type" FROM
"classifier_label" WHERE "classifier_label"."ad_id" IN (1, 3, 6, 10, 20, 29, 30, 35, 43, (and MANY more of these numbers) ....'}



{'time': '1.498', 'sql': 'SELECT "database_ad"."id" FROM "database_ad"
INNER JOIN "database_ad_searches" ON ("database_ad"."id" = "database_ad_searches"."ad_id") LEFT OUTER JOIN "classifier_label" ON 
("database_ad"."id" = "classifier_label"."ad_id") WHERE 
("database_ad_searches"."search_id" IN (SELECT U0."id" FROM
"scraper_search" U0 WHERE U0."scraping_operation_id" = 6) AND NOT 
("classifier_label"."id" IS NOT NULL))'}

每个 ScrapingOperation 'only' 都有 +/- 14000 个链接广告,但制作中的广告总数为 400.000 个(并且还在增长)。上面的所有代码在我的本地环境(仅包含 5% 的数据)上返回有效结果,但在生产中的 API 上返回 502 错误。

【问题讨论】:

  • Have you checked how many raw SQL queries are occurring?。如果没有,请点击链接,让我知道发生了多少。编辑:我会尽力提供帮助。
  • 感谢您的回复!它做了 7 个 SQL 查询,其中 2 个与上面的代码有关。为了提高可读性,我已将它们包含在我的问题中。
  • 哪个数据库,你比较的字段不应该有一些索引吗?
  • 数据库是 PostgreSQL,我在 ScrapingOperation 对象上索引了 'completed' 字段。 (我已经更新了代码以显示这一点)。但是我的大部分查找都是在 ForeignKey 对象上进行的,我的印象是 Django 自动为这些对象创建了索引。
  • 我对 PostgreSQL 不是很熟悉,但我相信有一个EXPLAIN 命令会告诉你发生了什么。

标签: python django


【解决方案1】:

我会先尝试隔离链接的广告,然后使用生成的随机列的顺序从中随机抽取 10 个。我不确定这对生成的 sql 有什么影响。可以肯定的是,我更愿意在任务上创建一个存储过程,因为这显然是一个以随机样本结束的数据挖掘操​​作。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2012-08-06
    • 1970-01-01
    • 1970-01-01
    • 2018-07-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-09-02
    相关资源
    最近更新 更多