|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Davydov 2:5020/400 30 Nov 2006 18:09:37
To : Slawa Olhovchenkov
Subject : Re: awk vs sql: предварительные результаты
--------------------------------------------------------------------------------
> From: Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org>
> Date: Thu, 30 Nov 2006 14:21:06 +0300
>
> VD> Hапомню постановку задачи: есть более-менее однородная таблица, в строках
> VD> которой присутствуют, помимо прочих, поля "клиент" и "количество".
> VD> Требуется для каждого клиента сосчитать полную сумму по всей таблице.
>
> VD> В эхе было высказано мнение о том, что awk на этой задаче порвёт любой
> VD> SQL-сервер. Я усомнился, поскольку правильно подготовленная таблица в
> VD> SQL-базе содержит весьма существенные хинты, а тупой awk вынужден идти
> VD> алгоритмически неэффективным путём. Для проверки решил поставить
> VD> эксперимент.
>
> VD> У меня имеется некая SQL-база с достаточно большой таблицей. Достаточно -
> VD> это значит, что ни сама таблица, ни промежуточные данные, ни конечный
> VD> результат в память не помещаются, так что и sql, и awk находятся в
> VD> одинаковых условиях, производительность ограничена дисковыми операциями.
> VD> Ибо в противном случае (когда вся база влезает в ОЗУ) о тормозах и речи
> VD> нет, нынешние процессоры весьма быстры.
>
> VD> Sql сервер (конкретно sqlite3, но не думаю, что результат принципиально
> VD> изменится при использовании другого) для выполнения запроса выбрал
> VD> следующую стратегию: двигаясь по (упорядоченному, в качестве бонуса)
> VD> индексу клиентов он собирает все строчки, относящиеся к данному клиенту,
> VD> выдаёт строку результата и переходит к следующему клиенту. Таким образом,
> VD> он обращается к каждой строке таблицы ровно один раз, но в случайном
> VD> порядке. И к каждой записи в индексе, замечу, он обращается тоже по
> VD> одному
> VD> разу. Селект выполнился за 12 с небольшим суток.
>
> VD> Затем был выполнен select * from table, и на полученный текстовый файл
> VD> (к слову сказать, занимающий примерно вдвое меньше места на диске, нежели
> VD> структурированный файл базы данных) натравлен awk '{a[$2]+=$7};
> VD> END{for(c in a) print c, a[c]}' | sort -k1. Поскольку awk вынужден
> VD> рассматривать строки в том порядке, в котором они идут в таблице, ему
> VD> _каждый_ раз приходится обращаться к индексу (массиву a), достраивая его
> VD> по мере необходимости. Сейчас awk работает уже шестые сутки, и за это
> VD> время переварил только 25% исходного файла. Даже если предположить
> VD> линейную
> VD> зависимость количества обработанных данных от времени (а она, скорее
> VD> всего, сильно сублинейна, ближе к корневой), то уже видно, что awk
> VD> заметно
> VD> проигрывает на этой задаче sqlю.
>
> VD> Когда (и если - мало ли на какие ограничения он может наткнуться) awk
> VD> закончит свою работу, я, надеюсь, опубликую более подробные данные.
>
>А программу на awk оптимизировать пробовал? Hаписать на нем сначала внешнюю
>ленточную сортировку, потом результать в один проход агрегировать.
Я, пока писал вышеотквоченное, ещё решил sort | awk попробовать. Только ведь
сортируй - не сортируй, всё равно промежуточные данные на диск должны лезть.
Правда, с sortом всё не так чисто: при том количестве промежуточных файлов
в $TMPDIR, которые он создаёт, ещё нормально работает dirhash. Hо чтобы и
это проверить, надо не просто много данных, а экспоненциально много, а у
меня такого количества дисков и времени нету.
Вал. Дав.
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: awk vs sql: предварительные результаты 