Производительность SQL Alchemy

Я работаю над проектом, которому потребуется огромная база данных. В настоящее время мы используем SQLAlchemy, но меня немного беспокоят проблемы с производительностью. Мой вопрос в том, что у меня есть запрос вроде:

session.query(DataStorage).filter(DataStorage.storage_path.startswith(path)).all()

Как SQLAlchemy выполняет фактический перевод и фильтрацию. Получает ли он все записи из DataStorage с предложением SELECT, а затем проверяет их всех? Или он знает, как перевести «фильтр (DataStorage.storage_path.startswith (путь))» в SQL? Насколько теряется производительность при использовании собственных SQL-запросов?

с уважением, Богдан


person Bogdan    schedule 12.05.2011    source источник


Ответы (2)


SqlAlchemy использует ваш код для создания оператора SQL. В вашем случае вы делаете что-то вроде:

SELECT * FROM DataStorage WHERE DataStorage.storage_path LIKE 'path%';

Запрос выполняется для базы данных после использования .all(). Таким образом, в этом случае он получит все строки в итераторе набора результатов и вернет их вам.

person Rick    schedule 12.05.2011

Я не знаком с конкретными конструкциями SQLAlchemy, которые вы используете, но лучший способ узнать это — попробовать. Включите ведение журнала запросов в MySQL и проверьте запросы, которые генерирует SQLAlchemy. Вы можете попробовать написать запрос вручную и сравнить их производительность. (Для этого вам понадобится куча тестовых данных в вашей базе данных.)

Как правило, ORM прекрасно справляются с простыми SELECT, предложениями WHERE, ORDER BY и т. д. Когда вы начинаете выполнять много объединений или много обрабатывать данные, построенные запросы становятся менее оптимальными. Это специфично для вашего приложения. Подход, который я обычно использую, заключается в том, чтобы записывать вещи, используя ORM, а затем оптимизировать и заменять SQL, где это необходимо.

person Michael Mior    schedule 12.05.2011
comment
Вы также можете включить ведение журнала в SQLAlchemy, чтобы просмотреть сгенерированный SQL. - person codeape; 12.05.2011