Классика баз данных - статьи
В исходном файле поля хранились
В исходном файле поля хранились упакованными с точностью до бита, а не как отдельные целые числа, но последующие тесты показали, что в базе данных использовалось в 3-4 раза больше внешней памяти, чем потребовалось бы для хранения каждого поля в виде 32-разрядного целого числа. Этот вид "раздувания" данных типичен для традиционных РСУБД, и его не обязательно следует считать проблемой, особенно в тех случаях, когда это является частью стратегии повышения производительности. В конце концов, дисковая память относительно дешева.)
Мне удалось успешно загрузить поднабор данных, состоящий из около миллиарда строк с всего тремя столбцами: код страны (8 бит, 256 возможных значений), возраст (7 бит, 128 возможных значений) и пол (1 бит, два значения). Объем этого поднабора составлял всего 2% от объема полных исходных данных, хотя СУБД для хранения базы данных использовала более 40 гигабайт дисковой памяти. Затем я попробовал выполнить следующий запрос, производящий, по сути, те же вычисления, что и верхняя часть программы с рис. 1:
SELECT country,age,sex,count(*) FROM people GROUP BY country,age,sex;
Этот запрос на небольших поднаборах данных выполнялся за считанные секунды, но время выполнения быстро выросло, когда число строк превысило один миллион (рис. 2). При применении ко всему миллиарду строк запрос выполнялся более 24 часов, что наводит на мысль о немасштабируемости PostgreSQL к этому "большому" набору данных, по-видимому, из-за плохого выбора алгоритма выполнения запроса на этих данных. Проблема прояснилась после вызова встроенного средства этой СУБД EXPLAIN: в то время как планировщик запросов для небольших таблиц выбирал разумную стратегию агрегации на основе хэширования таблицы, для более крупных таблиц он переключался на стратегию сортировки по столбцам группировки. Последняя стратегия близка к оптимальной при обработке нескольких миллионов строк, но очень плоха при наличии миллиарда строк. PostgreSQL отслеживает статистику, такую как минимальное и максимальное значения каждого столбца таблицы (и я проверял, что система правильно определяет диапазоны значений всех трех столбцов), так что она могла бы уверенно выбирать стратегию с хэшированием таблицы.
