|
|
|
Нужен совет по range partitioning
|
|||
|---|---|---|---|
|
#18+
Hi! Есть ряд вопросов, касающихся целесообразности использования секционирования (range, в частности). Итак: 1. Ключ секционирования - дата. 2. Необходимости или возможности выдёргивать исторические данные по одной секции нет. 3. Все секции находятся на одном дисковом массиве. 4. Доступ к данным происходит, в основном, по значению даты в неком диапазоне (ключ секционирования) и значению ряда других полей, при этом выбираются значения практически всех полей. В половине случаев запрос проходит по всем секциям таблицы (дата < sysdate, например). 5. Таблица увешана индексами (9 штук), как локальными, так и глобальными. 6. Таблица интенсивно обновляется, добавляется и удаляется (впрочем, добавляется, в первую очередь). 7. Приложение явным образом с секциями не работает. Имеет ли смысл использовать секционирование в данном случае? Имеет ли смысл одновременное использование и локальных и глобальных индексов? Сервисные операции (перестройка индексов, перемещение секций) не рассматриваем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 10:34 |
|
||
|
Нужен совет по range partitioning
|
|||
|---|---|---|---|
|
#18+
Вобще Oracle рекомендует использовать partitioning для всех таблиц размер которых более 2Гб. В твое случае нет явной необходимости использования partitioning, но как мне кажется, если данных много, стоит воспользоваться данной технологией. Хотябы потому что остается другая половина запросов :) >В половине случаев запрос проходит по всем секциям таблицы (дата < sysdate, например). >Приложение явным образом с секциями не работает Оптимизатор сам выберает нужные партиции по предложению where >Имеет ли смысл одновременное использование и локальных и глобальных индексов? Это зависит от запросов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 11:45 |
|
||
|
Нужен совет по range partitioning
|
|||
|---|---|---|---|
|
#18+
Hi! Все зависит от количества данных в таблице. Я разбивал таблицу из 20 млн. записей по дате. Каждый день в таблицу спускается ококо 250 тыс. записей. Особых результатов в скорости работы я не добился. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 11:53 |
|
||
|
Нужен совет по range partitioning
|
|||
|---|---|---|---|
|
#18+
>Имеет ли смысл одновременное использование и локальных и глобальных индексов? Это зависит от запросов Можешь рассказать чуть подробнее? Смысл в том, что все (вообще) селекты содержат в себе элемент даты, только в одной половине случаев дата ограничена с одной стороны, а в другой - с обеих. Ну и разные другие поля фигурируют (таблица очень широкая). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 11:55 |
|
||
|
Нужен совет по range partitioning
|
|||
|---|---|---|---|
|
#18+
Да, вот еще. Я строил локальный индекс по дате - индекс весил 1 гб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 11:56 |
|
||
|
Нужен совет по range partitioning
|
|||
|---|---|---|---|
|
#18+
Смысл в том, что все (вообще) селекты содержат в себе элемент даты, только в одной половине случаев дата ограничена с одной стороны, а в другой - с обеих Если дата ограничена сверху или снизу, то пойдет по секции (PARTITION RANGE ITERATOR) и работать будет быстрее. Но опять же все зависит от того во сколько pratition'ов ты попадешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 12:08 |
|
||
|
Нужен совет по range partitioning
|
|||
|---|---|---|---|
|
#18+
>Смысл в том, что все (вообще) селекты содержат в себе элемент даты, >только в одной половине случаев дата ограничена с одной стороны, а в >другой - с обеих. Ну и разные другие поля фигурируют (таблица очень >широкая). Все зависит от ограничения выборки данных. Если выборка идет из определенной партиции то локальный подоедет больше. Если в выборке участвуют данные из разных партиций то лутшеи выбрать глобальный. Что касается индексирования остальных полей это зависит от того в каком контексте ты будеш их выбирать, т.е. связан он с и выборкой по дате или имеет самостоятельное представление. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 12:10 |
|
||
|
Нужен совет по range partitioning
|
|||
|---|---|---|---|
|
#18+
А какая разница, связано что-то с датой или нет, если дата - всегда одно из условий запроса? Чего-то я запутался :) Расскажи, пожалуйста, за счёт чего может быть выигрыш в производительности в моём случае при использовании секционирования? Да, кстати, забыл сказать - таблица практически ни в одном запросе ни с одной другой таблицей не соединяется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 12:17 |
|
||
|
Нужен совет по range partitioning
|
|||
|---|---|---|---|
|
#18+
"Расскажи, пожалуйста, за счёт чего может быть выигрыш в производительности в моём случае при использовании секционирования? " Как я понимаю, смысл в партициях есть когда запросу требуются данные только из одной партиции. Если условие выборки заставляет обращаться к нескольким партициям - то собственно какой смысл в них. Выигрыш производительности:это всё равно, что иметь не одну таблицу в 1млн. записей, а две таблицы по 500тыс. запис. Если нужные тебе данные находятся только в одной и ты об этом знаешь, ты сделаешь запрос к той которой надо. С партициями тоже самое примерно, я так понимаю. Только выбор нужной партиции определяется исходя из условий запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 12:27 |
|
||
|
Нужен совет по range partitioning
|
|||
|---|---|---|---|
|
#18+
>А какая разница, связано что-то с датой или нет, если дата - всегда одно из условий запроса? Чего-то я запутался :) Скажем если дополнительное поле участвует в условии самостоятильно, т.е. нет никаких ограничений на дату Примерно так where field1=100 а не так where datefield>sysdate-100 and datefield<sysdate and field1=100 Если в деапазон дат попадает определенная партиция то для field1 следует выбрать локальный индекс. Если в последнем условии вместо and field1=100 будет or field1=100 то делай глобальный. и.т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2003, 12:30 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=32137417&tid=1991071]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
161ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 460ms |

| 0 / 0 |
