Павел Новокшонов Константин Лисянский
2 Павел Новокшонов:

Павел, а сколько у вас администраторов Терадаты на 1 ТБ?

2 DBA на ХД из ~1TB. В отделе 4 DBA плюс манагер. Помимо Терадаты мы администрим ряд OLTP систем на DB2 (EE) и Информиксе. Так что есть с чем сравнивать.


У нас чистых ДБА нет по штату, ДБА & SysAdmin(Сетевики Отдельно) это нагрузка к администратору приложения.


onstat-
Противоречие получается, мы как-то уже начинали разговор
о партиционировании и я говорил что отсоединяю 20 000 000 от
100 000 000 таблицы за 10 -20 минут, помните?

Павел Новокшонов
А зачем в хранилище данных вообще отсоединять 20 000 000 записей от 100 миллионной таблицы? Какой смысл? Смысл партицирования в Терадате один - это равномерно размазать данные во узлам кластера и по виртуальным процессорам СУБД внутри узлов. Тем самым система максимально сбалансирована и позволяет максимально быстро выполнять DSS запросы.


Реальная ситуация из жизни.
Имеем базу данных в день туда втягивается приблизительно
1 000 000 транзакций (добавление данных в 5 таблиц).
Время актуальности данных ~пол года. Данные старше полугодичной
давности в расчетах не участвуют.
Как максимально быстро от них избавиться и не мешать удалением
старых записей работе системы?
Складывается впечетление что этот вопрос вас никогда не интересовал.
Или у вас абсолютно статичные данные(читай справочники), но я не могу себе
даже представить какой либо современный бизнес с абсолютно статичными
данными обьемом больше ТераБайта.

Павел Новокшонов
Здесь важно понимать архитектуру самой СУБД. В Терадате существует всего два типа виртуальных процессоров, в отличие от Информикса к примеру где их до тучи. Один тип PE (Parsing Engine) отвечает за обработку пользовательских сессий, парсинг SQL и генерацию плана запроса. Другой тип виртуальных процессоров, называемый AMP отвечает за храниние и обработку данных. При начальной конфигурации системы каждому AMP'y жестко нарезается одинаковый кусок дискового пространства. Когда я заливаю таблицу скажем из одного миллиарда строк все что делает хэш это берет значение колонки, объявленной
как первичный индекс, прогоняет через хэш-алгоритм и определяет AMP на который пойдет запись. Таким образом если значения первичного индекса достаточно уникальны, то таблица будет равномерно размазана по вирт. процам СУБД.


Кстате как быть с идесным поиском по не первичному ключу?
Каким образом производится выбор узла хазаяина по индексу
(не первичному)?

Меня не нужно убеждать в том, что добавление записей по хешу
лучше лубого другого принципа деления для распаралеливания.
У меня есть свое мнение по этому поводу, составленное на практическом опыте эксплуатации базы данных обьемом 500 Gb.
Другие базы данных предоставляют альтернативные инструменты деления
данных. Для ТераДаты я о их достоиствах практически нечего не слышал.


Павел Новокшонов

Да еще про защиту инвестиций на уровне железа. По началу Терадата у нас жила на 4-х узлах, сейчас в системе 14 узлов с тремя генерациями CPU. 2 узла с 8 CPU (700 МГц), 4 узла с 8 CPU (2.8 ГГц) и 8 узлов с 32 CPU (3 ГГц). Т.е. межнодовая шина Bynet позволяет цеплять в кластер узлы с разными CPU, но с точки зрения СУБД это по прежнему одна система. Это удобно когда ХД строится на одной системе и по мере прогресса технологий и роста объема данных старое железо может со-существовать с новым. Опять же один вендор разрабатывает
и железо и СУБД и ОС.

Как с этим в Оракле и ДБ2?


По поводу oracle не скажу, не знаю.
А вот Informix XPS абсолютно всеравно какие сервера установлены по мощности, и если я не ошибаюсь даже на каких OS&Hardware они работают. Важно чтобы версия инстансов XPS были одинаковы.

А вы как нагрузку делите между узлами разной производительности?

С уважением onstat-

Павел Новокшонов
Интересовал. Если я удалю старые записи в хранилище меня выгонят с работы. Пользователи анализируют информацию и за 6 месяцев, и за 2 года и за пять лет. Причем данные пополняются каждодневно. В этом суть хранилища данных, информация по деятельности компании накапливается на детальном уровне, после этого можно выгружать данные в многомерные кубы, агрегировать (или не агрегировать), строить зависимые дата марты, делать data mining, проводить маркетинговые кампании, делать CRM, одним словом - you name it.


Бизнес безнесу рознь. И чистых OLTP или DSS систем наверное не существует.
Для моего бизнеса хранить милиарды записей за предидущие годы гораздо дороже. Мы пользуемся уже готовыми
срезами кубов по определенным критериям за предидущие периоды.
Вероятность необходимости получения детализации по операции 5 летней давности очень низка, а стоемость ее храниния в хранилище соезмерима со стоемостью последней записи.
В какую сумму вашей организации обходится хранение детализаций
по операциям 3 -5 летней давности. А какую маркетинговую ценность
представляют детали этих операций?

Конечно переоценив ситуацию можно срузу же лишиться пары терабайт базы
и хвастаться уже будет нечем.
Зато будет ощутима материальная составляющая.

У любых данных есть период их актуальности. По его окончанию данные маркетинговой ценности не представляют. Ценность представляют лишь статистические срезы кубов.
А архивы операций можно хранить на более медленных и дешевых
устройствах например на лентах или DVD матрицах. На то они и архивы.

Павел Новокшонов
onstat- А вы как нагрузку делите между узлами разной производительности?


На более шустрых узлах живет больше АМР'ов. Не намного правда. Поскольку данные равномерно размазаны между AMP'ми, то более быстрым узлам приходится ворочать больше данных. Узел (4 х 3ГГц) - 14 AMP'ов vs. узел (4 х 700МГц) - 10 АМР'ов.

onstat- Важно чтобы версия инстансов XPS были одинаковы.

Informix XPS вроде как параллельная версия Информикса. Но только вот администрить n-инстансов информикса в кластере из n-узлов. Много вопросов - партишонинг,



Не вижу никаких проблем с фрагментацией в informix. У меня есть таблицы
фрагментированные по 20 дбсейсам есть процедура их отключения
и повторного использования. При правильной организации работы с этим может справиться дежурный персонал со средним образованием.
Это обычные регламентные работы типа как помыть пол и вытереть пыль в серверной.

Павел Новокшонов

нужно ли спэйс добавлять по dbspace'ам, бэкап/рековэри по узлам делать или как, один onconfig файл править или много, опять же dbspace'ы, tblspace'ы, надо индексы перестраивать или нет, а можно ли в онлайне, GUI у Информикса мало, а у ДБ2 родные GUI просто сосут (в 8-й версии еще куда ни шло). Сугобо ИМХО конечно.


Я храню данные в сырых устройствах.
И пространство к базе подключать нужно, я не виже в этом недостатка.
Индексы перестраивать не нужно, Gui действительно маловато, сказывается былой маркетинговый просчет informix.
Для меня гораздо важнее наличие дополнительного функционала
по управлению данными, нежели ГУЙ.
По поводу конфигов тут вы правы на каждом сервере свой,но меняются они очень редко. Мы же эксплуатируем систему и эксперементы нам ни к чему.

Коль начали меряться перцами , то давайте еще обсудим такую
немаловажную тему как таблицы исключений(violations tables)
и насколько они повышают юзабельность хранилища данных и приложения.

С уважением,
onstat-