Комментарии 31
С апплетами всё прекращается из-за отсутствия поддержки со стороны браузеров. На апплетах, скажем, сидели те же Oracle Forms (клиентская часть), и заблаговременно перешли на работу из-под Java Web Start.
есть понятие совокупного коммерческого результата
Это звучит довольно красиво, однако на деле нуждается в обосновании.
Для Java есть достаточно вендоров, которые предлагают более дешевую поддержку. Так что после недавнего финта этой компании, куча больших клиентов просто ушла к условному Azul.
С технической точки зрения, на Java сильно давит Python, .Net, Rust (каждый в своей области). Для новых сервисов выбор Java зачастую обосновывается тем, что программисты не знают других языков. И постепенно тенденция переламывается. Например, Ansible написан на Python, хотя если бы первый релиз был бы раньше, то разработчики, скорее всего, пошли бы путем Jenkins/TeamCity. Аналогично про IDE — раньше было разумно писать её на Java, сейчас в моде — Электрон (IntelliJ Idea/Eclipse vs MSVS Code).
С базами данных у Oracle тоже начинаются серьезные трудности, так как:
- Oracle база так и не была адаптирована для облака до сих пор (текущие решения резко проигрывают по удобству тому же PosgreSql, за счет архитектуры).
- NoSql базы данных выигрывают у Oracle в области "много данных". Условно, биллинг сейчас эффективнее сделать на ClickHouse/kdb и аналогах, тогда как лет 20 назад Oracle был безальтернативным.
- Кроме "поддержка legacy", у Oracle практически нет технологических фишек, которые бы оправдали цену базы.
Как следствие в Oracle, я думаю, знают прекрасно об этом положении. И менеджеры просто мечутся, пытаясь хоть как-то вернуть прибыльность в стратегическом смысле.
Для Java есть достаточно вендоров, которые предлагают более дешевую поддержку. Так что после недавнего финта этой компании, куча больших клиентов просто ушла к условному Azul.И? За кого болеть-то?
С базами данных у Oracle тоже начинаются серьезные трудности, так как:
Oracle DB и MySQL-ю проигрывает по удобству. И?
NoSql базы данных выигрывают у Oracle в области «много данных»Если бы у бабушки… NoSQL не поддерживают SQL — и о чем идет речь? Что сравниваем?
Кроме «поддержка legacy», у Oracle практически нет технологических фишек, которые бы оправдали цену базы.Даже затрудняюсь прокомментировать.
Как следствие в Oracle, я думаю, знают прекрасно об этом положении. И менеджеры просто мечутся, пытаясь хоть как-то вернуть прибыльность в стратегическом смысле.Ну прямо фильм «Мертвец» Джармуша. Ещё ничего не произошло, первые кадры, а уже понятно, что герой мертв. :))))))))))))
Не нагнетайте лишнего.
Если бы у бабушки… NoSQL не поддерживают SQL — и о чем идет речь? Что сравниваем?
Извините, забыл добавить. Сравниваем скорость загрузки/сохранения данных, цену хранения одного мегабайта. 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:
- PostgreSql поддерживет jsonb, и даже хранит в нем и умеет индексировать. Получаем ускорение запросов и экономию места на диске.
- PostgreSql умеет разворачиваться в docker, а значит можно делать изолированные интеграционные тесты, когда база разворачивается из backup, далее выполняется миграция, проводится тестирование и так далее. Для Oracle необходимо держать отдельный сервер. Аналогично, усложняется окружение разработчика, так как нельзя локально разрабатывать и тестировать базу — сервер необходим всегда (ну или виртуализация с потерей ресурсов).
- Из-за низких цен на PostgreSql (с учетом поддержки), можно не беспокоиться по поводу числа серверов. А значит, используя logical replication фичу, можно иметь одну базу данных для записи и кучу для чтения. Последние можно разместить ближе к клиентам (в некотором смысле, CDN), или же выделить под сложные запросы. То есть за счет только этой фичи можно не обращать внимания на то, что запрос медленнее на 5% — просто заводится отдельный сервер и скорость запросов удваивается.
Извините, забыл добавить. Сравниваем скорость загрузки/сохранения данных, цену хранения одного мегабайта. 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.
В NoSQL за счёт ликвидации механизмов разграничения доступа (изоляции транзакции), за счет примитивизации механизмов доступа к информации — упрощена архитектура систем и, естественно, примитивные операции выполняются быстрее. Но в том-то и дело, что Oracle делает далеко не примитивные операции доступа к массиву данных и поэтому сравнивать это, как минимум, некорректно.
NoSql — это не замена для Oracle. Просто для ряда задач имеет смысл выбирать между ними. Я могу привести примеры, если хотите. 20 лет назад такого не было, сейчас у Oracle появилось довольно много конкурентов.
это не более чем следствие незнания внутренней изнанки устройства продуктов.
Не приму данный пассаж, как и Вашу фразу ":))))))))))))" выше или изречение "Это всё очень примитивный уровень.". Вы отклоняетесь от рассуждения, вместо приведения фактов пытаетесь свести все к мнимому авторитету от анонимного (на текущий момент) аккаунта в интернете. Хотя, если Вы приведете доказательства того, что проектировали хотя бы одну архитектуру более-менее популярной базы данных (я про программу типа Oracle, а не про базу на Oracle), то я возьму свои слова обратно и признаю авторитет. Сейчас же я очень Вас попрошу — писать строго факты со ссылками.
Скорость запросов удваиваться не будет.
Да, Вы правы. Я некорректно выразился. Я имел ввиду, что нагрузку на крупную базу можно размазать по нескольким серверам. И если аналитики чаще всего работают с куском базы, размеров в 1 Тб (чаще всего, однако им надо все, этот кусок — это просто часть таблиц, не более), то выделение отдельного сервера просто позволит запихнуть этот "кусок" в оперативную память. Более того, это само произойдет средствами ОС.
Технически скорость увеличить можно. На практике, в моих задачах, практически всегда базы работают достаточно быстро, чтобы на первое место вставали задачи скорее горизонтального масштабирования и проектирования. И вот здесь, как я описал Выше (и уточню в текущем ответе ниже) Oracle серьезно проигрывает.
Всё то же самое можно сделать и в Oracle.
Нет. Так — нельзя. Кроме базовых таблиц, остальное реплицировать нет смысла. Процедуры можно перенакатить (буквально — запустить программу не на одном сервере, а на нескольких) в момент релиза. Индексы глупо копировать — их можно восстановить баз базовых таблиц.
В моем комментарии важное слово было "можно не беспокоиться по поводу числа серверов". Если посчитать бюджет на оракловый распределенный кластер, то он будет стоит дико дорого, и так делать просто не будут. В случае Postgre бюджет будет намного симпатичнее. Еще раз, важно: цена.
Вообще непонятно в чем сложности.
Объясняю. Сделать дамп базы несложно. Мы же на хабре, а потому знаем, что есть даже несколько способов снять дамп (или же скопировать базу).
С Oracle невозможно поднять такое локальное и быстрое окружение для разработчика/билд агента, чтобы не оставлять следов на компьютере. Условно, в случае Posgtre/MariaDb разработчик может развернуть все из докера, а потом просто удалить образ — и всё. Никаких установок, никаких следов. Аналогично для агента — после скачивания образа базы из хранилища (не будем же мы грузить сервер баз по напрасну?), все тесты проходят локально. Вы можете даже гонять тесты локально на разных версиях базы данных, буквально немного подправив билд конфигурацию. Образы открыты и лежат в docker storage в интернете.
С Oracle такой простоты просто не будет. Вам надо ставить ПО на комп, у Вас будут проблемы, если несколько версий Oracle установлено одновременно и так далее. Если вы выделите сервер, то это не локальный прогон, необходимо будет следить за окружением.
Oracle поддерживает json и хранимые json-данные можно индексировать.
Я специально привел ссылку на stackoverflow. Я говорю не про json, а про binary json, который быстрее. А по ссылке говорится, что в Oracle просто нет такой фичи — вы должны использовать медленный строковый формат (в отличии от MariaDb, Mongo, Posgtre и пр). Вот та ссылка — https://stackoverflow.com/questions/53636840/query-jsonb-through-dblink-oracle-postgres
У меня здесь аккаунт верифицирован.
Слова amathus и его выводы в статье полностью подтверждаю.
И еще, у нас в стране (я про Россию) нет ни одного архитектора внутренних структур СУБД Oracle. Они сосредоточены в других странах, поэтому просьбу предъявить работу такого уровня считаю излишней.
Прошу конструктивности в ваших желаниях и требованиях к серверу Oracle, проще будет дискутировать. Мы с вами находимся в корпоративном блоге компании РДТЕХ — платинового партнера Oracle и партнера Postgres Professional.
Поэтому, при обсуждении тех или иных возможностей этих СУБД в конструктивном ключе, вы можете получить авторизованные и официальные ответы.
Здравствуйте, OBIEESupport (видимо, Юрий).
Слова amathus и его выводы в статье полностью подтверждаю.
Поэтому, при обсуждении тех или иных возможностей этих СУБД в конструктивном ключе, вы можете получить авторизованные и официальные ответы.
Повторю еще раз: мне не требуется экспертное мнение (к тому же вы с amathus работаете в одной компании, что немного намекает на определенную ангажированность). Мне необходимы доказательства позиции. Со ссылками на факты (например, на цены на официальном сайте), с воспроизводимыми тестами и так далее. Например, если Вы докажете, что Oracle будет работать дешевле и эффективнее в конфигурации ниже, то я с Вами соглашусь. Иначе — зачем пытаться сыграть на том же самом мнимом авторитете?
И еще, у нас в стране (я про Россию) нет ни одного архитектора внутренних структур СУБД Oracle. Они сосредоточены в других странах, поэтому просьбу предъявить работу такого уровня считаю излишней.
Я специально выше сказал, что подойдет любой человек, который докажет, что проектировал архитектуру для Oracle/Postgre/MariaDb или другой крупной базы. Однако, тут важно другое — если у вас нет такого человека, то придется приводить ссылки на доказательства, делать воспроизводимые измерения и так далее. Не получится просто взять и сказать "верьте мне, я прав".
Обещанная конфигурация:
- База данных занимает 30 Тб. Главная база находится в датацентре, например, Германии. В том же городе, в другом датацентре, находится её копия в active-hot passive режиме. Таким образом есть некоторое подобие disaster recovery.
- По всему миру, в разных локациях, есть read-only копии базы данных (они получают события из главной как я описывал выше — небольшой задержкой). Всего есть, допустим, пять дополнительных локаций: Азия (два сервера в Сингапуре), Австралия, США, ЮАР и та же Германия (чтобы разгрузить основной сервер).
Итого, у нас есть 12 серверов по 30 Тб (кстати, эта история является просто кратким пересказом реальной задачи, с поправкой на технологии). Если необходимо конкретное железо, то можно считать, что были вот эти серверы. Разумеется, также присутствует Staging зона (еще серверы), зона для интеграционного тестирования и зона для разработки. Интеграционные тесты, для сложности, могут гоняться параллельно.
С Вас — обосновать (со ссылками на цены), что конфигурация с Oracle будет дешевле (Вы ровно это и подтвердили, кстати).
Наверное вы не до конца поняли смысл моего предыдущего сообщения. Напишу четче: именно вам никто ничего не должен. Я просто не готов тратить своё время на то, чтобы что-то доказывать воинствующему разработчику по его «хотелкам». Желаете повысить своё ЧСВ — делайте это в другом месте.
Не видел Java апплеты и сервлеты с тех пор, как учился в институте. Единственное, что про них помню так — это то, что они очень медленно инициализируются. Это же были примочки типа Adobe Flash, которые сейчас уже ни кому не интересны.
Хе, а у нас на работе они до сих пор используется. HP ALM, работает на джава-апплетах через IE, и не похоже, что с него планируют слезать.
Самая кровь энтерпрайза! Т_Т
для некоторых организаций миграция на альтернативные решения весьма трудозатратна
Апплеты были исключены из Java 9 еще в 2017 году (три года назад). При этом даже тогда их использование уже было крайне сомнительным (ввиду полного их отсутствия на iPhone/Androind/WinPhone и пр.).
По сути, проблемы только у тех, кто полностью забил и на свое приложение, и на пользователей, однако продолжает получать ресурсы "за поддержку" (это относится как к вендорским решениям, так и ко внутренним продуктам; в обоих случаях команда когда надо говорит "мы поддерживаем приложение Х, давайте деньги", а когда надо — "нам очень трудно поддерживать приложение Х, не просите нас что-то делать").
Я бы не стал жалеть таких персонажей. Им надо определиться: либо они по-настоящему поддерживают свои продукты и идут в ногу со временем, или же они не требуют платы за продукт. А тут мы видим, что попытка усидеть на двух стульях привела к подобного рода проблеме.
Не видел Java апплеты и сервлеты
Ну, то, что вы не видели сервлетов это не их вина, а ваша :)… Так-то они везде, просто над ними надстроены аппсервера и фреймворки.
Спасибо. Буду знать, что это доисторическое слово может быть актуально в 2020.
Буду знать, что это доисторическое слово может быть актуально в 2020.
Вы жжоте! Давайте и http протокол тогда туда же, вместе с HTML :-)
Браузер уже все это сделал. Subtle crypto и, как следствие, integrity уже не дадут вам использовать http, если вы заботитесь о безопасности. Даже хэш в провальной sha-1 не посчитать, если пользователи по http лазают, а это рекомендации того же Google и они увеличивают доверие не только к ресурсу. HTML, мне кажется, очевидно, что хоронить глупо. Посмотрите на кишки Microsoft Store: там что-то до боли похожее на JSON+CSS.
Не путайте схему http:// с протоколом HTTP.
А я откуда знаю, что имеется ввиду? Вот скоро http 3 будет, как протокол, а использовать нужно на продакшн только https. Ни чего я не путаю.
Можно было к примеру реализовывать поддержку давления пера графического планшета задолго до того, как браузеры наконец-то добавили pen pressure (со скрипом, долго и криво, во всяком случае я проверял эту возможность эпизодически и только сейчас я вижу, что давление пера теоретически поддерживают все современные браузеры).
За последние лет пять видел апплеты в браузере (не путать с web-старт когда скачивается и запускается jar-файл как отдельное приложение в отдельном окне, такое кое-где встречается, например в IPMI-оборудовании) в древнем IPKVM Dlink, чтобы запустить всё это дело пришлось ставить браузер Palemoon так как там сохранили NPAPI и соответствующий плагин
Благо сейчас все новые разработки реализуются на HTML5 и VNC-протоколе
Кстати, а как сделать нормальную электронную подпись в браузере, не через сторонний бинарный NPAPI/PPAPI/ActiveX плагин и не через апплет? Кто-нибудь знает примеры?
NPAPI/PPAPI/ActiveX плагин и не через апплет
Я раньше работал с электронной подписью, вменяемых альтернатив небыло. И я точно знаю что многие сидят на ослике/ff 52 и проклинают их именно из-за поддерджки activeX/NPAPI. Те, кто в те времена умудрился мигрировать, в основном уходили на нативные приложения, без возможности работы в браузере либо с подписью в сторонних приложениях и загрузкой подписи в браузер в виде отдельного файла с подписью
Может, и сойдет, если на Android или iOS, где мало кто имеет доступ к файлам браузера (в отличие от Windows)
Java-апплеты будут исключены из Java 8 с окончанием поддержки NPAPI в MSIE