Есть таблица A, она партиционирована, скажем партиции A1 и A2 (можно и одну партицию A1, что бы был ваш случай). Все приложения работают с A и про партиции ничего не знают, оптимизатор сам решает какие партиции брать для запроса.
Теперь готовим отдельно таблицу A3, индексируем ее, далее отключаем/удаляем скажем A1 и подключаем A3. Пользователи как работали с A, так и работают, никаких кастомных скриптов, штатные DETACH PARTITION и ATTACH PARTITION.
Зачем представление и дополнительная таблица мне не понятно.
Партиционирование и подключение/отключение партиций это стандартный паттерн для DWH, зачем изобретать велосипед с переименованием таблиц мне не понятно.
DV имеет проблемы в MPP и на очень больших хранилищах (нужно прорабатывать партиционирование/шардирование, хотя есть реализации на том же GP, Яндекс регулярно докладывает)
DV требует материализации в плоские витрины (ну так это же не все хранилище а просто слой из которого собираются витрины)
DV пихают везде, не понимая его преимуществ и недостатков.
Итого, мое мнение: DV всем не нужен. Применяя DV, Вы должны понимать, что вы теряете, и что от этого получите. Самое смешное, но DV в последнее время требуют заказчики (им не нужно просто хранилище им подавай фреймворк), и их зачастую приходится отговаривать.
НО, там где он подходит, и заказчик готов платить за разработку фреймворка и за лишние вычислительные ресурсы, DV существенно сокращает time2market.
Тут все сложнее. Все же Informatica шла в правильном направлении там и оффлоад появлялся. Но конечно ODI на голову выше продукт, 2 года назад я бы однозначно рекомендовал его.
Вы абсолютно правильно подметили, что DIY не дает Data Lineage.
Полностью с Вами согласен по поводу особенностей и недостатков Data Vault. Все грамотно описано.
Но надо четко понимать, для чего нужен Data Vault:
Полное версионирование хранилища (отсюда выделение SAT как SCD машина). Т.е. возможность увидеть данные как они были N дней назад.
Динамическое развитие/изменение хранилища, добавление новых связей, работа по agile (представьте что вам надо в звезде Кимбала добавить измерение) (отсюда выделение связи в LINK)
И Data Vault используют если Вы готовы пожертвовать местом/удобством и скоростью работы хранилища ради двух вышеуказанных преимуществ.
На нашем опыте, СТРОГО при наличии фреймворка, Data Vault дает преимущество по скорости развития хранилища (time2market) в 1.5-2 раза, с учетом наличии требования по версионированию данных.
Не делайте Data Vault если у Вас нет требования по версионированию и нет (не планируете создавать) автоматического фреймворка.
Порядок букв важен ELT - это труба и трансформация на отдельном сервере, ET-L - нет. Архитектурно это разные паттерны.
Ну собственно говоря вендоры ушли (кроме Informatica), об этом в статье прямо говорится. Так что выбора особо то и нет.
При этом я по прежнему считаю, что архитектурно подход ODI на порядок лучше, чем все что я видел в области ETL/ELT-T. Если кто из росийских разработчиков повторит идею - будет крайне интересно. Там сумасшедшая скорость разработки, DYI рядом не валялся.
Преимущество или недостаток работы с вендорам можно отнести к холиварной теме и не хочу спорить.
Это не проблема sql developer, это проблема Oracle JDBC Thin Driver. Он не умеет cancel запросов до того как он верну хотя бы одну запись. Как лечить: поставить Oracle сlient и использовать thick JDBC драйвер/OCI. После настройки — запросы прерываются в любой момент, ничего не подвисает.
Мне кажется, тут еще важным аспект, что раньше была иерархия: локальная популярность в городе, затем популярность в стране, а потом в мире.
Эта иерархия фильтровала, и на весь мир совсем мусор не вылазил.
А теперь, все доступно всем, фильтров нет, в результате в потоке льется куча откровенно вторичного и слабого.
Извините, но вы видимо не поняли:
Есть таблица A, она партиционирована, скажем партиции A1 и A2 (можно и одну партицию A1, что бы был ваш случай). Все приложения работают с A и про партиции ничего не знают, оптимизатор сам решает какие партиции брать для запроса.
Теперь готовим отдельно таблицу A3, индексируем ее, далее отключаем/удаляем скажем A1 и подключаем A3. Пользователи как работали с A, так и работают, никаких кастомных скриптов, штатные DETACH PARTITION и ATTACH PARTITION.
Зачем представление и дополнительная таблица мне не понятно.
Партиционирование и подключение/отключение партиций это стандартный паттерн для DWH, зачем изобретать велосипед с переименованием таблиц мне не понятно.
А собственно почему нельзя просто партиционировать таблицу, и удалять а затем подключать новые партиции рассчитаные заранее?
Мы же говорим про DWH, как же там без партиционирования?!
Опять же такой механизм позволяет гибко работать не только подменяя всю таблицу, но и ее часть за конкретный период например.
Для приложения ничего не меняется, все блокировки PostgreSQL сам сделает
Ну я в DIS не работаю, как я понял, с их слов, они официально лицензировали ядро включая исходники, так что Информатика в курсе.
Если убрать эмоции, то я с Вами согласен:
DV имеет проблемы в MPP и на очень больших хранилищах (нужно прорабатывать партиционирование/шардирование, хотя есть реализации на том же GP, Яндекс регулярно докладывает)
DV требует материализации в плоские витрины (ну так это же не все хранилище а просто слой из которого собираются витрины)
DV пихают везде, не понимая его преимуществ и недостатков.
Итого, мое мнение: DV всем не нужен. Применяя DV, Вы должны понимать, что вы теряете, и что от этого получите. Самое смешное, но DV в последнее время требуют заказчики (им не нужно просто хранилище им подавай фреймворк), и их зачастую приходится отговаривать.
НО, там где он подходит, и заказчик готов платить за разработку фреймворка и за лишние вычислительные ресурсы, DV существенно сокращает time2market.
Тут все сложнее. Все же Informatica шла в правильном направлении там и оффлоад появлялся. Но конечно ODI на голову выше продукт, 2 года назад я бы однозначно рекомендовал его.
Вы абсолютно правильно подметили, что DIY не дает Data Lineage.
В FormIT Plus7 от DIS Group именно лицезированное ядро Informatica, так что это именно информатика под другим названием.
Полностью с Вами согласен по поводу особенностей и недостатков Data Vault. Все грамотно описано.
Но надо четко понимать, для чего нужен Data Vault:
Полное версионирование хранилища (отсюда выделение SAT как SCD машина). Т.е. возможность увидеть данные как они были N дней назад.
Динамическое развитие/изменение хранилища, добавление новых связей, работа по agile (представьте что вам надо в звезде Кимбала добавить измерение) (отсюда выделение связи в LINK)
И Data Vault используют если Вы готовы пожертвовать местом/удобством и скоростью работы хранилища ради двух вышеуказанных преимуществ.
И да, Data Vault ТРЕБУЕТ автоматического фреймворка, делать Data Vault руками - бред и самоубийство, я про это уже писал (https://habr.com/ru/companies/jetinfosystems/articles/721950/)
На нашем опыте, СТРОГО при наличии фреймворка, Data Vault дает преимущество по скорости развития хранилища (time2market) в 1.5-2 раза, с учетом наличии требования по версионированию данных.
Не делайте Data Vault если у Вас нет требования по версионированию и нет (не планируете создавать) автоматического фреймворка.
Порядок букв важен ELT - это труба и трансформация на отдельном сервере, ET-L - нет. Архитектурно это разные паттерны.
Ну собственно говоря вендоры ушли (кроме Informatica), об этом в статье прямо говорится. Так что выбора особо то и нет.
При этом я по прежнему считаю, что архитектурно подход ODI на порядок лучше, чем все что я видел в области ETL/ELT-T. Если кто из росийских разработчиков повторит идею - будет крайне интересно. Там сумасшедшая скорость разработки, DYI рядом не валялся.
Преимущество или недостаток работы с вендорам можно отнести к холиварной теме и не хочу спорить.
Что касается DV прокомментировал ниже Ваш пост.
P.S. Я автор статьи.
Тоже лет 5 как перешел на Sql Developer.
Проблему зависания как решать описал выше.
К плюсам могу отнести:
Отдельными фишками выделю не профильные для разработчика вещи:
Это не проблема sql developer, это проблема Oracle JDBC Thin Driver. Он не умеет cancel запросов до того как он верну хотя бы одну запись. Как лечить: поставить Oracle сlient и использовать thick JDBC драйвер/OCI. После настройки — запросы прерываются в любой момент, ничего не подвисает.
Как настроить можно почитать например здесь: https://www.thatjeffsmith.com/archive/2019/04/sql-developer-19-1-connections-thick-or-thin/
Я, на вскидку, вижу только FK на партиционированную таблицу.
Эта иерархия фильтровала, и на весь мир совсем мусор не вылазил.
А теперь, все доступно всем, фильтров нет, в результате в потоке льется куча откровенно вторичного и слабого.