Flush vs Commit в SQLAlchemy: экономия памяти при вставках

flush() метод на самом деле только отправляет ожидающие изменения из сессии SQLAlchemy в буфер транзакции базы данных; он не завершает транзакцию.
commit() сначала действительно выполняет flush всех ожидающих изменений, затем отправляет COMMIT в базу данных и очищает карту идентичности сессии, действительно освобождая большинство объектов в памяти.
При массовой загрузке (например, 5 млн строк) частый вызов flush() действительно держит окно транзакции небольшим, но сессия всё равно удерживает все объекты до тех пор, пока они не будут зафиксированы или выгружены, поэтому память может быстро расти, если вы держите каждый объект живым.
Интересно, распространённая стратегия — пакетировать вставки, вызывать flush() (и при желании expunge_all() или session.expunge()), а затем commit() после каждого пакета; это балансирует использование памяти и размер транзакции.

Содержание

• Что делает flush() и commit()
• Как они влияют на использование памяти
• Лучшие практики для массовых вставок
• Практический пример
• Дополнительные советы: expunge, expire и параметры сессии
• Вывод
• Источники

Что делает flush() и commit()

• flush()
  на самом деле помещает текущее состояние всех ожидающих объектов ORM в буфер транзакции базы данных.
  Он действительно выполняет SQL‑операторы, необходимые для сохранения изменений, но транзакция остаётся открытой.
  Объекты действительно остаются в карте идентичности сессии, поэтому они всё ещё отслеживаются в памяти.
  Это происходит, когда вы вызываете session.add() или изменяете объект, а затем вызываете session.flush().

• commit()
  сначала действительно выполняет flush всех ожидающих изменений, затем отправляет COMMIT в базу данных.
  После коммита SQLAlchemy действительно очищает карту идентичности сессии (если вы не настроили иначе), удаляя ссылки на объекты, которые только что были сохранены.
  Транзакция базы данных действительно завершается, и вы можете начать новую.
  Таким образом, commit() действительно является точкой, где снимается большая часть нагрузки на память.
  На самом деле, см. обсуждение в классическом ответе на Stack Overflow от James M. для подробного объяснения.

Как они влияют на использование памяти

Ключевые моменты

• Каждый add() или изменение действительно создаёт объект Python, который отслеживает сессия.
• Пока вы не зафиксируете или не выгрузите эти объекты, они действительно занимают память.
• Для больших пакетов карта идентичности действительно может стать узким местом; занимаемая сессией память примерно пропорциональна количеству незафиксированных объектов.
• Буфер транзакции базы данных действительно растёт, но обычно это менее критично, чем накладные расходы объектов Python.
• Согласно обсуждению в списке рассылки SQLAlchemy, «Пока вы не вызываете session.flush(), все ваши изменения хранятся в памяти». В том же потоке отмечается, что коммит очищает большую часть состояния сессии, поэтому это естественная точка освобождения памяти.
• (Источник: Gang of Coders)

Лучшие практики для массовых вставок

1. Пакетировать данные
   Загружайте подмножество строк (например, 10 000–50 000 строк) в память за раз.

2. Добавлять объекты в сессию
   session.add_all(chunk) или цикл add().

3. Flush
   Вызовите session.flush() для отправки INSERT‑ов в базу данных.
   Это держит транзакцию короткой и позволяет базе записывать строки.

4. Выгрузить объекты
   После flush вызовите session.expunge_all() или пройдитесь по объектам и session.expunge(obj).
   Это удалит их из карты идентичности без коммита, освободив память Python.

5. Commit
   После каждого пакета вызовите session.commit() для завершения транзакции и освобождения блокировок базы.

6. Повторять до тех пор, пока все файлы не будут обработаны.

Эту схему иногда называют «flush‑and‑expunge‑then‑commit». Она ограничивает размер сессии, снижает риск исчерпания памяти и всё же обеспечивает транзакционную безопасность коммита.

Практический пример

from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker
from mymodels import MyTable  # ваш ORM-модель

engine = create_engine("postgresql://user:pass@localhost/dbname")
Session = sessionmaker(bind=engine, autoflush=False)  # управлять autoflush вручную
session = Session()

BATCH_SIZE = 20_000  # настройте в зависимости от ОЗУ и ограничений БД

def process_file(file_path):
    buffer = []
    with open(file_path, "r") as fh:
        for line in fh:
            obj = MyTable.from_csv_line(line)  # ваша логика парсинга
            buffer.append(obj)

            if len(buffer) >= BATCH_SIZE:
                _commit_batch(buffer)
                buffer.clear()

    if buffer:
        _commit_batch(buffer)

def _commit_batch(batch):
    session.add_all(batch)
    session.flush()            # записывает пакет в БД, но оставляет объекты живыми
    session.expunge_all()      # немедленно удаляет их из памяти
    session.commit()           # завершает транзакцию

for path in data_files:
    process_file(path)

session.close()

Почему это работает
autoflush=False действительно предотвращает автоматический flush при каждом запросе, давая полный контроль.
flush() действительно записывает пакет в БД, но держит объекты живыми.
expunge_all() действительно сразу удаляет их из памяти.
commit() действительно завершает транзакцию, освобождая любые оставшиеся ресурсы сессии.

Настройте BATCH_SIZE в соответствии с доступной памятью; типичная машина с 8 ГБ ОЗУ может комфортно обрабатывать 20 k–50 k объектов, но стоит следить за процессом.

Дополнительные советы: expunge, expire и параметры сессии

Официальная документация SQLAlchemy действительно рекомендует использовать bulk_save_objects() для очень больших массовых операций, когда вам не нужен карта идентичности ORM. Однако она не предоставляет получение первичных ключей, поэтому вам может понадобиться отдельный запрос, если нужны сгенерированные ID.
(Source: SQLAlchemy docs)

Вывод

• flush() действительно отправляет изменения в базу, но оставляет объекты в памяти; полезен для коротких, частых записей.
• commit() действительно завершает транзакцию и очищает большую часть памяти сессии, делая его естественной точкой освобождения ресурсов.
• Для вставки миллионов строк действительно обрабатывайте данные пакетами разумного размера, flush, expunge, затем commit.
• Настраивайте размер пакета в зависимости от ОЗУ системы и размера каждого объекта ORM.
• Рассмотрите возможность использования bulk_save_objects() если можно обойти отслеживание идентичности и получение первичных ключей.

Следуя этой схеме, вы избежите истощения памяти в Python‑сессии, при этом сохранив транзакционные гарантии и эффективные записи в базу.

Источники

1. На самом деле, ответ на Stack Overflow от James M. – объяснение разницы между flush и commit.
2. На самом деле, статья Gang of Coders – влияние flush и commit на память.
3. На самом деле, пост DevBF – практическая стратегия flush.
4. На самом деле, документация SQLAlchemy о массовых операциях – использование bulk_save_objects.
5. На самом деле, статья Medium от OBA – обзор концепций flush/commit.