ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / db2 table partitioning и производительность
15 сообщений из 15, страница 1 из 1
db2 table partitioning и производительность
    #37714618
pomoev.u
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pomoev.u
Гость
Возник вопрос в каком случае имеет смысл разбивать таблицу на разделы (range partitions).
Предположим, у нас есть элементарная таблица t1:

id bigint,
timestamp timestamp,
somedata character(100)

id - primary key,
по полю somedata тоже построен индекс.
Ежедневно в таблица инсертится около 1 гб новых записей.
Периодически выполняются запросы вида select * from t1 where timestamp>'$ts1' and timestamp<'$ts2'.
Объем таблицы - около 300 гб.
Вопрос: имеет ли смысл разбивать таблицу на range partitions по дате, и если да - то как понять насколько мелко бить её?
Ведь есть же накладные расходы на обслуживание партиций.
...
Рейтинг: 0 / 0
20.03.2012, 22:42
| Ответить | Цитировать | Написать  
db2 table partitioning и производительность
    #37714830
mustaccio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mustaccio
Участник
pomoev.uВедь есть же накладные расходы на обслуживание партиций.

В первом (и втором) приближении можно считать, что нет. Выбор диапазона значений для секции (партиции) стоит делать, исходя из производительности запросов и времени жизни данных. Если, к примеру, по прошествии N лет вы планируете удалять данные за самый старый месяц, диапазон секции будет логично определить в один месяц.
...
Рейтинг: 0 / 0
21.03.2012, 05:13
| Ответить | Цитировать | Написать  
db2 table partitioning и производительность
    #37715029
pomoev.u
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pomoev.u
Гость
Тогда еще вопрос касательно производительности.
Допустим в большой таблице есть индекс по одному из полей. В каком случае имеет смысл разбивать таблицу на секции по значениям этого поля и создавать отдельные индексы в каждой секции?
В общем случае, если запросы произвольным образом относятся ко всему массиву данных, а не только к отдельной секции, будет ли прибавка производительности по сравнению с обычными индексами?
А как изменится производительность, если запросы будут вычитывать записи из сразу из нескольких секций?
Может быть есть какая-то статья, где подробно описаны эти механизмы?
...
Рейтинг: 0 / 0
21.03.2012, 10:08
| Ответить | Цитировать | Написать  
db2 table partitioning и производительность
    #37715047
CawaSPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CawaSPb
Участник
pomoev.u,

+1
Можно даже сказать, что накладные расходы "отрицательные" - те индексы, которые будут partitioned, будут обслуживаться (при тех же вставках) значительно быстрее, при load их вообще можно будет смело rebuild'ить (somedata в большинстве случаев тоже будет иметь смысл делать partitioned).

Некоторый минимальный overhead возможно будет при fetch отдельных строчек по ID, но а) вопрос, как часто это будет делаться; б) можно легко протестировать - надёргать случайным образом пару миллионов ID в отдельную таблицу и курсором по ней с выборкой соответствующей "родительской" записи, сначала по непарционированной, потом по парционированной таблицам, сравнить время (будет, наверное, всем интересно).

BTW Index behavior on partitioned tables
...
Рейтинг: 0 / 0
21.03.2012, 10:19
| Ответить | Цитировать | Написать  
db2 table partitioning и производительность
    #37715178
CawaSPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CawaSPb
Участник
> Допустим в большой таблице есть индекс по одному из полей. В каком случае имеет смысл разбивать таблицу на секции по
> значениям этого поля

Если производится поиск по диапазонам или конкретным значениям этого поля (или _внутри_ диапазонов значений по этому полю)

> и создавать отдельные индексы в каждой секции?

