Хорошо известна шутливая истина, что любая действующая программа устарела. Действительно, имея дело с программным продуктом, всегда надо быть готовым к тому, что в каком-то обозримом будущем он станет историей, о которой будут помнить только страницы Википедии. По-видимому, вплотную к этому подошла довольно популярная в былые времена технология java-апплетов.
Действительно, основное, о чем предупреждалось в документе "Oracle Java SE Support Roadmap" уже свершилось: с релизом Java 8 завершилась поддержка технологии Java Plugin в составе среды Java Runtime Environment, и c апреля 2019 года корпорация Oracle прекратила активную поддержку технологии во всех новых релизах виртуальной машины. Существенным следствием завершения поддержки Java Plugin является завершение активной поддержки тесно взаимосвязанной с Java Plugin технологии апплетов. Все выпускаемые обновления JDK 8 будут иметь в своем составе компоненты Java Plugin и апплетов, для которых корпорацией будет обеспечиваться «остаточный» уровень поддержки Sustained Support (Note 2511148.1: "Java SE 8 End of Java Plugin Support").
Решение о прекращении поддержки было принято в связи с отменой производителями браузеров программного интерфейса подключаемых модулей (NPAPI) в своих продуктах, с помощью которого как раз и происходила интеграция апплетов в браузеры. На текущий момент только Microsoft Internet Explorer 11 продолжает поддержку этого интерфейса.
Несмотря на то, что сопровождение JVM 8 в рамках расширенной поддержки обещано корпорацией до конца 2030 года и Oracle пока сохраняет в JVM 8 остаточную поддержку Java Plugin и апплетов, и пока они включаются в составы обновлений JVM 8, в упомянутых ранее документах недвусмысленно объявлено, а также было подтверждено ответом на запрос к технической поддержке Oracle, что Java Plugin и апплеты могут исчезнуть из JVM 8 в любой момент с выходом очередного обновления виртуальной машины. Подобное развитие событий может быть очень вероятным в случае прекращения поддержки NPAPI Microsoft-ом. В таком случае, программные компоненты Java Plugin и апплетов будут присутствовать в составе виртуальной машины JVM 8 только до какого-то обновления.
drWhy
С глаз долой — из сердца вон. Иногда складывается впечатление, что для Oracle поддержка Java становится всё менее интересной и вскоре и у этого чемодана может оторваться ручка.
amathus Автор
Ручка не оторвётся, по крайней мере в средней перспективе, т.к. Java это один из ключевых компонентов инфраструктуры Oracle Middleware. Oracle это контора, если говорить грубо, там нет понятия интереса, есть понятие совокупного коммерческого результата. Сейчас, скажем, посчитали, что можно брать два бакса за jvm у пользователя, по 25 баксов за jvm на процессор на сервере — и, думаю, бизнес заплатит, расчет оправдается.
С апплетами всё прекращается из-за отсутствия поддержки со стороны браузеров. На апплетах, скажем, сидели те же Oracle Forms (клиентская часть), и заблаговременно перешли на работу из-под Java Web Start.
imanushin
Это звучит довольно красиво, однако на деле нуждается в обосновании.
Для Java есть достаточно вендоров, которые предлагают более дешевую поддержку. Так что после недавнего финта этой компании, куча больших клиентов просто ушла к условному Azul.
С технической точки зрения, на Java сильно давит Python, .Net, Rust (каждый в своей области). Для новых сервисов выбор Java зачастую обосновывается тем, что программисты не знают других языков. И постепенно тенденция переламывается. Например, Ansible написан на Python, хотя если бы первый релиз был бы раньше, то разработчики, скорее всего, пошли бы путем Jenkins/TeamCity. Аналогично про IDE — раньше было разумно писать её на Java, сейчас в моде — Электрон (IntelliJ Idea/Eclipse vs MSVS Code).
С базами данных у Oracle тоже начинаются серьезные трудности, так как:
Как следствие в Oracle, я думаю, знают прекрасно об этом положении. И менеджеры просто мечутся, пытаясь хоть как-то вернуть прибыльность в стратегическом смысле.
amathus Автор
Oracle DB и MySQL-ю проигрывает по удобству. И?
Если бы у бабушки… NoSQL не поддерживают SQL — и о чем идет речь? Что сравниваем?
Даже затрудняюсь прокомментировать.
Ну прямо фильм «Мертвец» Джармуша. Ещё ничего не произошло, первые кадры, а уже понятно, что герой мертв. :))))))))))))
Не нагнетайте лишнего.
imanushin
Извините, забыл добавить. Сравниваем скорость загрузки/сохранения данных, цену хранения одного мегабайта. ClickHouse поддерживает SQL, кстати. В NoSql базах, обычно, нет транзакционности и контроля целостности, из-за этого можно одновременно обновлять две таблицы без блокировок, что положительно влияет на скорость.
Про поддержку SQL — то, что JVM не поддерживает C#, не означает, что они не конкуренты. В kdb вообще есть functional select, когда вы создаете запрос в хранилище как бы "заполняя dto". Например, запрос
select from t where b<4можно выразить какwhereCon: enlist (<;`b;4);?[ `t; whereCon; 0b; ()]. Это аналог dynamic sql из Oracle, только фаза разбора запроса пропускается.Sql не всегда необходим для работы. Зачастую более дешевая система + увеличенные трудозатраты стоят меньше, чем дорогая система и уменьшение числа сотрудников.
Я говорю, что Oracle просто не сможет необоснованно повышать цену на поддержку Java, так как есть конкуренты, которые уже дешевле. Более того, необходимость в той же Java сейчас ниже, чем лет 10 назад (см. мой пример с Ansible). А потому довод с "$25 с сервера" является неправильным, так как крупные компании купят поддержку дешевле. Цены можно посмотреть здесь. Для Azul, в случае Premium Unlimited, годовая цена за поддержку Java 6-14 будет $341500 в год. Для компании со 100.000 серверов (среднего размера инвестиционный банк) это $3 в год. Так что $25 с сервера требовать просто не получится.
Извините, я плохо выразился. У Oracle нет просто функций, из-за которых эту базу данных (не BI, не Oracle Forms, а именно базу) было бы разумно использовать сейчас для нового проекта. Вы можете привести контрпример (только сразу договоримся — в комментариях, не надо, пожалуйста, кидать ссылку на громадный маркетинговый материал).
Я приведу примеры для PostgreSql:
amathus Автор
В Oracle есть транзакционность, есть изоляция транзакций и точно так же можно обновлять две таблицы без блокировок. Можно обновлять одну таблицу без блокировок одновременно N-сеансами.
И скорость доступа к данным тоже будет очень высокой: есть кэш буферов, есть in-memory опция.
В NoSQL за счёт ликвидации механизмов разграничения доступа (изоляции транзакции), за счет примитивизации механизмов доступа к информации — упрощена архитектура систем и, естественно, примитивные операции выполняются быстрее. Но в том-то и дело, что Oracle делает далеко не примитивные операции доступа к массиву данных и поэтому сравнивать это, как минимум, некорректно.
Для NoSQL может поддерживаться SQL интерфейс, да, но почитайте про ограничения (best practices), которые накладываются. Скорее всего: доступ через только через первичный ключ, транзакции фиксировать как можно быстрее итд итп. Чудес не бывает, за примитивизм и распределённость хранения придётся расплачиваться.
Нет, это никакой не аналог. У Oracle работает оптимизатор, который строит план исполнения запроса, даже для sql-запросов, которые визуально занимают несколько экранов текста. Это одно и то же, что сравнивать механизм Streams API в java с БД Oracle и говорить, что, дескать, да весь ваш Oracle через лямбда-выражения сейчас перепишу.
До поры до времени.
«Компьютеры ненадежны, но люди еще ненадежнее».
И? Какой глупый Oracle?
До этого Oracle вообще отдавал JVM бесплатно в пользование. А сейчас берет деньги.
Вот как раз сейчас вводится у клиента новый продукт с базой Oracle на 60 терабайт.
Сравнивать Oracle и PostgreSql некорректно, это разные весовые категории. Рассуждения о том, что PostgreSql своей гениальной мыслью затмевает Oracle, 25 лет не затмевал, а тут вдруг на ниве импортозамещения рассмотрели самородок, — часто звучат, но это не более чем следствие незнания внутренней изнанки устройства продуктов.
Oracle поддерживает json и хранимые json-данные можно индексировать.
Вообще непонятно в чем сложности.
Развернуть в базе Oracle PDB, при необходимости отклонировать без прерывания работы пользователей в другой PDB.
Скорость запросов удваиваться не будет.
Всё то же самое можно сделать и в Oracle. Почитайте про ограничения: DDL не поддерживается, truncate не реплицируется, «Replication is only possible from base tables to base tables». Это всё очень примитивный уровень. И очень хорошо кореллирует с моими утверждениями о элементарной несопоставимости Oracle и PG.
Таких ограничений нет ни при репликации в Oracle Golden Gate, ни через стендбай с опцией Active Data Guard.
imanushin
NoSql — это не замена для Oracle. Просто для ряда задач имеет смысл выбирать между ними. Я могу привести примеры, если хотите. 20 лет назад такого не было, сейчас у Oracle появилось довольно много конкурентов.
Не приму данный пассаж, как и Вашу фразу ":))))))))))))" выше или изречение "Это всё очень примитивный уровень.". Вы отклоняетесь от рассуждения, вместо приведения фактов пытаетесь свести все к мнимому авторитету от анонимного (на текущий момент) аккаунта в интернете. Хотя, если Вы приведете доказательства того, что проектировали хотя бы одну архитектуру более-менее популярной базы данных (я про программу типа Oracle, а не про базу на Oracle), то я возьму свои слова обратно и признаю авторитет. Сейчас же я очень Вас попрошу — писать строго факты со ссылками.
Да, Вы правы. Я некорректно выразился. Я имел ввиду, что нагрузку на крупную базу можно размазать по нескольким серверам. И если аналитики чаще всего работают с куском базы, размеров в 1 Тб (чаще всего, однако им надо все, этот кусок — это просто часть таблиц, не более), то выделение отдельного сервера просто позволит запихнуть этот "кусок" в оперативную память. Более того, это само произойдет средствами ОС.
Технически скорость увеличить можно. На практике, в моих задачах, практически всегда базы работают достаточно быстро, чтобы на первое место вставали задачи скорее горизонтального масштабирования и проектирования. И вот здесь, как я описал Выше (и уточню в текущем ответе ниже) Oracle серьезно проигрывает.
Нет. Так — нельзя. Кроме базовых таблиц, остальное реплицировать нет смысла. Процедуры можно перенакатить (буквально — запустить программу не на одном сервере, а на нескольких) в момент релиза. Индексы глупо копировать — их можно восстановить баз базовых таблиц.
В моем комментарии важное слово было "можно не беспокоиться по поводу числа серверов". Если посчитать бюджет на оракловый распределенный кластер, то он будет стоит дико дорого, и так делать просто не будут. В случае Postgre бюджет будет намного симпатичнее. Еще раз, важно: цена.
Объясняю. Сделать дамп базы несложно. Мы же на хабре, а потому знаем, что есть даже несколько способов снять дамп (или же скопировать базу).
С Oracle невозможно поднять такое локальное и быстрое окружение для разработчика/билд агента, чтобы не оставлять следов на компьютере. Условно, в случае Posgtre/MariaDb разработчик может развернуть все из докера, а потом просто удалить образ — и всё. Никаких установок, никаких следов. Аналогично для агента — после скачивания образа базы из хранилища (не будем же мы грузить сервер баз по напрасну?), все тесты проходят локально. Вы можете даже гонять тесты локально на разных версиях базы данных, буквально немного подправив билд конфигурацию. Образы открыты и лежат в docker storage в интернете.
С Oracle такой простоты просто не будет. Вам надо ставить ПО на комп, у Вас будут проблемы, если несколько версий Oracle установлено одновременно и так далее. Если вы выделите сервер, то это не локальный прогон, необходимо будет следить за окружением.
Я специально привел ссылку на stackoverflow. Я говорю не про json, а про binary json, который быстрее. А по ссылке говорится, что в Oracle просто нет такой фичи — вы должны использовать медленный строковый формат (в отличии от MariaDb, Mongo, Posgtre и пр). Вот та ссылка — https://stackoverflow.com/questions/53636840/query-jsonb-through-dblink-oracle-postgres
amathus Автор
Прошу извинить, у меня нет столько свободного времени, чтобы заниматься пустыми дискуссиями.
OBIEESupport
Добрый день imanushin!
У меня здесь аккаунт верифицирован.
Слова amathus и его выводы в статье полностью подтверждаю.
И еще, у нас в стране (я про Россию) нет ни одного архитектора внутренних структур СУБД Oracle. Они сосредоточены в других странах, поэтому просьбу предъявить работу такого уровня считаю излишней.
Прошу конструктивности в ваших желаниях и требованиях к серверу Oracle, проще будет дискутировать. Мы с вами находимся в корпоративном блоге компании РДТЕХ — платинового партнера Oracle и партнера Postgres Professional.
Поэтому, при обсуждении тех или иных возможностей этих СУБД в конструктивном ключе, вы можете получить авторизованные и официальные ответы.
imanushin
Здравствуйте, OBIEESupport (видимо, Юрий).
Повторю еще раз: мне не требуется экспертное мнение (к тому же вы с amathus работаете в одной компании, что немного намекает на определенную ангажированность). Мне необходимы доказательства позиции. Со ссылками на факты (например, на цены на официальном сайте), с воспроизводимыми тестами и так далее. Например, если Вы докажете, что Oracle будет работать дешевле и эффективнее в конфигурации ниже, то я с Вами соглашусь. Иначе — зачем пытаться сыграть на том же самом мнимом авторитете?
Я специально выше сказал, что подойдет любой человек, который докажет, что проектировал архитектуру для Oracle/Postgre/MariaDb или другой крупной базы. Однако, тут важно другое — если у вас нет такого человека, то придется приводить ссылки на доказательства, делать воспроизводимые измерения и так далее. Не получится просто взять и сказать "верьте мне, я прав".
Обещанная конфигурация:
Итого, у нас есть 12 серверов по 30 Тб (кстати, эта история является просто кратким пересказом реальной задачи, с поправкой на технологии). Если необходимо конкретное железо, то можно считать, что были вот эти серверы. Разумеется, также присутствует Staging зона (еще серверы), зона для интеграционного тестирования и зона для разработки. Интеграционные тесты, для сложности, могут гоняться параллельно.
С Вас — обосновать (со ссылками на цены), что конфигурация с Oracle будет дешевле (Вы ровно это и подтвердили, кстати).
amathus Автор
Уважаемый imanushin
Наверное вы не до конца поняли смысл моего предыдущего сообщения. Напишу четче: именно вам никто ничего не должен. Я просто не готов тратить своё время на то, чтобы что-то доказывать воинствующему разработчику по его «хотелкам». Желаете повысить своё ЧСВ — делайте это в другом месте.