ну да.. это то. о чем я писал - аггрегирующий матвью с рефрешем на комиит и квери реврит. В результате запрос производится не к табличке а к матвьюхе.   
Админ был хорош!

я девелопер, не админ. В железе не шарю. Шарю в долларах.
Завтра я дам тебе тиминг с сервера за полтора ляма оных. Думаю, если стоимость выражает качество железа, это очень хорошее железо.

Да, у нас это редкость, спроса мало.

Сейчас попробую сделать job-ы, спасибо  

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

что делать?

Это сообщение отредактировал(а) azesmcar - 28.2.2010, 18:21

Выбирать правильный разрез преаггрегации 
/*под разрезом представления статистических данных обычно имеют в виду поля, перечисленные в group by*/
У тебя уже один из разрезов выявлен - год.  Возможно месяц или день.
Второй, по всей видимости - вендор, т.к. по нем группируешься.
Можно иметь несклько разрезов преаггрегации, для разного рода отчетов.

Вообще сложно тебе советовать, не понимая твоей специфики. Я с задачами биллинга, увы, никогда не сталкивался. И, кстати, на приведенной тобой структуре вообще не фегурирует ни одной даты, потому как реализовывать требование "за последний год"- вообще не ясно.


Если это только отчеты, которые читать предназначено людям, то отставание статистики на время менее чем в полминуты, вообще может оказаться незамеченным. А чтобы уложиться в полуминутный норматив, можно пустить несколько процессов пересчета. Главное озаботиться, чтобы эти процессы не толкались меж собой на блокировках. Например если у тебя разрез преаггрегации - (вендор, месяц), а пускаешь для расчета два процесса, то один может пересчитывать данные для четных вендоров, другой, для нечетных.


Это сообщение отредактировал(а) Zloxa - 28.2.2010, 18:52

если представить все разрезы преаггрегации получится таблица CDR  в этом то и вся проблема..разве что если не делать поиск по времени а только по дате .. нужно будет подумать об этом.


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

По сути CDR (Call Duration Records) - таблица, которая хранить данные о всех звонках (даже не прошедших), данные об ошибке, коды разные, айпи адреса и тому подобное .. в общем всю ту фигню, которую посылает свитч. Там же хранится дата. Отчет, о котором мы говорим - суммарный, его смысл - посмотреть суммарные данные за некий промежуток времени, т.е. сумму длительностей всех звонков, среднюю длительность звонка, сколько всего звонков было, сколько из них не прошло и все это для каждого customer-а и vendor-а. 

Еще как идея, хранить преаггрегацию, скажем по месяцу.  
А аггрегацию по произвольному интервалу делать аггрегацией по объединению трех запросов:


Добавлено @ 20:02
ps сорри за ораклиный синтаксис в ветке по MySQL. думаю о чем речь понятно, а иначе выразить мысль не смог.

Это сообщение отредактировал(а) Zloxa - 28.2.2010, 20:07

Zloxa

А если пользователь захочет данные за последние 2 дня например? Или я не так понял?
Сейчас убрал поиск по времени, все равно он особо не нужен, создал таблицу

пока что решил обновлять в триггере таблицы CDR, завтра сделаю замеры производительности при стресс-тесте (на моем ноутбуке это бессмысленно), потом, если производительность вставки не устроит, вынесу в отдельный job.

Вроде работает, запустил автомат-тест, завтра утром посмотрю, что там произошло.


Zloxa
Спасибо за помощь.

azesmcar, а прокэшировать запрос нельзя чтоли?

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

говорят что если много инсертов, то триггерЫ могут жрать ресурсы очень, так как они будут все время вызыватся

Это сообщение отредактировал(а) gcc - 28.2.2010, 21:05

Тогда второй и третьи подзапросы ничего не отберут, если я не накосячил.

Если у тебя инсерты прут разными сессиями - не забывай о блокировках. В случае реализации преаггрегации в триггере, ты упорядочиваешь вставки по ключам аггрегации.

Добавлено через 1 минуту и 7 секунд

информация в кэше актуальна до ближайшего инсерта.
нет?

инсертит одна сессия - ядро системы, читают пользователи через веб. Я видимо слишком долго сидел за компьютером, совсем не соображаю, в общем проблема с отчетами решилась, все в порядке, но первая проблема осталась, я только допер  

В общем дела обстоят так:

Есть веб страница, на ней показываются последние звонки, все, для всех пользователей, эта страница существует для администратора. Он имеет возможность фильтровать данные, например: показать все звонки на номер 37410%, или все звонка от конкретного customer-а или и то и другое (все звонки от customer-а на номер xxxx). Совет

сперва мне показался удачным, но сейчас понимаю что тут есть проблемы, а именно
выбираем 10 id (т.е. первую страницу показа) потом подключаем к ней таблицу customers и vendors, а уж потом фильтруем. Что получаем в итоге? Отфильтрованные строки из 10-и строк а не 10 отфильтрованных. Да и count считать по любому нужно на фильтрованном запросе.

Пока вижу один вариант - не показывать данные без фильтра, т.е. если пользователю интересно что-то конкретно то пусть ищет, а загрузка всех данных одновременно (пусть даже постранично) убирается.

Есть идеи?


да 

Добавлено через 5 минут и 24 секунды

ну так мне и нужно чтобы он все время вызывался.


  это по поводу отчета или первого вопроса?

Это сообщение отредактировал(а) azesmcar - 28.2.2010, 21:33

тогда это не подходит...
насколько я видел что счетчики в билинге срабатываются дискретно за какое-то время, например, подсчитывается количество трафика за какое-то время... но не до первого следующего инсерта....

чуть не забыл, мне вот рекомендовали когда-то посмотреть на Атомарность операций и счетчики в memcached (см. Счетчик просмотров).



Это сообщение отредактировал(а) gcc - 28.2.2010, 22:11

Тогда пляс с бубном вокруг иммитации жобы  не уместен ;)

КО говорит что фильтровать таки надо сначала    
Не совсем понятно что тому препятствует

Некоторые поля появляются только после JOIN-а, пришлось перенести.  

вот эта желеска попроще.
Кластер о двух нодах и очень хорошая корзина.
Когда меня на это железо переехали, я возрадовался.
Пяти минут не получилось, получилось только две. Если бы оставил дефолтным мультиблок рид каунт, было бы малость подольше


а вот это - самолет за который много бабла плачено, который ИБМ обслуживают
Удивительно, но считал он подольше малость.
Но та табличка секционирована, можно было бы параллелизацию запустить, быстрее было б.