Компания Microsoft объявила об открытии кода проекта DocumentDB, который может использоваться как отдельная NoSQL СУБД, как платформа для создания собственных систем хранения или как дополнение для хранения данных в формате BSON в СУБД PostgreSQL. На практике DocumentDB применяется в Microsoft в качестве основы продукта "Azure Cosmos DB for MongoDB", предоставляющего интерфейс, совместимый с документо-ориентированной СУБД MongoDB. Код проекта написан на языке Си и распространяется под лицензией MIT. Движок DocumentDB реализован в форме надстройки над СУБД PostgreSQL...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62621
Тем временем AWS DocumentDB в ах*е от хуцпы мелкомягких.
Ну AWS DocumentDB относительно недавно появился, а СУБД Azure DocumentDB уже лет 15 как существует, его даже переименовать успели в Azure Cosmos DB.
Кому может понадобится код от Microsoft)) Если только посмотреть, как не надо делать =)
Понадобится
Уже в FerretDB затащили
FerretDB - а кому оно надо? любителем монго-кактусов?
Ну, я могу себе представить контору, у которой экспертиза по postgres вот есть - а по mongo "нет и через забор не надь" - и тут "нате-на-лопате" коробочное решение с прикрученной на изоленту mongo'й нарисовалось - но в реальной жизни допущений чот многовато выходит...
если отсутствует экспертиза по монге и ты не хочешь ее получать, то тебе нафиг не надо никакая монго ни та ни поверз постгреса
> если отсутствует экспертиза по монге и ты не хочешь ее получать, то
> тебе нафиг не надо никакая монго ни та ни поверз постгресаСпасибо, кэп!
О! вам улчше не знать)
На opennet'е? Примерно "никому", у всех жеж "лапки", да и задач-то под кроватью таких нет.
А так вот разработчикам ferretdb вот понадобилось (Зачем кому-нибудь сам ferretdb нужен - не спрашивай) - судя по всему, у MS получилось мал-мала лучше, чем у них самих.
Конкретное вот облачное решение чтоб с самой mongo'й не связываться - вообще дофига кому, да.
Ну на опеннете ведь как: закрытый код — «а что это тут делает»? Открыли код — «от корпораций нам ничего не надо!». Не в первый и не в десятый раз уже.
> Если только посмотреть, как не надо делать =)Для этого линукс есть. Сорцы открыты, бери и учись как делать не нужно.
Дейтвительно, кому мог бы понадобиться, например, VS Code - единственный годный редактор под линух.
> единственный годный редактор под линухкто-то сказал neovim? 😆
Там ввод уже починили? Выйти из него уже можно по-человечески? Разрабы в курсе, что IBM Model M появилась и теперь необязательно биндить перемещение курсора на hjkl, ибо есть стрелочки?
аж монитор потек
> Кому может понадобится код от Microsoft)) Если только посмотреть, как не надо делать =)Винда прекрасно работает для миллионов непритязательных пользователей. Stackoverflow и ДоДо пицца целиком на стеке мелкомягких работали, когда я узнавал. Хорошо работали.
Современный дотнет, тот который полностью open source, хорошо написан. Гляньте как-нибудь.
> Винда прекрасно работает для миллионов непритязательных пользователейНу конечно) Вот буквально сегодняшная новость: "Microsoft confirms Windows 11 January 2025 update issues, DAC audio failure". Винда как была кривой с рождения, так и осталась...
Там хотя бы ломается то, что изначально работало а исправляют быстро. А в этих ваших дескпотопных линуксах половина железа изначально работала только наполовину в лучшем случае. А нормальный dac вообще вез всяких пшш и ик-ик, нужно еще постараться настроить.
Надеюсь что это эффективнее jsonb. Не знаю что за имбeцилы в постгресе писали jsonb, где судя по всему для каждого вложенного словаря/массива хранится 4 или 8 байт его длины, из-за чего относительно json его раздувает в пару раз. Поэтому значительно удобнее и эффективнее в базе хранить не json а протобуфы (схема и прямая/обратная совместимость бонусом).
Напиши лучше
возьми текст JSON в UTF-8 и засунь это в обычный бинарь, можешь предварительно сжать gzip, цена такой операции копейки, вполне примелимо, за будешь за вендор-лок к БД
>возьми текст JSON в UTF-8 и засунь это в обычный бинарьОткрой для себя MessagePack - It's like JSON, but fast and small
>>возьми текст JSON в UTF-8 и засунь это в обычный бинарь
> Открой для себя MessagePack - It's like JSON, but fast and smallа JSON который он сформирует это будет не UTF-8 текст? и мне нужен именно LZ4 встроенный? не gzip, не бротли и не zstd?
притом речь шла о том что JSON у него уже есть (читай текст), то зачем ему всего лишь еще один сериализатор?
то что ты знаешь неплохой сериализатор, еще не означает что ты умеешь читать
Только вот работать с этим придется - ну, на уровне приложения, а не с помощью СУБД со всеми вытекающими, ага. Ложь (Не "клади") паркетом под себя и не мучай слоника, чоужтам - смотрите у всех датасатанистов страны ))).
А так-то postgresql даже индексить тот jsonb умеет - была б реализация чуть менее уродлива (Примерно со всех сторон - от функций по работе С, которые разок уже менялись, до - да-да, структуры хранения и, как следствие, эффективности работы с данными) - цены б ей не было - но маемо шо маемо.
>Не знаю что за имбeцилы в постгресе писали jsonb, где судя по всему для каждого вложенного словаря/массива хранится 4 или 8 байт его длины,Ну давай, если сам не имбецил, расскажи, как упаковать в бинарном сторадже последовательности массивов байтов произвольных размеров, не сохраняя их длин, или смещений.
1 байт длины не подойдет?
>1 байт длины не подойдет?И какие значения длины можно записать в переменную размером 1 байт? Что будет если значение длинны равно 1M?
Я к тому, что можно использовать что-то типа LEB128, как это сделано в protobuf, чтоб не хранить всегда 4 или 8 байт под длину.
"640 КБ должно хватить для любых задач!" (c)
А теперь сделай эффективный поиск по этому всему...
Так jsonb можно ложить в compressed колонку хранения, абсолютно прозрачно. К тому же у jsonb работают все индексы и быстрый доступ по jsonpath в отличие от protobuf. Так тогда можно и сериализованный byte array или msgpack сохранять, если индексы не нужны.
Какая разница, если в подаваляющем большинстве случаев JSONB лежит сжатым в TOAST?
Можно ещё сериализовать с помощью Boost::LexicalCast
Вот! В очередной раз платиновый спонсор LF и лучший друг опенсорса дарит всему сообществу свой код.Причем не потому, что их обязала раковая лицуха, а потому что им так захотелось - под Свободной лицензии MIT.
Потому что это никому не нужно даже самим майкам.
Подскажите, а какая сейчас самая вменяемая реляционная БД без встроенных хлеборкзки и компаса?Это же просто набор таблиц, селекты, транцакции... а руководство только к одной MSSQL - тысяч пять строк
> Подскажите, а какая сейчас самая вменяемая реляционная БД
> без встроенных хлеборкзки и компаса?SQLite)))
Легкая, встравается во что угодно, даже в компас и хлеборезку!
Свободная, можно использовать где и как угодно.
Есть конечно чуток минусов, но где их нет?)(
Голосую за firebird!
К этим Интербейзам документация ничуть не короче, чем к MSSQL, оно ж тоже самое умеет, по-сути.
Напиши свое в таком случае под свои хотелки.
просто не используй все хрень сверху ее реляционных возможностей и это будет правильноа так-то уже и JS в MySQL завезли в превью билдах
И трать ресурсы на join большого числа табл, а в некоторых случаях и сканирований по неподходящим индексам. Короче, школу закончи, пару курсов вуза, потом советуй.
> И трать ресурсы на join большого числа табл, а в некоторых случаях
> и сканирований по неподходящим индексам. Короче, школу закончи, пару курсов вуза,
> потом советуй.мда, речь шла о функциях на JS типа SQL Server CLR functions, если вкратце
P.S.
вот будет же такое как ты сидеть в каком-нибудь кабинете, будучи уверенным в собственной обалденности и людям жить портить
Postgres конечно. Если приложение монопольно будет базу использовать - sqlite.
А мелкософт молодцы...
Взяли готовое решение, которые написали немамонты из PostgreSQL, дописали чуток кода и теперь рубят на этом бабки. Причем вклада в сам PostgreSQL от них практически нет. Как напр. и в ядро линя. Хотя на азуре они зарабатывают больше чем на десктопной винде.
> любой вор/паразит.Вор просто забрал бы себе и запретил остальных пользоваться - примерно как ГНУтики просто взяли кода с BSD/MIT и заразили гнураком.
Паразит только использовал не давая ничего взамен.А тут типичный симбионт - он использует существующий код, поддерживая и улучшая его, тк от этого зависит его благосостояние.
И когда таких много - например 80% кода в ядре пишут корпорации, то вопрос "а кто теперь васяны, которые только пользуются ядром?" становится не таким однозначным))
Благо на мнение васянов кладут огромный болт.
> 80% кода в ядре пишут корпорацииНет. 100% кода пишет сам.
Эээээ... да собственно примерно наоборот же. "Немамонты" написали, "ну, такоЭ" - другие товарищи из ferretdb попытались это "ну очень такоЭ" использовать - вышло "ну эдакое". Потом пришли MS и показали, "как надо" и любители "эдакого" радостно на это "как надо" и переключились.
Вопрос "кто мешал "не мамонтом" сделать у себя нормальную работу с json" оставим пока за скобками...
К чему все твои "ну, такоЭ" и "ну эдакое"?
Речь о том, что мелкомягкие опять зарабатывают деньги на написаном другими коде. Практически не вкладываясь в него. Причем из-за олигополии облачных провайдеров, они со своим Азуром получают огромную фору по сравнению со всеми другими.
> К чему все твои "ну, такоЭ" и "ну эдакое"?
> Речь о том, что мелкомягкие опять зарабатывают деньги на написаном другими коде.
> Практически не вкладываясь в него. Причем из-за олигополии облачных провайдеров, они
> со своим Азуром получают огромную фору по сравнению со всеми другими.К тому, что вот в данном случае зарабатывать на написанном "не мамонтами" не выходит, пришлось самим писать.
Можно подумать, опеннетовкие анонимы не зарабатывают на написанном другими коде. Практически не вкладываясь в него.
Бузинес все правильно сделали.
Разработка софта *для* платформы — а Постгрес это платформа — большое и важное дело. Претензий к Блендеру или Гимпу что не коммитят в ядро почему-то не возникает. Но не дай бог Майкрософту выпустить любой опенсорс, и опеннет как с цепи срывается.
Во-первых, "свободная" лицензия, по мнению некоторых которые не признают OSI/FSF, оказалась недостаточно свободной, что пришлось заменять. Во-вторых, навернули уродливый mongo api поверх RDBMS, можно вставлять BSON, а также можно делать CRUD и пару индексов на сдачу. И ещё не известно что по бенчмаркам, ведь их пока не показали, надо подождать. В-третьих, взяли название у amazon documentdb чтобы успешнее конкурировать в поиске.
>для хранения данных в формате BSON в СУБД PostgreSQLНо CBOR же намного лучше. BSON - это первый блин комом. Вернее далеко не первый.
Bson поддерживает рандомное чтение, в отличие от клона msgpack. Что критически важно для базы данных. Так что твой аргумент полностью не обоснован.
>Bson поддерживает рандомное чтениеНе надо сказки рассказывать. Для рандомного чтения надо, чтобы элемент был постоянной длины. Это в принципе невозможно для словарей, ключи значения которых содержат разнородные типы. Более того, массивы в BSON хранятся, честно говоря, через жопу. Как словари, ключи у которых - строки, содержащие индекс элемента в текстовом виде. О каком "рандомном чтении" в принципе может идти речь в таких условиях?
> Движок DocumentDB реализован в форме надстройки над СУБД PostgreSQL.Стареют NoSQLники. Лет 15 назад за такие идеи затролили и прогнали бы из хипстеров.
Так это ж не они, это те самые тролли и есть. "Зачем вам монга, она лицензию требует, без штанов останетесь - вон нате вам нашу аналогов не... то есть точно такую же, но шва6одную documentDB - смотрите, смотрите, все как вы любите!"
Те и повелись. Опа - а там postgres.
Да они просто внезапно выяснили, что весь их NoSQL прекрасно запихивается в RDBMS, и ведёт себя при этом не хуже.
и вовсе даже не они!
Только отваливаются транзакции, acid, джойны, оконные и агрегатные функции. А так да json можно продолжать пихать в файлы.
FerretDB не осилили транзакции. Так что не стоит всерьез рассматривать эту поделку.
Напомню, в Mongo они есть
MongoDB умеет работать в условиях раздроблении кластера, PostgreSQL - нет. И никакой "интерфейс, совместимый с документо-ориентированной СУБД MongoDB" это не исправит. Потому что это вопрос архитектуры СУБД, которая у PostgreSQL принципиально другая, и поэтому поддержать такой вариант работы просто не в состоянии.Я не знаю как мелкомягкие решили эту проблему в своем облаке... хотя судя по тому, что код их поделки открыт, можно предположить, что удовлетворительного решения они так и не нашли. В общем, ИМХО, очередное "дай вам боже, что нам не гоже"
А что такое -- раздробление кластера? Потеря (временная) синхронности и согласованности между узлами, которые, вроде как, реализуют одну общую схему? Нет никаких препятствий для реализации чего-то подобного поверх Слона. Более того, есть ряд таких же плохих, как в Монге, свободных реализаций чего-то подобного средствами ванильного Слона. И ряд не очень плохих коммерческих.
> А что такое -- раздробление кластера? Потеря (временная) синхронности и согласованности
> между узлами, которые, вроде как, реализуют одну общую схему? Нет никаких
> препятствий для реализации чего-то подобного поверх Слона. Более того, есть ряд
> таких же плохих, как в Монге, свободных реализаций чего-то подобного средствами
> ванильного Слона. И ряд не очень плохих коммерческих.Вообще-то есть. И это что-то называется теорема CAP
Под спойлером: "Теорема САР - это утверждение о том, что любая распределенная система не может обладать одновременно тремя свойствами: согласованность данных, доступность и устойчивость к разделению"
Так вот, архитектура PostgreSQL гарантирует согласованность (ACID) и доступность, а MongoDB - доступность и устойчивость к разделению.
Нет никакой "теоремы САР".
> Нет никакой "теоремы САР".Отрицание. Вам осталось пройти "Гнев", "Торг" и "Депрессию". Уже скоро))
PS Можно так же до кучи начать отрицать BASE и PACELC. Это полезно: стадия "Принятие" у вас наступит для всего зоопарка теорем разом))
Что не г, то к нашему берегу. Спроси у чатика, что такое этимология, а потом спроси этимологию теоремы.
... И уж тем более эта "теорема" не мешает реализации чего угодно на чём угодно.