Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Стоит ли делать секционирование(партиционирование)?  [new]
griboedov
Member

Откуда:
Сообщений: 2
Здравствуйте! Прошу совета, будучи новичком в секционировании.
Есть БД. Большая часть данных сосредоточена в 10 таблицах. Суммарно ожидается добавление около 20млн записей в год.
Планирую добавить таблицу отделов и в этих 10 таблицах добавить ссылку на отдел. Отделов будет 5-10.
Имеет ли смысл делать секционирование по отделам, при условии, что подавляющее большинство запросов работают с данными только одного отдела?
4 дек 14, 18:12    [16951622]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
varlamovvp
Member

Откуда: Moscow
Сообщений: 297
griboedov,

подавляющее большинство запросов просто будет работать в 5-10 раз быстрее.
а надо или нет - это Вам решать
4 дек 14, 18:14    [16951642]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
AmKad
Member

Откуда:
Сообщений: 5222
griboedov
Отделов будет 5-10.
Если кол-во отделов постоянно, то смотрите в сторону List-partitioning.
4 дек 14, 18:24    [16951703]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
stax..
Guest
griboedov
Здравствуйте! Прошу совета, будучи новичком в секционировании.
Есть БД. Большая часть данных сосредоточена в 10 таблицах. Суммарно ожидается добавление около 20млн записей в год.
Планирую добавить таблицу отделов и в этих 10 таблицах добавить ссылку на отдел. Отделов будет 5-10.
Имеет ли смысл делать секционирование по отделам, при условии, что подавляющее большинство запросов работают с данными только одного отдела?

не знаю как счас
но раньше partition опция стоила отдельных денех

......
stax
4 дек 14, 18:52    [16951876]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
griboedov
Member

Откуда:
Сообщений: 2
AmKad,
Кол-во отделов не постоянное. Изначально 1. Остальные добавляются динамически.

stax..,
Сейчас тоже за доп. плату http://orashop.ru/calculate.asp?s_no=750&d_no=755

Возникает вопрос будет ли в данном случае секционирование оптимальным решением с точки зрения производительности? Или лучше копать в какую-нибудь другую сторону.
4 дек 14, 19:05    [16951938]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
Nikolay Savvinov
Member

Откуда: Россия
Сообщений: 98
griboedov
Здравствуйте! Прошу совета, будучи новичком в секционировании.
Есть БД. Большая часть данных сосредоточена в 10 таблицах. Суммарно ожидается добавление около 20млн записей в год.
Планирую добавить таблицу отделов и в этих 10 таблицах добавить ссылку на отдел. Отделов будет 5-10.
Имеет ли смысл делать секционирование по отделам, при условии, что подавляющее большинство запросов работают с данными только одного отдела?


Секционирование дает преимущества в производительности при полном просмотре (full scan) таблицы или индекса, при условии что запрос содержит предикат по ключу секционирования. В этом случае в место того, чтобы просматривать всю таблицу (индекс), просматриваться будет один раздел (или диапазон разделов). При индексном доступе (index unique/range scans) секционирование практически не дает никаких преимуществ, скорее оно может вызвать проблемы с производительностью в случае с локальными индексами (см. ниже).

Помимо производительностью, весомыми факторами при решении о секционировании таблицы являются соображения поддержки таблицы -- например, при секционировании таблицы вы можете разместить разные секции в разных табличных пространствах, и каждую из них по отдельности бэкапить, убирать в оффлайн, переводить в режим "только чтение" и т.п. Также популярная причина для секционирования -- соображения Information Lifecycle Management and/or Storage Tiering (например, при хронологическом секционировании вы можете разместить самые свежие данные на быстрых и дорогих дисках, а более старые и менее востребованные на более дешевых, или сжимать их). Хотя это вряд ли ваш случай.

Если вы решаете секционировать таблицу, то вам нужно будет определиться, как быть с индексами по ней: делать их локальными или оставить глобальными. Глобальный индекс -- значит, можно оставить все как было, один индекс на всю таблицу, или секционировать индекс по другому ключу. Локальный индекс -- каждому разделу таблицы будет соответствовать раздел индекса. Локальные индексы лучше с точки зрения поддержки (перестроили раздел таблицы -- нужно перестроить только один раздел локального индекса). Глобальные индексы этого преимущества не имеют, зато не имеют и проблем с производительностью, от которых страдают локальные индексы. А именно, если запрос использует локальный индекс, но при этом не содержит условия по ключу секционирования, то сканирование индекса будет происходить в каждом разделе отдельно. В вашем случае это означает, что запросы без указания отдела будут работать, грубо говоря, в 10 раз медленнее.

