Опубликован выпуск проекта FerretDB 1.0, позволяющего заменить документо-ориентированную СУБД MongoDB на PostgreSQL без внесения изменений в код приложений. FerretDB реализован как прокси-сервер, транслирующий обращения к MongoDB в SQL-запросы к PostgreSQL, что позволяет использовать PostgreSQL в качестве фактического хранилища. Версия 1.0 отмечена как первый стабильный выпуск, готовый для повсеместного использования. Код написан на языке Go и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=58915
> createIndexes и dropIndexesу нормальных людей это зовется indices, а не indexes.
Both "indexes" and "indices" are acceptable plural forms of the word "index" or to refer to more than one index. Index is one of those rare words that have two different plurals in English. "Indices" is originally a Latin plural, while "Indexes" has taken the English way of making plurals, using –s or –es. Though both are still widely used, they take on different usage in their senses. "Indices" is used when referring to mathematical, scientific and statistical contexts
А вот и подъехала цитата прямиком из выдачи гугла, даже без прохождения по ссылке.
ChatGPT detected?
Специально для анонимов с опеннета посмотрел в хардварном словаре напечатанном в Великобритании, всё правильно написано.
Который отсканировали и выложили в сеть, где его и нашла нейросеть и гугл. Разговор был не о содержании а о форме подачи. Притом в ироническом ключе.
Иронизировать про шашечки на опеннете любят, да.
CENTER ИЛИ CENTRE?
Da
Прокси для тех кто не осилил sql?
Не всем нужен sql
Программист не осилил sql? Привлечение кадров которые не могут переучиться на sql?
для тех у кого задачи что-то кроме sql
Если у тебя в руке молоток, то все предметы вокруг автоматически считаются гвоздями.
Нет.
Так программист и нужен чтобы создать приложение которое скроет от оператора внутренности. Поэтому он должен знать sql и техзадание выраженное в предметной логике. Оператору действительно не нужен sql. Предваряя ответ, оператору нельзя давать свободный доступ к СУБД.
Вы знаете, бывают случаи, когда даже программисту не нужен SQL.
Да если он не работает с sql СУБД.
сиквел продуктовому программеру нужен, если только для саморазвития. Сейчас же кругом ОРМы.
Вот так умирает нативность. Типа могу работать с sql db но язык запросов к не знаю.
Ах, если бы реляционные базы данных покрывали 100% всех кейсов. Ах, если бы на SQL было удобно выразить любой запрос. Это была бы такая жизнь, анонче… Сказка была бы, а не жизнь. Но эти мечты, как и многие, разбились о чугунный зад реальности.
> Ах, если бы реляционные базы данных покрывали 100% всех кейсов.Вроде бы, в мире уже не осталось чистых реляционных СУБД, как правило, все поддерживают несколько парадигм.
> Ах, если бы на SQL было удобно выразить любой запрос.
SQL - тюринг-полный язык. Об удобстве выражения, конечно, спорить бесполезно. Но вот на тему "любой" - вполне даже можно.
> SQL - тюринг-полный языкБред. SQL не тюринг-полон. Иначе не появились бы графовые базы данных с их собственными языками запросов.
А как же ApacheAge или MS SQL Graph?
> MS SQL GraphЧувак, ты газируешь лужу: и у той, и другой есть куча дополнительных команд, не входящих в SQL. Так что мимо. Попробуй ещё.
Деточка, я не знаю ни одной реальной СУБД, не поддерживающей "куча дополнительных команд, не входящих в SQL". Например, в SQL:2016 стандартизировали поддержку JSON, что ничуть не дальше графов от базовых SQL парадигм. Просто более часто востребованно.
А так как стандартизируется то, что уже реализовано в каких-то СУБД, то значит графы уже в очереди на очередной стандарт SQL.
На очереди или нет, не так важно. Важно, что SQL - достаточно слабый и ограниченный per se.
И работа с графами это наглядно иллюстрирует.
Для тех кто хочет развернуть сторонний проект, требующий mongo, но у них уже есть postgres, таким образом можно обойтись без лишнего сервиса.
> Для тех кто хочет развернуть сторонний проект, требующий mongoи гадать потом - это он так глючит потому что руки из оттуда, или потому что монга у тебя не совсем монга?
Нет, это где, в каком месте такие сущеглупые обитают, чтоб не вляпаться?
А чего гадать, любой нормальный проект покрыт тестами. Прогнал тесты и посмотрел.
не волнуйся
Какая БД самая популярная? Какую лучше учить? Вопрос из разряда, какой ЯП самый популярный, какой учить?
Пятый принцип философии юникс:
> Храните данные в простых текстовых файлахВсе эти СУБД с бинарным форматом - от Поттеринга.
Текстовый файл хранится внутри файловой системы с бинарными ссылками в виде inode на них, все эти файловые системы от гари потера, философ предлагает лучше хранить прям в секторах накопителя, аля: "dd if=myawesomework of=/dev/sda bs=512 skip=10"
только не забыть записать где ни будь на бумажке карандашиком, какого размера файл, и какое смещение в блочном устройстве было, что бы потом правильно его считать..
Надо всем опеннет экспертам собраться и изобрести фс с метаданными в тестовом формате и тогда не придется хранить листочки.
> Надо всем опеннет экспертам собраться и изобрести фс с метаданными в тестовом формате и тогда не придется хранить листочки.Там тогда вся файловая система будет состоять из дурак-сам-дурак и места для данных не останется
Да, с точки зрения философии UNIX, крайне желательно, чтобы весь /dev/sda1 был одним большим текстовым файлом, а содержимое разных документов отделялось бы специальными строками в тексте.
В принципе, так и есть. Просто для некоторых оптимизаций, связанных в основном с ограничениями железа, пришлось специальные строки сделать бинарными и структурировать текстовый файл. В остальном же — всё именно как ты описал, и не только на UNIX.
Какой текстовый язык используется. Как насчёт фрагментации. Как насчёт равномерной нагрузки на сектора. Как насчёт вложенности не связных файлов. И много ещё вопросов. ? - на все вопросы оптом.
Вот именно из-за этих вопросов пришлось оптимизировать и структурировать. Впрочем, текст существует только в твоей голове, когда ты на экран смотришь. Для компьютера это просто поток битов, не имеющий смысла.
> В принципе, так и есть. Просто для некоторых оптимизаций, связанных в основном с ограничениями железа, пришлось специальные строки сделать бинарными и структурировать текстовый файл.Ну да, если считать бинарь специально структурированным текстом, то получается, что все файлы текстовые.
Так давным давно уже> 0x1C FS File separator End of file. Or between a concatenation of what might otherwise be separate files.
> 0x1D GS Group separator - between sections of data. Not needed in simple data files.
> 0x1E RS Record separator End of a record or row.
> 0x1F US Unit separator Between fields of a record, or members of a row ( aka FieldSeparator).
Остаётся определиться что является неделимой единицей и как из них создавать новые знания.
Не получится - процессор неграмотных.
Если объектная СУБД не тянет технически и в бэкенд берет sql СУБД, то нужны подобного рода костыли и прокси для легаси.
Дело не в "не тянет технически" (наоборот, достаточно очевидно, что хранить документы в реляционном движке менее эффективно, чем в документном, не говоря уже о том, что отказоустойчивость в постгресе сделать гораздо сложнее, чем в монге). Дело исключительно в лицензии. SSPL запрещает продавать облачные mongo as a service без согласия авторов монги, и поэтому считается несвободной.
Вот! Насчёт лицензии согласен.
А как насчёт mongoAPI?
Sql гибче в плане запросов.
Задача проекта - как раз спрятать от программистов SQL за API Mongo
Задача проекта ничего не прятать, а дать монгистам иллюзию, что они работают на монге
Возвращаемся к профессионализму программиста, который не может напрямую общаться с бэкэндом.
Программист он же как обезьянка ... Дали ему фреймвок - он на нём и пишет ... Нифига не разбираясь в языке ...
Дали ему ORM - он будет дёргать в цикле 100500 вызовов из одной таблицы, не подозревая что есть SQL.Мне вот только интересно, когда postgre сделает прослойку и для MySQL и для SQLite ? Типа для Oracle уже доделали.
> Типа для Oracle уже доделали.это русские сделали - потому что оракла им теперь как своих ушей не видать.
А вовсе не потому что работает. (Там где ставят ораклы - не бывает примитивных кейсов и малонагруженных системок на полтора юзверя, где эта штука могла бы как-то работать.)Так что правильный ответ - никогда, потому что никому не уперлось.
Да и как показал опыт яндекса - не так уж это и просто, обеспечить совместимость с mysql по протоколу даже на элементарном уровне, не умея половины того что тот умеет.
Зайдите на HH. Там в основном таких программистов ищут. И наверное находят.
Вместо приложения монгооператор? Тетеньки будут не довольны. Излишние требования к оператору.
Задача проекта прервать лицензию и дать работать легаси под свободной лицензией. Остаётся вопрос с правами на mongoapi. Подменять один апи другим это и есть костыль.
Это не костыль, а вполне легитимный паттерн, описанный в одной фундаментальной книжке по дизайну софта. Но ты книг не читал, поэтому тебе всё это костылями кажется.
Начал я читать одного такого модного автора, который ратовал за максимальное упрощение функций, чтобы много их было мелких. Мне не понравилась концепция. В меня уже что-то летит?
Не понравилась — не пользуйся. Летит — уворачивайся.
Не уворачиваться - вполне легитимный паттерн.
Ну пройдись гибким SQLем по графу, потом расскажешь впечатления. Не пойми меня неправильно, это _можно_ сделать на SQL, но запросы выходят уж больно кучерявые, на несколько страниц. С документами дело обстоит чуть лучше, но это пока в структуру слабоструктурированных документов не нужно нырять.
Вероятно вам досталась не нормализованная БД.
Нормализация хороша только в теории. На практике же, денормализация — известный и часто применяемый инструмент оптимизаций.
Ну например запись со структурой сущность - апсвязь - даунсвязь не подходит? Количество связей можно увеличить.
Кроме двусвязного списка есть ещё и другие структуры данных. Подходит он или нет — зависит только, исключительно и целиком от данных как таковых и их применения в программе.
Хорошо. Даунсвязь это блоб хранящий переменное число связей и требующий обработчик.
Где будет выполняться обработчик? Как обеспечить изоляцию и атомарность транзакций, репликацию, конкурентную запись?
Некоторые базы позволяют писать расширения(плагины). Поэтому возможно есть возможность написать расширение которое будет парсить этот блоб.
Бывают задачи, когда требуется доступ к данным уже имеющимся в различном представлении.
Можно, конечно, плодить десятки DAG на Airflow. И если речь о терабайтах - это даже оправдано. А можно иметь и то и другое в одной БД, сразу доступное для обновления витрин.
И ещё туда пару десятков терабайт картинок засунуть, вместо S3-совместимого хранилища. Потому что удобно.
И кэши там держать, вместо редиса. Удобно же.
И очереди, вместо кролика/кафки. Аргумент тот же.
Именно так. Поднимать конфлюент ради передачи сотни сообщений в сутки - бессмысленно. Так же как кешировать гигабайт в редисе или ради пару сотен картинок по 200К поднимать хранилище.Я, простите, именно с этого и начинал, что на терабайтах - оправдано и правильно, то для гигабайтов - стрельба из пушки по воробьям.
И поэтому ради вебсайта на сотню пользователей поднимать дополнительно к постгресу монгу - поссориться с головой, что искрене пытаетесь сделать Вы )
> Именно так. Поднимать конфлюент ради передачи сотни сообщений в сутки - бессмысленно. Так же как кешировать гигабайт в редисе или ради пару сотен картинок по 200К поднимать хранилище.Легко. Особенно когда у админа уже есть за плечами минимальный опыт и готовые плейбуки/чарты.
> И поэтому ради вебсайта на сотню пользователей поднимать дополнительно к постгресу монгу - поссориться с головой
Еще бы узаконить извращённые формы насилия над теми, кто все собирает на таком вот дендрофекале, в случае, если проект выстрелит и им начнут пользоваться более 3.5 пользователей. Потому что тогда переделывать уже поздно, и остается только в качестве утешения искать автора и натягивать ему глаз на опу.
> Легко. Особенно когда у админа уже есть за плечами минимальный опыт и готовые плейбуки/чарты.и любую проблему это владелец молотка и нулевого опыта рассматривает как гвоздь.
Кстати с каких пор девляпс стал админом? Админ бы в первую очередь подумал что ему нахрен не нужен еще один сложный сервис - отдельная единица администрирования, за которой надо отдельно следить и вовремя менять воду в поилке и выносить лоток.
Ты точно не админ.
> в случае, если проект выстрелит и им начнут пользоваться более 3.5 пользователей.
открою тебе страшный секрет - если проект делался под трех с половиной пользователей а потом выстрелил не себе в ногу - его переделывают. Потому что упрется он не в неправильную монгу (которую ты как раз вполне мог бы заменить на единственно-правильную в любой момент, если бы в этом было дело), а как раз в дизайн решения самого ядра проекта.
Одно не понимаю: зачем так извращаться? SQL — это одно, NoSQL — совершенно другое. Нужен заменитель NoSQL на шару в облаке? Так нужно запилить аналог MongoDB, на том же Go, но без привязки к РСУБД с их SQL. Не думаю, что это прямо какой-то Rocket Science. Тем более что Mongo была долго открытой, её внутреннее устройство, алгоритмы и API хорошо известны, это не какой-то чёрный ящик вроде Oracle Database. А попытки скрестить ужа с ежом — так и не дадут настоящую монгу с её киллер-фичами(среди которых отсутствие SQL плюс, а не минус, для некоторых) на выходе.
> не дадут настоящую монгу с её киллер-фичами(среди которых отсутствие SQL плюс, а не минус, для некоторых)Ну тогда главную киллер фичу они и реализовали
> Так нужно запилить аналог MongoDB, на том же Go, но без привязки к РСУБД с их SQL. Не думаю, что это прямо какой-то Rocket Science.Напоминает тех чуваков, которые делали чат. Тоже думали что это не рокет сайнс, а потом пошли задачи поддержки чатов на десятки тысяч человек и там начались прям ньюансы. И всё оказалось прям не очень просто.
Чем то даже напоминает переписывальщиков всего на раст тоже думают что это не рокет сайнс, а потом чего-то не входит каменный цветок.
> Чем то даже напоминает переписывальщиков всего на раст тоже думают что это не рокет сайнс, а потом чего-то не входит каменный цветок.Хы, как Вы ловко... И за растовцев подумали (телепат, что ли? просто не встречал ни одного их заявления "это легко! Поэтому сейчас перепишем!") и потом за правду выдаете ложное утверждение про каменный цветок. Аж так не выходит, что всё новое нативное в андроиде собираются писать на расте вместо си/плюсов. Наверное им нравится каменные цветки через это самое выдавливать. И tor'овцы на них глядючи так хотят. И амазоновцы со своим Firecracker'ом туда же лезут. И уже много их таких. Все извращенцы, один Вы Д'Артаньян. Извините, ошибся - вас тут много таких мушкетеров.
> Одно не понимаю: зачем так извращаться?Чтобы за лицуху не дернули
> Чтобы за лицуху не дернулиДля этого надо зайти на https://db-engines.com/en/systems и выбрать под свою задачу подходящую СУБД с подходящей лицензией, а не лепить троллейбус из буханки.
> Для этого надо зайти на https://db-engines.com/en/systems и выбрать под свою задачу подходящую СУБД с подходящей лицензией, а не лепить троллейбус из буханки.Аха, и переписать весь накопившийся софт завязанный на монгу...
Тогда плати. Коготок увяз - всей птичке пропасть.
> Тогда плати. Коготок увяз - всей птичке пропасть.Гениально! Какие же все вокруг "бараны"...
Вы в новость то воткнули?!
Да, особенно вот в это:
> На текущем этапе развития FerretDB поддерживает подмножество возможностей MongoDBА Вы?
> А Вы?Гоняем на CI/CD в гамме, пока что все Ок... на продакшене пока все на 4-й монге
используй монгу 4й версии. В отличие от этого хлама, она хотя бы поддерживает ВСЕ свои команды, а не угадай где тут рыбу заворачивали.И работает предсказуемо, а не утыкается в 100% cpu load как мы тут имели щастье наблюдать с постгрезом (ух ты, я и не знал что так можно).
> используй монгу 4й версии.Так и есть, но альтернатива тоже не помешает там где скорость не нужна
и скорость, и полная совместимость, и полноценный fault tolerant cluster, и нормальное шардирование...(последние два пункта в постгрезном исполнении это... такое себе)
И получается что в лучшем случае годится для своего любимого проекта. Который как раз вполне можно перенести на что-то другое, если уж приспичило отказываться от четвертой - поскольку вероятнее всего именно монга ему не особенно-то была и нужна.
> и скорость, и полная совместимость, и полноценный fault tolerant cluster, и нормальное шардирование...Да не все проекты на таком скэйле, до фига умников которые тащат в зависимости монгу (а то как же, как у всех) где она по большому счету нафиг не нужна, не понимая разницы между документ vs key/value storage отмазываясь что типа на будующее там, хотя сами проекты в принципе не скэйлэбл...
"приятно иметь дело с ди6илами"... спасибо что напомнил.В целом да, вот для них это и сделали. Тех кому нафиг не нужна document database вовсе, а просто "нам надо хранить в базке жсон, значит монго!" И лучше в этот код не заглядывать, а то глазыньки лопнут. И уж тем более ну нафиг его чинить.
Да, для таких решение самое то, особенно если половину данных они и так хранят в постгре потому что в тот раз "у нас же таблица - нам нужно еще и sql, как у всех" (вспоминая онлиофис с его единственной таблицей)
И вот такого контингента - мильен с тыщами, в отличие от тех кому на самом деле от монги что-то надо.
И админ у них такой же, поэтому монга с ее...э...е...нетривиальной авторизацией проигрывает постгрезу еще и в этом.А копипаста со стековерфлова почти вся будет работать.
За 10 лет в профессии работал из реляц БД с Postgres, Firebird, MySQL. У PG кривенько сделана кластеризация (Patroni всякие нужны), и привет из 90х, что все на подпроцессах вместо многопоточки. В остальном - огромнейшее количество фич, куча настроек, которые можно потвикать пож свою нагрузку. Последние несколько лет в банкинге видел либо Oracle, либо Postgres/PostgresPro. А после того, как оракл ушёл с рынка, вообще без вариантов.
Наверное поэтому - https://www.postgresqltutorial.com/postgresql-tutorial/postg.../
Здравствуйте, это Bing. Я могу помочь вам найти информацию о возможностях NoSQL в PostgreSQL. Вот краткий ответ из результатов поиска в Интернете:PostgreSQL поддерживает JSON и другие функции NoSQL, такие как встроенная поддержка XML и пары ключ-значение с HSTORE. Он также поддерживает индексирование данных JSON для более быстрого доступа⁴. PostgreSQL может работать как реляционная и как документоориентированная база данных⁵. PostgreSQL имеет преимущества перед другими SQL базами данных с открытым исходным кодом, такими как MySQL, в плане производительности, надежности и гибкости².
Источник: беседа с Bing, 05.04.2023(1) PostgreSQL vs. MySQL - сравнение, особенности и отзывы. https://fb.ru/article/437280/postgresql-vs-mysql---sravnenie... Получен доступ 05.04.2023.
(2) Postgres NoSQL лучше, чем MongoDB? - Хабр. https://habr.com/ru/post/272735/ Получен доступ 05.04.2023.
(3) Чем PostgreSQL лучше других SQL баз ... - Хабр. https://habr.com/ru/post/282764/ Получен доступ 05.04.2023.
(4) PostgreSQL vs. MySQL - сравнение, особенности и отзывы. https://bing.com/search?q=%d0%92%d0%be&#... Получен доступ 05.04.2023.
(5) Основы проектирования баз данных – сравнение PostgreSQL, Cassandra и .... https://habr.com/ru/company/otus/blog/451042/ Получен доступ 05.04.2023.