Опубликован выпуск проекта IvorySQL 4.0, развивающего редакцию СУБД PostgreSQL, обеспечивающую совместимость с приложениями, рассчитанными на работу с СУБД Oracle. В IvorySQL заявлена возможность работы в качестве прозрачной замены последней версии PostgreSQL, отличие от которой сводится к появлению настройки "compatible_db", включающей режим совместимости с Oracle. Код написан на языке Си и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62483
А не бояздно, что орки скажут, что синтаксис и семантика PL/SQL есть их "интеллектуальная собственность" как результат их креативности?
Их подобный выпад в сторону Java потерпел фиаско.
Именно что "подобный". За Dalvik стоял не менее сильный игрок. Тут же мелкая конторка. Вы же понимаете, что lawsuitы - это не более чем война на истощение. Кто больше связей потянет и бабла завезёт - тот и выигрывает. С Гуглом не фартануло - это не значит, что против мелкой конторки не фартанёт. Вон, у Take Two и Nintendo фартануло не смотря на полную нелепость их исков.
Если бы сабж извлекал какую-то прибыль то можно было бы пободаться, а тут какой-то опенсорс с платой за поддержку. Ну такое.
> с платой за поддержкуэто и есть прибыль, лол
> в универсальном формате JSONПри обилии числовой информации - не лучший вариант. Тот же Protobuf очень заметно выигрывает у JSON. В случае Kafka у нас получилось, что в разы. При этом proto предоставляет возможности расширения, где через option можно указывать SQL типы данных для полей. Например, для DECIMAL это может быть очень важно.
если ты присмотришься повнимательней - там в самом конце - "format converter"потому что постгрезу нужен ни разу вот не json (и protobuf он тоже парсить не умеет)
Поэтому есть ровно одна причина его использования - они нашли готовую библиотечку. А готовую библиотечку для готового формата pgsql - не нашли.
> если ты присмотришься повнимательней - там в самом конце - "format converter"И к чему лишние конвертации?
> потому что постгрезу нужен ни разу вот не json (и protobuf он
> тоже парсить не умеет)А это и не нужно PostgreSQL. Главное, что Protobuf умеет из коробки парсить Debezium.
> Поэтому есть ровно одна причина его использования - они нашли готовую библиотечку.
> А готовую библиотечку для готового формата pgsql - не нашли.Про то и речь, что вместо того, чтобы пойти наболее эффективным путем, пошли путем наименьшего сопростивления.
так у них на входе в хранилище - ТОЖЕ json - который эти воркеры затем старательно конвертят в постгрезный sql. Я йаво слепила - из того что было, короче.
https://ru.wikipedia.org/wiki/EBML
А смысл не использовать с кафкой avro?
Во-первых, Protobuf более универсален. Собственно говоря именно поэтому Confluent добавил его поддержку. Такие стандартные(!) конструкции Protobuf, как package, option, extend, service и т.п. существенно расширяют его область применения.
Во-вторых, когда кроме Kafka используется gRPC, это нередко позволяет избежать лишних десериализации и сериализации. Запихивать же Avro в потоковый gRPC - так себе идея.
Ну, grpc пожалуй, аргумент па в остальном ну, такое. И avro-тулинг вокруг именно кафки развесистый, и со schema-based сериализацией работать прям сильно более удобно/гибко чем персборкой proto на каждый чих страдать...
> И avro-тулинг вокруг именно кафки развесистыйВот только он какой-то сильно Java ориентированный. Указать разные классы обработки кастомных типов для Java, Go, C#, Rust и C++ стандартными средствами невозможно. А когда это указывается не стандартными средствами, то через какое-то время получается Фарнкенштейн.
> и со schema-based сериализацией работать прям сильно более
> удобно/гибко чем персборкой proto на каждый чих страдать...Protobuf не обязан компилироваться. Да, рефлексия иногда удобна и повышает производительность. Но совсем не обязательна к применению.
Посмотрите на тот же Confluent/Debezium. Всё замечательно работает из коробки без пересборок. Достаточно публикации очередной версии схемы protobuf в schema registry.
Велосипедостроение на ровном месте. И велосипед ради велосипеда.
> Велосипедостроение на ровном месте. И велосипед ради велосипеда.Согласен. Можно взять готовые коннекторы (Debezium connect + Sink) и гнать всё через Kafka. Дополнительно требовалось лишь добавить свои конверторы там, где это необходимо. Ну или воспользоваться потоками kSQLDB.
А зачем вообще нужна эта совместимость? Oracle - это же легаси, от которого все стараются избавиться. Или это решение для тех, кто застрял в прошлом веке и не хочет переписывать свои PL/SQL-портянки?
НЕ ВСЕ И НЕ ВЕЗДЕ.
Новости из параллельной реальности.
>Oracle - это же легаси, от которого все стараются избавитьсяСамая популярная реляционная СУБД в мире с самой богатой функциональностью - легаси?
Не обращайте внимания у нас там в комментариях ненормальный. Проходим мимо, здесь не на что смотреть.
винда тоже самая популярная ОС на десктопе. как это противоречит тому, что все от неё пытаются избавиться, даже сами мс?
Речь шла не о том, кто от чего пытается избавиться. Речь шла о том, что считать легаси. А так, чем бы энтузиасты не тешились, абы не плакали.
>Самая популярная реляционная СУБДа на втором месте небось мускуль? и вообще это места в каких-то рунических магических квадрантах в головах эффективных распильщиков?
Ты как всегда прав, мой юный друг.
1. Oracle
2. MySQL
3. Microsoft SQL Server
4. PostgreSQL
5. MongoDB
По какому рейтингу? По количеству бабла, вытягиваемого с клиентов?
Не завидуйте.
Оракл не ведет деятельности на территории РФ. Если дял вас это что-то говорит. Так что не просто легаси от которого хотят избавится- а опасное дно, которое тянет и не дает развиваться.
>Если дял вас это что-то говоритМне на это плевать. Речь не об этом шла.
> Так что не просто легаси
Вы понимаете, что такое легаси вообще? Это морально устаревший софт. Даже при очень большом желании СУБД от Оракл нельзя назвать морально устаревшей.
Вообще-то legacy - это не "устаревшая" система, а унаследованная система, которая может быть и не устаревшей, но требующей замены.Да, Oracle DB - самая удобная и безотказная OLTP база данных в Мире, но пути Oracle (развивавшейся под крылом гос. структур США) и России разошлись теперь навсегда. Это факт, с которым трудно спорить. В России Oracle DB больше не будет, а тем где она есть ее заменят на другие СУБД.
>навсегданичего себе апломб, вы часом не сотрудник постгрипро?
А вы не сотрудник ли случаем Oracle или гос.депа?
В то что сотрудник ппро ошивается на опеннет охотно поверю.
В то что сотрудник оракла/госдепа ЗНАЕТ о существовании опеннет.ру... оч сильно сомневаюсь ))))
Когда же добавят совместимость с SQLite?
нахуа и зачем это все? это король костылей, хотя SSIS тоже так появился
Ну, вдруг у тебя твоя приложуха крутилась на Оракуле, а ВНЕЗАПНО ты решил всю свою инфраструктуру перенести на ПГ.
Что бы не переписывать все сразу на соединения с ПГ, ты можешь переписать на подобие ораклового синтаксиса крутящегося на ПГ.
Вроде как и совместимость с легаси оракловыми запросами сохранил,
заодно и стал бета-тестером, для отлавливания непонятных ошибок в этой прослойке.
если тебе надо чтобы оно было онлайн постоянно, то правильнее на какое-то время прикрутить XA Transactions и тригера, иначе не факт что получишь конситентное состояние в целовой БД, а если не надо то перенести можно чем хочешь