Исходя из того, что вы сообщили, в вашем случае скорее всего уместно будет провести секционирование по описанной вами схеме, и оставить все индексы глобальными, чтобы не рисковать с производительностью. Понятное дело, что вы планируете большинство запросов проводить с указанием отдела, но ведь некоторые запросы будут и без (например "найти, в каком отделе работает Иванов"). Вряд ли вас порадует, если они будут работать в 10 раз медленнее, чем без секционирования. Соображения в пользу локальных индексов в вашем случае представляются менее весомыми.

С уважением,
Николай
4 дек 14, 22:32    [16952688]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
stax..
Guest
griboedov
Здравствуйте! Прошу совета, будучи новичком в секционировании.
Есть БД. Большая часть данных сосредоточена в 10 таблицах. Суммарно ожидается добавление около 20млн записей в год.
Планирую добавить таблицу отделов и в этих 10 таблицах добавить ссылку на отдел. Отделов будет 5-10.
Имеет ли смысл делать секционирование по отделам, при условии, что подавляющее большинство запросов работают с данными только одного отдела?


если по отделах есть идекс, то мож и проиграете

ps
імхо, написал кагда надо партитион, постеснялся и стер
.....
stax
4 дек 14, 22:48    [16952736]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
griboedov,

хотя условие, что "подавляющее большинство запросов работают с данными только одного отдела" действительно выглядит убедительным, но по-хорошему такое нужно тестировать на конкретном приложении и конкретной нагрузке, т.к. вполне может оказаться, что меньшинство запросов как раз создаст большую проблему. Кроме того, во время тестирования вы вероятно найдете запросы, в которых "забыли" предикаты по отделу.
4 дек 14, 23:29    [16952850]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
Nikolay Savvinov
При индексном доступе (index unique/range scans) секционирование практически не дает никаких преимуществ, скорее оно может вызвать проблемы с производительностью в случае с локальными индексами (см. ниже).
с красным категорически не согласен:
во-первых, это помогает снизить конкуренцию(самую разную);
во-вторых, дает позволяет оптимизатору использовать механизм table expansion, т.е. иметь разные пути доступа для разных секций;
в-третьих, позволяет оптимизатору иметь более точные статистики;
в-четвертых, позволяет понизить высоту индексов(что в общем-то не так важно)

С зеленым несогласен по поводу:
Nikolay Savvinov
А именно, если запрос использует локальный индекс, но при этом не содержит условия по ключу секционирования, то сканирование индекса будет происходить в каждом разделе отдельно. В вашем случае это означает, что запросы без указания отдела будут работать, грубо говоря, в 10 раз медленнее.

Грубо говоря, индексный доступ при partition range/all iterator'e это просто как поиск в нескольких таблицах:
select * from tab1 where a=:a
union all
select * from tab2 where a=:a

то есть работы прибавляется лишь на сам перебор по секциям и на "лишнее" проход по бранч-блокам, т.е. если при несекционированной таблице нужно было один раз пройти от корня, то при 10 секциях - 10 раз, но это всего лишь 10*высота дерева.
4 дек 14, 23:49    [16952903]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
xtender
то есть работы прибавляется лишь на сам перебор по секциям и на "лишнее" проход по бранч-блокам, т.е. если при несекционированной таблице нужно было один раз пройти от корня, то при 10 секциях - 10 раз, но это всего лишь 10*высота дерева.
Ну, это, собственно говоря, и есть "грубо говоря, в 10 раз медленнее". Как правило, высота глобального индекса если и будет отличаться от высоты локального, то не более, чем на 1.
5 дек 14, 02:20    [16953105]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
Вячеслав Любомудров,

