ตัววนซ้ำ / เครื่องกำเนิดไฟฟ้า SqlAlchemy ในตัวที่มีประสิทธิภาพหน่วยความจำ?

ฉันมีตารางบันทึก MySQL ~ 10M ที่ฉันเชื่อมต่อโดยใช้ 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?

คำตอบสำหรับคำถามนี้ดูเหมือนจะบ่งชี้ว่าไม่ควรคาดหวังการใช้หน่วยความจำ

การนำ DBAPI ไปใช้งานส่วนใหญ่จะบัฟเฟอร์แถวอย่างสมบูรณ์ตามที่มีการดึงข้อมูลดังนั้นโดยปกติก่อนที่ SQLAlchemy ORM จะได้รับผลลัพธ์เพียงรายการเดียวชุดผลลัพธ์ทั้งหมดจะอยู่ในหน่วยความจำ

แต่วิธีการQueryทำงานก็คือโหลดผลลัพธ์ที่กำหนดตามค่าเริ่มต้นอย่างสมบูรณ์ก่อนที่จะส่งคืนวัตถุให้คุณ เหตุผลในที่นี้เกี่ยวกับการสืบค้นที่มากกว่าคำสั่ง SELECT แบบธรรมดา ตัวอย่างเช่นในการรวมเข้ากับตารางอื่นที่อาจส่งคืนข้อมูลประจำตัวของอ็อบเจ็กต์เดียวกันหลายครั้งในชุดผลลัพธ์หนึ่งชุด (โดยทั่วไปกับการโหลดอย่างกระตือรือร้น) แถวทั้งหมดจะต้องอยู่ในหน่วยความจำเพื่อให้สามารถส่งคืนผลลัพธ์ที่ถูกต้องได้มิฉะนั้นจะมีการรวบรวม อาจมีเพียงบางส่วนเท่านั้น

ดังนั้นมีตัวเลือกที่จะเปลี่ยนพฤติกรรมนี้ผ่านQuery yield_per()การเรียกนี้จะทำให้เกิดQueryแถวเป็นแบตช์โดยที่คุณกำหนดขนาดแบทช์ ตามสถานะของเอกสารสิ่งนี้จะเหมาะสมก็ต่อเมื่อคุณไม่ได้ทำการโหลดคอลเลกชันใด ๆ อย่างกระตือรือร้นดังนั้นโดยพื้นฐานแล้วถ้าคุณรู้ว่าคุณกำลังทำอะไร นอกจากนี้หากแถวก่อนบัฟเฟอร์ DBAPI ที่อยู่ภายใต้จะยังคงมีค่าใช้จ่ายของหน่วยความจำนั้นดังนั้นวิธีการจะปรับขนาดได้ดีกว่าการไม่ใช้

ฉันแทบไม่เคยใช้yield_per(); แต่ฉันใช้แนวทาง LIMIT เวอร์ชันที่ดีกว่าที่คุณแนะนำข้างต้นโดยใช้ฟังก์ชันหน้าต่างแทน LIMIT และ OFFSET มีปัญหาใหญ่ที่ค่า OFFSET ที่ใหญ่มากทำให้การสืบค้นช้าลงและช้าลงเนื่องจาก OFFSET ของ N ทำให้หน้าผ่าน N แถว - เหมือนกับการทำแบบสอบถามเดียวกันห้าสิบครั้งแทนที่จะเป็นหนึ่งในแต่ละครั้งที่อ่าน a จำนวนแถวที่มากขึ้นและมากขึ้น ด้วยวิธีการทำงานของหน้าต่างฉันจะดึงชุดของค่า "หน้าต่าง" ไว้ล่วงหน้าซึ่งอ้างถึงส่วนของตารางที่ฉันต้องการเลือก จากนั้นฉันจะปล่อยคำสั่ง SELECT แต่ละรายการที่ดึงจากหน้าต่างเหล่านั้นทีละรายการ

วิธีการทำงานของหน้าต่างอยู่ในวิกิและฉันใช้มันอย่างประสบความสำเร็จ

