#python #pandas #sqlalchemy #pyodbc
#python #панды #sqlalchemy #pyodbc
Вопрос:
Я начал использовать это fast_executemany свойство при создании объекта движка SQLAlchemy для загрузки файлов на SQL Server через pandas. Я понимаю преимущества, которые он имеет при загрузке данных.
Существуют ли ситуации, когда не рекомендуется включать его для задач SQL Server? Может быть, если все время делать только одноэлементные вставки? Я все еще не понимаю, насколько fast_executemany будет медленнее.
Ответ №1:
Существуют ли ситуации, когда не рекомендуется включать его для задач SQL Server? Может быть, если все время делать только одноэлементные вставки?
Нет, fast_executemany=True не повлияет на однорядные вставки, если .execute() вызывается метод pyodbc. Одним из примеров является проблема pandas, когда поведение отличается между фреймом данных с одной строкой ( .execute() ) и несколькими строками ( .executemany() ). Исправление для этой конкретной проблемы будет заключаться в том, что pandas всегда будет вызывать .executemany() , даже если фрейм данных содержит только одну строку. (Также обратите внимание, что fast_executemany=True это не вызывает проблемы, это устраняет проблему.)
Однако есть несколько других известных проблем с fast_executemany=True и .to_sql() в конкретных случаях:
1. Базы данных с параметрами сортировки «дополнительный символ» (_SC) по умолчанию
Если база данных определена с параметрами сортировки по умолчанию «… _SC», например,
cnxn.execute(f"CREATE DATABASE {db_name} COLLATE Latin1_General_100_CI_AS_SC")
затем .to_sql() произойдет сбой для строк длиной более 2000 символов.
2. Фреймы данных с большим количеством нулевых значений
Относительно разреженные фреймы данных (содержат много нулевых значений None , таких как NaN , NaT , и т.д.) Могут ухудшить производительность вставки .executemany() , хотя в худшем случае это fast_executemany=True будет выполняться примерно так же медленно, как fast_executemany=False .
3. Увеличение потребления памяти [n]varchar(max) столбцами
to_sql() по умолчанию создаются строковые столбцы as varchar(max) и это может привести к раздуванию памяти fast_executemany=True .
Комментарии:
1. Спасибо! Это полностью отвечает на мой вопрос. Когда вы планируете исправить эти проблемы? JK: P
2. Для # 3 есть PR, который выглядит многообещающим. # 2 на самом деле не ошибка, а просто проблема производительности, для которой существуют обходные пути (например, использование
bcp). # 1 — это, IMO, недостаток в msodbcsql, который еще предстоит устранить.