Я к тому, что грубо говоря это от x до y, которые сильно зависят от количества возвращаемых строк: если их 0 - то все плохо, а если их по тысяче в каждой секции, то разница настолько мизерная что ее считай нет
5 дек 14, 02:31    [16953110]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
Еще кстати, параллелить хорошо можно будет от range scan'ов
5 дек 14, 02:50    [16953113]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
Nikolay Savvinov
Member

Откуда: Россия
Сообщений: 98
xtender
Nikolay Savvinov
При индексном доступе (index unique/range scans) секционирование практически не дает никаких преимуществ, скорее оно может вызвать проблемы с производительностью в случае с локальными индексами (см. ниже).
с красным категорически не согласен:
во-первых, это помогает снизить конкуренцию(самую разную);
во-вторых, дает позволяет оптимизатору использовать механизм table expansion, т.е. иметь разные пути доступа для разных секций;
в-третьих, позволяет оптимизатору иметь более точные статистики;
в-четвертых, позволяет понизить высоту индексов(что в общем-то не так важно)

С зеленым несогласен по поводу:
Nikolay Savvinov
А именно, если запрос использует локальный индекс, но при этом не содержит условия по ключу секционирования, то сканирование индекса будет происходить в каждом разделе отдельно. В вашем случае это означает, что запросы без указания отдела будут работать, грубо говоря, в 10 раз медленнее.

Грубо говоря, индексный доступ при partition range/all iterator'e это просто как поиск в нескольких таблицах:
select * from tab1 where a=:a
union all
select * from tab2 where a=:a

то есть работы прибавляется лишь на сам перебор по секциям и на "лишнее" проход по бранч-блокам, т.е. если при несекционированной таблице нужно было один раз пройти от корня, то при 10 секциях - 10 раз, но это всего лишь 10*высота дерева.


Формально вы говорите все правильно. Фактически -- вы ставите на одну доску какие-то тонкие и/или редкие эффекты, с одной стороны, и с другой -- эффекты очень весомые, грубые и зримые. "Найти в каком отделе работает Вася Пупкин" -- это один из самых популярных use case'ов, и вот все такие запросы с локальными индексами будут работать в 10 раз медленнее.


С уважением,
Николай
5 дек 14, 08:42    [16953301]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
Nikolay Savvinov
Member

Откуда: Россия
Сообщений: 98
xtender
Еще кстати, параллелить хорошо можно будет от range scan'ов


Index range scan, который требует параллелизации -- вещь редкая. Во-первых, на практике большинство IRS читают один leaf block, во-вторых, если блоков читается много, то по мере роста их количества IRS достаточно быстро начинает проигрывать index fast full scan'у (за счет способности последнего к многоблоковым чтениям).

С уважением,
Николай
5 дек 14, 08:54    [16953331]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
Nikolay Savvinov
Фактически -- вы ставите на одну доску какие-то тонкие и/или редкие эффекты, с одной стороны, и с другой -- эффекты очень весомые, грубые и зримые.

Николай, ну вроде очевидно же, что это очень сильно зависит от конкретного приложения и конкретной нагрузки... При высокой нагрузке конкуренция становится крайне "убедительной и зримой". Редко ли на жалуются на всякие index contention, cache buffer chains, gc XXXX, и тд и тп?
Например, недавно обсуждали RAC, так правильное секционирование и разбиение нагрузки по нодам -- одно из важнейших архитектурных решений, влияющих на scaling. Если не предусмотрели на ранних этапах возможность секционирования, то потом это потребует гораздо больших затрат при росте нагрузки и кол-ва данных.
5 дек 14, 10:23    [16953725]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
Nikolay Savvinov
Во-первых, на практике большинство IRS читают один leaf block
большинство-не большинство, как-то субъективно. А если скажем в какой-то системе подавляющее число запросов идут с диапазонными условиями, скажем "за последний час"?

Nikolay Savvinov
то по мере роста их количества IRS достаточно быстро начинает проигрывать index fast full scan'у (за счет способности последнего к многоблоковым чтениям).
"достаточно быстро" зависит от распределения данных. и, кстати, секционирование как раз и может помочь снизить границу проигрыша IFFS. Но не нужно забывать, что частый IFFS/FTS может как раз создать проблемы конкуренции.
5 дек 14, 10:33    [16953797]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63960
Блог
griboedov
Имеет ли смысл делать секционирование по отделам, при условии, что подавляющее большинство запросов работают с данными только одного отдела?

