программерское

[alex14san]

Увлечение Scala можно считать серьёзным - нашёл в нёй первую ошибку (Add: и исправил, Add2: commit#17380). Очень приятный язык. Если 5 лет назад, когда я увлекался Scheme (и даже написал её компилятор в JavaScript), была возможность в одном крупном проекте использовать любые языки и средства - я всё-таки не рискнул, а сейчас в такой же ситуации

Comments

[cathody]

Кстати, по highload-у есть задачка

[alex14san]

какая?

[cathody]

Текущее состояние:
1) в MySQL-е есть табличка log (serial log_id, int time, int date, char campaign, char product, char fromsearchengine, char country) , в которую пишутся хиты по странице (там 1 insert и 1 select last_insert_id), прочая информация хранится в других таблицах, присоединяемых по log_id ( соответствие many to one).

Когда табличка опухает до 2-3 млн. записей, генерация отчётов ( к примеру, взятие всех хитов в интервале [time1;time2] и группировка по campaign) занимает какое-то совсем неприличное время ~10 cек. Более изъёбистые запросы типа (взять все хиты в промежутке, сгруппировать по campaign и fromsearchengine, после чего посчитать себестоимость по табличке engine ( char campaign, char engine, double cost) радует глаз 30-40-секундной задумчивостью. Трекинг хитов при этом тоже "умирает".

Вопрос: как переписать/переделать эту хню, чтобы не тормозило? По ТЗ, система должна ставиться на виртуальный хостинг и планируемое число кликов порядка 80 000 в день "ровным слоем", а отчёты просматривает один чел?

[alex14san]

1) insert на страницу - абсолютно не дело, по уму надо иметь некий буфер, в котором накапливаются данные для вставки, и периодически вставлять в базу сразу всю пачку

[alex14san]

если нет триггеров то обновления этих агрегированных таблиц делается ручным запросами там же где и пишется log

[alex14san]

если нужна разбивка по времени - делаешь заранее группировку по часам, или по 10-минутным интервалам, и в отчете можно выбрать не произвольный временной диапазон а только по заранее выбранной гранулярности

[alex14san]

ну и составные индексы - наше всё

[cathody]

, по уму надо иметь некий буфер,

Есть проблема: доступа к кронду нет, согласно ТЗ.

баловство

Ага. И очень обидно, когда из-за отчёта лог теряется.

По п.3 - по ТЗ минимальная гранулярность - 10 минут, в чём вся засада.

[alex14san]

если у пхп есть APC буфер можно хранить в нём. 10 минут вполне нормальная гранулярность, в чём проблема-то?

[cathody]

Число записей не сильно снижается, но можно попробовать (хотя поиметь 10-15 INSERT-ов на 1 track - это больно) APC буфер - в PHP4 он есть? (ТЗ не я писал, если чо).

[alex14san]

так тебя число записей волнует или 10-40 секундные select-ы?

[cathody]

Нащёт записей я ступил - там один доп. инсёрт возникает. Но больше волнуют 10-40 секундные селекты

[alex14san]

ну и создай для них таблицы с precalculated данными