Это выгодно для всех индексов по таблице. Ограничение - глобальная уникальность поля/набора полей (тогда индекс должен быть общий или быть superset'ом от partitioning key). Возможно, в некоторых ситуациях будет даже разумным отказаться от поддержки уникальности средствами СУБД (тут разные варианты могут быть).

> В общем случае, если запросы произвольным образом относятся ко всему массиву данных, а не только к отдельной секции,
> будет ли прибавка производительности по сравнению с обычными индексами?

Будет.

> А как изменится производительность, если запросы будут вычитывать записи из сразу из нескольких секций?

Зависит от количества затрагиваемых секций.

> Может быть есть какая-то статья, где подробно описаны эти механизмы?

Дока, плюс:
developerWorks: Introducing DB2 9, Part 2: Table partitioning in DB2 9
Using DB2 Table (Range) Partitioning
Red Book: Database Partitioning, Table Partitioning, and MDC for DB2 9
Partitioning and Clustering Guide (pdf)
В доках этих смотреть также и про Multi-Dimentional Clustering
...
Рейтинг: 0 / 0
21.03.2012, 11:18
| Ответить | Цитировать | Написать  
db2 table partitioning и производительность
    #37716134
pomoev.u
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pomoev.u
Гость
CawaSPbДока, плюс:
developerWorks: Introducing DB2 9, Part 2: Table partitioning in DB2 9
Using DB2 Table (Range) Partitioning
Red Book: Database Partitioning, Table Partitioning, and MDC for DB2 9
Partitioning and Clustering Guide (pdf)
В доках этих смотреть также и про Multi-Dimentional Clustering
За ссылки спасибо, читаю partitioning guide.

CawaSPb> В общем случае, если запросы произвольным образом относятся ко всему массиву данных, а не только к отдельной секции,
> будет ли прибавка производительности по сравнению с обычными индексами?

Будет.


А вот здесь можно подробней, откуда берется прибавка производительности? Ведь по сути индекс это тоже некое дерево, которое позволяет за несколько операций сравнения перейти к нужному узкому диапазону значений искомого поля. Вроде бы разбиение индекса на куски должно вести к большему оверхеду?
...
Рейтинг: 0 / 0
21.03.2012, 16:38
| Ответить | Цитировать | Написать  
db2 table partitioning и производительность
    #37716347
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
pomoev.uВ общем случае, если запросы произвольным образом относятся ко всему массиву данных, а не только к отдельной секции, будет ли прибавка производительности по сравнению с обычными индексами?
А как изменится производительность, если запросы будут вычитывать записи из сразу из нескольких секций?Если вы про сравнение производительности индексного поиска по всей таблице, то если индекс локальный - будет некоторое падение производительности по сравнению с поиском по глобальному индексу.
...
Рейтинг: 0 / 0
21.03.2012, 17:48
| Ответить | Цитировать | Написать  
db2 table partitioning и производительность
    #37716462
mustaccio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mustaccio
Участник
Mark Barinsteinесли индекс локальный - будет некоторое падение производительности по сравнению с поиском по глобальному индексу.

По секрету скажу, что в следующей версии ДБ2 планируется возможность параллельного сканирования нескольких секций данных или индекса.
...
Рейтинг: 0 / 0
21.03.2012, 18:24
| Ответить | Цитировать | Написать  
db2 table partitioning и производительность
    #37716579
pomoev.u
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pomoev.u
Гость
Mark Barinsteinpomoev.uВ общем случае, если запросы произвольным образом относятся ко всему массиву данных, а не только к отдельной секции, будет ли прибавка производительности по сравнению с обычными индексами?
А как изменится производительность, если запросы будут вычитывать записи из сразу из нескольких секций?Если вы про сравнение производительности индексного поиска по всей таблице, то если индекс локальный - будет некоторое падение производительности по сравнению с поиском по глобальному индексу.
Я о сравнении производительности индексного поиска для partitioned table и non-partitioned table. Хочу понять каким образом может повыситься производительность при усложнении структуры данных.
...
Рейтинг: 0 / 0
21.03.2012, 19:29
| Ответить | Цитировать | Написать  
db2 table partitioning и производительность
    #37716591
pomoev.u
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pomoev.u
Гость
mustaccioMark Barinsteinесли индекс локальный - будет некоторое падение производительности по сравнению с поиском по глобальному индексу.

По секрету скажу, что в следующей версии ДБ2 планируется возможность параллельного сканирования нескольких секций данных или индекса.
роскошно :)
...
Рейтинг: 0 / 0
21.03.2012, 19:32
| Ответить | Цитировать | Написать  
db2 table partitioning и производительность
    #37727108
A.Panskikh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.Panskikh
Гость
pomoev.u,

Что такое одна таблица, которая разбита на партиции? Фактически это несколько таблиц и объединяющая их вьюха union all. Если запросы к такой структуре содержат предикат, который является диапазоном - мы получаем выигрыш. Если нет - оверхед, поскольку количество объектов (индексов/таблиц), участвующих в запросе, возрастает.