Зависит от запросов. В целом при таких объёмах секционирование имеет шансы не понадобиться. Советую сделать функционал, и если скорость запросов окажется неудовлетворительной, подумать о секционировании.
5 дек 14, 10:38    [16953832]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
Nikolay Savvinov
Member

Откуда: Россия
Сообщений: 98
xtender
Nikolay Savvinov
Фактически -- вы ставите на одну доску какие-то тонкие и/или редкие эффекты, с одной стороны, и с другой -- эффекты очень весомые, грубые и зримые.

Николай, ну вроде очевидно же, что это очень сильно зависит от конкретного приложения и конкретной нагрузки... При высокой нагрузке конкуренция становится крайне "убедительной и зримой". Редко ли на жалуются на всякие index contention, cache buffer chains, gc XXXX, и тд и тп?
Например, недавно обсуждали RAC, так правильное секционирование и разбиение нагрузки по нодам -- одно из важнейших архитектурных решений, влияющих на scaling. Если не предусмотрели на ранних этапах возможность секционирования, то потом это потребует гораздо больших затрат при росте нагрузки и кол-ва данных.


Естественно, в зависимости от конкретной нагрузки возможны самые разные сценарии. Но поскольку деталей у нас нет, то надо фокусироваться на каких-то очевидных вещах, с которыми придется сталкиваться в любом случае. Так вот, с моей точки зрения, точечные запросы без ключа секционирования -- это практически неизбежность. А конкуренция -- она может быть, а может и не быть. Если не брать кластерные базы (я думаю, автор предупредил бы нас, если это был тот случай), то при чтении она вообще случается нечасто, благодаря архитектуре Оракл (неблокирующие чтения).

Конкуренция при записи, разумеется, более реальная угроза, но тут есть масса разных вариантов, которые требуют разных мер, в зависимости от конкретики. Вообще, если ориентироваться на производительность записи, то нужно смотреть в совсем другую сторону -- hash partitioning, причем по какому-то ключу, который обеспечивал бы более равномерное распределение по секциям, нежели идентификатор отдела.

С уважением,
Николай
5 дек 14, 12:31    [16954703]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
Nikolay Savvinov
Так вот, с моей точки зрения, точечные запросы без ключа секционирования -- это практически неизбежность.
Да, но это же не означает нижеследующего:
Nikolay Savvinov
При индексном доступе (index unique/range scans) секционирование практически не дает никаких преимуществ

Так или иначе, но нужно полноценно анализировать секционировать ли и если - да, то как.

Nikolay Savvinov
Вообще, если ориентироваться на производительность записи, то нужно смотреть в совсем другую сторону -- hash partitioning, причем по какому-то ключу, который обеспечивал бы более равномерное распределение по секциям, нежели идентификатор отдела.
ну, если куча сессий и каждая и пишет и читает по своему отделу, то лучше логичное секционирование по отделам, чем хэш-секционировании по какому-нибудь ключу, при котором данные будет попадать сразу во все секции и будут продолжать создавать конкуренцию(хоть и меньше), но уже по секциям
5 дек 14, 14:32    [16955819]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли делать секционирование(партиционирование)?  [new]
Nikolay Savvinov
Member

Откуда: Россия
Сообщений: 98
xtender
Nikolay Savvinov
Вообще, если ориентироваться на производительность записи, то нужно смотреть в совсем другую сторону -- hash partitioning, причем по какому-то ключу, который обеспечивал бы более равномерное распределение по секциям, нежели идентификатор отдела.
ну, если куча сессий и каждая и пишет и читает по своему отделу, то лучше логичное секционирование по отделам, чем хэш-секционировании по какому-нибудь ключу, при котором данные будет попадать сразу во все секции и будут продолжать создавать конкуренцию(хоть и меньше), но уже по секциям


Это какая-то идеализированная ситуация (обычно работает конекшн пул, и сервер приложения не знает, в какую сессию пойдет его запрос). Но даже в этой идеализированной ситуации такое решение будет половинчатым, потому что запись упирается в количество отделов, а их всего 10.

С уважением,
Николай
5 дек 14, 17:16    [16957194]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить