В одном pet-проекте, которым я сейчас эпизодически занимаюсь (возможно, о нем расскажу позже), в качестве БД используется MongoDB. И я заметил, что стал гореть с того, как организован язык запросов в Mongo. Кто не знает, там используется не традиционный всем известный и прекрасный SQL, а язык собственной разработки - MongoDB Query Language aka MQL.
В основе этого языка лежит оперирование json-структурой документов (это типа записи с SQL базах), которые лежат в коллекциях (типа таблицы). В своем запросе к БД нужно описывать критерии полей в json-документах в собственной нотации MQL. Например, если представить, что у нас есть коллекция users, то чтобы получить количество пользователей, сгруппированных по некоему полю provider, имеющих updatedAt позже 1 октября 2024 года, у которых в поле email есть подстрока "gmail", то нужно будет написать вот такой запрос:
db.users.aggregate([ { $match: { updatedAt: { $gt: new Date("2024-10-01") }, email: { $regex: "gmail", $options: "i" } } }, { $group: { _id: "$provider", count: { $sum: 1 } } } ])
Сравните это с SQL-версией такого же запроса:
SELECT provider, COUNT(*) as count FROM users WHERE updatedAt > '2024-10-01' AND email LIKE '%gmail%' GROUP BY provider;
Скажите же, что SQL более лаконичен и понятен, чем эти count: { $sum: 1 } и $regex: "gmail", $options: "i". Ну скажите, я же не один это вижу?
Почему другие NoSQL базы типа Elasticsearch, CouchDB, Cassandra поддержали SQL, а Mongo нет?
Конечно, я не могу залезть в голову к команде разработки Mongo и понять всех причин. Я пытался найти ответ в интернетах, но не нашел информации из первых уст. Когда я начал писать пост, то хотел сказать, что в их решении усматриваю желание создать дополнительный фактор удержания своих пользователей - юзеры УЖЕ изучили особенности самой Mongo и ее языка, зачем им этот "медленный" SQL? Расчет на то, что при прочих равных они будут выбирать Mongo из-за того, что уже инвестировали время в ее изучение.
Однако с другой стороны такое решение создает доп. барьер для новых пользователей - им придется инвестировать больше времени в изучение, переучивать команду и т.д. С продуктовой точки зрения барьеры для использования продукта лучше устранять, чем создавать.
Штош, вот такое решение приняла команда MongoDB, и оно не помешало инструменту получить популярность по всему миру. Однако кто знает, какова могла быть популярность, поддержи они SQL - тут остается только гадать.
P.S. Кстати, популярность могла быть и намного меньше, потому что для поддержки SQL, вероятно, им пришлось бы принять много архитектурных компромиссов и тогда пострадали бы другие характеристики - например, производительность. И это бы сказалось на качестве, и как следствие, популярности инструмента.