Комментарии 69
Хотя Postgres уже давно является достаточно быстрой NoSql Базой с jsonb, массивами, индексами GIN, Gist, hstore, jsonb, что как раз и используется в OSM.
1TB не мало, надо учитывать размер их аудитории и поток запросов
Отсутствие ORM слоя при работе с MongoDB значительно ускоряет скорость разработки.
Иногда это критеческое преимущество.
Поддержка и развитие такого продукты может быть значительно сложнее (логика работы с данными усложняется, как правило, и многое из того что есть в реляционных СУБД придётся реализовывать самим).
Верно, что написать продукт сложнее. Но ничего реализовывать не надо, все уже сделано до нас! Я использую монгу с ее первых версий, как и Elasticsearch. Могу с полной ответственностью заявить, что никакого припоста производительности или еще каких-то значимых преимуществ перед реляционными ДБ у нее нет! Если разработчик начинает ее использовать как РДБ, а он именно так и сделает, т.к. еще плохо знаком с документами, то точно спилит свой сук! Основная проблема не в монге, а в понимании документов, их проектирования и использования! Это своя наука, и при правильном применении, вам нафиг эти РДБ не нужны, нет таких задач, которые не сделает та и сделает другая БД. Есть кривое или продуманное решение задачи программистом! Как-то так...
Но ведь иногда критично сделать очень быстро, например что бы получить финансирование для стартапа.
Не соглашусь, что его нет, у меня он есть! :) А ORM Вы и в реляционнках опустить можете.
Но в большинстве случаев ORM таки ускоряет скорость разработки. Не забываем, что хороший софт это тот, который легко читать, а не тот которые легко писать.
Отсутствие ORM слоя при работе с MongoDB
1) Как ужe написали, использование ОРМ не является обязательным при работе с реляционками
2) Для монги есть, например, Mongoose
Иногда на собеседованиях просят рассказать про достоинства и недостатки MongoDB.
В таких случаях я всегда теряюсь: мммм… достоинства… ну… эээ… можно неструктурированные данные хранить… в общем-то и всё.
О недостатках же я мог говорить часами: совершенно невероятный язык запросов с которым очень сложно работать и который никто не знает, недостаток тулов для работы (Intelij Idea в то время Mongo не поддерживала), невозможность проинтегрировать с 3-rd party библиотеками заточенными под SQL базы (разные ORM, логирование, репликаторы, миграторы, quartz, репортинг, и пр. пр. ), медленная агрегация, нет транзакций, куча непонятных ограничений, сложность в администрировании.
Дамы и господа, пожалуйста, скажите какие технические преимущества имеет монга?
Разрывает любопытство.
В статье было уже сказано, что транзакции поддерживаются с версии 4.0. Что касается достоинств и недостатков, тут нужно понимать с какой позиции Вы смотрите. Если с позиции реляционных БД, но недостатков, наверное, можно много насчитать, если с позиции Key-Value, то же самое, например скорость и т.д. Примитивно преимущество любой СУБД относительно другой, заключается в способе хранения данных, например, key-value для быстрого доступа по ключу, колоночные, для быстрых вставок, документоориентированные для хранения больших структур, а реляционные для удержания целостности данных и легкого построения запросов.
Посмотрите язык запросов Elasticsearch, я думаю, большое количество людей когда увидят как выглядит несложный запрос в этой БД, заплюют ее. НО! Просто так ничего не происходит. Во всякой особенности той или иной БД есть смысл.
Выше nvv правильно заметил, что в NoSQL нужно все контролировать и учитывать. Для РСУБД этот контроль на себя берет сама СУБД.
Итак, достоинство. В MongoDB можно реализовать сложную схему данных с массивами, вложенными объектами, вложенными массивами вложенных документов с вложенными массивами вложенных документов и т.д. Это дает возможность в итоге безо всяких джойнов достать все и сразу. Представим, что у Вы разрабатываете интернет-магазин, и проектируете страницу товара, тогда у вас будет документ товара, в котором будет все, что есть на этой странице (грубо): производитель с логотипом, вся галерея картинок, все характеристики, отзывы с постраничной отдачей, наличие и т.д. И все это Вы загрузите из одного документа, т.е. 1 запрос без каких либо джойнов. Недостаток же заключается в сложности проектирования, поддержания целостности и разработки.
Вы верно заметили, что NoSQL — это не SQL! Мне не понадобится, т.к. я это не проектировал. Ну а все же, если понадобится, я либо создам новую коллекцию и буду писать туда статистику обращений, либо заюзаю колоночную БД для такой записи.
Если ПО разрабатывается по принципу, "а вдруг понадобится", то следует использовать РСУБД!
Конечно, все так. Но Вы же уже считали эту статистику. Тогда берете и юзаете в той же монге Aggregation Framework… В общем и целом за 10 лет практики с NoSQL я не столкнулся с какими либо подобными задачами. Все так же как и везде… Просто я стараюсь при проектировании учесть многое, тем самым сократив расходы на стандартные функции, а не стандартные решаю так же как все...
Совершенно верно! Я его тоже не использую, как и любые ее возможности поиска. Вообще говоря, монга не очень для каких либо деяний. Я за документы! Храню в ней сырые данные, потом заливаю их в другие БД, которые уже и используются для частых запросов. Все сугубо индивидуально от задачи.
Например, из вышеприведенного примера можно собирать из монги или другой БД сырые данные, класть их в описанный документ. Я так и поступаю. Там и статистику можно закомитить и что угодно вообще! Без отдельного warehouse, ETL и тому подобного… Схема — всему голова! И правильное применение.
Отнюдь… Я как-раз таки выбрал именно монгу для хранения таких данных. Моя ORM прекрасно работает с множественными БД, поэтому никаких проблем не испытываю. Почему именно Монго? Я слишком привык к документам, уже и не могу понять как можно хранить данные в таблицах, это не очень удобно, хотя понадежнее с точки зрения целостности и последующей обработки… Но с этими проблемами еще не сталкивался. И второе, Монго имеет достаточно постоянное время вставки, а так же простую репликацию и шардинг.
По поводу тех или иных фич Монго — в том-то и дело, что все они есть сегодня и в реляционках — плюс «еще чуть-чуть» в виде SQL
А зачем мне хранить из в JSON-столбцах, если я могу их хранить в документах? Кстати, индексы умеют строить РСУБД для таких столбцов?
postgrespro.ru/docs/postgrespro/11/datatype-json#JSON-INDEXING
Ну ничего себе! Документы пустили корни в РСУБД! Что бы это значило? Я думаю это значит, что документы — это очень удобно и глупо ими не пользоваться! Но все же считаю, что JSON-столбцы, тем более с индексами — это костыль...
Согласно принципу KISS это, конечно, костыль, но внедрение другой технологии для решения узкого спектра задач, тоже может быть костылем, и при не заданных условиях неизвестно какой хуже. Помню как мне приходилось однажды обеспечивать согласованность данных между mongodb и mysql, так это прям костылище какой-то получился. Короче тут как посмотреть. О чем, собственно, статья и была.
Как бы правильно все говорите… И все логично рассуждают тут, прям сложно не согласиться, что NoSQL — Г… НО(это именно "но", а не продолжение предыдущего слова)! Лучше пользоваться той технологией, которой умеешь хорошо пользоваться! Я, например, умею очень хорошо пользоваться документами. РСУБД я уже подзабыл за 8 лет… Я помню, что когда начинал изучать документы, тоже не мог в голове уложить, как с помощью "ЭТОГО" можно что-то решить!? Прям рассуждал как все… Но прошло время и стало все понятно. Я желаю всем здесь собравшимся, хотя бы в качестве факультатива применить на небольших проектах сначала и другие технологии, например документоориентированные СУБД, сейчас их палным-пално всяких разных (MongoDB, Elasticsearch, in-memory документы: Tarantool, Apache Ignite и т.д.)
Не факт что это единственный способ — но это то, что работает у нас.
у нас на хадупе примерно такой подход опробовали. сначала «документы» хранили в habse, начало тормозить на сканах, переделали на развесистые avro объекты в parquet. теперь жопа. источников все больше, бизнес требует реалтаймы и джоины с новыми источниками на лету. аналитики требую полноценные таблицы, которые можно скармливать нормальным инструментам анализа, типа sas dataminer.
т.е. полная жопа в итоге.
Основное тут, конечно, коллекция с информацией о пользователях, все остальное это мелочи. Уровни и конфиг выгружались в кэш сервера. Статистика и транзакции только писались. В записях коллекции пользователя содержались какие-то громадные структуры с прогрессом, с друзьями, с достижениями, со всякими таймерами, подарками и т. д. Вся эта информация была очень индивидуальной и для нормализации потребовала бы большого количества отношений, но так как поиск по этой коллекции (кроме нескольких агрегаций для внутренних задач и поиска по нескольким полям первого уровня) практически был не нужен, то смысл в нормализованной структуре данных терялся.
Имхо это очень смелое утверждение. Для этого существуют бенчмарки.
Далее, способ хранения данных у всех БД разный. Но было бы странно отождествлять реляционность и способ хранения. Это немного ортогональные понятия.
Ну и наконец: что такого плохого в джойнах? Тем более что ORM часто делают их прозрачными для разработчиков.
Релиционные БД хорошо решают небольшой класс задач: OLTP, Accounting итд. Для остального приходится лепить костыли.
Горизонтальное масштабирование
Вы действительно утверждаете что ни одна реляционная СУБД не способна горизонтально масштабироваться?
скорость записи
Это утверждение подкрепляется цифрами? Или опять будет мантра про «медленные» транзакции?
батчинг любых операций
Не совсем понятно что имеется ввиду, но батчинг есть и в других БД.
качественные драйвера/клиенты без нативных зависимостей (привет Oracle)
Опять не понятно, что имеется ввиду. Оракловские драйвера для java весьма юзабельны. Про нативные зависимости тоже не понял.
Вы действительно утверждаете что ни одна реляционная СУБД не способна горизонтально масштабироваться?
Приведите пример РСУБД с шардированием.
> Это утверждение подкрепляется цифрами?
vladmihalcea.com/mongodb-facts-80000-insertssecond-on-commodity-hardware
Не совсем понятно что имеется ввиду, но батчинг есть и в других БД.
Приведите пример РСУБД которая поддерживает батчинг SELECT/UPDATE запросов с разными критериями.
Опять не понятно, что имеется ввиду. Оракловские драйвера для java весьма юзабельны. Про нативные зависимости тоже не понял.
Оракловские драйвера для .NET «Oracle.DataAccess.dll» это обертка над unmanaged DLL. Которые еще надо инсталлировать в ОС. Где клиенты для монги написаны на тех языках, где их используют.
Вопрос портабельности для современных РСУБД решен только у SQLite и еще пары экзотических вариантов. Все остальные хотят инсталляцию или «хотя бы» инициализацию. В то время как Mongo DB требует только исполняемого файла и конфига.
Приведите пример РСУБД с шардированием.
Гуглите <имя БД> sharding и будет вам счастье. Вы почти наверняка найдёте решение для вашей любимой БД. Даже если нет специализированного решения наверняка найдётся соответствующий тул под generic sql.
Неужели вы думаете что разрабочики MongoDB — единственные кто до этого додумался?
vladmihalcea.com/mongodb-facts-80000-insertssecond-on-commodity-hardware
К чему это? Здесь нет никакого сравнения.
пример РСУБД которая поддерживает батчинг SELECT/UPDATE запросов с разными критериями
Примерно любая, не? В jdbc батчинг апдейтов предусмотрен, драйвера имеют возможность эту возможность реализовать (и реализовывают). Я знаю в jdbc для MySQL были параметры для батчинга на чтение.
Оракловские драйвера для .NET «Oracle.DataAccess.dll» это обертка над unmanaged DLL. Которые еще надо инсталлировать в ОС. Где клиенты для монги написаны на тех языках, где их используют.
В Java такой проблемы точно нет.
Вопрос портабельности для современных РСУБД решен только у SQLite и еще пары экзотических вариантов. Все остальные хотят инсталляцию или «хотя бы» инициализацию. В то время как Mongo DB требует только исполняемого файла и конфига.
Не совсем понятно сравнение с SQLite который embeded если вам надо embeded то есть несколько популярных. В чём проблема установить БД тоже непонятно.
Монго надо в коде инициализировать скорее.
Гуглите <имя БД> sharding и будет вам счастье. Вы почти наверняка найдёте решение для вашей любимой БД. Даже если нет специализированного решения наверняка найдётся соответствующий тул под generic sql.
Бремя доказывания лежит не на мне.
Примерно любая, не? В jdbc батчинг апдейтов предусмотрен, драйвера имеют возможность эту возможность реализовать (и реализовывают). Я знаю в jdbc для MySQL были параметры для батчинга на чтение.
Опять же, примеры.
В Java такой проблемы точно нет.
Отлично что Oracle хотя бы поддерживает свою платформу. А парни из Mongo нормально поддерживают все популярные, комюнити остальное.
В чём проблема установить БД тоже непонятно.
Портабильное приложение всегда удобнее устанавливаемого. Проблема в том, что его надо ставить каждому разработку, тестировщику, билд машине итд.
Этого удобство уровня туалетной бумаги, сложно доказать удобство, тем кто ей ни разу не использовал. Газета, листья, кора выполняют аналогичную функцию, но не так удобно.
Оракловские драйвера для .NET «Oracle.DataAccess.dll» это обертка над unmanaged DLL.
Как будто это что-то плохое
Проблема РСУБД в том, что они изначально создавались для тех применений, где критически важной является целостность данных. И в связи с эти они крайне плохо масштабируются (ACID, CAP и вот это вот всё). То есть если ваша БД «вылезла» за пределы производительности вашего сервера — у вас начинаются проблемы. Их пытаются решать партиционированием, шардированием и репликацией (и, надо признать, весьма успешно), но тут же теряется целостность (где-то она не принципиальна).
Ну и ещё есть (по ощущениям) вот какой фактор: сейчас стало «не модно» серьёзно проектировать и все хотят «из коробки» получить быстрое решение под свои задачи. И здесь любая подходящая специализированная система легко «уделывает» любую универсальную. Именно поэтому, я думаю, развелось такое количество разнообразных NoSQL (а по факту — NoACID) СУБД. Каждая создавалась под достаточно узкий круг задач.
Дамы и господа, пожалуйста, скажите какие технические преимущества имеет монга?
В статье жe написано — шардирование из коробки и большая скорость записи.
Что значит большая? Скорость вставки/обновления данных в монге постоянная. Она не быстрее, чем в СКЛ, она относительно ПОСТОЯННА. Если вы используете монго как мастер-бд, то имейте ввиду, что с накоплением данных, поиск по ним будет усложняться. Я советую использовать монгу, как хранилище для сырых данных с добавлением/обновлением и простым поиском.
Она не быстрее, чем в СКЛ
Т.к. монге не надо делать почти никаких проверок (не нарушены ли релейшены и т.п.) — то она во многих кейсах работает быстрее чем relational базы на запись.
Вы совершенно правы! Тут надо пометку сделать, что для простых запросов...
Мне вот интересна судьба тех, кто попытался внедрить монгу в фин.сектор и потерял несколько трансакций…
К этому всему должны прилагаться наполеоновские планы по количеству хранимых данных. (так как на небольших базах двинуть схему — и проблема, соответственно, не большая).
Такой подход очень часто оправдан с точки зрения бизнеса, как по затратам, так и по времени до первого выхода на рынок.
Со временем такие проекты начинают сталкиваться с хорошо известными проблемами, приведшими человечество к реляционным базам данных: обеспечивать консистентность данных на стороне клиента — медленно и глупо, на стороне сервера приложения — трудоёмко и совсем не так весело, как запиливать фичушички и свистелки на ранних стадиях развития.
Таким образом, Монга хороша и полезна там, где она действительно хорошая и полезна, исходя из требований проекта, а вовсе не везде, куда её бездумно и безудержно суют (кстати, по личным ощущениям — уже гораздо меньше, хайп NoSQL, к счатью, поутих).
Наоборот, проще на РСУБД накидать прототип. Господа, боюсь, вы не совсем верно понимаете суть свободной схемы, см. мои предыдущие комментарии.
Очень сомнительное утверждение. А Вы уже использовали монгу и другие подобные системы? В монге есть курсоры
Еще раз — в Монго после самого первого подзапроса вы можете забыть про индексы — даже если они были определены в оригинальных коллекциях. И курсоры там активируются только после вычисления всего запроса — в то время, как реляционки могут вычислять каждую следующую строку результата когда она понадобится.
Сейчас откатились обратно на SQL. Правда пришлось писать нехилую отдельную программку для перевода.
Все-таки нормализация данных ( до разумного уровня ) полезна во всех смыслах. И с точки зрения и хранения и с точки зрения обработки.
Поразвлекавшись с добавлением индексов и всяким тюнингом — мы это дело забросили, в Монго только пишем транзакции (совсем выкинуть его пока нельзя из-за кучи API для разных клиентов) — оттуда через утилиту-репликатор MOMY копируем в MYSQL и запросы уже идут к нему.
Была ли MongoDB вообще правильным выбором?