trình tạo / tạo trình lặp SqlAlchemy tích hợp hiệu quả bộ nhớ?

Tôi có một bảng MySQL bản ghi ~ 10 triệu mà tôi giao diện bằng SqlAlchemy. Tôi nhận thấy rằng các truy vấn trên các tập hợp con lớn của bảng này sẽ tiêu tốn quá nhiều bộ nhớ mặc dù tôi nghĩ rằng tôi đang sử dụng một trình tạo tích hợp có thể tìm nạp các phần nhỏ cỡ nhỏ của tập dữ liệu một cách thông minh:

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

Để tránh điều này, tôi thấy mình phải xây dựng trình vòng lặp của riêng mình.

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)

Điều này là bình thường hay có điều gì đó tôi đang thiếu liên quan đến máy phát điện tích hợp SA?

Câu trả lời cho câu hỏi này dường như chỉ ra rằng mức tiêu thụ bộ nhớ không được mong đợi.

Hầu hết các triển khai DBAPI đều đệm đầy đủ các hàng khi chúng được tìm nạp - vì vậy thông thường, trước khi SQLAlchemy ORM nhận được một kết quả, toàn bộ tập kết quả sẽ nằm trong bộ nhớ.

Nhưng sau đó, cách Queryhoạt động là nó tải hoàn toàn kết quả đã cho được đặt theo mặc định trước khi trả về cho bạn các đối tượng của bạn. Sự hợp lý ở đây liên quan đến các truy vấn không chỉ là các câu lệnh SELECT đơn giản. Ví dụ: trong các phép nối đến các bảng khác có thể trả về cùng một đối tượng nhiều lần trong một tập kết quả (phổ biến với tải nhanh), tập hợp đầy đủ các hàng cần phải có trong bộ nhớ để có thể trả về kết quả chính xác, nếu không thì các tập hợp và tương tự có thể chỉ được điền một phần.

Vì vậy, Querycung cấp một tùy chọn để thay đổi hành vi này thông qua yield_per(). Lệnh gọi này sẽ tạo ra các Queryhàng theo lô, nơi bạn cung cấp cho nó kích thước lô. Như trạng thái tài liệu, điều này chỉ thích hợp nếu bạn không thực hiện bất kỳ loại tải bộ sưu tập háo hức nào, vì vậy về cơ bản nó là nếu bạn thực sự biết mình đang làm gì. Ngoài ra, nếu các hàng DBAPI bên dưới bộ đệm trước, sẽ vẫn có chi phí bộ nhớ đó nên cách tiếp cận chỉ có quy mô tốt hơn một chút so với việc không sử dụng nó.

Tôi hầu như không bao giờ sử dụng yield_per(); thay vào đó, tôi sử dụng phiên bản tốt hơn của phương pháp LIMIT mà bạn đề xuất ở trên bằng cách sử dụng các hàm cửa sổ. LIMIT và OFFSET có một vấn đề lớn là các giá trị OFFSET rất lớn khiến truy vấn ngày càng chậm hơn, vì OFFSET của N khiến nó chuyển trang qua N hàng - giống như thực hiện cùng một truy vấn năm mươi lần thay vì một, mỗi lần đọc một số lượng hàng lớn hơn và lớn hơn. Với cách tiếp cận hàm cửa sổ, tôi tìm nạp trước một tập hợp các giá trị "cửa sổ" tham chiếu đến các phần của bảng mà tôi muốn chọn. Sau đó, tôi phát ra các câu lệnh SELECT riêng lẻ mà mỗi câu lệnh kéo từ một trong các cửa sổ đó tại một thời điểm.

Phương pháp tiếp cận chức năng cửa sổ có trên wiki và tôi sử dụng nó rất thành công.

Cũng lưu ý: không phải tất cả các cơ sở dữ liệu đều hỗ trợ các chức năng cửa sổ; bạn cần Postgresql, Oracle hoặc SQL Server. IMHO sử dụng ít nhất Postgresql chắc chắn đáng giá - nếu bạn đang sử dụng cơ sở dữ liệu quan hệ, bạn cũng có thể sử dụng tốt nhất.

Tôi không phải là chuyên gia về cơ sở dữ liệu, nhưng khi sử dụng SQLAlchemy làm lớp trừu tượng Python đơn giản (tức là không sử dụng đối tượng Truy vấn ORM), tôi đã nghĩ ra một giải pháp thỏa mãn để truy vấn bảng 300M hàng mà không sử dụng bộ nhớ ...

Đây là một ví dụ giả:

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)

Sau đó, tôi sử dụng fetchmany()phương thức SQLAlchemy để lặp lại các kết quả trong một whilevòng lặp vô hạn :

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()

Phương pháp này cho phép tôi thực hiện tất cả các loại tổng hợp dữ liệu mà không cần bất kỳ chi phí bộ nhớ nguy hiểm nào.

NOTE các stream_resultslàm việc với Postgres và pyscopg2bộ chuyển đổi, nhưng tôi đoán nó sẽ không làm việc với bất kỳ DBAPI, cũng không phải với bất kỳ trình điều khiển cơ sở dữ liệu ...

Có một usecase thú vị trong bài đăng blog này đã truyền cảm hứng cho phương pháp trên của tôi.

Tôi đã xem xét việc duyệt / phân trang hiệu quả với SQLAlchemy và muốn cập nhật câu trả lời này.

Tôi nghĩ rằng bạn có thể sử dụng lệnh gọi lát cắt để giới hạn đúng phạm vi của một truy vấn và bạn có thể sử dụng lại nó một cách hiệu quả.

Thí dụ:

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

Theo tinh thần của câu trả lời của Joel, tôi sử dụng như sau:

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

Sử dụng LIMIT / OFFSET là không tốt, vì bạn cần tìm tất cả các cột {OFFSET} trước đó, vì vậy OFFSET càng lớn - bạn nhận được yêu cầu càng lâu. Đối với tôi, việc sử dụng truy vấn cửa sổ cũng cho kết quả không tốt trên bảng lớn với lượng dữ liệu lớn (bạn đợi kết quả đầu tiên quá lâu, điều đó không tốt trong trường hợp của tôi đối với phản hồi web phân khúc).

Cách tiếp cận tốt nhất được đưa ra tại đây https://stackoverflow.com/a/27169302/450103 . Trong trường hợp của tôi, tôi đã giải quyết vấn đề chỉ bằng cách sử dụng chỉ mục trên trường datetime và tìm nạp truy vấn tiếp theo với datetime> = before_datetime. Thật ngu ngốc, vì tôi đã sử dụng chỉ mục đó trong các trường hợp khác nhau trước đây, nhưng nghĩ rằng để tìm nạp tất cả truy vấn cửa sổ dữ liệu sẽ tốt hơn. Trong trường hợp của tôi, tôi đã sai.

AFAIK, biến thể đầu tiên vẫn lấy tất cả các bộ giá trị từ bảng (với một truy vấn SQL) nhưng xây dựng bản trình bày ORM cho từng thực thể khi lặp lại. Vì vậy, sẽ hiệu quả hơn việc xây dựng một danh sách tất cả các thực thể trước khi lặp lại nhưng bạn vẫn phải tìm nạp tất cả dữ liệu (thô) vào bộ nhớ.

Vì vậy, sử dụng LIMIT trên các bảng lớn nghe có vẻ là một ý kiến ​​hay đối với tôi.