Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Копирование данных в DWH (Oracle)

Страницы: < 1 2 3 >
ANB © (2009-12-23 09:27:00)
Стоит следущая задача (не передо мной, но нас коснется) :
Имеется таблица (проводки) в которой чуток больше миллиарда записей.
Нужно :
1) Скопировать данные в хранилище данных
2) Ежедневно поддерживать хранилище в актуальном состоянии
3) Не притормозить ОЛТП систему
Дельта :
в обычные дни в таблицу добавляется несколько сотен тысяч записей. В особые дни - несколько миллионов, в конце месяца - порядка 30-40 миллионов.

Вопрос : у кого нибудь есть опыт, как реализовать данную задачу ?
Своих идей хватает, но т.к. опыта работы с DWH нету - все варианты стремно применять из-за условия 3).

ANB (2009-12-23 18:10:00) [21]

> Можно пофлудить? Просто интересна область применения такого
> огромного количества данных? Сори за офтоп

Маленький скромный банк.

zorik (2009-12-23 17:57:00) [22]
Можно пофлудить? Просто интересна область применения такого огромного количества данных? Сори за офтоп

ANB (2009-12-23 17:25:00) [23]

> Никто и не заставляет всю кучу сразу тянуть. Тяни пачками.

апдейт 30 миллионов записей что пачками что разом - не быстро это. Плюс тянульщиков уже минимум 2 образовалось.

ANB (2009-12-23 17:23:00) [24]

> У меня сейчас под рукой нет ни одной книги по DWH в Oracle,
> я б процитировал насчет materialized views.

Игорь, материализованные представления мы первым делом опробовали. Может мы их неправильно готовили, конечно.
Делали :
1) Прицепили на одну таблицу снап шот лог (всего их надо несколько десятков реплицировать)
2) Создали мат.представление с фаст обновлением раз в сутки
Запустили массовую процедуру. Причем обновление в этот момент не работало. Массовая процедура отработала раза в 3 медленнее. Да и вся система стала притормаживать. Снесли логи - система задышала.

Sergey13 (2009-12-23 16:40:00) [25]
> [18] ANB (23.12.09 16:11)
> RBS не хватит столько проапдейтить.

Никто и не заставляет всю кучу сразу тянуть. Тяни пачками.

Игорь Шевченко (2009-12-23 16:35:00) [26]
ANB (23.12.09 16:11) [18]

Видишь ли, проблема перекачки данных из OLTP в DWH появилась не у тебя первого. Из большого OLTP в большой DWH тоже. Потому я склонен все-таки доверять Oracle, который на этих процессах не одну собаку съел.
У меня сейчас под рукой нет ни одной книги по DWH в Oracle, я б процитировал насчет materialized views.

Martin Rennhackkamp в журнале DBMS много писал как про организацию DWH, так и про его загрузку, причем было это лет 8 назад. Я к чему - я к тому, что с тех пор многое из описанного взято на вооружение производителями СУБД :)

ANB (2009-12-23 16:11:00) [27]

> Еще одно поле-признак архивирована/нет. Может тогда и дату
> время не надо писать.

RBS не хватит столько проапдейтить.

> Зато получается почти автономная система, которую можно
> легко выключить если попытка будет неудачной.

Выкачка может затянуться на пару часиков. А табличка не одна.

> Это читал наизусть ?
> http://download.oracle.com/docs/cd/B14117_01/server.101/b10736/basicmv.
> htm#i1007299
> http://download.oracle.com/docs/cd/B14117_01/server.101/b10736/advmv.
> htm#i1007694

Читал и даже делал. Игорь, не держи нас за полных лохов.
С материализованных представлений и начали. Вот только мой прошлый опыт работы с ними показал, что не такая уж это и клевая штука.
Она хорошо работает в фулл режиме, но у нас нет столько времени и ресурсов на ежедневную полную перекачку.
А фаст режим достаточно капризный и, как показал эксперимент, включение логов торомозит ОЛТП систему, что недопустимо.

Игорь Шевченко (2009-12-23 15:58:00) [28]

> Пробовали. ОЛТП система легла. Ведение снапшот логов затормозило
> массовые процедуры раза в 3.

Что вы пробовали ?

