内存有效的内置SqlAlchemy迭代器/生成器？

Question 1

我有一个〜10M记录的MySQL表，可以使用SqlAlchemy进行交互。我发现对这个表的大子集的查询将消耗过多的内存，即使我以为我使用的是内置生成器，它可以智能地获取数据集的一口大小的块：

for thing in session.query(Things):
    analyze(thing)

为了避免这种情况，我发现我必须构建自己的迭代器，该迭代器会分块地进行处理：

lastThingID = None
while True:
    things = query.filter(Thing.id < lastThingID).limit(querySize).all()
    if not rows or len(rows) == 0: 
        break
    for thing in things:
        lastThingID = row.id
        analyze(thing)

这是正常现象还是关于SA内置发电机我缺少什么？

这个问题的答案似乎表明内存消耗是不希望的。

Question 2

大多数DBAPI实现在获取行时都会完全缓冲行-因此通常，在SQLAlchemy ORM甚至没有保留一个结果之前，整个结果集就在内存中。

但是，有效的方法Query是在返回对象之前默认情况下完全加载给定的结果集。这里的基本原理是查询不只是简单的SELECT语句。例如，在连接到可能在一个结果集中多次返回相同对象标识的其他表中（与急切加载相同），整个行集都需要存储在内存中，以便可以返回正确的结果，否则返回集合。可能仅被部分填充。

因此Query提供了一个通过更改此行为的选项yield_per()。此调用将导致Query批量生成行，并在其中指定批量大小。正如文档所述，这仅在您不进行任何急切加载集合的情况下才是合适的，因此基本上是您真的知道自己在做什么。同样，如果底层的DBAPI预缓冲行，则仍然会有内存开销，因此该方法的伸缩性仅比不使用它更好。

我很少用过yield_per(); 取而代之的是，我使用上面建议的使用窗口函数的LIMIT方法的更好版本。LIMIT和OFFSET存在一个巨大的问题，即非常大的OFFSET值会导致查询变得越来越慢，因为N的OFFSET会使它分页浏览N行-就像执行相同的查询而不是一次，每次查询50次行数越来越大。使用窗口函数方法，我预取了一组“窗口”值，这些值引用了我要选择的表的块。然后，我发出单独的SELECT语句，每个语句一次从这些窗口之一拉出。

窗口函数方法在Wiki上，我使用它非常成功。

另请注意：并非所有数据库都支持窗口功能。您需要Postgresql，Oracle或SQL Server。恕我直言，至少使用Postgresql绝对值得-如果您使用的是关系数据库，则最好使用最佳数据库。

Question 3

我不是数据库专家，但是当使用SQLAlchemy作为简单的Python抽象层（即，不使用ORM查询对象）时，我想出了一个令人满意的解决方案，可以查询300M行表而不会增加内存使用量...

这是一个虚拟的示例：

from sqlalchemy import create_engine, select

conn = create_engine("DB URL...").connect()
q = select([huge_table])

proxy = conn.execution_options(stream_results=True).execute(q)

然后，我使用SQLAlchemyfetchmany()方法在无限while循环中遍历结果：

while 'batch not empty':  # equivalent of 'while True', but clearer
    batch = proxy.fetchmany(100000)  # 100,000 rows at a time

    if not batch:
        break

    for row in batch:
        # Do your stuff here...

proxy.close()

这种方法使我可以进行所有类型的数据聚合，而没有任何危险的内存开销。

NOTE 在stream_results与Postgres的和作品pyscopg2适配器，但我想这不会有任何DBAPI工作，也没有与任何数据库驱动程序...

这篇博客文章中有一个有趣的用例，启发了我的上述方法。

Question 4

我一直在研究SQLAlchemy的高效遍历/分页，并希望更新此答案。

我认为您可以使用slice调用来适当地限制查询的范围，并且可以有效地重用它。

例：

window_size = 10  # or whatever limit you like
window_idx = 0
while True:
    start,stop = window_size*window_idx, window_size*(window_idx+1)
    things = query.slice(start, stop).all()
    if things is None:
        break
    for thing in things:
        analyze(thing)
    if len(things) < window_size:
        break
    window_idx += 1

Question 5

本着乔尔的回答精神，我使用以下内容：

WINDOW_SIZE = 1000
def qgen(query):
    start = 0
    while True:
        stop = start + WINDOW_SIZE
        things = query.slice(start, stop).all()
        if len(things) == 0:
            break
        for thing in things:
            yield thing
        start += WINDOW_SIZE

Question 6

使用LIMIT / OFFSET不好，因为您需要先找到所有{OFFSET}列，所以OFFSET越大-您得到的请求越长。对我来说，使用窗口式查询还会在包含大量数据的大表上产生不好的结果（您等待第一个结果的时间太长，以至于我不适合分块的Web响应）。

此处给出的最佳方法https://stackoverflow.com/a/27169302/450103。就我而言，我仅在datetime字段上使用索引并使用datetime> = previous_datetime获取下一个查询就解决了问题。愚蠢的，因为我之前在不同情况下都使用过该索引，但认为对于获取所有数据的窗口式查询会更好。就我而言，我错了。

Question 7

AFAIK，第一个变体仍然从表中获取所有元组（带有一个SQL查询），但是在迭代时为每个实体建立ORM表示。因此，它比在迭代之前建立所有实体的列表更有效，但是您仍然必须将所有（原始）数据提取到内存中。

因此，在大型表上使用LIMIT对我来说是个好主意。