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