Это читал наизусть ?
http://download.oracle.com/docs/cd/B14117_01/server.101/b10736/basicmv.htm#i1007299
http://download.oracle.com/docs/cd/B14117_01/server.101/b10736/advmv.htm#i1007694

Sergey13 (2009-12-23 15:33:00) [29]
> [15] ANB (23.12.09 15:27)
> 30 миллионов записей джойнить нестед лупсом стремно потом.

Зато получается почти автономная система, которую можно легко выключить если попытка будет неудачной.

> Чего тут можно придумать ?

Еще одно поле-признак архивирована/нет. Может тогда и дату время не надо писать.

ANB (2009-12-23 15:27:00) [30]

> Возможно стОит подумать об организации отдельной IOT таблицы,
> с ID-шником основной и временной меткой. Ее можно будет
> периодически чистить от старья.

30 миллионов записей джойнить нестед лупсом стремно потом.

> materialized views ? оно само умеет "актуальность" поддерживать,
> AFAIK

Пробовали. ОЛТП система легла. Ведение снапшот логов затормозило массовые процедуры раза в 3.

Тут с тамйштампом проблемка рисуется.

Имеем :
1) последний раз выгружали 00:00:00.0000, сейчас 01:00:00.0000.
В 00:59:59.9999 легла инсертом запись. Таймштамп триггером выставился, есно 00:59:59.9999. Коммита не было. Стартует джоб, выгребает все записи
с 00:00:00.0001 по 01:00:00.0000. Запись 00:59:59.9999 он не видит (не закоммичена).
2) сейчас 02:00:00.0000. Стартует джоб. Запись 00:59:59.9999 закоммитилась в 01:00:01.0000. Но в новой итерации джоб опять ее не видит, т.к. джоб смотрит с 01:00:00.0001 по 02:00:00.0000.
Проводка потерялась.

Чего тут можно придумать ?

Игорь Шевченко (2009-12-23 14:48:00) [31]
materialized views ? оно само умеет "актуальность" поддерживать, AFAIK

sniknik (2009-12-23 13:01:00) [32]
> Только заполнять при апдейте придется триггером.
я вообще то предложил его как раз потому, что заполнять не надо... в mssql. уникальное возрастающее значение после любого редактирования записи, можно использовать в общем, и без тригера. т.к. было -
> Да вот думаем, но его заполнять неоткуда (все места в коде не поправишь) - это придется триггер вешать.

но в общем то ладно, все одно не пойдет, из-за платформы.

Sergey13 (2009-12-23 12:52:00) [33]
> [11] ANB (23.12.09 12:33)

Возможно стОит подумать об организации отдельной IOT таблицы, с ID-шником основной и временной меткой. Ее можно будет периодически чистить от старья.

ANB (2009-12-23 12:33:00) [34]

> timestamp ?

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

sniknik (2009-12-23 12:27:00) [35]
блин, не обратил внимания на оракл, сбило
> Правда на МССКЛ,

sniknik (2009-12-23 12:26:00) [36]
> Отдельное поле с датой последней модификации записи не подходит?
> Да вот думаем, но его заполнять неоткуда (все места в коде не поправишь) - это придется триггер вешать.
timestamp ?

ANB (2009-12-23 11:26:00) [37]

> А у вас физически проводка удаляется? Вроде как неправильно
> это.

Тока в особых случаях лично главбухом с объяснительной накосячившего. И логгированием. Собственно, логгирование удаления для проводок уже есть, это для других таблиц.

Sergey13 (2009-12-23 11:16:00) [38]
> [6] ANB (23.12.09 11:12)
> На удаление повесим триггер - пусть складывает логи

А у вас физически проводка удаляется? Вроде как неправильно это.

ANB (2009-12-23 11:12:00) [39]

> Sergey13 © (23.12.09 10:16) [5]

Идея катит. На удаление повесим триггер - пусть складывает логи, это редко бывает и плевать на скорость.
Остается вопрос с местом решить.

Sergey13 (2009-12-23 10:16:00) [40]
> [4] ANB (23.12.09 10:08)
> Сидим чешем репу - замедлит или нет потом массовые процедуры.

А с чего бы ему замедлять? Он же никуда не полезет - просто возьмет текущую системную дату. И уникальность (как источник тормозов) не надо поддерживать.

Страницы: < 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »