Comments 96
Во-первых, можно включить материализацию только, если у вас уже был создан обычный VIEW.Нет, не так. Материализованные представления с обычными вообще никак не связаны. Для создания мат.представления никакого «обычного VIEW» не требуется. И нельзя создать «обычное VIEW» а потом как-то его материализовать. View и Materialized View это просто совсем разные объекты. Оптимизатор умеет материализовывать части запросов, по ходу дела, да, но это немного другая история.
Иначе придется переписывать остальные запросы на обращение к вновь созданному представлению
Тоже отсебятина. Oracle уже давно умеет переписывать запросы «на лету». Правда механизм это довольно капризный и работает только при наличии прямых рук.
Замечание про «тысячу индусов» оставим на вашей совести, она у вас видимо большая.
Я имел ввиду немного другое. Давайте на примере. Предположим, у вас не хранится количество сотрудников в отделе. И при этом есть сто запросов (отчеты всякие и прочие), которые для подсчета количества сотрудников делают это подзапросом. Если бы изначально вы создали VIEW, а затем во всех этих ста запросах обращались бы к нему, то достаточно было бы изменить VIEW на MATERIALIZED VIEW, и они начали бы обращаться уже к преподсчитанным данным. Если же эти сто запросов в явную высчитывали количество через подзапросы, то вам бы создание MATERIALIZED VIEW не помогло бы.
Но я допускаю, что возможно я не в курсе последних версий Oracle.
А можете дать, пожалуйста, ссылку на этот механизм — я хочу почитать про него.
Но я допускаю, что возможно я не в курсе последних версий Oracle.
Oracle уже давно умеет переписывать запросы «на лету»
А можете дать, пожалуйста, ссылку на этот механизм — я хочу почитать про него.
Вот здесь например. Но более понятно написано у Тома Кайта в «Oracle для профессионалов» (самая первая книжка и легко гуглится). В общем, если кратко, Materialized View появились в Oracle в три шага.
1. Просто snapshot-ы с ручным обновлением, к которым можно обращаться как к таблицам
2. Обновление по commit-у, в том числе запросов с группировками и агрегациями (здесь куча ограничений, да)
3. Оптмизатор научился догадываться сам, где можно переписать запрос так, чтобы он обращался к мат.представлению (здесь ещё ограничения и кучерявая настройка)
В общем, из-за 3 пункта не надо переписывать «кучу запросов». В 9-ой версии это уже всё было (если не в 8i), так что довольно древние фичи.
1. Просто snapshot-ы с ручным обновлением, к которым можно обращаться как к таблицам
2. Обновление по commit-у, в том числе запросов с группировками и агрегациями (здесь куча ограничений, да)
3. Оптмизатор научился догадываться сам, где можно переписать запрос так, чтобы он обращался к мат.представлению (здесь ещё ограничения и кучерявая настройка)
В общем, из-за 3 пункта не надо переписывать «кучу запросов». В 9-ой версии это уже всё было (если не в 8i), так что довольно древние фичи.
Спасибо за ссылку. Я только не понял: он с FAST REFRESH работает? Почему в их первом же примере не включен FAST REFRESH? Ведь нельзя же переписывать запросы, если данные в этом VIEW «несвежие»: будет другой результат. Более того, если в одной транзакции идет запись, то после изменения данных, которые затрагивают VIEW нужно их учитывать во последующих запросах в транзакции.
Вот с этим и связаны все причуды тонкой настройки. В общем, там есть уровни «доверия» к данным и если оптимизатор посчитает данные не свежими, то не станет их использовать. С FAST REFRESH переписывание запросов ортогонально, то есть оптимизатор может работать с любыми мат.представлениями. Гляньте Кайта, если будет возможность, книжка полезная и понятная.
Я почитаю конечно Кайта, но на это, к сожалению, уйдет время, и я не смогу вам сейчас отвечать по этой книжке.
И тогда начнет все рассчитывать заново? А если там материализация из сотни миллионов записей?
Простите, но ваше описание того, как работает Oracle сводится к тому, что там есть какой-то механизм, но использовать его крайне опасно, так как подводных мин — огромное число. Для многих людей это равносильно тому, что лучше вообще не использовать (и все мои знакомые Oracle разработчики по этой причиние никогда его не используют).
не станет их использовать
И тогда начнет все рассчитывать заново? А если там материализация из сотни миллионов записей?
Простите, но ваше описание того, как работает Oracle сводится к тому, что там есть какой-то механизм, но использовать его крайне опасно, так как подводных мин — огромное число. Для многих людей это равносильно тому, что лучше вообще не использовать (и все мои знакомые Oracle разработчики по этой причиние никогда его не используют).
Точно также как я не готов обсуждать концепции вашего продукта, вы не готовы обсуждать концепции Oracle (и не надо этого делать). Спорный абзац в статье рекомендую переписать или убрать вообще. Оптимизатор не будет ничего «рассчитывать заново» — это не его задача. Он просто определяет может использовать заранее рассчитанные данные или нет, в соответствии с заданными настройками. И я не давал вам описания того «как работает Oracle». Я рассказывал только о его мат.представлениях да и то, весьма поверхностно. Хотите подробностей — читайте документацию или Кайта.
вы не готовы обсуждать концепции Oracle (и не надо этого делать)
Лично я очень даже готов. Но почему-то очень много людей работающих с СУБД, на конкретные вопросы начинают отсылать к книжкам, со словами там все есть. А это книжки на 200 страниц. И делать так на мой взгляд в обсуждении некорректно. Потому как я же не напишу вам, прочитал 200 страниц ничего не нашел, вы все врете.
Ну и смущает чаще другое. Очень часто возникает ощущение, что люди сами не знают как, то что они обсуждают, работает и работает ли вообще. При этом эти же люди ратуют за то что SQL запросы должны быть прозрачны и предсказуемы (причем не их выполнение а сами запросы), хотя как именно они выполняются никто не знает.
Лично я очень даже готов
Нет, не готовы, поскольку не знаете концепций Oracle, про которые пишите. В результате, вы пишите ерунду, которую кто-то, также не знакомый с этими концепциями, может принять на веру. Кстати, глава про мат.представления много меньше 200 страниц. Найдите время, почитайте.
Прочитал всю 13 главу. Как я и думал. Хотите в OLTP использовать нужен REFRESH ON COMMIT. В остальных случаях данные тупо будут неправильные.
Собственно он сам пишет, что в OLTP использовать материализованные представления нельзя, но обоснует это почему-то большим количеством возникающих update conflict'ов. То есть понятно что если материализовать прибыль предприятия, вся база будет в update conflict'ах. Но если, к примеру, остаток на складе материализовать то все же будет ок. Более того так все и делают, только руками.
Про переписывание там вообще оригинально написано, как будто Oracle реально текст запроса сравнивает (то есть алиас изменил все уже не используется), но по факту простые случаи он действительно вроде разбирает (хотя учитывая ограничения на REFRESH ON COMMIT там все случаи простые).
В любом случае, ничего нового, в контексте того что мы тут обсуждают я не узнал.
Собственно он сам пишет, что в OLTP использовать материализованные представления нельзя, но обоснует это почему-то большим количеством возникающих update conflict'ов. То есть понятно что если материализовать прибыль предприятия, вся база будет в update conflict'ах. Но если, к примеру, остаток на складе материализовать то все же будет ок. Более того так все и делают, только руками.
Про переписывание там вообще оригинально написано, как будто Oracle реально текст запроса сравнивает (то есть алиас изменил все уже не используется), но по факту простые случаи он действительно вроде разбирает (хотя учитывая ограничения на REFRESH ON COMMIT там все случаи простые).
В любом случае, ничего нового, в контексте того что мы тут обсуждают я не узнал.
Спорный абзац в статье рекомендую переписать или убрать вообще
Я переписал его с учетом ваших замечаний:
но многие запросы их не всегда используют, а высчитывают заново
Так будет точнее?
Oracle уже давно умеет переписывать запросы «на лету»
Вы имеете ввиду находить существующие MATERIALIZED VIEW в базе и прямо внутри какого-то другого запроса «выделять» часть join'ов / union'ов из этого MATERIALIZED VIEW и заменять эту часть на join 'ы/ union'ы с MATERIALIZED VIEW? И я так понимаю MATERIALIZED VIEW должен естественно быть FAST REFRESH? И как это все в транзакции главное работает, когда часть данных уже поменялось, а MATERIALIZED VIEW еще не обновился?
На лету ничего находить не надо. Все связи между объектами Oracle постоянно хранятся в метаданных. На счёт join-ов и тем более union-ов вряд ли. Мат. представления больше про OLAP и группировки. Если обновление по commit-у, то с транзакциями всё замечательно работает, поскольку для других транзакций это выглядит как одновременное изменение агрегатов и исходных таблиц. Другой вопрос, что на обновление по commit-у имеется куча ограничений и не везде оно возможно. Мат. представления, как и большинство механизмов в Oracle создавались для решения конкретных задач, а не для сферической идеи «материализовать всё что можно».
сферической идеи «материализовать всё что можно»
Прошу прощения за замечание, но идея — не сферическая, а имеет вполне конкретное практическое применение. Позволяет «на лету» балансировать запись и чтение.
Мат. представления больше про OLAP и группировки.
Тут скорее правильнее говорить про OLAP. Группировок и в OLTP вагон и маленькая тележка, то есть это общее понятие и в OLAP и в OLTP.
Мат. представления, как и большинство механизмов в Oracle создавались для решения конкретных задач, а не для сферической идеи «материализовать всё что можно».
Если я правильно понимаю, мат. представления в Oracle создавались именно для аналитики (OLAP). FAST REFRESH прилепили потом именно для OLTP, но что-то пошло не так, и по факту они только SELECT SUM() GROUP BY умеют делать. А остальное -OUTER JOIN, UNION'ы, analytic function, recursive cte они так и не научились делать.
Собственно, если я правильно понял, в статье речь шла про OLTP, соответственно «переписывать», если и можно то, только FAST REFRESH view, а это получается ограничения в квадрате. То есть ограничения FAST REFRESH умножить на всякие странные ограничения вроде
ENFORCED
This is the default mode. The optimizer only uses fresh data from the materialized views and only use those relationships that are based on ENABLED VALIDATED primary, unique, or foreign key constraints.
Но в любом случае статья то как раз не про «переписывание запросов» (про это всего одна фраза), а про прозрачную материализацию.
Если я правильно понимаю, мат. представления в Oracle создавались именно для аналитики (OLAP). FAST REFRESH прилепили потом именно для OLTP, но что-то пошло не так, и по факту они только SELECT SUM() GROUP BY умеют делать. А остальное -OUTER JOIN, UNION'ы, analytic function, recursive cte они так и не научились делать.
Послушайте, не надо ничего домысливать. Вы прекрасно начали абзац, но затем у вас опять «что-то пошло не так». Все ограничения мат.представлений были прекрасно известны на момент разработки их архитектуры, а вовсе не проявились в процессе их разработки, как вы пытаетесь это показать. Вы занимаетесь агрессивным маркетингом своего продукта — прекрасно, но зачем поливать грязью другие продукты? При всех (хорошо известных) ограничениях мат.представлений, на текущий момент, это лучшее решение, на фоне предоставляемых другими СУБД. И ещё раз. Я не вашу статью обсуждаю, а всего один, вполне конкретный абзац.
Во-первых, я не хочу обидеть вас или Oracle (поверьте он не нуждается ни вашей, ни чьей либо еще защите). Мне самому не очень понравилась эта фраза про тысячу индусов, скорее всего причина все-таки другая — а именно legacy. Но не суть.
То есть по вашему все эти ограничения они вставили специально?
А где вы увидели поливание грязью. Oracle — отличный продукт, для реализации ACID, определения порядков, типов join, паралеллизма и т.п. И скорее всего лучший из существующих на рынке. Но реализовать по настоящему крутые возможности у них по разным причинам не получилось. Но это не повод, что у других это не получится, и тем более не повод не указывать на отсутствие этих возможностей у других, даже если это Oracle.
Все ограничения мат.представлений были прекрасно известны на момент разработки их архитектуры, а вовсе не проявились в процессе их разработки, как вы пытаетесь это показать
То есть по вашему все эти ограничения они вставили специально?
прекрасно, но зачем поливать грязью другие продукты?
А где вы увидели поливание грязью. Oracle — отличный продукт, для реализации ACID, определения порядков, типов join, паралеллизма и т.п. И скорее всего лучший из существующих на рынке. Но реализовать по настоящему крутые возможности у них по разным причинам не получилось. Но это не повод, что у других это не получится, и тем более не повод не указывать на отсутствие этих возможностей у других, даже если это Oracle.
поверьте он не нуждается ни вашей, ни чьей либо еще защите
А я не Oracle защищаю (тоже мне, была нужда). Я защищаю людей, которые могут прочитать в вашей статье ерунду про Oracle.
То есть по вашему все эти ограничения они вставили специально?
Да, без них предложенный механизм не смог бы работать. То есть они (индусы) может быть и рады бы обойтись без ограничений, но это был бы совсем другой механизм, до которого пока никто (включая корейцев и китайцев) не додумался.
А где вы увидели поливание грязью
Я процитировал абзац в самом первом своём комментарии. Ну и про индусов тоже. Насколько я вижу, они до сих пор на месте. Да и это то же:
Но реализовать по настоящему крутые возможности у них по разным причинам не получилось.
Вы здесь свой продукт собрались продвигать или обсуждать недостатки Oracle? Продвигаете — продвигайте, продукты других компаний не трогайте.
Я защищаю людей, которые могут прочитать в вашей статье ерунду про Oracle.
Честно не могу найти эту главу Том Кайта про материализованные представления (уже полчаса ищу эту книжку), может поделитесь в личку где ее можно достать?
Потому как во всяком случае, вот здесь, materialized view описывается именно как view, который просто хранится как таблица:
docs.oracle.com/cd/E11882_01/server.112/e40540.pdf
Да реализация у него естественно отличается от обычного VIEW, добавляются всякие materialized view logs в master таблицы, для обеспечения инкрементального обновления (что естественно для не FAST REFRESH view), но логически тоже самое.
Да, без них предложенный механизм не смог бы работать. То есть они (индусы) может быть и рады бы обойтись без ограничений, но это был бы совсем другой механизм, до которого пока никто (включая корейцев и китайцев) не додумался.
Это был бы точно такой же механизм но без ограничений.
Я процитировал абзац в самом первом своём комментарии. Ну и про индусов тоже. Насколько я вижу, они до сих пор на месте.
А если туда добавить, что механизм переписывания запросов есть в некоторых СУБД (кстати в MSSQL я помню он вроде тоже есть), но к ограничениям FAST REFRESH добавляется еще список ограничений, что делает этот механизм нежизнеспособным, по вашему будет корректно?
Продвигаете — продвигайте, продукты других компаний не трогайте.
Это как вы себе представляете? То есть если Tesla продвигает электромобили, им нельзя говорить что бензиновые загрязняют окружающую среду?
Да реализация у него естественно отличается от обычного VIEW
View — это просто SQL-запрос, сохранённый в словаре с каким-то именем. Materialized View — по сути таблица, с сегментом данных в тэйблспейсе и некоторыми дополнительными возможностями. И то и другое можно использовать в SQL-запросах, как и табличные функции, например, но все три — это совсем разные объекты.
что делает этот механизм нежизнеспособным
Если вы к этому добавите «по нашему мнению», будет вполне здоровая субъективная критика. А вот абзац с индусами так просто не лечится.
То есть если Tesla продвигает электромобили, им нельзя говорить что бензиновые загрязняют окружающую среду?
Ой, не кивайте на других. То что делает Тесла — на совести Теслы, то что делаете вы — на вашей совести.
View — это просто SQL-запрос, сохранённый в словаре с каким-то именем. Materialized View — по сути таблица, с сегментом данных в тэйблспейсе и некоторыми дополнительными возможностями. И то и другое можно использовать в SQL-запросах, как и табличные функции, например, но все три — это совсем разные объекты.
Так я вроде так и написал. Логически (с точки зрения использования) Materialized View это тоже самое, что View. Физически (с точки зрения реализации) да отличается, но в этом и фокус абстрагирования, что субьекту все равно что там внутри.
Если вы к этому добавите «по нашему мнению», будет вполне здоровая субъективная критика. А вот абзац с индусами так просто не лечится.
Ну там уже поменяли на «не всегда». Хотя версия, которую я предлагал (с вашей поправкой) мне кажется лучше, но пусть будет не всегда.
Ой, не кивайте на других. То что делает Тесла — на совести Теслы, то что делаете вы — на вашей совести.
А как вообще можно продвигать на рынок что-то не сравнивая с конкурентами. Если первый же вопрос — зачем нам еще один новый продукт.
Понимаете в чём дело, вы сравниваете ERP и RDBMS. Ну это как шурупы с гвоздями. И делаете это, несколько экспрессивно.
Это да. Если бы не одно но, что у ERP и RDBMS (во всяком случае больших и сложных) очень сильно пересекаются области применения (по моему во всяком случае опыту). Собственно RDBMS (имеется ввиду написание на хранимках, PL/SQL и т.п., а не просто как подложка под ORM) сейчас по факту чаще всего и применяются там где ERP по производительности не вытягивает (банки и ритейл).
Не на сайтиках же Oracle используют.
Не на сайтиках же Oracle используют.
Собственно RDBMS (имеется ввиду написание на хранимках, PL/SQL и т.п., а не просто как подложка под ORM) сейчас по факту чаще всего и применяются там где ERP по производительности не вытягивает
Гм. Вот есть функция ERP "загрузка данных о заказах из удаленной системы". Ну, в смысле, есть API endpoint, куда удаленная система стучится, чтобы залить свою информацию о заказах в ERP, где с ней уже работают пользователи. Предположим, "ERP по производительности не вытягивает", то есть этот endpoint не отрабатывает за нужное время. И как вы тут предлагаете "использовать RDBMS"?
Мне вообще кажется, что говорить "у ERP и RDBMS [...] очень сильно пересекаются области применения" — это что-то очень странное, потому что у ERP — это система, которой пользуются пользователи, через UI, она (обычно) выражена в терминах их пользовательских задач, а RDBMS — это нечто, чем пользователи (обычно) не пользуются напрямую, потому что она не выражена в терминах их задач.
Я сейчас не ERP-системы, а ERP-платформы (SAP, Axapta, 1C) имел ввиду.
Они работают поверх RDBMS (как правило). Из чего следует, что они «пересекаются» с RDBMS?
Давайте так, чтобы не уходить в абстрактные рассуждения, приведу пример. OEBS продукт знаете. А SAP ERP. Вы же понимаете, что технически они полные конкуренты. И один считай на Oracle RDBMS + Oracle Forms (или что у них там сейчас для UI), второй на SAP Platform.
Давайте так. Я сейчас выскажу известную, но не очень афишируемую мысль. У Oracle конечно есть ERP (и скорее всего не один), но он меня мало интересует. Единственное, что есть хорошего у Oracle это базы данных. ERP от Oracle, Oracle Forms, APEX и прочее — всё это для мазохистов.
Давайте так. В условиях когда даже при использовании ERP платформ приходится отказываться от ORM, автоматических блокировок и других абстракций этих ERP платформ в пользу SQL ради масштабируемости, а SQL используется только для ACID и порядка / типов JOIN (без materialized view, predicate pushdown, trigger'ов и т.п. так как все они поддерживаются в каких-то частных случаях или с непонятной производительностью) любая ERP, что 1С ERP, что SAP ERP — это лютый ад (там от полотен императивного кода по генерации SQL запросов кровь из глаз идет). А когда все вокруг мазохисты — no one is. Так что сравнение вполне корректное.
Вот опять я не улавливаю вашей логической цепочки. Допустим, я согласен с тем что все ERP — ад. Как из этого следует, что сравнивать возможности RDBMS с ERP корректно? И при чём тут вообще ORM? Вы ведь про Materialized View говорили? Так вот, возможно для вас это сюрприз, но… они не в Oracle Forms.
Смотрите, я сказал, что OEBS (сделан только с использованием RDBMS + UI в виде Oracle Forms) и SAP ERP (сделан с использованием ERP платформы + RDBMS внизу) прямые конкуренты. Вы сказали что OEBS — для мазохистов и нельзя так сравнивать, я ответил что это не аргумент. Итого возвращаемся к изначальному тезису. OEBS vs SAP ERP. В OEBS — бизнес-логика сделана в RDBMS, в SAP ERP — в ERP платформе (которая впрочем тоже юзает RDBMS но уже в меньшей степени). Соответственно они обе используются для решения одной задачи (программирования бизнес-логики), то есть конкуренты, то есть сравнение корректно.
Вы сказали что OEBS — для мазохистов и нельзя так сравнивать
Неа. Я сказал (и продолжаю говорить) что возможности ERP и RDBMS нельзя сравнивать. Вообще говоря, это никак не связано с OEBS (он мне вообще никак не интересен). Так что нет, не возвращаемся. Статья посвящена мат. представлениям. Покажите мне их в OEBS или SAP ERP, тогда «вернёмся».
Понимаете в чём дело, вы сравниваете ERP и RDBMS. Ну это как шурупы с гвоздями. И делаете это, несколько экспрессивно.
Вообще это вы первые сказали про сравнение ERP и RDBMS (я если честно в тот момент не понял причем тут ERP, но раз вы спросили). А слово ERP первый раз до этого встречалось только в статье в качестве примера проектов реализованных с использованием подходов прозрачной материализации функций / view. Хотя кроме ERP на ней и CRM и BPM и ECM проекты реализовывались и проблема прозрачной материализации была везде (балансирование записи и чтения это вообще универсальная проблема).
То есть вы сделали ещё одну RDBMS, Да?
Я бы сказал мы сделали надстройку над RDBMS. Такую Turbo-RDBMS на стероидах: с представлениями с возможностью материализаций, constraint'ов и trigger'ов без ограничений, динамической физической моделью, более понятной функциональной логикой (вместо реляционной), с очень умным оптимизатором, ну и с логикой представлений, метапрограммированием, явной типизацией, модульностью и кучей чего еще в комплекте.
Вы сделали конструктор для разработки ERP и CRM, так? Что-то вроде OEBS или 1С? Ну так и сравнивайте свой продукт с OEBS-ом. Зачем вы пытаетесь сравнивать его с Oracle Database? Turbo RDBMS вместе со стероидами — это ваш маркетинг. Это почти также смешно как термин «постреляционная» (тоже есть такая линейка маркетинга). Перестаньте сравнивать несравнимое.
OEBS это вообще прикладной продукт, не понятно он тут причем. И область применения продукта в статье — разработка любых информационных систем. То есть такая же как и у RDBMS.
Фактически продукт в статье решает те же задачи, что и связка Oracle Database + Oracle Forms. Как впрочем и SAP/Axapta/1C. Он обобщает и то и другое, поэтому его можно сравнивать и с тем и другим.
Хотя если так не подходит, его можно использовать / рассматривать чисто как DBMS и соответственно сравнивать чисто с RDBMS (которую впрочем lsFusion использует как более низкоуровневую виртуальную машину). Ну то есть это как грубо говоря C и Assembler.
Фактически продукт в статье решает те же задачи, что и связка Oracle Database + Oracle Forms. Как впрочем и SAP/Axapta/1C. Он обобщает и то и другое, поэтому его можно сравнивать и с тем и другим.
Хотя если так не подходит, его можно использовать / рассматривать чисто как DBMS и соответственно сравнивать чисто с RDBMS (которую впрочем lsFusion использует как более низкоуровневую виртуальную машину). Ну то есть это как грубо говоря C и Assembler.
Только вот роль Oracle в вашей связке выполняет PostgreSQL? Я ничего не путаю? Так что нет. Ваш продукт не DBMS. он решает совсем другие задачи. Кстати, кто вам сказал, что задача RDBMS «разработка любых информационных систем»? Вас обманули. Задача DBMS — надёжное и эффективное хранение данных.
Задача DBMS — надёжное и эффективное хранение данных.
А зачем тогда туда добавили хранимые процедуры, триггерах, view и вообще эти две буквы PL? То есть почему язык PL/SQL, а не SQL?
То есть то что на Oracle целые АБС и тот же OEBS, или Oracle Retail реализованы это не считается?
Затем, что долгое время считалось, что данные надо обрабатывать как можно ближе к месту их хранения.
А зачем тогда туда добавили хранимые процедуры, триггерах, view и вообще эти две буквы PL? То есть почему язык PL/SQL, а не SQL?
Вы не поверите, затем чтобы решить задачу эффективного хранения данных. Впрочем, товарищ lair, чуть выше, об этом уже сказал. Представьте, что у вас есть 100500 записей, которые надо нетривиально обработать. Что дешевле: выкачать их туда где есть годный ЯП и обработать там или обработать прям в базе и отдать клиенту небольшой результат? Кстати, в такой модной технологии как Hadoop, идея обработки данных по месту их размещения всё ещё в тренде.
Подождите вы сказали что:
Мое утверждение было, что кроме хранения есть еще обработка и изменение данных. И там где Оракл в основном используется (по моему опыту, это ритейл, банки и другие финансы), его используют именно в варианте с PL/SQL (то есть на нем вся бизнес-логика). Что логично, так как в противном случае, это все равно что стейк из мраморной говядины с кетчупом есть. И с этой точки зрения область применения lsFusion практически полностью совпадает с областью применения Oracle.
Задача DBMS — надёжное и эффективное хранение данных.
Мое утверждение было, что кроме хранения есть еще обработка и изменение данных. И там где Оракл в основном используется (по моему опыту, это ритейл, банки и другие финансы), его используют именно в варианте с PL/SQL (то есть на нем вся бизнес-логика). Что логично, так как в противном случае, это все равно что стейк из мраморной говядины с кетчупом есть. И с этой точки зрения область применения lsFusion практически полностью совпадает с областью применения Oracle.
Данные которые нельзя обрабатывать никому не нужны. Так что «эффективность хранения» подразумевает и их обработку. Но вы опять начинаете за здравие а кончаете как-то не так. Как из этого посыла следует что «область применения lsFusion практически полностью совпадает с областью применения Oracle»?
Вы PostgreSQL используете! Вот его область применения, да, практически совпадает с областью применения Oracle Database.
Вы PostgreSQL используете! Вот его область применения, да, практически совпадает с областью применения Oracle Database.
Вы PostgreSQL используете! Вот его область применения, да, практически совпадает с областью применения Oracle Database.
Мы с вами о разных вещах говорим. Вы видели системы где вся бизнес-логика на PL/SQL реализована (то есть не на PL/SQL только UI на Delphi / Oracle Forms)? Я видел. Более того все системы, которые я видел где в качестве БД Oracle именно так и реализованы (а я видел их достаточно много). Потому как Oracle стоит дохера денег, и если нужна просто подложка для ORM в основном использовали MySQL, Firebird, Postgres или на крайний случай MSSQL.
Я видел даже системы только на PL/SQL (напоминаю, это язык и Oracle Forms тоже). Как с этим связаны попытки сравнения вашего продукта с СУБД? Вы ставите знак равенства между PL/SQL и Oracle Database? Так это неправильно (как я уже говорил, PL/SQL есть не только в базе данных). Про ORM тут вообще ни к месту. Совершенно ортогональная к нашему диалогу вещь.
Еще раз, на пальцах. То что вы продаёте это PostgreSQL (СУБД) + Ваш продукт (не СУБД). Да, работают они вместе. Но из чего следует ваше желание сравнивать ваш продукт (не СУБД) с Oracle Database (СУБД)? Сравнивайте с Oracle Forms и все будут довольны!
Еще раз, на пальцах. То что вы продаёте это PostgreSQL (СУБД) + Ваш продукт (не СУБД). Да, работают они вместе. Но из чего следует ваше желание сравнивать ваш продукт (не СУБД) с Oracle Database (СУБД)? Сравнивайте с Oracle Forms и все будут довольны!
Еще раз, на пальцах. То что вы продаёте это PostgreSQL (СУБД) + Ваш продукт (не СУБД). Да, работают они вместе. Но из чего следует ваше желание сравнивать ваш продукт (не СУБД) с Oracle Database (СУБД)? Сравнивайте с Oracle Forms и все будут довольны!
А материализация представлений, ограничения и триггеры на представления, predicate pushdown (и всякие другие оптимизации такого плана), материализация подзапросов, наследование таблиц/объектов это все тоже Oracle Forms? То есть я не спорю часть функционала пересекается и с Oracle Forms, но значительная часть пересекается и с RDBMS.
Нет конечно. Об этом я вам и говорю. Всё сравнение проведённое в статье полностью некорректно. Тот механизм, который вы придумали (возможно хороший, тут не буду спорить) к мат.представлениям Oracle не имеет никакого отношения (более того, выяснилось, что вы и не очень то хорошо знаете, что такое мат.представления Oracle).
То что вы придумали со всем оптимизациями и прочим, это как раз таки такой интеллектуальный ORM. Который работает вместе с СУБД, а не вместо неё.
То что вы придумали со всем оптимизациями и прочим, это как раз таки такой интеллектуальный ORM. Который работает вместе с СУБД, а не вместо неё.
Нет конечно. Об этом я вам и говорю. Всё сравнение проведённое в статье полностью некорректно. Тот механизм, который вы придумали (возможно хороший, тут не буду спорить) к мат.представлениям Oracle не имеет никакого отношения (более того, выяснилось, что вы и не очень то хорошо знаете, что такое мат.представления Oracle).
Ну я прочитал уже все что можно про материализованные представления, и именно такой же механизм. Только реализованный с тучей ограничений.
Вот к примеру статья где это как раз обсуждается.
www.dba-oracle.com/t_sql_patterns_materialized_view.htm
То что вы придумали со всем оптимизациями и прочим, это как раз таки такой интеллектуальный ORM. Который работает вместе с СУБД, а не вместо неё.
Нет никакого ORM, по большому счету данные вообще не покидают сервер БД, грубо говоря только при отображении пользователю и только видимый блок. То есть еще меньше чем в связке Oracle + Oracle Forms.
И тут правильно говорить что и вместе и вместо. То есть predicate pushdown, проталкивание LIMIT внутрь подзапросов, преобразование GROUP LAST в подзапрос и т.п. SELECT LIMIT 1 и кучу других оптимизаций, которые по идее должны были делать сами СУБД это вместо. ACID, типы JOIN'ов и параллелизм к примеру да — это вместе (так как lsFusion этим не занимается).
Ну как же нет? Если он крякает как утка… Вы преобразуете SQL-запросы перед передачей их в СУБД, что-то кэшируете, возможно управляете распределёнными транзакциями (если нет — то я разочарован). Что это как не ORM? Впрочем, у вас ведь не OO сверху? Ну ладно, будем называть это XRM.
Что касается материализованных представлений — это механизм реализованный внутри СУБД. Вы же сделали клиентский кэш (ну или кэш на уровне сервере приложений, не важно). Это принципиально разные механизмы и их нельзя напрямую сравнивать. За сим, пережёвывать дальше эту тему не вижу большого смысла.
Что касается материализованных представлений — это механизм реализованный внутри СУБД. Вы же сделали клиентский кэш (ну или кэш на уровне сервере приложений, не важно). Это принципиально разные механизмы и их нельзя напрямую сравнивать. За сим, пережёвывать дальше эту тему не вижу большого смысла.
Что это как не ORM?
Я может отстал от жизни, но ORM это когда данные пересылаются на сервер приложений и создают там прикладные объекты соответствующие этим данные и там же они обрабатываются.
Что касается материализованных представлений — это механизм реализованный внутри СУБД. Вы же сделали клиентский кэш (ну или кэш на уровне сервере приложений, не важно).
Еще раз все делается на уровне СУБД. Никаких клиентских кэшей и кэшей на уровне сервере приложений нет. Данные не покидают СУБД пока вы не начнете показывать данные пользователю (то есть используете логику представлений).
Но вообще забавно, вы нас упрекаете, что мы что-то утверждаем не разбираясь в Oracle (хотя я прочитал все что вы мне говорили), а сами делаете утверждения не разобравшись с lsFusion. Понятно, что вас никто не обязывает с ней разбираться, но тогда зачем вы что-то вообще так безаппеляционно утверждаете.
И там где Оракл в основном используется (по моему опыту, это ритейл, банки и другие финансы), его используют именно в варианте с PL/SQL (то есть на нем вся бизнес-логика).
Гм. Даже если допустить, что это верно для Oracle (во что я тоже не верю), для других RDBMS, например, MS SQL и MySQL, это совершенно точно не верно.
То есть то что на Oracle целые АБС и тот же OEBS, или Oracle Retail реализованы это не считается?
А вы не путайте клиентский PL/SQL и серверный. Язык один — задачи разные. Если не очень понятно, рассмотрите, в качестве аналогии, JavaScript, с его Node.js
А вы не путайте клиентский PL/SQL и серверный
А можно подробнее про «клиентский» PL/SQL. А то я долго гуглил ничего не нашел про это? И Node.js это библиотека, а PL это единый язык с SQL встроенный в то же синтаксическое дерево практически бесшовно. Нут аналогом скорее C# и linq to sql, и то его там не так бесшовно встраивали.
Ну, во первых. Node.js — это сервер, на котором крутится JavaScript (но это к делу не относится). Что касается клиентского PL/SQL, то он есть в Oracle Forms. То есть, язык тот же что и в хранимках, но используется на клиентском компьютере для обработки событий экранных форм. Так что, если желаете гуглить, гуглите Oracle Forms и просвещайтесь. По поводу бесшовности PL и SQL, даже комментировать не буду (отсутствие этой бесшовности уже с десяток лет у всех ораклоидов в печёнках сидит).
По поводу бесшовности PL и SQL, даже комментировать не буду (отсутствие этой бесшовности уже с десяток лет у всех ораклоидов в печёнках сидит).
Это да, вот прямо сейчас нарвался, на то, что EXECUTE в SQL это выполнение prepared statement, а в pgplsql выполнение строки. И долго втыкал в syntax error в при выполнении команды в psql :)
Их области применения все равно пересекаются мало, потому что их задачи разные. Или вы хотите сказать, что "когда люди пишут ERP, и у них не справляется ERP-платформа, они начинают работать напрямую с RDBMS"?
Или вы хотите сказать, что «когда люди пишут ERP, и у них не справляется ERP-платформа, они начинают работать напрямую с RDBMS»?
Ирония, но практически так и есть. Если вы откроете код Управления торговлей в 1С, вы увидите что в большинстве ключевых документов, все делается через формирование больших строк запросов и записи их результатов во времянки. То есть там ORM с большего похерили и перешли по сути на ручное написание запросов.
Важно понимать разницу между "миновали ORM" и "отказались от платформы". Ну и да, надо понимать, к чему приводит отказ от ORM в конкретной задаче.
Ну они по сути отказались там и от идеологии справочник-документ-регистр, то есть проведения / распроведения (там они по факту вручную диффграмму строят, иначе опять таки легло бы все по производительности). То есть по факту в типовых они 1С-платформу грубо говоря как POJO(Java) или Delphi используют. Хорошо хоть до хранимок не дошли :)
Смешались в кучу люди, кони. А CRM и RDBMS тоже пересекаются? Может будем сравнивать ERP с CRM или CAD?
На практике это выглядит следующим образом.[...] все это идет в тестирование или эксплуатацию. [...] Когда обнаруживается долгий запрос, то [...] принимается решение о включении MATERIALIZED на некоторой промежуточной функции. Тем самым немного замедляется запись [...] значительно ускоряется не только этот запрос, но и все другие, которые используют эту функцию
Я так понимаю, основной профит возникает из разницы между "немного замедляется запись" и "значительно ускоряется [...] запрос". Возникает разумный вопрос: что в концепции "функциональной базы данных" гарантирует, что первое сильно меньше второго?
И, раз уж зашла речь о функциональном поведении, чем это лучше, чем мемоизация?
В самой концепции ничего не гарантирует. Но в большинстве случаев так и есть, так как изменяется, как правило, значительно меньшее количество записей, чем было в базе.
И, раз уж зашла речь о функциональном поведении, чем это лучше, чем мемоизация?
Строго говоря, мемоизация подразумевает выполнение перед сохранением. А материализация, о которой речь идет в статье, подразумевает инкрементальное обновление. Но это уже особенности реализации (хотя и важные). Логически, можно считать, что материализация не отличается от мемоизации.
А материализация, о которой речь идет в статье, подразумевает инкрементальное обновление.
Что в статье нигде не написано. Ну и интересно, что будет, если инкрементальное обновление невозможно.
Логически, можно считать, что материализация не отличается от мемоизации.
За исключением как минимум того, что мемоизация — ну, по крайней мере, как я ее понимаю — делается по запросу, а ваша материализация — всегда.
Что в статье нигде не написано. Ну и интересно, что будет, если инкрементальное обновление невозможно.
Возможность инкрементального обновления — вещь относительная. Инкрементальное обновление может быть более эффективное, может быть менее эффективное, но возможно всегда.
Так к примеру GROUP SUM, GROUP LAST, MAX, MIN с индексами, (+), RECURSION, взаимоисключающие выбор (EXCLUSIVE, ABSTRACT) — обновляются очень эффективно, композиция, +, IF, CASE — просто эффективно, PARTITION (разбиение) ORDER, GROUP LAST MAX MIN без индексов — наименее эффективно, но все равно за пределы разбиения / группировки не выходят (то есть на самом деле даже вручную вы их сильно эффективнее не обновите)
За исключением как минимум того, что мемоизация — ну, по крайней мере, как я ее понимаю — делается по запросу, а ваша материализация — всегда.
К мемоизации главный вопрос как результат выполнения запроса обновляется при изменении данных, которые на него влияют. Но в любом случае это вопрос реализации. Вы когда выполняете функцию вам то какая разница почему она быстро считается, главное что быстро и правильно.
Возможность инкрементального обновления — вещь относительная.
В первую очередь она "относительна" того, как вы определяете "инкрементальное обновление". Чего вы пока не сделали, поэтому вполне может оказаться, что и это мы с вами понимаем по-разному.
К мемоизации главный вопрос как результат выполнения запроса обновляется при изменении данных, которые на него влияют
А это невозможная ситуация, потому что одно из условий мемоизации — неизменность данных. И это опять возвращает нас к тому, что понимать под "функциональным".
Вы когда выполняете функцию вам то какая разница почему она быстро считается, главное что быстро и правильно.
Отнюдь. Мне важно, почему она быстро считается, потому что это "почему" определяет те границы, в которых она быстро считается.
Инкрементальное обновление… возможно всегда
Хмм. GROUP AVG тоже инкрементально обновите? Только не SUM/CNT — это уже доработка напильником. Но ладно, бог с ним со средним. Как на счёт инкрементального обновления медианы? Только на серьёзных объёмах. Миллион записей например.
AVG (а точнее медиана) попадает в группу LAST, MAX, MIN без индексов, то есть наименее эффективно. Обновляется плохо, но с другой стороны требует чтение данных только в пределах изменившихся групп (и если есть какая-то сильно селективная группировка например инвойс, проблемы не возникает). Ни шага влево, ни шага вправо.
Еще раз инкрементальность это количественный показатель. Он бывает лучше и хуже. Просто в том же Oracle там два режима — или SELECT SUM GROUP BY, или полный перерасчет.
Еще раз инкрементальность это количественный показатель. Он бывает лучше и хуже. Просто в том же Oracle там два режима — или SELECT SUM GROUP BY, или полный перерасчет.
Ой, ну мы же это проходили. Какие два режима? О чём вы? Зачем писать о том, в чём не разбираешься? То что агрегат можно рассчитать всегда, это и так понятно (и не обязательно приплетать сюда Oracle). Когда говорят об инкрементальном обновлении, обычно имеют в виду, что обновление происходит без полного перечитывания исходных данных. Поэтому оно и называется инкрементальным. Остальное (лучше или хуже) — это уже демагогия. Это как осетрина, понимаете?
Подождите, ну так AVG происходит тоже без без полного перечитывания исходных данных. Если к примеру вы считаете AVG по инвойсу, или по товару, складу, вам достаточно перечитать только данные по инвойсу, или по товару складу. Фокус конечно определить инвойсы, по которым произошло изменение и только для них пересчитать. И это реальный живой кейс (ну точнее AVG обычно на SUM, CNT разбивают, правильнее говорить о медиане).
Строго говоря при любом инкрементальном обновлении нужно что-то перечитать.
Честно прочитал всю Главу про материализованные представления и документацию. И там чтобы получить корректные данные всего 2 варианта: или REFRESH ON COMMIT с тучей ограничений, или никак.
Строго говоря при любом инкрементальном обновлении нужно что-то перечитать.
Какие два режима? О чём вы? Зачем писать о том, в чём не разбираешься?
Честно прочитал всю Главу про материализованные представления и документацию. И там чтобы получить корректные данные всего 2 варианта: или REFRESH ON COMMIT с тучей ограничений, или никак.
Строго говоря при любом инкрементальном обновлении нужно что-то перечитать.
Нет. Если у вас есть поле суммы и приходит новое значение, вы добавляете новое значение к сумме. Старые данные по этому полю (все) перечитывать не нужно. Именно это и называется инкрементальным обновлением. Речь не о сахаре и рюшечках которыми обвешан интерфейс к этому. Речь о том, как вы обновляете агрегированные данные.
Только не SUM/CNT — это уже доработка напильником
Это почему напильником? Так гораздо эффективнее инкрементность, и со средним мы обычно так и делаем. Материализуем сумму и количество.
Все так делают. Но это означает, что «из коробки», то есть сам инструмент инкрементально обновлять среднее не умеет. Как и медиану.
Если вы сделаете
median = GROUP SUM MEDIAN(quantity(InvoiceDetail id)) BY invoice(id) MATERIALIZED;
Он отлично будет обновляться при любых изменениях в том числе, если InvoiceDetail перепривязать к другому инвойсу. И высчитывать будет данные только для инвойса, то есть в среднем для 100 записей, чего чаще всего вполне достаточно (хотя под ответственность DBA). В Oracle вы этого не сделаете никак. Придется руками разработчику за всем этим следить.
median = GROUP SUM MEDIAN(quantity(InvoiceDetail id)) BY invoice(id) MATERIALIZED;
Он отлично будет обновляться при любых изменениях в том числе, если InvoiceDetail перепривязать к другому инвойсу. И высчитывать будет данные только для инвойса, то есть в среднем для 100 записей, чего чаще всего вполне достаточно (хотя под ответственность DBA). В Oracle вы этого не сделаете никак. Придется руками разработчику за всем этим следить.
Я же спросил, миллион записей она так сколько по времени (и памяти) будет «инкрементить»? И так на каждом добавлении? Спасибо, я лучше как все, руками.
Да хоть миллиард. Проверено опытом. Если в одном инвойсе 100 записей, больше 100 записей оно не прочитает никогда.
PS: если invoice = DATA Invoice (InvoiceDetail) INDEXED естественно.
Один раз на транзакцию. И только если изменилось quantity или invoice (привязка к инвойсу). И руками вы скорее всего будете делать точно также, если у вас максимум 100 записей (ну если только вы не за миску риса работаете и можете потратить неограниченное время на premature optimization)
PS: если invoice = DATA Invoice (InvoiceDetail) INDEXED естественно.
И так на каждом добавлении?
Один раз на транзакцию. И только если изменилось quantity или invoice (привязка к инвойсу). И руками вы скорее всего будете делать точно также, если у вас максимум 100 записей (ну если только вы не за миску риса работаете и можете потратить неограниченное время на premature optimization)
Знаете, я вот тут немножко как раз DBA. И Oracle разработчик. И как раз сейчас занимаюсь задачей в которой в сутки падает примерно 6 миллионов записей. Я прекрасно знаю сколько времени занимает сканирование миллиона записей с (пусть даже SSD) диска. И сколько всё это займёт памяти если загрузить в оперативку. Не надо мне тут про «хоть миллиард».
Ну я тоже каждый день наблюдаю, как в ритейле во многих оперативных базах более сотни крупных супермаркетов в день в онлайне скидывают все чеки с детализацией. Причем в этом же онлайне идет (актуальность пару минут), к примеру, расписывание по партиям, и вообще обработка / обновление пары тысяч различных событий / ограничений и материализацией.
И как вы понимаете записей там уже далеко за миллиард.
И прекрасно знаю что сканирование миллиона записей не должно быть никогда, и для того чтобы этого не было есть индексы, материализации, динамическая физическая модель и очень умный оптимизиатор.
И кстати крутится все на Postgres и на 2 серверах типа такого:
ark.intel.com/content/www/ru/ru/ark/products/120484/intel-xeon-gold-5115-processor-13-75m-cache-2-40-ghz.html
Это я еще мощный нашел.
И как вы понимаете записей там уже далеко за миллиард.
И прекрасно знаю что сканирование миллиона записей не должно быть никогда, и для того чтобы этого не было есть индексы, материализации, динамическая физическая модель и очень умный оптимизиатор.
И кстати крутится все на Postgres и на 2 серверах типа такого:
ark.intel.com/content/www/ru/ru/ark/products/120484/intel-xeon-gold-5115-processor-13-75m-cache-2-40-ghz.html
Это я еще мощный нашел.
Можно при желании сделать синтаксический сахар, который будет «невидимо» для пользователя создавать два таких поля. Просто вы привели случаи, которые на практике используются достаточно редко. В отличии от многих других, которые не поддерживаются ни Oracle, ни MSSQL.
Только на серьёзных объёмах. Миллион записей например.
В мало-мальски серьёзных системах миллион записей — это не то что «не серьёзно», про это даже говорить неприлично! :)
Не совсем ясно как эта база данных решает известную проблему денормализации — происходит трек зависимостей и полное перевычисление или анализируются выражения для инкрементальных изменений? Решена ли проблема ромбовидных зависимостей (когда вычисление какой-то вьюхи может запуститься дважды)? Что насчет возможности получения реалтайм-оповещений об изменениях материализованной вьюхи? Что насчет возможности инкрементальной синхронизации (когда при восстановлении оборванного соединения через которого клиент получал оповещения от материализованной вьюхи будет происходить загрузка не всех данных вьюхи а только тех которые изменились за время оффлайна) ?
Не совсем ясно как эта база данных решает известную проблему денормализации — происходит трек зависимостей и полное перевычисление или анализируются выражения для инкрементальных изменений?
Материализация это и есть денормализация. Обновление инкрементальное, то есть грубо говоря если идет x = GROUP SUM(g(a)) BY f(a), то при изменении f(a) с b на d, x(b) уменьшается на f(a), а x(d) увеличивается на f(a) и делается это естественно не императивно (со всякими N+1) а одним скомпилированным и оптимизированным запросом.
Решена ли проблема ромбовидных зависимостей (когда вычисление какой-то вьюхи может запуститься дважды)?
Механизму инкрементальности — фиолетово, можете одну функцию хоть сто раз использовать.
Что насчет возможности получения реалтайм-оповещений об изменениях материализованной вьюхи?
Я бы сказал, там сделано даже больше, там сама «материализованная вьюха» не нужна, можно делать так:
WHEN CHANGED(x(a)) DO
EMAIL…
хотя конечно если x(a) materialized это работает куда эффективнее, так как может обновляться инкрементально, как в ответе выше.
Что насчет возможности инкрементальной синхронизации (когда при восстановлении оборванного соединения через которого клиент получал оповещения от материализованной вьюхи будет происходить загрузка не всех данных вьюхи а только тех которые изменились за время оффлайна) ?
Этот механизм работает в рамках одного сервера. Для распределенных серверов нужно по хорошему теми же событиями делать
WHEN CHANGED(x(a)) DO
EXTERNAL LSF x(a) посылаем изменения на удаленный сервер
А на удаленном записываем в первичное свойство x(a), и дальше весь стек событий / ограничений / материализаций отрабатывает уже на этом удаленном сервере автоматически.
del
Типичная OLTP база данных работает с соотношениями запись: чтение от 1:1000 до 1:1000000 и более. Не очень понятно что понимается под декларируемой «балансировкой чтения и записи»?
К сожалению, это не всегда так. Возьмем, например, обычную учетную систему типа 1С, в которой документы, которые изменяют остатки пишутся допустим 100 раз в день. При этом читаются остатки во много раз чаще (отчеты, заказы и прочее).
UPD: прошу прощения, неправильно комментарий прочитал.
Собственно в этом и смысл, чтобы ускорить значительно 1000 и 1000000 чтений, замедлив эту одну запись.
UPD: прошу прощения, неправильно комментарий прочитал.
Собственно в этом и смысл, чтобы ускорить значительно 1000 и 1000000 чтений, замедлив эту одну запись.
Уменьшить затраты на чтение (путём переноса нагрузки на этап записи) можно только в ограниченном наборе ситуаций, большинство которых связано с расчётами тех или иных агрегатов. Но для этого не нужны никакие специальны БД — всё это прекрасно делается на обычных SQL базах (хотя и путём ощутимого усложнения логики как на самой БД, так и во внешних по отношению к ней приложениях)
Уменьшить затраты на чтение (путём переноса нагрузки на этап записи) можно только в ограниченном наборе ситуаций, большинство которых связано с расчётами тех или иных агрегатов
А можно поподробнее? Почему в ограниченных? В описанной концепции можно в любых случаях.
Но для этого не нужны никакие специальны БД — всё это прекрасно делается на обычных SQL базах (хотя и путём ощутимого усложнения логики как на самой БД, так и во внешних по отношению к ней приложениях)
Так в этом и основной смысл и преимущество технологии. Что это можно сделать вообще не изменяя логику программы.
Sign up to leave a comment.
Балансировка записи и чтения в базе данных