Потребление памяти при параллельной обработке в python при доступе к базе данных

Question

У меня довольно большая таблица (180 миллионов записей) в SQL Серверная база данных. Пример ниже:

my_table>> columns: Date, Value1, Value2, Valeu3

У меня также есть сценарий python, который запускается одновременно с pool.map(), и в каждом дочернем процессе (итерации) устанавливается соединение для доступа к my_table и извлечения фрагмента с помощью приведенного ниже сценария и выполнения других вычислений:

select * from my_table where Date is between a1 and a2

У меня вопрос: когда сценарий python выполняется параллельно, каждый дочерний процесс загружает все данные таблицы SQL (180 миллионов строк) в памяти, а затем нарезать ее в зависимости от условия где?

Если это так, то каждый дочерний процесс должен был бы загрузить 180 миллионов строк в память, и это могло бы заморозить все.

Я почти уверен что если я сделаю запрос к огромной таблице на SQL Сервере пару раз, все данные будут загружены в память SQL Сервером только один раз для первого запроса, а другие запросы будут использовать данные, загруженные в ОЗУ первым запрос.

Answer 1

В SQL Серверные запросы всегда читают данные из кэша страниц в памяти. Если плану запросов требуются строки на странице, которая в данный момент отсутствует в кэше страниц, менеджер буфера помещает запрос в ожидание PAGEIOLATCH и извлекает страницу в память.

Если несколько процессов отправляют запрос, например

select * from my_table where Date is between a1 and a2

Каждому запросу может потребоваться прочитать все строки, чтобы применить фильтр (который зависит от индексов), но все они будут считывать одни и те же страницы из памяти в той мере, в которой таблица помещается в память.

Вы можете значительно увеличить объем таблицы, помещаемой в память, сохраняя ее с помощью сжатия страниц (~ 3x сжатие) или кластеризованного хранилища столбцов (~ 10x сжатие).

И вы можете оценить сжатие с помощью sp_estimate_data_compression_savings .

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

Также SQL Server 2017 и более поздние версии имеют дополнительный компонент SQL Службы машинного обучения сервера , которые позволяет запускать ваш код Python на сервере с супер-быстрым доступом к данным.