значит ли это, что отсутствует возможность горячей переброски данных в процедуре?
Понятия не имею, т.к. не имею и понятия о том, что значить "горячая переброска данных".
Вообще, для переноса данных откуда-то из вне в проектах с Терадатой используют промышленные ETL: Informatica, DataStage, ODI и т.д. Даже в проектах где Оракл является основной СУБД для ХД Database Link'и используются очень редко, обычно когда проект и хд еще маленькие и незрелые, затем их благополучно выкидывают и используют промышленные ETL.
значит ли это, что отсутствует возможность горячей переброски данных в процедуре?
Понятия не имею, т.к. не имею и понятия о том, что значить "горячая переброска данных".
Вообще, для переноса данных откуда-то из вне в проектах с Терадатой используют промышленные ETL: Informatica, DataStage, ODI и т.д. Даже в проектах где Оракл является основной СУБД для ХД Database Link'и используются очень редко, обычно когда проект и хд еще маленькие и незрелые, затем их благополучно выкидывают и используют промышленные ETL.Ну насколько я понял человек хочет обращаться к удаленному серверу в момент выполнения запроса к Teradata.
Обычно так не делают. Хранилище оно на то и хранилище, чтобы иметь полную копию всех данных, необходимых для аналитики.
Денисик_Аналитикесть ODBC драйвер для другой СУБД. как вытянуть данные на Teradata в рамках запроса?Вообразим, что это возможно. Тогда либо надо было бы рядом с проприентарной терадатовской сеткой проложить приличный GigE или не дай бог инфинибанд, чтобы каждый узел мог напрямую кинуть запрос на ту "другую" СУБД. Это долларого. Либо надо было бы назначить несколько узлов "шлюзами" (и заодно "бутылочными горлышками").
Технически реализуемо. По деньгам --- смущает.
Как следствие, толстые СУБД в подобных случаях стараются не связывать напрямую. Либо классический ETL, либо что-то интероперабельное на базе RDF, либо ставят миддлварную СУБД с виртуальной схемой, которая обращается к двум толстым СУБД за данными и собирает ответ из кусочков (ну и обновление тогда уж через ту же миддлварь с честным DTS рядышком). Либо 2--3 этих метода вперемешку.
iv_an_ruВообразим, что это возможно. Тогда либо надо было бы рядом с проприентарной терадатовской сеткой проложить приличный GigE или не дай бог инфинибанд, чтобы каждый узел мог напрямую кинуть запрос на ту "другую" СУБД. Это долларого. Либо надо было бы назначить несколько узлов "шлюзами" (и заодно "бутылочными горлышками").
Технически реализуемо. По деньгам --- смущает.
Считаю, что бред: т.к. если с клиентского компа коннектитесь к базе и делаете select - вы что же инфинибандом к нодам Терадаты привязаны? Или "горлышков" в TD от этого полно?
Коннектятся 100 клиентов - весь инстанс Терадаты фатально деградирует из-за "бутылочных горлышек"? Или все клиентские компы по 10Гигабитным сеткам к инстансу подключены?
pectopatopСчитаю, что бредЗря считаете. Представьте себе, что вы заменили терадатовский внутрикластерный протокол на ODBC. Терадата после этого шевелиться будет, как вы думаете?
Как раз в надежде хоть чем-то скомпенсировать полную непригодность ODBC для обмена промежуточными данными SQL-интерпретатора, вам вместо одной связи разумной толщины придётся сделать неразумно толстую распределённую связь.
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
