Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Подскажите как правильно ?
|
|||
|---|---|---|---|
|
#18+
Ситуация: есть биллинговая система, информация о звонках (кто, куда, когда, сколько, и т.д.) хранится в таблицах, при чем на каждый месяц таблица создается заново, например radacct2006_03, radacct2006_04, radacct2006_05 и т.д. Создателями системы это объясняется тем что иначе выборка существенно медленне происходит. Вопрос 1. Правилен ли такой подход ? 2. Возможно ли хранить все в одной таблице, настроив правильную индексацию ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 07:33 |
|
||
|
Подскажите как правильно ?
|
|||
|---|---|---|---|
|
#18+
Уточнение: в каждой таблице около 150 000 - 200 000 записей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 07:36 |
|
||
|
Подскажите как правильно ?
|
|||
|---|---|---|---|
|
#18+
Даже в мощных СУБД (Oracle, DB2, MS SQL server) используют такие же подходы, только делают это на уровне СУБД посредством секционированных таблиц (partitioned tables), ну и объемы партиций измеряются десятками и сотнями миллионов записей. Подход оправдан. Очевидный плюс - использование подхода "разделяй и властвуй" - маленькими табличками управлять легче чем большими (с точки зрения администрирования) Очевидный минус - неудобство сопровождения, сложность написания запросов (с точки зрения разработки). Если слить в одну таблицу, и навешать "правильную индексацию", то можно ускорить запросы, но замедлить DML-операции. Как вариант, если уж так охото всё в кучу собрать - сделать секционированной представление вида: select * from radacct2006_03 union all select * from radacct2006_04 union all ... и т.д. И каждый месяц это представление перестраивать с учетом вновь добавленной таблицы. Все же запросы (отчеты) направлять к этому представлению. "Продвинутые" сервера могут исключать из рассмотрения "лишние" секции такого представления, данные которых не удовлетворяют условиям WHERE, накладываемым на выборку из этого представления. НО!!! В любом случае - нужно пробывать. Ибо универсальных решений не существует... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 08:09 |
|
||
|
Подскажите как правильно ?
|
|||
|---|---|---|---|
|
#18+
Как пища для ума ----------------------------------------------------------------------------------------------------------------------------------------- З.Ы. Неспешно ищу работу, согласен на переезд в Москву или Питер ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 08:22 |
|
||
|
Подскажите как правильно ?
|
|||
|---|---|---|---|
|
#18+
Ну и непосредственно сылка на доку по PostgreSQL, где идет речь о секционировании таблиц: тынц - PostgreSQL 8.1.4 Documentation, Chapter 5. Data Definition, 5.9. Partitioning ----------------------------------------------------------------------------------------------------------------------------------------- З.Ы. Неспешно ищу работу, согласен на переезд в Москву или Питер ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 08:32 |
|
||
|
|
start [/forum/topic.php?fid=53&fpage=316&tid=2006208]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
37ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
26ms |
get tp. blocked users: |
1ms |
| others: | 217ms |
| total: | 316ms |
| 0 / 0 |
