Оптимизация в сборке 015
Оптимизация в сборке 015
Что она делает?
Re: Оптимизация в сборке 015
Делает "склеивание" похожих записей. Например, за день было 100 списаний на одного пользователя за класс трафика 10 по цене 0.1 у.е./МБ. После оптимизации будет 1 запись с суммарным объемоми суммарной стоимостью. На наших тестах и на реальных базах эффективность очень хорошая - к примеру из 5 млн. записей получается около 200 тыс.dalex писал(а):Что она делает?
mysql 5.x ?taf писал(а):А вот в этом случае как нельзя кстати выплывает применение хранимых процедур на стороне СУБД. ( Тооолстый намек на одну определенную PRDBMSChris писал(а):Aospan молодец! Давно пора! НО НАДО ЭТО ДЕЛАТЬ НА УРОВНЕ КОГДА ЗАЛИВАЕТСЯ ТРАФИК! Если применительно к трафику.)
Изначально было принято решение не завязываться (по крайней мере в массовом продукте) на специфику конкретной БД. В "штучных" вариантах (под заказчика) оправданно.
Детализация с точностью до периода аггрегации нужны за 2-3 месяца, а дальше уже можно и аггрегировать старые данные. В связи с этим на лету при записи трафика делать аггрегацию не столько актуально ...Chris писал(а):Aospan молодец! Давно пора! НО НАДО ЭТО ДЕЛАТЬ НА УРОВНЕ КОГДА ЗАЛИВАЕТСЯ ТРАФИК! Если применительно к трафику.
Понимаешь... Тебе надо посмотреть продукты скажет Niclaus, IPSoft Billing, там аггрегация делается при заливке в базу, деталка храниться отдельно. Это делается для того, чтобы обрабатывать в базе как можно больше запросов и трафика, тем самым данные системы получают хорошую прибавку в скорости работы. Вычисления все делаются на уровне опять же базы, т.к. у тебя MySQL данная хрень не прокатит, придёться делать либо при заливке трафика клиентом по заливке (UTM Core соотв), либо заливать и тупо анализить ворочая миллион записей и теряя процессорное время.
а дефрагментацию InnoDB еще если включить?
viewtopic.php?t=1371
viewtopic.php?t=1371
С какого перепугу мыскль стал PRDBMS? Оно еще до полноценной RDBMS не дорослоaospan писал(а):mysql 5.x ?taf писал(а):А вот в этом случае как нельзя кстати выплывает применение хранимых процедур на стороне СУБД. ( Тооолстый намек на одну определенную PRDBMSChris писал(а):Aospan молодец! Давно пора! НО НАДО ЭТО ДЕЛАТЬ НА УРОВНЕ КОГДА ЗАЛИВАЕТСЯ ТРАФИК! Если применительно к трафику.
Изначально было принято решение не завязываться (по крайней мере в массовом продукте) на специфику конкретной БД. В "штучных" вариантах (под заказчика) оправданно.
Я имел в виду PostgreSQL. Система весьма серьезная, личный опыт эксплуатации UTM5 есть и на мыскле 4.x и на PG. После перехода на PG забыл, что такое тормоза при большой базе, забыл (тьфу-тьфу-тьфу) что такое осыпавшиеся таблицы (а про такую напасть время от времени здесь пишут). Это что мне вспоминается сразу же.А тут еще агрегация записей списания, которая так и напрашивается на storage-procedure решение
Перед тем, как спорить, нужно почитать документацию.Chris писал(а):Понимаешь... Тебе надо посмотреть продукты скажет Niclaus, IPSoft Billing, там аггрегация делается при заливке в базу, деталка храниться отдельно. Это делается для того, чтобы обрабатывать в базе как можно больше запросов и трафика, тем самым данные системы получают хорошую прибавку в скорости работы. Вычисления все делаются на уровне опять же базы, т.к. у тебя MySQL данная хрень не прокатит, придёться делать либо при заливке трафика клиентом по заливке (UTM Core соотв), либо заливать и тупо анализить ворочая миллион записей и теряя процессорное время.
Деталька в UTM5 никогда не хранилась в SQL. Речь идет о склеивании уже агрегированных данных. И агрегация делается, как "вы тут советуете" перед тем, как записать данные в БД.
Детальная статистика в UTM 5.0 хранится в бинарных файлах и объем таких файлов за день может достигать десятков гигабайт. Никакая SQL база данных не справится с такими объемами.