หมายเหตุ: ฐานข้อมูลบางส่วนไม่รองรับฟังก์ชันหน้าต่าง คุณต้องใช้ Postgresql, Oracle หรือ SQL Server IMHO ที่ใช้ Postgresql เป็นอย่างน้อยก็คุ้มค่าอย่างแน่นอน - หากคุณใช้ฐานข้อมูลเชิงสัมพันธ์คุณอาจใช้สิ่งที่ดีที่สุดเช่นกัน

ฉันไม่ใช่ผู้เชี่ยวชาญด้านฐานข้อมูล แต่เมื่อใช้ SQLAlchemy เป็นเลเยอร์นามธรรม Python อย่างง่าย (เช่นไม่ใช้อ็อบเจ็กต์ ORM Query) ฉันได้คิดวิธีแก้ปัญหาที่น่าพอใจในการสืบค้นตาราง 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)

จากนั้นฉันใช้fetchmany()วิธีSQLAlchemy เพื่อวนซ้ำผลลัพธ์ใน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 ใด ๆ หรือกับไดรเวอร์ฐานข้อมูลใด ๆ ...

มี usecase ที่น่าสนใจในบล็อกโพสต์นี้ซึ่งเป็นแรงบันดาลใจให้กับวิธีการข้างต้นของฉัน

ฉันได้ตรวจสอบการส่งผ่าน / เพจที่มีประสิทธิภาพด้วย SQLAlchemy และต้องการอัปเดตคำตอบนี้

ฉันคิดว่าคุณสามารถใช้การเรียกแบบแบ่งส่วนเพื่อ จำกัด ขอบเขตของแบบสอบถามได้อย่างเหมาะสมและคุณสามารถใช้ซ้ำได้อย่างมีประสิทธิภาพ

ตัวอย่าง:

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

ด้วยจิตวิญญาณของคำตอบของโจเอลฉันใช้สิ่งต่อไปนี้:

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

การใช้ LIMIT / OFFSET นั้นไม่ดีเนื่องจากคุณต้องหาคอลัมน์ {OFFSET} ทั้งหมดก่อนดังนั้นยิ่งมีขนาดใหญ่ OFFSET ก็จะยิ่งได้รับคำขอนานขึ้น การใช้คิวรีแบบมีหน้าต่างสำหรับฉันยังให้ผลลัพธ์ที่ไม่ดีบนตารางขนาดใหญ่ที่มีข้อมูลจำนวนมาก (คุณรอผลลัพธ์แรกนานเกินไปซึ่งมันไม่ดีในกรณีของฉันสำหรับการตอบสนองทางเว็บที่เป็นก้อน)

วิธีที่ดีที่สุดให้ที่นี่https://stackoverflow.com/a/27169302/450103 ในกรณีของฉันฉันแก้ไขปัญหาเพียงแค่ใช้ดัชนีในฟิลด์วันที่และเวลาและเรียกแบบสอบถามถัดไปด้วย datetime> = previous_datetime โง่เพราะฉันเคยใช้ดัชนีนั้นในกรณีต่างๆมาก่อน แต่คิดว่าการดึงข้อมูลแบบสอบถามที่มีหน้าต่างทั้งหมดจะดีกว่า ในกรณีของฉันฉันผิด

AFAIK ตัวแปรแรกยังคงได้รับ tuples ทั้งหมดจากตาราง (ด้วยแบบสอบถาม SQL เดียว) แต่สร้างงานนำเสนอ ORM สำหรับแต่ละเอนทิตีเมื่อทำซ้ำ ดังนั้นจึงมีประสิทธิภาพมากกว่าการสร้างรายการของเอนทิตีทั้งหมดก่อนที่จะทำซ้ำ แต่คุณยังต้องดึงข้อมูล (ดิบ) ทั้งหมดไปยังหน่วยความจำ

ดังนั้นการใช้ LIMIT บนโต๊ะขนาดใหญ่จึงเป็นความคิดที่ดีสำหรับฉัน