|
|
|
Агрегация данных по дате
|
|||
|---|---|---|---|
|
#18+
Система - биллинг. Необходимо каждое действие со счетом отражать в таблице или приходом (запись со знаком +) или расходом (с минусом :-) ). Актуальное состояние счета на конкретную дату планируется получать суммированием. Безусловно, суммировать всю историю изменения счета глупо. Поэтому целесообразно применить агрегацию, т.е. расчеты по состоянию на какую-то дату. В результате получение состояния счета сведется к суммированию изменений с даты последней агрегации, меньшей требуемой даты, по требуемую дату. Возникла резонная мысль: а не делает ли это СУБД самостоятельно, неявно? И насколько оправдан такой подход расчета? Информация: изменений счета за сутки может быть до десятков миллионов раз. СУБД Postgresql ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2007, 16:52 |
|
||
|
Агрегация данных по дате
|
|||
|---|---|---|---|
|
#18+
TheUserСистема - биллинг. Необходимо каждое действие со счетом отражать в таблице или приходом (запись со знаком +) или расходом (с минусом :-) ). Актуальное состояние счета на конкретную дату планируется получать суммированием. Безусловно, суммировать всю историю изменения счета глупо. Поэтому целесообразно применить агрегацию, т.е. расчеты по состоянию на какую-то дату. В результате получение состояния счета сведется к суммированию изменений с даты последней агрегации, меньшей требуемой даты, по требуемую дату. Возникла резонная мысль: а не делает ли это СУБД самостоятельно, неявно? И насколько оправдан такой подход расчета? Информация: изменений счета за сутки может быть до десятков миллионов раз. СУБД Postgresql Обычно в подобных (биллинговых) системах сохраняется состояние счета на каждый день ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2007, 18:18 |
|
||
|
Агрегация данных по дате
|
|||
|---|---|---|---|
|
#18+
TheUser Возникла резонная мысль: а не делает ли это СУБД самостоятельно, неявно? Не слыхал! Если кто-то делает, вы и с нами поделитесь инфой !!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2007, 19:47 |
|
||
|
Агрегация данных по дате
|
|||
|---|---|---|---|
|
#18+
Postgresql насколько я знаю не имеет materialized view + query rewriting. Но даже там, где оно есть, фича не настолько продвинута, чтобы решать алгебраические уравнения. Добиться результата наверно можно, однако нужно будет в своем запросе практически открытым текстом упомянуть запрос того materialized view, которое хотим использовать. Какой от этого прок - не видно. Проще руками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 10:01 |
|
||
|
Агрегация данных по дате
|
|||
|---|---|---|---|
|
#18+
TheUserВозникла резонная мысль: а не делает ли это СУБД самостоятельно, неявно? И насколько оправдан такой подход расчета? Информация: изменений счета за сутки может быть до десятков миллионов раз. СУБД Postgresql Подход типичный - остатки на конкретную дату = аггрегированные остатки на начало периода (регистры остатков) + обороты за период. Период аггрегации выбирается в соответствии с нарузкой на систему. Регистры остатков могут быть многоуровневыми (1-час/2-день/3-месяц...) помимо материализованных вью (oracle) и индексированных вью (mssql), часто для подобной задачи применяют OLAP (ROLAP). Однако, в биллинге материализованные и индексированные вью не самое лучшее решение, т.к. любая операция по изменению данных вызывает перестройку этого вью. Чаще все так и регистры создаются по заданию при закрытии периода, к тому же с объемами данных в биллинге гораздо важнее оптимизировать таблицы оперативных данных (таблицы движений), например, секционированием (partitioned view, partitioned table). А секционирование + индексированные вью на одних и тех же таблицах - очень сомнительное мероприятие... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 11:06 |
|
||
|
Агрегация данных по дате
|
|||
|---|---|---|---|
|
#18+
TheUserИнформация: изменений счета за сутки может быть до десятков миллионов раз. СУБД PostgresqlВ системах биллинга есть два хороших решения. Первое - разделение таблицы базы данных на три. В одной хранятся сырые данные за сегодня, во второй - за всю остальную историю, в третьей - агрегированные данные. Ночью, часа в три-четыре, данные за вчерашний день переносятся из первой таблицы во вторую. Второй подход связан с помещением агрегированных данных о текущем состоянии счётов в память и прибавлении-вычитании сумм реальном времени плюс ведении plain-text логов о транзакциях. Например, счётчики для аккаунтов всей Москвы уместятся в 4*10 млн.*2 = 80 Мб, всей России в 4*150 млн.*2 = 1,2 Гб. Это с учётом 2 аккаунтов на человека и хранения значений типа int32. Нагрузка будет держаться до 50 тыс. записей в секунду, самая медленная подсистема - жёсткий диск. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2007, 14:37 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=34838928&tid=1544263]: |
0ms |
get settings: |
6ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
145ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 221ms |
| total: | 452ms |
| 0 / 0 |
