Очень и очень поверхностное описание. Многие вещи можно и нужно смотреть глубже. Только в качестве такого же поверхностного примера, тот же full table scan может и должен быть в некоторых случаях, и когда предикат присутсвует в индексе, но использование индекса неэффективно. Причём алгоритмы расчёта эффективно-неэффективно, правила расчёта cost-a (для CBO) меняются не то что от версии к версии, но и на уровне под-версий и даже патч-сетов. По этой теме крайне рекомендую почитать книгу Jonathan Lewis «CBO fundamentals»
Ну это зря. Mview — это не только табличка, которая обновляется по запросу (хотя в данной статье — пока что — не более). Но это первый шаг к реализации других фич материализованных представлений. Если они пойдут дальше реализовывать возможости оракла, то, возможно, со временем появится и code rewrite, например. А его уже так просто «триггерами» не напишешь — на нём навешено существенно больше функционала. Конечно, можно всё руками написать, и перед каждым запросом самому проверять актуальны ли данные в каких представлениях, в зависимости от настройки системы, анализировать все запросы, можно ли хотя бы часть его покрыть существующими сотнями материализованных представлений, как можно преобразовать запрос итд итп. Но так можно скатиться до того, что сказать, что индексы тоже не нужны — можно самим аналогичные структуры сформировать, если пару библиотек написать. За это ведь мы и используем СУБД — чтобы не изобретать велосипеды.
Ну, справедливости ради, надо добавить, что в «нормальных materialized view», если мы говорим про реализацию того же Оракла, оверхед от инкрементального обновления тоже весьма чуствителен: включение materialized view log нагружает OLTP систему-источник данных порядочно. Приходилось видеть как, после подклчения mview log-ов, система начинала «тормозить», просаживаясь в отдельных местах на 200% (DML-ы проходили на 2-3 раз медленнее на таблицах, где висят mview logs).
Спасибо за статью, очень интересно было почитать. В отличии от многих статей связаных с big-data, здесь всё на живых примерах и конкретике, а не о подсчётах количеств вхождения слова «error» в лог файле :) Скажите, если ли у вас информация о том, за последние пол года с момента написания статья, насколько улучшилась (у улучшилась ли вообще) как-то стабильность продукта HBase в её оригинальной поставке без ваших доработок? И / или, возможно, ваши доработки были приняты в основную версию?
Сам задал вопрос, сам расковырял. Вроде, оригинальная копия сделает нечто подобное копии для себя от оригинального snapshot-a (на изменённые данные)… Но люди жалуются, что если активно менять исходную копию появляются проблемы с производительностью. Лично, пока что, не проверял.
Да, CI среда для базы — давно моя «мечта», даже скрипты для этого подготовил, но нам постоянно не хватает по мнению менеджмента «свободного» окружения для этого и куча бюрократической волокиты с DBA- командой, которая поддерживает наши сервера и от них зависит настройка выгрузки прода. Но идея очень правильная, поддерживаю всеми руками и плюсую!
Согласен, такое возможно. В данном контексте разговор больше об отличиях в структурах данных, а точнее инфраструктуре (tablespaces, database links, directory, schema name etc etc).
В случае данный применять условную компиляцию тоже можно… но это уже совсем другая история, как говорится.
И да, хотя бы UAT крайне стоит организовывать максимально подобным к Prod-окружению. Тем более что в ряде организаций у вас на Prod не будет доступа, даже r\o (к сожалению).
В случае данный применять условную компиляцию тоже можно… но это уже совсем другая история, как говорится.
И да, хотя бы UAT крайне стоит организовывать максимально подобным к Prod-окружению. Тем более что в ряде организаций у вас на Prod не будет доступа, даже r\o (к сожалению).