Как стать автором
Обновить

Комментарии 12

А не проще будет двигать партиции на накопители, состоящие из дешевых не-SSD дисков, вместо того, чтобы платить за Advanced Compression лицензию и хранить сжатые партиции на тех же дорогих накопителях?

Да, есть и такая возможность. Мы её уже частично используем. Переносим данные на сервера аналитики и согласуем с бизнесом чистку данных на Процессингах старых кампаний.

Да можно даже и не переносить в другие базы. В той же базе создать один или более tablespaces, датафайлы которых будут находится на более дешевых накопителях. И потом двигать партиции в эти tablespaces, это Оракл умеет с версии 11, а в 12 даже с опцией ONLINE (хотя для вас оно, наверное, не очень важно).

Мы так храним некоторые базы : небольшой объем read-write данных на быстрых и "родных" Exadata storage cells, а исторические данные - на более дешевых ZFS appliances. Легким движением руки данные еженедельно или ежемесячно переносятся с одного накопителя на другой : alter table ... move partition ... tablespace <ZFS>, всё автоматизировано.

Причем, иногда данные в этих партициях на ZFS приходится обновлять, ну, типа, клиент решил воспользоватся законом "right to be forgotten" и его имя / адрес / размер противогаза приходится вымарывать отовсюду, включая исторические данные. Тоже работает, пусть и не быстро - но в таких делах никто быстроты не ожидает, важна скорость работы с оперативными данными, а не с историческими.

Ну и ещё TBS в read only можно поставить ;) после накидывания новой порции архивных секций

А зачем вы платите за опцию advanced compression если в итоге все равно в регламенте сжимаете отдельным процессом?! С этим и бесплатный basic compression справиться на ура. Плата за воздух по сути.

О каких проблемах с нарезанием секций до версии 12.2 вы говорите? Автоматическое секционирование существует лет 15 в оракл и лучше оно не стало. Автоматическое плохо тем, что использует свой паттерн именования, что не очень удобно. Простая процедура по генерации нарезки секций с отложенным созданием решает все проблемы в любой версии.

Про лицензию на Advanced Compression, думаю на Exadata оно есть без доп. платы.

С Automatic List Partitioning стало возможно создавать секции partition by list на лету. До этого by range так умело.

Речь про Exadata в статье не идет и за опцию все равно придется платить даже на Exa, увы.

Ещё вопрос - зачем делать жёсткую проверку foreign key? В 12шке есть отложенная мягкая. В batch нагрузке с ней гораздо быстрее.

Это интересная мысль, но какие подводные камни с deferred есть? Долгий коммит? Если все-таки fk сработает нас ждет толстый откат?

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

В целом, если запись в таблицу управляется регламентными ЕТЛ процессами либо API, который спроектирован правильно и есть массивные batch операции, то проверка fk нужна только лишь для ручных изменений\удалений (как бы не удалить чего лишнего на что есть ссылка).

А какая у вас нагрузка rps? Какое максимальное кол-во клиентов можно оповестить за раз?

Непосредственно оповещением занимается другая система, функционал Campaign только генерирурует персональные коммуникации.

А rps это? row-per-second?

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.