В приведенном примере мы имеем уникальный ID. Нужен уникальный индекс, который никак не поддается диапазонному разграничению, и будет, соответственно, целым. Тут мы и имеем оверхед, поскольку внутри индекса нужно будет хранить ссылку rid + партиция. Операции по присоединению/удалению партиций будут дорогостоящими из-за этого самого уникального индекса.

Данная возможность больше всего подходит под задачи хранилищ, для oltp-систем нужно правильно спроектировать...

Andy
...
Рейтинг: 0 / 0
28.03.2012, 12:18
| Ответить | Цитировать | Написать  
db2 table partitioning и производительность
    #37738727
pomoev.u
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pomoev.u
Гость
A.Panskikhpomoev.u,

Что такое одна таблица, которая разбита на партиции? Фактически это несколько таблиц и объединяющая их вьюха union all. Если запросы к такой структуре содержат предикат, который является диапазоном - мы получаем выигрыш. Если нет - оверхед, поскольку количество объектов (индексов/таблиц), участвующих в запросе, возрастает.

В приведенном примере мы имеем уникальный ID. Нужен уникальный индекс, который никак не поддается диапазонному разграничению, и будет, соответственно, целым. Тут мы и имеем оверхед, поскольку внутри индекса нужно будет хранить ссылку rid + партиция. Операции по присоединению/удалению партиций будут дорогостоящими из-за этого самого уникального индекса.

Данная возможность больше всего подходит под задачи хранилищ, для oltp-систем нужно правильно спроектировать...

Andy

Очевидно, что разбивать на партиции по уникальному полю неразумно. А если разбивать таблицу по полю timestamp? Оно не уникально, но изменение значений предсказуемо и практически упорядочено.
...
Рейтинг: 0 / 0
04.04.2012, 16:29
| Ответить | Цитировать | Написать  
db2 table partitioning и производительность
    #37739001
xz321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
xz321
Гость
В OLTP - использовать timestamp для партиционирования не очень логично. Хотя как вариант перемещать данные на более дешевые носители будет удобнее... Но с другой стороны в 10.1 появился зверь под названием multi-temperature storage который поможет решить эту задачу проще...

IMHO логичнее использовать MDC и автоматически генерируемый столбец INT( date(TS_FIELD))/100
по которому строить измерения.

Одно условие TS_FIELD не должно меняться, так как и при партиционировании и при MDC будет overhead на перемещение строк между партициями и extents (MDC)
...
Рейтинг: 0 / 0
04.04.2012, 18:06
| Ответить | Цитировать | Написать  
db2 table partitioning и производительность
    #37739408
CawaSPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CawaSPb
Участник
pomoev.u,

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

Ну, то есть может, но только с точки зрения удобства maintenance - по каким кускам данные от таблицы откусывать.

Определитесь с бизнес-задачами, связанными с таблицей, всё сразу станет ясно.
...
Рейтинг: 0 / 0
05.04.2012, 00:28
| Ответить | Цитировать | Написать  
db2 table partitioning и производительность
    #37743806
A.Panskikh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.Panskikh
Гость
pomoev.uA.Panskikhpomoev.u,
В приведенном примере мы имеем уникальный ID. Нужен уникальный индекс, который никак не поддается диапазонному разграничению, и будет, соответственно, целым.
Andy

Очевидно, что разбивать на партиции по уникальному полю неразумно. А если разбивать таблицу по полю timestamp? Оно не уникально, но изменение значений предсказуемо и практически упорядочено.

Для OLTP систем, в общем случае, имеет смысл рассмотреть вопрос партишионинга больших таблиц, только когда Primary-key содержит диапазон. Разбиение по дате подходит для задач архивирования - логи типичный пример или когда составной ключ с датой (платеж обычно это id + дата).

Другие сценарии - зависят от многих факторов. Например, вариант, когда составной ключ вида ID+Type, можно порезать на логически разнесенные группы по type. Как правило это будет попытка исправление ошибок проектирования, по моему опыту, оттягивание фола.

Andy
...
Рейтинг: 0 / 0
08.04.2012, 13:45
| Ответить | Цитировать | Написать  
15 сообщений из 15, страница 1 из 1
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / db2 table partitioning и производительность
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]