Firebird, group by и временные файлы

[metaclass]

Покопался в исходниках Firebird (2.5.2) на тему размеров временных файлов.
В итоге, там картина примерно такая:
* Запрос с условием и group by, входной датасет - десятки миллионов записей, результатирующий датасет - 150000 записей, размер записи порядка 150 байт (varchar расширены до максимального размера).
* Для выполнения запроса, подпадающие под условие записи (десятки миллионов) пишутся в сортировщик, затем досортировываются и выгребаются из него в правильном порядке с вычислением аггрегатов.
* Сортировщик реализован поверх временного хранилища данных, которое в свою очередь представляет последовательность блоков размером 1 мб, поначалу находящихся в памяти, а по мере превышения порога (8 МБ по умолчанию для классик-сервера) - записываемых во временные файлы. По виду это все крайне напоминает самодельную реализацию pagefile.
* Временные файлы расширяются кусками по 64 мб, с записью 262144 байтных буферов с нулями в эти куски.

Что здесь очень мне не нравится - это то, что обмен с временными файлами в принципе не выровнен по границам блоков диска, а является кратным размеру записи. Вот, например, из отладочного лога TempSpace::write: 2898976500 1048500

Второе - по-моему, конкретно для данного случая положить готовый результат group by в памяти в виде какого-нибудь дерева поиска и считать аггрегаты на ходу в него было бы гораздо эффективнее, чем долбится в i/o. Фактически мы при запросе читаем всю таблицу, пишем часть прочитанного в временный файл, потом сортируем, потом читаем обратно.
Но, возможно, нету эффективных способов отличить небольшой размер результата от большого размера, который эффективнее делать через сортировку.

Comments

[nicka-startcev.livejournal.com]

ммап() и 64 бита заметно упростят эту проблему, по идее.

[metaclass.livejournal.com]

Там, в целом, было бы достаточно сунуть 16 гиг памяти, воткнуть супер-сервер и сделать лимит памяти 4 гига для сортировщика.
Проблема в том, что классик-сервер создает по процессу на каждого юзера и если туда поставить хотя бы немного осмысленный лимит памяти - на серваке после 2-3 юзеров кончится память :)

[denisioru.livejournal.com]

Костыльно-велосипедная технология :))

[nicka-startcev.livejournal.com]

замапил, всосал, отсортировал, размапил. Память вернулась.
при этом вопрос о "как кэшировать/аллоцировать замапленое" решает ОС и, по идее, решает кошерно.

[gds.livejournal.com]

мене рассказывали, что mmap будет похуже, чем пряморукая работа с файлами.

[nicka-startcev.livejournal.com]

я плотник. Возможно, это сильно осезависимо, настройкозависимо, итп.

[kiryl.livejournal.com]

Все кому *действительно* нужно быстро, пользуют O_DIRECT.

[gds.livejournal.com]

ваистену так, ибо.

[avnik.livejournal.com]

А в каком нибудь хипстерском риаке эта задача не решается?
(или хотя бы в более приличном sql)

[metaclass.livejournal.com]

Пока нет.
На данный момент будет быстрее сделать мемоизацию результатов запросов с проверками на валидность, чуть-чуть подкрутить размеры сортировочных записей и прочую оптимизацию, чем мигрировать на другую СУБД.

[mipa.livejournal.com]

Что, прямо вот так и написано: 8Мб? Или все-таки настройка есть, типа TempCacheLimit?

[metaclass.livejournal.com]

Конфиг есть. В данном случае, для 2гб места на сортировку и 50 пользователей классик-сервера это мне не особо поможет.

У меня уже с сервером были проблемы, когда там кончалась память, от чего все дохло с концами. Но это проблема не столько в FB, сколько в том, что это запущено в не совсем вменяемом окружении.

[fd979.livejournal.com]

сортировщик везде реализован через темп-файлы. но причем тут сортировщик? или ячего-то не понял в четвертом часу ночи? :)

[worm-ii.livejournal.com]

> обмен с временными файлами в принципе не выровнен по границам блоков диска

По моим представлениям, это не критично, оверхед минимален. Главное, чтобы размер однократно читаемого куска был побольше, а число чтений соответственно — поменьше.

[metaclass.livejournal.com]

Может быть. Мерять надо.

[zamotivator.livejournal.com]

* Для выполнения запроса, подпадающие под условие записи (десятки миллионов) пишутся в сортировщик, затем досортировываются и выгребаются из него в правильном порядке с вычислением аггрегатов.

Это называется Sort-based group by.

* Сортировщик реализован поверх временного хранилища данных, которое в свою очередь представляет последовательность блоков размером 1 мб, поначалу находящихся в памяти, а по мере превышения порога (8 МБ по умолчанию для классик-сервера) - записываемых во временные файлы.

Это есть в любой СУБД

> По виду это все крайне напоминает самодельную реализацию pagefile.

Именно так, и только так и можно работать.

> Временные файлы расширяются кусками по 64 мб, с записью 262144 байтных буферов с нулями в эти куски.

Угу

[metaclass.livejournal.com]

Да, ребе белнетмон это же дело засунул в Postgresql - практически та же картина.

[zamotivator.livejournal.com]

> Второе - по-моему, конкретно для данного случая положить готовый результат group by в памяти в виде какого-нибудь дерева поиска и считать аггрегаты на ходу в него было бы гораздо эффективнее, чем долбится в i/o

это называется Hash Group By. Для него нужно, чтобы ключи влезли в память, и нифига не факт, что они лезут.
Впрочем, это уже фундаментальная проблема любой СУБД - сделать правильный estimate для row count, и на основе этой информации выбрать между sort, hash и index алгоритмами

[zamotivator.livejournal.com]

> Но, возможно, нету эффективных способов отличить небольшой размер результата от большого размера, который эффективнее делать через сортировку.


Ребе, вы сами всё поняли! В данном случае нужно знать unique cardinality по некоторому ключу.
Если у вас по этому ключи есть B-Tree индекс - estimate сделать легко, а вот если нету - сосите хуй. СУБД в такой ситуции работает по пессимистичному сценарию, и это правильно.

Другой вопрос в том, что можно научить её обучаться по итогам выполнения запросов.