|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Andrew Lesnichenko 2:5020/400 03 Sep 2002 09:27:18
To : Michael
Subject : Re: Hужна СУБД с быст рым добавлением запис ей
--------------------------------------------------------------------------------
Michael wrote:
> Hi Andrew,
>
> >> >> Говорим об Оракле.
> >> >>
> >> >> 1. Секционирование наиболее подходящее решение в данном случае. Hо вот
> >> >> стоит ли создавать "секцию" на каждый день - я далеко не уверен.
> >>
> >> AL> Hужно делать делать столько секций, сколько процедур загрузки.
> >>
> >> Данные обычно секционируются на основе боле мене логических правил а
> >> не на основе столь технической вещи как процедура загрузка, котороя не
> >> постоянна по своей природе
>
> AL> Из постановки задачи следовало, что данные грузятся за сутки ...
>
> Из того что ты предлагаешь, следует например:
> 1. если данные, CDRов скажем грузяться в 4ре утра, тогда все звонки с 24.00 до
> 4.00 идут в секцию предидущего дня, что ни есть гуд
> 2. если загрузка по каким то причинам была не возможна несколько дней получаем
> дополнительный геморой.
>
> >> >> 3. данные вливаются в буферную таблицу у которой нет индексов,
> >> используя
> >> >> direct path в случае флэт файлов
> >> >> 4. из буферной таблицы они переносятся в основную используя
> >> >> распараллелиный SQL запрос. (в случае многопроцессорного сервера)
> >>
> >> AL> А это-то все (пп. 3 и 4) зачем ?
> >>
> >> сравни разницу в скорости загрузки между сonventional path и direct path
> >> на больших объемах данных
> >>
> >> для более подробной информации см. Oracle Data Warehousing Guide
>
> AL> Hафига использовать какой-то буфер, когда нужно залить пустую таблицу,
> AL> построить индекс и прицепить к уже имеющейся секционированной таблице
> AL> безо всякого переливания данных.
>
> если использовать секции равные загрузке тогда можно и так.
>
> Кстати расскажи по какому параметру секционировать будешь, по номеру загрузки?
1. Секционировать нужно по тому параметру, который им больше всего
подходит под их приложение. В случае с CDR'ами, это в подавляющем случае
- время совершения звонка. Хотя я сталкивался с ситуациями, когда
выгоднее было секционировать именно по моменту загрузки. Т.е., все
зависит от обработки данных ...
2. Hеясно было, что именно содержат данные, но при съеме данных с
коммутатора можно указать интервал дат. Скажем, снять звонки с 0:00 по
0:00. Либо ставится mediation, который компонует файлы по нужному принципу.
Так или иначе, дальнейшее обсуждение уже есть уточнение деталей под
конкретную задачу. В целом же, на $subj следует отвечать так: "Дело не в
СУБД, умеющей быстро вставлять данные, а в приложении (бизнес-логике),
позволяющей быстро вливать массивы данных." Всякие советы, типа убить
индексы / залить / построить индексы, это технические детали, не имеющие
отношения к выбору СУБД ...
--
Andrew Lesnichenko
--- ifmail v.2.15dev5
* Origin: Mobile TeleSystems (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
