awk vs sql: предварительные результаты

From

Slawa Olhovchenkov (2:5030/500)

To

Valentin Davydov

Date

2006-11-30T14:21:06Z

Area

RU.UNIX.BSD

Hello Valentin!

30 Nov 06, Valentin Davydov writes to All:

 VD> Напомню постановку задачи: есть более-менее однородная таблица, в строках
 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> разу. Селект выполнился за 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> всего, сильно сублинейна, ближе к корневой), то уже видно, что awk заметно
 VD> проигрывает на этой задаче sqlю.

 VD> Когда (и если - мало ли на какие ограничения он может наткнуться) awk
 VD> закончит свою работу, я, надеюсь, опубликую более подробные данные.

А программу на awk оптимизировать пробовал? Написать на нем сначала внешнюю ленточную сортировку, потом результать в один проход агрегировать.

... Засуньте подальше ваше  сообщение  об  ошибках.
--- GoldED+/BSD 1.1.5
 * Origin:  (2:5030/500)
SEEN-BY: 50/12 203 400/814 450/186 1024 451/30 550/196 4614/20 4635/4
SEEN-BY: 5000/5000 5011/13 5012/46 5015/28 5019/26 31 5020/154 175 400 545 549
SEEN-BY: 5020/758 1523 1604 1630 2142 2238 2395 2450 2590 2871 4441 5021/3 29
SEEN-BY: 5022/128 5025/3 750 5027/12 5029/32 5030/49 500 556 966 1063 1080
SEEN-BY: 5030/1900 1957 2828 5031/47 70 5035/38 5040/47 5042/13 5045/7 5049/50
SEEN-BY: 5049/97 5054/1 4 8 9 11 28 35 36 37 45 66 67 70 75 84 85 5055/95
SEEN-BY: 5059/9 37 5062/1 10 5063/3 5064/7 5076/1 5077/70 5080/80 1003 5082/6
SEEN-BY: 5083/21 5084/9 5085/13 5090/108 5094/4 5095/20 5096/18 5099/11
SEEN-BY: 6001/10

PATH: 5030/500 5020/4441 545 5054/1 37