Мастера 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 (2010-01-05 10:12:00) [1]

> а если заказчик за это платит - так, даже, нужно)

На окладе я. И заказчик - мой начальник отдела. :(
Ищем вместе решение. Хорошо, хоть еще пару месяцев это не наша проблема, а другого отдела.

> что значит "лежит"?)

Коллеги попробовали погонять стрим на тесте. Им нужно было выкачать около 30 табличек. Сутки почти выкачивалась дельта за день. Долго читает логи. Хотя надо бы самому еще глянуть - могли и написать криво.
К дба ходил - те вообще говорят, что хранить долго логи им негде, нужно для репликаций покупать еще один дисковый массив, а это довольно дорого. Впрочем, если припрет - купят.

Кщд (2010-01-01 18:41:00) [2]
>ANB (30.12.09 15:56) [42]
>Попробовали стрим. Лежит он. :(
что значит "лежит"?)
у нас было свыше ста интерфейсов интеграции одновременно работавших на базе streams по табличкам, сравнимым с таблицами банковских проводок, - проблем не было
так что - пусть dba и админы докручивают сервак, т.к. затык явно не в технологии streams...

>Что еще можно посмотреть ?
посмотреть можно BPEL, но это заведомо медленнее streams и плюс денежные затраты
из преимуществ - гибкость и простота настройки самих процессов переноса данных

можно, конечно, изобретать и собственный велосипед
а если заказчик за это платит - так, даже, нужно)

ANB (2009-12-30 15:56:00) [3]
Попробовали стрим. Лежит он. :(
Что еще можно посмотреть ?

ANB (2009-12-25 15:33:00) [4]

> который шерстит архивлоги со скоростью 10-20 строк в секунду
> сколько-нибудь существенного вклада в утилизацию CPU и I/O
> не вносит

Процессора не сильно жалко - у нас их 32, а И/О - на отдельный массив архив лог и проблема решена.
Только деньги придется трясти на новый массив.

Кщд (2009-12-25 07:46:00) [5]
>ANB (24.12.09 14:30) [39]
>По стриму, как я понял, самое полезное, что ОЛТП база вообще не >затрагивается.
именно так, а процесс, который шерстит архивлоги со скоростью 10-20 строк в секунду сколько-нибудь существенного вклада в утилизацию CPU и I/O не вносит

ANB (2009-12-24 14:30:00) [6]

> не тот объем, который повесит Oracle)

По стриму, как я понял, самое полезное, что ОЛТП база вообще не затрагивается. Все на архив.логах сделано. А тормоза DWH нас волнуют слабо. Не наша проблема.

ANB (2009-12-24 14:28:00) [7]

> Можно же без апдейта. На отдельную таблицу ссылок не будет
> - удалить должно быстро.

Таблицу можно вообще транкейтить.
С обработкой отдельной таблицы проблем особых нет, но :
1) Будет момент, когда в ней будет 30 миллионов записей (джойн с основной таблицей повиснет)
2) Можно не джойнить, а сразу складывать все поля, но ведение лога сильно затормозит массовые процессы.
Короче, будем смотреть в сторону стрима, если не придумаем ничего толкового с таймштампом.
Но, милин, начальство нас убъет :)
Там не один лям баксов надо будет вложить.

Кщд (2009-12-24 13:41:00) [8]
> ANB (24.12.09 10:52) [32]
> > "тормозов" не замечено
> На каких обьемах ?

на сравнимых, т.е. порядка 10^6 записей в день
впрочем, объемы не важны, т.к. репликация идет по мере поступления, а 10-20 записей в секунду - не тот объем, который повесит Oracle)

Sergey13 (2009-12-24 13:35:00) [9]
> [35] ANB (24.12.09 12:02)
> Висеть будет апдейт.

Можно же без апдейта. На отдельную таблицу ссылок не будет - удалить должно быстро. Да и будет она при таком подходе небольшая.

ANB (2009-12-24 12:02:00) [10]

> Потому и надо их на ночь переносить - пусть подтормаживает.
> Лишь бы за ночь отрабатывало.

Нужно каждый час запускать.
На перекачке тормозов не будет - минут 5-10. Висеть будет апдейт. Более того - он будет тормозить ОЛТП базу.

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

Sergey13 (2009-12-24 11:41:00) [11]
> [32] ANB (24.12.09 10:52)
> Тормоза начинаются.

На чем тормоза? На перекачке? Так они ИМХО по любому будут на таких объемах. Потому и надо их на ночь переносить - пусть подтормаживает. Лишь бы за ночь отрабатывало.

ANB (2009-12-24 10:54:00) [12]

> Наколбасить 30 лимонов записей да проапдейтить.

Колбасил - апдейт висит долго.

ANB (2009-12-24 10:52:00) [13]

> В отдельной таблице хранятся просто ид-шники измененных/новых
> и НЕзаархивированных записей. При перетаскивании/архивации
> из нее соответственно удалять.

Примерно так и работает фаст мат.вьюха на снапшот логах. Тормоза начинаются.

> "тормозов" не замечено

На каких обьемах ?

Sergey13 (2009-12-24 09:54:00) [14]
Кстати можно и без апдейта и без всяких доп полей.
В отдельной таблице хранятся просто ид-шники измененных/новых и НЕзаархивированных записей. При перетаскивании/архивации из нее соответственно удалять.

Кщд (2009-12-24 09:52:00) [15]
ANB (24.12.09 09:25) [28]
Streams - фича довольно-таки "старая"
в 10-ке Ваши пп.1-3 отлично работают
"тормозов" не замечено
удобство написания: три основных пакета с основными интерфейсами - capture, propagation, apply - ничего сложного
канал связи - действительно, желателен стабильный, но если связь прервется - ничего страшного, т.к. при возобновлении соединения данные польются ровно с того места(SCN), на котором связь пропала

Sergey13 (2009-12-24 09:52:00) [16]
> [28] ANB (24.12.09 09:25)
> Для инсерта - да. Для апдейта - достаточно много.

Помнится в институте слышал - критерием истины является практика. Наколбасить 30 лимонов записей да проапдейтить.

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

> чем плохи Oracle Streams, BPEL?

А чем хороши ? У них другой принцип, по сравнению с мат.вьюхами ?
У меня почему то сложилось стойкое предубеждение к новомодным фичам оракла.
Испытывались :
1. Репликация односторонняя
2. Адвансед репликация (двухсторонняя)
3. Очереди
От всех этих фичей осталось самое хреновое впечатление. Тормозят безбожно, много ограничений, писать под них много и неудобно.
И при любом раскладе требуют толстого и надежного канала связи.

> Ну во первых не так уж и много.

Для инсерта - да. Для апдейта - достаточно много.

Кщд (2009-12-24 09:24:00) [18]

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

зачем ориентироваться на timestamp, который к тому же надо будет дважды в год анализировать на таймзону, когда в Oracle есть SCN?
если банк, то база точно в архивлогах, поэтому стандартный механизм репликации не создаст существенной доп. нагрузки наOLTP-сервер.

Sergey13 (2009-12-24 08:54:00) [19]
> [22] ANB (23.12.09 17:25)
> апдейт 30 миллионов записей что пачками что разом - не быстро это.

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

Кщд (2009-12-24 05:47:00) [20]
чем плохи Oracle Streams, BPEL?

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

Наверх

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