Задача - скопировать данные из одной таблицы в другую. Таблица 1 - Тарадата сервер, 50 колонок, 10 миллионов строк. Таблица 2 - Оракл сервер.
Сколько времени тебе займет имплпентировать простую копию таблиц и чтоб работало оно побыстрее (быстрее всех остальных конкурентов).
.... и кто сказал, что программа, производящая перенос бежит под Windows ? Как насчет Юникса (всех Юниксов) ?
10 миллионов строк - это не слишком много. Что такое Тарадата сервер - понятия не имею. Но ежели я могу законнектиться через сеть к нему через ODBC/OLE DB - то при помощи Поверобилдера уйдет на перекачку там часа два три. В зависимости от скорорости канала. Ежели законнектиться нельзя - то ручками выгрузив в файл потом засунуть в Оракл - че такого то? Пятьдесят столбцов в лоадере описать? Ежели тебе нужны агрегированные данные - то можно походу а можно и потом.
А может вам надо сделать? Так запросто. Могу токма удаленно поскоку 35 часов в офисе надо отсиживать.
Vovchik писал(а): .... И ОЛТП база - это тоже есть отражение бизнеса. И ежели просто скопировать эту базу в другую и перемещать данные в нее из ОЛТП - вот вам и ворехауз в первом приближеннии. Второе приближение - это ускорение выборки данных и наплевав на скорость вставки с помощью всякиз примочек. Третье приближение - улучшение производительности путем агрегирования данных. Ну и четврертое - уменьшение количества таблиц чтоб юзеры могли сами данные выдергивать. ...
... в warehouse ускорение выборки и производительность особо не нужна, там запросы могут днями обрабатываться с разных OLTP, там основная задача планирование бизнеса на будущее, помощь в принятии решений и насущных бизнес проблем видя все бизнес процессы в компании в multi-dimensional view... то что ты рассказываешь это обычная OLTP дающая снепшот текущих бизнес процессов ... IMHO
Ну такие 'белые страницы' я могу налепить скока хошь. Со всякими красными словцами типа multi-dimensional view и прочей фигней.
Старина Зотин писал(а):> Сколько времени тебе займет имплпентировать простую копию
> таблиц и чтоб работало оно побыстрее (быстрее всех остальных
> конкурентов).
А что на рынке копирования таблицы с тарадаты в оракл такая большая конкуренция?
5 копеек.
Нет, конечно. Просто спецы не досказали немного, что если использовать копирование, например, програмно при помощи ADO/OLEDB/ODBC, то очень часто приходится читать рекордсет, а затем в лупе, вычитывая последовательно записи, копировать в таблицу другой базы. (select into не всеми базами поддерживается). Большой луп получается для 10 миликов. Вот и получается, что 35 часов не хватит на работе сидеть. Больше надо.
Старина Зотин писал(а):> Сколько времени тебе займет имплпентировать простую копию
> таблиц и чтоб работало оно побыстрее (быстрее всех остальных
> конкурентов).
А что на рынке копирования таблицы с тарадаты в оракл такая большая конкуренция?
5 копеек.
Нет, конечно. Просто спецы не досказали немного, что если использовать копирование, например, програмно при помощи ADO/OLEDB/ODBC, то очень часто приходится читать рекордсет, а затем в лупе, вычитывая последовательно записи, копировать в таблицу другой базы. (select into не всеми базами поддерживается). Большой луп получается для 10 миликов. Вот и получается, что 35 часов не хватит на работе сидеть. Больше надо.
Мне такой фигни делать почему то не приходится. Считая что 3 с половиной лимона записей я перебрасываю по лан где то за минут 40 - можно оценить сколько займет времени на 10 лимонов. Конечно, ежели использовать всякие технологии Майкрософта типа рекордсетов и прочее убожество - то да, проще застрелиться.
Старина Зотин писал(а):> Сколько времени тебе займет имплпентировать простую копию
> таблиц и чтоб работало оно побыстрее (быстрее всех остальных
> конкурентов).
А что на рынке копирования таблицы с тарадаты в оракл такая большая конкуренция?
Старина Зотин писал(а):> Сколько времени тебе займет имплпентировать простую копию
> таблиц и чтоб работало оно побыстрее (быстрее всех остальных
> конкурентов).
А что на рынке копирования таблицы с тарадаты в оракл такая большая конкуренция?
5 копеек.
Нет, конечно. Просто спецы не досказали немного, что если использовать копирование, например, програмно при помощи ADO/OLEDB/ODBC, то очень часто приходится читать рекордсет, а затем в лупе, вычитывая последовательно записи, копировать в таблицу другой базы. (select into не всеми базами поддерживается). Большой луп получается для 10 миликов. Вот и получается, что 35 часов не хватит на работе сидеть. Больше надо.
Мне такой фигни делать почему то не приходится. Считая что 3 с половиной лимона записей я перебрасываю по лан где то за минут 40 - можно оценить сколько займет времени на 10 лимонов. Конечно, ежели использовать всякие технологии Майкрософта типа рекордсетов и прочее убожество - то да, проще застрелиться.
у тебя был хоть один клиент, который бы не импользовал Windows и хотел-бы что-б все бежало на Юниксе ?
Старина Зотин писал(а):>
Мне такой фигни делать почему то не приходится. Считая что 3 с половиной лимона записей я перебрасываю по лан где то за минут 40 - можно оценить сколько займет времени на 10 лимонов. Конечно, ежели использовать всякие технологии Майкрософта типа рекордсетов и прочее убожество - то да, проще застрелиться.
у тебя был хоть один клиент, который бы не импользовал Windows и хотел-бы что-б все бежало на Юниксе ?
Ну тут надо стмотреть как гриться в корень. На чем крутятся сами базы это как мы понимаем абсолютно пофиг - нам нужет токма коннект. Далее мы пихаем данные через виндовую воркстейшен - дергая из источника пачками и пихая в пункт назначения. Теоретически это не есть эффективный результат но практически шуршит клево. Особенно ежели обнаружить что изготовление такого проекта гораздо дешевле чем дергать сразу из одного места в другого. Опять же главные тормоза в этом деле - это скорость канала
Vovchik писал(а):Мне такой фигни делать почему то не приходится. Считая что 3 с половиной лимона записей я перебрасываю по лан где то за минут 40 - можно оценить сколько займет времени на 10 лимонов. Конечно, ежели использовать всякие технологии Майкрософта типа рекордсетов и прочее убожество - то да, проще застрелиться.
на МСе можно быстрее пробросить чем за 40 минут.... для справки.. я персонально пробрасывал финансовые квоты всех инструментов в мире (наврняка 90-95% от всех) за примерно 4 минуты
Вовчик, могут-ли быть клиенты, принцип (назови это как хочешь) которых такой, что ни одна апликация, которая имеет дело с моими бизнесс данными не бежит под Windows ?
Как ты решишь их проблему без ETL tool ? ...особенно, если они готовы заплатить хорошие деньги.
dima писал(а):Вовчик, могут-ли быть клиенты, принцип (назови это как хочешь) которых такой, что ни одна апликация, которая имеет дело с моими бизнесс данными не бежит под Windows ?
Как ты решишь их проблему без ETL tool ? ...особенно, если они готовы заплатить хорошие деньги.
Да не тута мне как то типа на интервью впорос задали какие типа ETL там чего то процессы и методы.. Ну я рассказал там когда ручками мона когда самому аппликуху сваяю... А они все че пользовал да че пользовал - я грю я сам эти тулзы пишу когда приспичит типа делов то. Они по моему решили что такого не бывает.
dima писал(а):Вовчик, могут-ли быть клиенты, принцип (назови это как хочешь) которых такой, что ни одна апликация, которая имеет дело с моими бизнесс данными не бежит под Windows ?
Как ты решишь их проблему без ETL tool ? ...особенно, если они готовы заплатить хорошие деньги.
Да не тута мне как то типа на интервью впорос задали какие типа ETL там чего то процессы и методы.. Ну я рассказал там когда ручками мона когда самому аппликуху сваяю... А они все че пользовал да че пользовал - я грю я сам эти тулзы пишу когда приспичит типа делов то. Они по моему решили что такого не бывает.
Дело даже не очень и в ЕТЛ. Простой пример. Базу MS надо трансфер на MySQL. База МС содержит таблицы, где есть, например, 'C:\hfsj\kjsfhksj.xml', или поля дэйттайм. MySQL понимет только C-строки ("C:\\hfsj\\kjsfhksj.xml", что записанное константой выглядело бы ещё безобразней"C:\\\\hfsj\\\\kjsfhksj.xm"). Формат datetime (2001-06-06 23:00:01.59)- тоже не совместим с MC строковым представлением. Короче, кроме как ручками писать -думаю, не получится. Так что всё одно приходится писать проект. MySQL 5.0 миграйшн тул - полный отстой. Почти ничего не даёт. Не говоря о том, что кучу хранимых процедур никак как в рукопашную не перепишешь. Триггеры - так это вообще что-то в понимание МайСКЛ.
