Уважаемый imanushin
Наверное вы не до конца поняли смысл моего предыдущего сообщения. Напишу четче: именно вам никто ничего не должен. Я просто не готов тратить своё время на то, чтобы что-то доказывать воинствующему разработчику по его «хотелкам». Желаете повысить своё ЧСВ — делайте это в другом месте.
Извините, забыл добавить. Сравниваем скорость загрузки/сохранения данных, цену хранения одного мегабайта. ClickHouse поддерживает SQL, кстати. В NoSql базах, обычно, нет транзакционности и контроля целостности, из-за этого можно одновременно обновлять две таблицы без блокировок, что положительно влияет на скорость.
Вы путаете теплое с мягким.
В Oracle есть транзакционность, есть изоляция транзакций и точно так же можно обновлять две таблицы без блокировок. Можно обновлять одну таблицу без блокировок одновременно N-сеансами.
И скорость доступа к данным тоже будет очень высокой: есть кэш буферов, есть in-memory опция.
В NoSQL за счёт ликвидации механизмов разграничения доступа (изоляции транзакции), за счет примитивизации механизмов доступа к информации — упрощена архитектура систем и, естественно, примитивные операции выполняются быстрее. Но в том-то и дело, что Oracle делает далеко не примитивные операции доступа к массиву данных и поэтому сравнивать это, как минимум, некорректно.
Для NoSQL может поддерживаться SQL интерфейс, да, но почитайте про ограничения (best practices), которые накладываются. Скорее всего: доступ через только через первичный ключ, транзакции фиксировать как можно быстрее итд итп. Чудес не бывает, за примитивизм и распределённость хранения придётся расплачиваться.
Про поддержку SQL — то, что JVM не поддерживает C#, не означает, что они не конкуренты. В kdb вообще есть functional select, когда вы создаете запрос в хранилище как бы «заполняя dto». Например, запрос select from t where b<4 можно выразить как whereCon: enlist (<;`b;4);?[ `t; whereCon; 0b; ()]. Это аналог dynamic sql из Oracle, только фаза разбора запроса пропускается.
Нет, это никакой не аналог. У Oracle работает оптимизатор, который строит план исполнения запроса, даже для sql-запросов, которые визуально занимают несколько экранов текста. Это одно и то же, что сравнивать механизм Streams API в java с БД Oracle и говорить, что, дескать, да весь ваш Oracle через лямбда-выражения сейчас перепишу.
Sql не всегда необходим для работы. Зачастую более дешевая система + увеличенные трудозатраты стоят меньше, чем дорогая система и уменьшение числа сотрудников.
До поры до времени.
«Компьютеры ненадежны, но люди еще ненадежнее».
Я говорю, что Oracle просто не сможет необоснованно повышать цену на поддержку Java, так как есть конкуренты, которые уже дешевле. Более того, необходимость в той же Java сейчас ниже, чем лет 10 назад (см. мой пример с Ansible). А потому довод с "$25 с сервера" является неправильным, так как крупные компании купят поддержку дешевле. Цены можно посмотреть здесь. Для Azul, в случае Premium Unlimited, годовая цена за поддержку Java 6-14 будет $341500 в год. Для компании со 100.000 серверов (среднего размера инвестиционный банк) это $3 в год. Так что $25 с сервера требовать просто не получится.
И? Какой глупый Oracle?
До этого Oracle вообще отдавал JVM бесплатно в пользование. А сейчас берет деньги.
Извините, я плохо выразился. У Oracle нет просто функций, из-за которых эту базу данных (не BI, не Oracle Forms, а именно базу) было бы разумно использовать сейчас для нового проекта. Вы можете привести контрпример (только сразу договоримся — в комментариях, не надо, пожалуйста, кидать ссылку на громадный маркетинговый материал).
Вот как раз сейчас вводится у клиента новый продукт с базой Oracle на 60 терабайт.
Я приведу примеры для PostgreSql
Сравнивать Oracle и PostgreSql некорректно, это разные весовые категории. Рассуждения о том, что PostgreSql своей гениальной мыслью затмевает Oracle, 25 лет не затмевал, а тут вдруг на ниве импортозамещения рассмотрели самородок, — часто звучат, но это не более чем следствие незнания внутренней изнанки устройства продуктов.
PostgreSql поддерживет jsonb, и даже хранит в нем и умеет индексировать. Получаем ускорение запросов и экономию места на диске.
Oracle поддерживает json и хранимые json-данные можно индексировать.
PostgreSql умеет разворачиваться в docker, а значит можно делать изолированные интеграционные тесты, когда база разворачивается из backup, далее выполняется миграция, проводится тестирование и так далее. Для Oracle необходимо держать отдельный сервер. Аналогично, усложняется окружение разработчика, так как нельзя локально разрабатывать и тестировать базу — сервер необходим всегда (ну или виртуализация с потерей ресурсов).
Вообще непонятно в чем сложности.
Развернуть в базе Oracle PDB, при необходимости отклонировать без прерывания работы пользователей в другой PDB.
Из-за низких цен на PostgreSql (с учетом поддержки), можно не беспокоиться по поводу числа серверов. А значит, используя logical replication фичу, можно иметь одну базу данных для записи и кучу для чтения. Последние можно разместить ближе к клиентам (в некотором смысле, CDN), или же выделить под сложные запросы. То есть за счет только этой фичи можно не обращать внимания на то, что запрос медленнее на 5% — просто заводится отдельный сервер и скорость запросов удваивается.
Скорость запросов удваиваться не будет.
Всё то же самое можно сделать и в Oracle. Почитайте про ограничения: DDL не поддерживается, truncate не реплицируется, «Replication is only possible from base tables to base tables». Это всё очень примитивный уровень. И очень хорошо кореллирует с моими утверждениями о элементарной несопоставимости Oracle и PG.
Таких ограничений нет ни при репликации в Oracle Golden Gate, ни через стендбай с опцией Active Data Guard.
Для Java есть достаточно вендоров, которые предлагают более дешевую поддержку. Так что после недавнего финта этой компании, куча больших клиентов просто ушла к условному Azul.
И? За кого болеть-то?
С базами данных у Oracle тоже начинаются серьезные трудности, так как:
Oracle DB и MySQL-ю проигрывает по удобству. И?
NoSql базы данных выигрывают у Oracle в области «много данных»
Если бы у бабушки… NoSQL не поддерживают SQL — и о чем идет речь? Что сравниваем?
Кроме «поддержка legacy», у Oracle практически нет технологических фишек, которые бы оправдали цену базы.
Даже затрудняюсь прокомментировать.
Как следствие в Oracle, я думаю, знают прекрасно об этом положении. И менеджеры просто мечутся, пытаясь хоть как-то вернуть прибыльность в стратегическом смысле.
Ну прямо фильм «Мертвец» Джармуша. Ещё ничего не произошло, первые кадры, а уже понятно, что герой мертв. :))))))))))))
Не нагнетайте лишнего.
Вопрос не в том, кого пожалеть, а кого не пожалеть, а в том, что все может закончиться скоропостижно, задолго до окончания расширенной поддержки JVM 8.
Апплеты используются в корпоративных решениях и для некоторых организаций миграция на альтернативные решения весьма трудозатратна. А учитывая, что даже нет гарантии по срокам поддержки (The Java Plugin (Java Applets) remains updated in Java 8, but may be removed at any time in a future release), то всё это не очень хорошо.
Ручка не оторвётся, по крайней мере в средней перспективе, т.к. Java это один из ключевых компонентов инфраструктуры Oracle Middleware. Oracle это контора, если говорить грубо, там нет понятия интереса, есть понятие совокупного коммерческого результата. Сейчас, скажем, посчитали, что можно брать два бакса за jvm у пользователя, по 25 баксов за jvm на процессор на сервере — и, думаю, бизнес заплатит, расчет оправдается.
С апплетами всё прекращается из-за отсутствия поддержки со стороны браузеров. На апплетах, скажем, сидели те же Oracle Forms (клиентская часть), и заблаговременно перешли на работу из-под Java Web Start.
Наверное вы не до конца поняли смысл моего предыдущего сообщения. Напишу четче: именно вам никто ничего не должен. Я просто не готов тратить своё время на то, чтобы что-то доказывать воинствующему разработчику по его «хотелкам». Желаете повысить своё ЧСВ — делайте это в другом месте.
В 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.
Oracle DB и MySQL-ю проигрывает по удобству. И?
Если бы у бабушки… NoSQL не поддерживают SQL — и о чем идет речь? Что сравниваем?
Даже затрудняюсь прокомментировать.
Ну прямо фильм «Мертвец» Джармуша. Ещё ничего не произошло, первые кадры, а уже понятно, что герой мертв. :))))))))))))
Не нагнетайте лишнего.
С апплетами всё прекращается из-за отсутствия поддержки со стороны браузеров. На апплетах, скажем, сидели те же Oracle Forms (клиентская часть), и заблаговременно перешли на работу из-под Java Web Start.