SQLAlchemy: Сканировать огромные таблицы с помощью ORM?

Question

Я сейчас немного играю с SQLAlchemy, что на самом деле довольно аккуратно.

Для тестирования я создал огромную таблицу, содержащую мой архив фотографий, индексированный хэшами SHA1 (для удаления дубликатов :-)). Который был impressingly быстро ...

Для удовольствия я сделал эквивалент select * над полученной SQLite базой данных:

session = Session() 
for p in session.query(Picture): 
    print(p) 

Я ожидал увидеть хэш прокрутки, но вместо этого он просто продолжал сканирование диска. В то же время использование памяти резко увеличилось, достигнув 1 ГБ через несколько секунд. Это, похоже, исходит из функции идентификационной карты SQLAlchemy, которая, как я думала, только сохраняла слабые ссылки.

Может кто-нибудь объяснить это мне? Я думал, что каждый Picture p будет собран после того, как будет выписан хэш !?

Answer 1

Хорошо, я просто нашел способ сделать это сам. Изменение кода на

session = Session() 
for p in session.query(Picture).yield_per(5): 
    print(p) 

загружает всего 5 снимков за раз. Кажется, что запрос будет загружать все строки за раз по умолчанию. Тем не менее, я пока не понимаю отказ от этого метода. Цитата из

ВНИМАНИЕ: используйте этот метод с осторожностью; если один и тот же экземпляр присутствует в более чем одной партии строк, изменения в атрибутах конечного пользователя будут перезаписаны. В частности, это правило невозможно использовать с загруженными коллекциями (то есть любым lazy = False), так как эти коллекции будут очищены для новой загрузки, если они встречаются в последующей партии результатов.

Так при использовании yield_per на самом деле правильный путь (тм) для сканирования по обильным данным SQL при использовании ОРМА, когда это безопасно использовать?

Answer 2

Вы можете отложить съемку только до получения доступа. Вы можете сделать это по запросу по запросу. как

session = Session() 
for p in session.query(Picture).options(sqlalchemy.orm.defer("picture")): 
    print(p) 

или вы можете сделать это в картографа

mapper(Picture, pictures, properties={ 
    'picture': deferred(pictures.c.picture) 
}) 

Как сделать это в документации here

Делать это в любом случае будет убедиться, что картина только загружается при доступе к атрибуту.

Answer 3

вот что я обычно делаю в этой ситуации:

def page_query(q): 
    offset = 0 
    while True: 
     r = False 
     for elem in q.limit(1000).offset(offset): 
      r = True 
      yield elem 
     offset += 1000 
     if not r: 
      break 

for item in page_query(Session.query(Picture)): 
    print item 

Это позволяет избежать различной буферизации, что DBAPIs сделать так (например, psycopg2 и MySQLdb). Его по-прежнему необходимо использовать надлежащим образом, если в вашем запросе есть явные JOINs, хотя надежно загруженные коллекции гарантированно загружаются полностью, так как они применяются к подзапросу, который содержит фактический LIMIT/OFFSET.

Я заметил, что Postgresql занимает почти столько же времени, чтобы возвращать последние 100 строк большого результирующего набора, как и для возврата всего результата (за вычетом фактических служебных издержек строки), поскольку OFFSET просто выполняет простое сканирование Все это.