Если вам вдруг кажется, что я защищаю MongoDB, пожалуйста, прочитайте дисклеймер в конце статьи.
Новый тренд
Я работаю в софтверной индустрии больше лет, чем прилично говорить, но всё равно на мою долю пришлась лишь малая часть трендов, которые ударили по нашей отрасли. Я был свидетелем роста 4GL, AOP, Agile, SOA, Web 2.0, AJAX, блокчейна… список бесконечный. Каждый год появляются новые тенденции. Некоторые быстро угасают, а другие принципиально меняют способы разработки ПО.
Вокруг каждого нового тренда создаётся некое всеобщее волнение: люди или сами прыгают в лодку, или видят шум, генерируемый другими — и идут за толпой. Этот процесс кодифицирован компанией Gartner в цикле хайпа. Хотя и спорный, но этот график примерно описывает, что происходит с технологиями, прежде чем они в итоге станут полезными для использования.
Но время от времени появляется (или случается второе пришествие, как в данном случае) новая инновация, движимая лишь одной конкретной её реализацией. В случае NoSQL хайп был сильно обусловлен появлением и стремительным подъёмом MongoDB. Не MongoDB запустила этот тренд: на самом деле в крупных интернет-компаниях начались проблемы с обработкой больших объёмов данных, которые и привели к возвращению нереляционных БД. Общее движение стартовало с таких проектов, как Bigtable от Google и Cassandra от Facebook, но именно MongoDB стала самой известной и доступной реализацией базы данных NoSQL, к которой имели доступ большинство разработчиков.
Примечание: вы можете подумать, что я смешиваю документные БД с колоночными БД, хранилищами ключей/значений или любым из многочисленных других типов хранилищ данных, которые попадают под общее определение NoSQL. И вы правы. Но в то время царил хаос. Все помешались на NoSQL, всем оно стало абсолютно необходимо, хотя многие не видели различий в разных технологиях. Для многих MongoDB стала синонимом NoSQL.
И разработчики набросились на неё. Была довольно заманчивой идея базы данных без схемы, которая магически масштабируется для решения любой проблемы. Около 2014 года казалось, что везде, где ещё год назад использовалась реляционная база данных, такая как MySQL, Postgres или SQL Server, стали разворачивать базы MongoDB. На вопрос почему, вы могли получить ответ от банального «это масштаб веба» до более продуманного «мои данные очень слабо структурированы и хорошо вписываются в базу данных без схемы».
Важно помнить, что MongoDB и базы данных документов в целом решают ряд проблем с традиционными реляционными базами данных:
- Строгая схема: с реляционной базой данных, если у вас динамически сформированные данные, вы вынуждены либо создать кучу случайных «разных» столбцов данных, впихнуть туда блобы данных или использовать конфигурацию EAV… у всего этого значительные недостатки.
- Трудность масштабирования: если данных настолько много, что они не помещаются на один сервер, MongoDB предлагала механизмы, позволяющие масштабировать их на нескольких машинах.
- Сложные модификации схемы: никаких миграций! В реляционной базе данных изменение структуры БД может стать огромной проблемой (особенно когда данных становится очень много). MongoDB смогла значительно упростить процесс. И сделало его настолько лёгким, что вы можете просто обновлять схему на ходу и очень быстро двигаться дальше.
- Производительность записи: производительность MongoDB была хорошей, особенно при грамотной настройке. Даже конфигурация MongoDB из коробки, за которую её часто критиковали, демонстрировала некоторые впечатляющие показатели производительности.
Все риски на вас
Потенциальные преимущества MongoDB были огромны, особенно для определённых классов проблем. Если прочитать вышеприведённый список без понимания контекста и не имея опыта, то может сложиться впечатление, что MongoDB действительно революционная СУБД. Единственная проблема заключалась в том, что перечисленные выше преимущества сопровождались рядом оговорок, некоторые из которых указаны ниже.
Справедливости ради, никто в 10gen/MongoDB Inc. не скажет, что названное далее неправда, это просто компромиссы.
- Потеря транзакций: транзакции являются основной особенностью многих реляционных баз данных (не всех, но большинства). Транзакционность означает, что вы можете выполнять несколько операций атомарно и можете гарантировать, что данные останутся согласованными. Конечно, с базой данных NoSQL транзакционность может быть в рамках одного документа или вы можете использовать двухфазные коммиты, чтобы получить транзакционную семантику. Но вам придётся самому реализовать эту функциональность… что может быть сложной и трудоёмкой задачей. Часто вы не сознаёте проблемы, пока не увидите, что данные в БД попадают в недопустимые состояния, потому что невозможно гарантировать атомарность операций. Примечание: многие мне сообщили, что в прошлом году в MongoDB 4.0 появились транзакции, но с рядом ограничений. Вывод из статьи остаётся прежним: оцените, насколько технология соответствует вашим нуждам.
- Потеря реляционной целостности (внешние ключи): если в ваших данные есть отношения, то вам придётся применять их в приложении. Наличие БД с соблюдением этих отношений снимет значительную часть работы с приложения и, следовательно, с ваших программистов.
- Отсутствие возможности применять структуру данных: строгие схемы иногда становятся большой проблемой, но это также и мощный механизм хорошего структурирования данных, если грамотно их использовать. Документные БД, такие как MongoDB, обеспечивают невероятную гибкость схемы, но эта гибкость снимает ответственность за сохранение данных в чистоте. Если вы не позаботитесь о них, то в конечном итоге придётся писать в приложении много кода для учёта данных, которые хранятся не в той форме, какую вы ожидаете. Как часто говорят в нашей компании Simple Thread… приложение когда-нибудь перепишут, а данные будут жить вечно. Примечание: MongoDB поддерживает проверку схемы: она полезна, но не предоставляет те же гарантии, что в реляционной БД. Прежде всего, добавление или изменение проверки схемы не влияет на существующие данные в коллекции. Вы сами должны убедиться, что обновляете данные в соответствии с новой схемой. Решайте сами, достаточно ли этого для ваших нужд.
- Собственный язык запросов / потеря экосистемы инструментов: появление SQL стало абсолютной революцией, и с тех пор ничего не изменилось. Это невероятно мощный язык, но и довольно сложный. Необходимость конструировать запросы к БД на новом языке, состоящем из фрагментов JSON, расценивается как большой шаг назад людьми, имеющими опыт работы с SQL. Существует целая вселенная инструментов, которые взаимодействуют с базами данных SQL: от IDE до инструментов отчётности. Переход к базе данных, которая не поддерживает SQL, означает, что вы не можете использовать большинство этих инструментов или вам нужно перевести данные в SQL, чтобы их использовать, а это может оказаться сложнее, чем вы думаете.
Многие разработчики, которые обратились к MongoDB, не очень понимали компромиссы, и часто ныряли с головой, устанавливая её в качестве основного хранилища данных. После такого зачастую было невероятно сложно вернуться назад.
Что можно было сделать иначе?
Не все прыгали головой вперед и врезались в дно. Но немало проектов устанавливали базу MongoDB туда, куда она просто не подходила — и им придётся жить с ней ещё немало лет. Если бы эти организации потратили некоторое время и методично обдумали выбор технологий, то многие сделали бы иной выбор.
Как выбрать подходящую технологию? Было несколько попыток создать систематический фреймворк для оценки технологий, такие как «Фреймворк для внедрения технологий в софтверные организации» и «Фреймфорк для оценки программных технологий», но мне кажется, что это излишняя сложность.
Многие технологии можно разумно оценить, задав всего два основных вопроса. Проблема заключается в поиске людей, которые могут ответственно на них ответить, потратив время на поиск ответов и без предвзятости.
Если вы не сталкиваетесь с какой-то проблемой, вам не нужен новый инструмент. Точка.
Вопрос 1: Какие проблемы я пытаюсь решить?
Если вы не сталкиваетесь с какой-то проблемой, вам не нужен новый инструмент. Точка. Не нужно искать решение, а затем придумывать проблему. Если вы не столкнулись с проблемой, которую новая технология не решает значительно лучше, чем ваша существующая технология, то здесь нечего обсуждать. Если вы рассматриваете возможность использования этой технологии, потому что видели, как её используют другие, то подумайте, с какими проблемами они сталкиваются, и спросите, есть ли у вас такие проблемы. Легко принять технологию, потому что её используют другие, трудность заключается в понимании, сталкиваетесь ли вы с теми же проблемами.
Вопрос 2: Чего я лишаюсь?
Это, безусловно, более трудный вопрос, потому что придётся копаться и хорошо понять как старую, так и новую технологию. Иногда вы не можете по-настоящему понять новую, пока не построите что-то с её помощью или у вас не появится сотрудник, имеющий такой опыт.
Если у вас нет ни того, ни другого, то имеет смысл подумать о минимально возможных инвестициях для определения ценности этого инструмента. И если вы сделаете инвестиции, насколько трудно будет отменить решение?
Люди всегда всё портят
Пытаясь ответить на эти вопросы как можно беспристрастнее, помните одну вещь: вам придётся бороться с человеческой природой. Существует ряд когнитивных искажений, которые необходимо преодолеть, чтобы эффективно оценить технологию. Вот лишь несколько:
- Эффект присоединения к большинству — все о нём знают, но всё равно с ним трудно бороться. Просто убедитесь, что технология действительно соответствует вашим реальным потребностям.
- Эффект новизны — многие разработчики склонны недооценивать технологии, с которыми работали в течение длительного времени, и переоценивать преимущества новой технологии. Не только программисты, все подвержены этому когнитивному искажению.
- Эффект положительных характеристик — мы склонны видеть то, что есть, и упускаем из виду то, что отсутствует. Это может привести к хаосу в сочетании с эффектом новизны, поскольку вы не только по своей сути переоцениваете новую технологию, но и игнорируете её недостатки.
Объективная оценка даётся непросто, но понимание основных когнитивных искажений поможет принять более рациональные решения.
Резюме
Когда появляется некая инновация, нужно с большой осторожностью ответить на два вопроса:
- Этот инструмент решает реальную проблему?
- Хорошо ли мы понимаем компромиссы?
Если вы не можете уверенно ответить на эти два вопроса, сделайте несколько шагов назад и подумайте.
Так была ла MongoDB вообще правильным выбором? Конечно, да; как и в большинстве инженерных технологий, это зависит от множества факторов. Среди тех, кто ответил на эти два вопроса, многие извлекли пользу из MongoDB и продолжают её извлекать. Кто же этого не сделал, надеюсь, получили ценный и не слишком болезненный урок о движении по циклу хайпа.
Дисклеймер
Хочу уточнить, что я не испытываю ни любви, ни ненависти к MongoDB. Просто у нас не было таких проблем, для решения которых лучше всего подходит MongoDB. Я знаю, что 10gen/MongoDB Inc. поначалу действовала очень смело, установив небезопасные значения по умолчанию и продвигая MongoDB везде (особенно на хакатонах) в качестве универсального решения для работы с любыми данными. Вероятно, это было плохое решение. Но оно подтверждает описанный здесь подход: эти проблемы можно было обнаружить очень быстро даже при поверхностной оценке технологии.
Комментарии (64)
trir
31.03.2019 23:39+1OSM использует модель EAV и уже десять лет прекрасно живёт на PostgreSQL — а данных у них до хрена
vics001
01.04.2019 03:59Это не так уж и до хрена — 100 GB упакованных и 1 TB Postgis. Если говорить про OSM, то специально написанная база для OSM Overpass живет гораздо лучше и быстрее и обрабатывает гораздо более сложные запросы.
Хотя Postgres уже давно является достаточно быстрой NoSql Базой с jsonb, массивами, индексами GIN, Gist, hstore, jsonb, что как раз и используется в OSM.nvv
01.04.2019 07:331TB не мало, надо учитывать размер их аудитории и поток запросов
vics001
01.04.2019 11:35Это много и очень круто для 1 сервера, но надо понимать, что у postgresql до сих пор нет из коробки шардирования и простой failover конфигурации. Из-за этого в том же OSM, мы не можем раскидать планету на 5-6 серверов и синхронизировать их раздельно, а рано или поздно придется разбивать по геометрии, хотя до этого возможно еще лет 10.
menstenebris
01.04.2019 08:48+1Локально overpass не ставил. А вот postgis со всей планетой ставил. Работает крайне быстро с плоской схемой сгенерированной через osm2pgsql.
gbatrak
01.04.2019 07:15Упущено еще одно преимущество.
Отсутствие ORM слоя при работе с MongoDB значительно ускоряет скорость разработки.
Иногда это критеческое преимущество.nvv
01.04.2019 07:27Поддержка и развитие такого продукты может быть значительно сложнее (логика работы с данными усложняется, как правило, и многое из того что есть в реляционных СУБД придётся реализовывать самим).
Magic_B
01.04.2019 07:44Верно, что написать продукт сложнее. Но ничего реализовывать не надо, все уже сделано до нас! Я использую монгу с ее первых версий, как и Elasticsearch. Могу с полной ответственностью заявить, что никакого припоста производительности или еще каких-то значимых преимуществ перед реляционными ДБ у нее нет! Если разработчик начинает ее использовать как РДБ, а он именно так и сделает, т.к. еще плохо знаком с документами, то точно спилит свой сук! Основная проблема не в монге, а в понимании документов, их проектирования и использования! Это своя наука, и при правильном применении, вам нафиг эти РДБ не нужны, нет таких задач, которые не сделает та и сделает другая БД. Есть кривое или продуманное решение задачи программистом! Как-то так...
AEP
01.04.2019 18:08По реляционным СУБД существует куча хороших учебников. А по документным — неплохо было бы найти и прочитать несколько хороших книг, в которых бы были изложены best practices. Можно ссылочки?
Magic_B
02.04.2019 08:54Не встречал… Поищите, наверняка есть. Могу только советы дать из личного опыта
Magic_B
01.04.2019 07:46Не соглашусь, что его нет, у меня он есть! :) А ORM Вы и в реляционнках опустить можете.
sved
01.04.2019 11:13Никто не заставляет использовать ORM.
Но в большинстве случаев ORM таки ускоряет скорость разработки. Не забываем, что хороший софт это тот, который легко читать, а не тот которые легко писать.
YemSalat
03.04.2019 09:18Отсутствие ORM слоя при работе с MongoDB
1) Как ужe написали, использование ОРМ не является обязательным при работе с реляционками
2) Для монги есть, например, Mongoose
VioletGiraffe
01.04.2019 09:44Когда я щупал MongoDB, меня не устроила производительность на относительно небольших объёмах данных (когда индекс мог бы влезать целиком в RAM), и ещё расстроили крайне ограниченные возможности server-side выполнения запросов (выборка / вставка / апдейт по сложным условиям, зависящим от значений полей). Но всё остальное было очень удобно, разрабатывать под MongoDB быстро.
sved
01.04.2019 11:10Столкнулся с монгой 5 лет назад. И тогда в упор не мог понять: зачем кто-то её использует?
Иногда на собеседованиях просят рассказать про достоинства и недостатки MongoDB.
В таких случаях я всегда теряюсь: мммм… достоинства… ну… эээ… можно неструктурированные данные хранить… в общем-то и всё.
О недостатках же я мог говорить часами: совершенно невероятный язык запросов с которым очень сложно работать и который никто не знает, недостаток тулов для работы (Intelij Idea в то время Mongo не поддерживала), невозможность проинтегрировать с 3-rd party библиотеками заточенными под SQL базы (разные ORM, логирование, репликаторы, миграторы, quartz, репортинг, и пр. пр. ), медленная агрегация, нет транзакций, куча непонятных ограничений, сложность в администрировании.
Дамы и господа, пожалуйста, скажите какие технические преимущества имеет монга?
Разрывает любопытство.Magic_B
01.04.2019 11:32В статье было уже сказано, что транзакции поддерживаются с версии 4.0. Что касается достоинств и недостатков, тут нужно понимать с какой позиции Вы смотрите. Если с позиции реляционных БД, но недостатков, наверное, можно много насчитать, если с позиции Key-Value, то же самое, например скорость и т.д. Примитивно преимущество любой СУБД относительно другой, заключается в способе хранения данных, например, key-value для быстрого доступа по ключу, колоночные, для быстрых вставок, документоориентированные для хранения больших структур, а реляционные для удержания целостности данных и легкого построения запросов.
Посмотрите язык запросов Elasticsearch, я думаю, большое количество людей когда увидят как выглядит несложный запрос в этой БД, заплюют ее. НО! Просто так ничего не происходит. Во всякой особенности той или иной БД есть смысл.
Выше nvv правильно заметил, что в NoSQL нужно все контролировать и учитывать. Для РСУБД этот контроль на себя берет сама СУБД.
Итак, достоинство. В MongoDB можно реализовать сложную схему данных с массивами, вложенными объектами, вложенными массивами вложенных документов с вложенными массивами вложенных документов и т.д. Это дает возможность в итоге безо всяких джойнов достать все и сразу. Представим, что у Вы разрабатываете интернет-магазин, и проектируете страницу товара, тогда у вас будет документ товара, в котором будет все, что есть на этой странице (грубо): производитель с логотипом, вся галерея картинок, все характеристики, отзывы с постраничной отдачей, наличие и т.д. И все это Вы загрузите из одного документа, т.е. 1 запрос без каких либо джойнов. Недостаток же заключается в сложности проектирования, поддержания целостности и разработки.
Paskin
01.04.2019 11:47А потом вам понадобится найти все страницы с определенным логотипом, к которым не обращались уже неделю — и вы застрелитесь.
Magic_B
01.04.2019 11:51Вы верно заметили, что NoSQL — это не SQL! Мне не понадобится, т.к. я это не проектировал. Ну а все же, если понадобится, я либо создам новую коллекцию и буду писать туда статистику обращений, либо заюзаю колоночную БД для такой записи.
Если ПО разрабатывается по принципу, "а вдруг понадобится", то следует использовать РСУБД!
Paskin
01.04.2019 11:59ПО не разрабатывается по принципу «а вдруг понадобится» — оно разрабатывается поэтапно. И заказчик, которому вы сделали систему OLTP, теперь хочет добавить online-аналитику и offline- отчеты. И вы начинаете городить отдельный warehouse, ETL и тому подобное.
Magic_B
01.04.2019 12:11Конечно, все так. Но Вы же уже считали эту статистику. Тогда берете и юзаете в той же монге Aggregation Framework… В общем и целом за 10 лет практики с NoSQL я не столкнулся с какими либо подобными задачами. Все так же как и везде… Просто я стараюсь при проектировании учесть многое, тем самым сократив расходы на стандартные функции, а не стандартные решаю так же как все...
Paskin
01.04.2019 12:18Aggregation Framework — как же без него… Только тормозит он безбожно, требует кучу памяти и писать на нем никто не хочет. По сравнению с MySQL на обьемах в миллион-два записей — как разработка, так и рантайм быстрее на порядок (реально, в 10 раз!)
Magic_B
01.04.2019 12:53Совершенно верно! Я его тоже не использую, как и любые ее возможности поиска. Вообще говоря, монга не очень для каких либо деяний. Я за документы! Храню в ней сырые данные, потом заливаю их в другие БД, которые уже и используются для частых запросов. Все сугубо индивидуально от задачи.
Например, из вышеприведенного примера можно собирать из монги или другой БД сырые данные, класть их в описанный документ. Я так и поступаю. Там и статистику можно закомитить и что угодно вообще! Без отдельного warehouse, ETL и тому подобного… Схема — всему голова! И правильное применение.
Paskin
01.04.2019 15:00Тогда напрашивающийся следующий шаг — просто избавиться от Монго и хранить «сырые данные» в той же базе (в смысле — той же технологии, не обязательно на том же сервере). Будет всего один комплект утилит, библиотек, скриптов и т.п.
Magic_B
02.04.2019 09:00Отнюдь… Я как-раз таки выбрал именно монгу для хранения таких данных. Моя ORM прекрасно работает с множественными БД, поэтому никаких проблем не испытываю. Почему именно Монго? Я слишком привык к документам, уже и не могу понять как можно хранить данные в таблицах, это не очень удобно, хотя понадежнее с точки зрения целостности и последующей обработки… Но с этими проблемами еще не сталкивался. И второе, Монго имеет достаточно постоянное время вставки, а так же простую репликацию и шардинг.
Paskin
02.04.2019 11:10Никто не заставляет вас «хранить данные в таблицах». Все современные реляционки умеют хранить JSON.
По поводу тех или иных фич Монго — в том-то и дело, что все они есть сегодня и в реляционках — плюс «еще чуть-чуть» в виде SQLMagic_B
02.04.2019 11:13А зачем мне хранить из в JSON-столбцах, если я могу их хранить в документах? Кстати, индексы умеют строить РСУБД для таких столбцов?
movl
02.04.2019 12:03На счет всех не скажу, но PostgreSQL точно умеет, как-то даже пользовался этим, преобразовывал JSON данные в другие представления, для сбора статистики и индексы неплохо все ускоряли. Но синстаксис для JSON данных там тоска, агрегации в монге для таких задач были бы на много проще.
postgrespro.ru/docs/postgrespro/11/datatype-json#JSON-INDEXINGMagic_B
02.04.2019 12:07Ну ничего себе! Документы пустили корни в РСУБД! Что бы это значило? Я думаю это значит, что документы — это очень удобно и глупо ими не пользоваться! Но все же считаю, что JSON-столбцы, тем более с индексами — это костыль...
movl
02.04.2019 12:36Так давно уже пустили. С выводами согласен: иногда документы это очень удобно. Но в РСУБД документы удобно только писать, производить над ними манипуляции и искать что-то не так удобно (по крайней мере в PostgreSQL), в этом недостаток.
Согласно принципу KISS это, конечно, костыль, но внедрение другой технологии для решения узкого спектра задач, тоже может быть костылем, и при не заданных условиях неизвестно какой хуже. Помню как мне приходилось однажды обеспечивать согласованность данных между mongodb и mysql, так это прям костылище какой-то получился. Короче тут как посмотреть. О чем, собственно, статья и была.Magic_B
02.04.2019 12:49Как бы правильно все говорите… И все логично рассуждают тут, прям сложно не согласиться, что NoSQL — Г… НО(это именно "но", а не продолжение предыдущего слова)! Лучше пользоваться той технологией, которой умеешь хорошо пользоваться! Я, например, умею очень хорошо пользоваться документами. РСУБД я уже подзабыл за 8 лет… Я помню, что когда начинал изучать документы, тоже не мог в голове уложить, как с помощью "ЭТОГО" можно что-то решить!? Прям рассуждал как все… Но прошло время и стало все понятно. Я желаю всем здесь собравшимся, хотя бы в качестве факультатива применить на небольших проектах сначала и другие технологии, например документоориентированные СУБД, сейчас их палным-пално всяких разных (MongoDB, Elasticsearch, in-memory документы: Tarantool, Apache Ignite и т.д.)
Paskin
02.04.2019 16:29В MySQL это делается через виртуальные поля (указатели на элемент в JSON-иерархии). Очень удобно — определил такое поле и для него работают все SQL-операции и функции.
Не факт что это единственный способ — но это то, что работает у нас.
Yo1
03.04.2019 10:03до определенного объема схема всему голова, но когда объем подрастает такой подход становится жопой всему.
у нас на хадупе примерно такой подход опробовали. сначала «документы» хранили в habse, начало тормозить на сканах, переделали на развесистые avro объекты в parquet. теперь жопа. источников все больше, бизнес требует реалтаймы и джоины с новыми источниками на лету. аналитики требую полноценные таблицы, которые можно скармливать нормальным инструментам анализа, типа sas dataminer.
т.е. полная жопа в итоге.Magic_B
03.04.2019 10:37Я решаю этот вопрос, выделением частей объекта. Т.е. у одна сущность может храниться во множестве коллекций. Как я уже писал, это сырые данные. Для пользователей эти данные коммитятся в другую базу, в которой и уже работает поиск и т.п.
movl
01.04.2019 19:41Но не всегда можно предполагать такие задачи. Магазин может не самый удачный пример, там как правило удобнее реляционные модели. Но у меня есть пример лучше. Для игр типа «3 в ряд», мы использовали MongoDB для сохранения всей информации о конфигурации уровней, о пользователях, транзакциях и статистике по уровням, и там же хранился конфиг, одна запись на всю коллекцию, просто потому что так было удобнее всего.
Основное тут, конечно, коллекция с информацией о пользователях, все остальное это мелочи. Уровни и конфиг выгружались в кэш сервера. Статистика и транзакции только писались. В записях коллекции пользователя содержались какие-то громадные структуры с прогрессом, с друзьями, с достижениями, со всякими таймерами, подарками и т. д. Вся эта информация была очень индивидуальной и для нормализации потребовала бы большого количества отношений, но так как поиск по этой коллекции (кроме нескольких агрегаций для внутренних задач и поиска по нескольким полям первого уровня) практически был не нужен, то смысл в нормализованной структуре данных терялся.
sved
01.04.2019 11:51Ну здесь вы подразумеваете, что абстрактная реляционная СУБД в вакууме не может быстро вставлять или быстро читать по ключу или хранить большие структуры.
Имхо это очень смелое утверждение. Для этого существуют бенчмарки.
Далее, способ хранения данных у всех БД разный. Но было бы странно отождествлять реляционность и способ хранения. Это немного ортогональные понятия.
Ну и наконец: что такого плохого в джойнах? Тем более что ORM часто делают их прозрачными для разработчиков.
shai_hulud
01.04.2019 11:40Горизонтальное масштабирование, отсутствие схемы, скорость записи, батчинг любых операций, качественные драйвера/клиенты без нативных зависимостей (привет Oracle), и конечно же хранение деревьев (документов). Последнее качество не монги, а всех Document DB, но там где в реляционной БД 100500 джоинов и таблиц, у документной БД это будет документ. А все мы, программисты, оперируем объектами и иерархиями объектов, а не таблицами.
Релиционные БД хорошо решают небольшой класс задач: OLTP, Accounting итд. Для остального приходится лепить костыли.sved
01.04.2019 12:01Горизонтальное масштабирование
Вы действительно утверждаете что ни одна реляционная СУБД не способна горизонтально масштабироваться?
скорость записи
Это утверждение подкрепляется цифрами? Или опять будет мантра про «медленные» транзакции?
батчинг любых операций
Не совсем понятно что имеется ввиду, но батчинг есть и в других БД.
качественные драйвера/клиенты без нативных зависимостей (привет Oracle)
Опять не понятно, что имеется ввиду. Оракловские драйвера для java весьма юзабельны. Про нативные зависимости тоже не понял.shai_hulud
01.04.2019 14:31Вы действительно утверждаете что ни одна реляционная СУБД не способна горизонтально масштабироваться?
Приведите пример РСУБД с шардированием.
> Это утверждение подкрепляется цифрами?
vladmihalcea.com/mongodb-facts-80000-insertssecond-on-commodity-hardware
Не совсем понятно что имеется ввиду, но батчинг есть и в других БД.
Приведите пример РСУБД которая поддерживает батчинг SELECT/UPDATE запросов с разными критериями.
Опять не понятно, что имеется ввиду. Оракловские драйвера для java весьма юзабельны. Про нативные зависимости тоже не понял.
Оракловские драйвера для .NET «Oracle.DataAccess.dll» это обертка над unmanaged DLL. Которые еще надо инсталлировать в ОС. Где клиенты для монги написаны на тех языках, где их используют.
Вопрос портабельности для современных РСУБД решен только у SQLite и еще пары экзотических вариантов. Все остальные хотят инсталляцию или «хотя бы» инициализацию. В то время как Mongo DB требует только исполняемого файла и конфига.sved
01.04.2019 15:54+1Приведите пример РСУБД с шардированием.
Гуглите <имя БД> 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 то есть несколько популярных. В чём проблема установить БД тоже непонятно.
Монго надо в коде инициализировать скорее.
shai_hulud
01.04.2019 16:27Гуглите <имя БД> sharding и будет вам счастье. Вы почти наверняка найдёте решение для вашей любимой БД. Даже если нет специализированного решения наверняка найдётся соответствующий тул под generic sql.
Бремя доказывания лежит не на мне.
Примерно любая, не? В jdbc батчинг апдейтов предусмотрен, драйвера имеют возможность эту возможность реализовать (и реализовывают). Я знаю в jdbc для MySQL были параметры для батчинга на чтение.
Опять же, примеры.
В Java такой проблемы точно нет.
Отлично что Oracle хотя бы поддерживает свою платформу. А парни из Mongo нормально поддерживают все популярные, комюнити остальное.
В чём проблема установить БД тоже непонятно.
Портабильное приложение всегда удобнее устанавливаемого. Проблема в том, что его надо ставить каждому разработку, тестировщику, билд машине итд.
Этого удобство уровня туалетной бумаги, сложно доказать удобство, тем кто ей ни разу не использовал. Газета, листья, кора выполняют аналогичную функцию, но не так удобно.
fukkit
01.04.2019 16:05Оракловские драйвера для .NET «Oracle.DataAccess.dll» это обертка над unmanaged DLL.
Как будто это что-то плохое
0xd34df00d
01.04.2019 17:12Ну, конкретно скрестить оракл с конкретно хаскелем, например — это просто ад и погибель.
Хотя это проблемы оракла. С постгресом, мусклом и скулайтом всё отлично работает.
eefadeev
01.04.2019 14:18То что вы пишете про деревья и т.п. было задолго до реляционных БД. Почитайте про «иерархические БД».
Проблема РСУБД в том, что они изначально создавались для тех применений, где критически важной является целостность данных. И в связи с эти они крайне плохо масштабируются (ACID, CAP и вот это вот всё). То есть если ваша БД «вылезла» за пределы производительности вашего сервера — у вас начинаются проблемы. Их пытаются решать партиционированием, шардированием и репликацией (и, надо признать, весьма успешно), но тут же теряется целостность (где-то она не принципиальна).
Ну и ещё есть (по ощущениям) вот какой фактор: сейчас стало «не модно» серьёзно проектировать и все хотят «из коробки» получить быстрое решение под свои задачи. И здесь любая подходящая специализированная система легко «уделывает» любую универсальную. Именно поэтому, я думаю, развелось такое количество разнообразных NoSQL (а по факту — NoACID) СУБД. Каждая создавалась под достаточно узкий круг задач.
YemSalat
03.04.2019 09:23Дамы и господа, пожалуйста, скажите какие технические преимущества имеет монга?
В статье жe написано — шардирование из коробки и большая скорость записи.Magic_B
03.04.2019 10:40Что значит большая? Скорость вставки/обновления данных в монге постоянная. Она не быстрее, чем в СКЛ, она относительно ПОСТОЯННА. Если вы используете монго как мастер-бд, то имейте ввиду, что с накоплением данных, поиск по ним будет усложняться. Я советую использовать монгу, как хранилище для сырых данных с добавлением/обновлением и простым поиском.
fukkit
01.04.2019 11:24Монга прекрасна для проектов, живущих в условиях сильной неопределенности, условных «стартапов», у которых есть идея, наброски реализации, которые сами не знают, чего они (и их пользователи!) захотят послезавтра и к чему они придут в плане данных. Нет достаточно квалифицированных специалистов, чтобы в техническом и экономическом плане проработать продукт на бумаге до начала реализации. Набираем экспертов по объявлениям и в скрамно-аджайловом темпе поскакали навстречу неизвестности!
К этому всему должны прилагаться наполеоновские планы по количеству хранимых данных. (так как на небольших базах двинуть схему — и проблема, соответственно, не большая).
Такой подход очень часто оправдан с точки зрения бизнеса, как по затратам, так и по времени до первого выхода на рынок.
Со временем такие проекты начинают сталкиваться с хорошо известными проблемами, приведшими человечество к реляционным базам данных: обеспечивать консистентность данных на стороне клиента — медленно и глупо, на стороне сервера приложения — трудоёмко и совсем не так весело, как запиливать фичушички и свистелки на ранних стадиях развития.
Таким образом, Монга хороша и полезна там, где она действительно хорошая и полезна, исходя из требований проекта, а вовсе не везде, куда её бездумно и безудержно суют (кстати, по личным ощущениям — уже гораздо меньше, хайп NoSQL, к счатью, поутих).Magic_B
01.04.2019 11:33Наоборот, проще на РСУБД накидать прототип. Господа, боюсь, вы не совсем верно понимаете суть свободной схемы, см. мои предыдущие комментарии.
fukkit
01.04.2019 12:45Я, может быть, чего-то и не совсем верно понимаю в теоретической стройности, но я часто сталкиваюсь с проектами, выбравшими Монгу когда-то на старте и теперь страдающими от необходимости костылить обработку взаимосвязей (они то, сюрприз-сюрприз, из предметной области никуда не делись) вне сервера, героически переизобретая алгоритмы, используемые в серверах РСУБД.
Magic_B
01.04.2019 12:55Хайп, не лучшый механизм выбора решения. Мне вот потребовалось 8 лет, чтобы осознать что, как и когда надо использовать… Тоже на этой хайпе был сначала!
Paskin
01.04.2019 11:53Главная проблема Монго и других подобных систем — что в свое время вместо NoSchema зачем-то сделали NoSQL. И еще одна — то что в Монго любой запрос уже после первого выражения теряет связь с исходными коллекциями и тянет все обьекты в память — там где реляционки просто двигают курсоры, пользуясь индексами.
Magic_B
01.04.2019 11:59Очень сомнительное утверждение. А Вы уже использовали монгу и другие подобные системы? В монге есть курсоры
Paskin
01.04.2019 12:13До лета планируем выкинуть последние два сервера — они пока используются как write-only, с репликацией в MySQL к которому уже делаются запросы.
Еще раз — в Монго после самого первого подзапроса вы можете забыть про индексы — даже если они были определены в оригинальных коллекциях. И курсоры там активируются только после вычисления всего запроса — в то время, как реляционки могут вычислять каждую следующую строку результата когда она понадобится.
Alex_Builder
01.04.2019 18:59Лично я тоже знаю одних бедолаг, которые повелись на модно-молодежный NoSQL, но столкнулись по их словам лишь с неуправляемым и непереносимым хаосом после стандартизованного и легко переносимого порядка.
Сейчас откатились обратно на SQL. Правда пришлось писать нехилую отдельную программку для перевода.
Все-таки нормализация данных ( до разумного уровня ) полезна во всех смыслах. И с точки зрения и хранения и с точки зрения обработки.Paskin
01.04.2019 22:21Мы сейчас как раз боремся с тяжким наследием адептов «модно-молодежного»… Оригинальная система была содрана аутсорсерами с какого-то другого их проекта. Они довольно обоснованно предполагали, что пока/если дело дойдет до серьезных обьемов данных — сдохнет либо ишак либо падишах, а за законченный проект платят уже сейчас.
Поразвлекавшись с добавлением индексов и всяким тюнингом — мы это дело забросили, в Монго только пишем транзакции (совсем выкинуть его пока нельзя из-за кучи API для разных клиентов) — оттуда через утилиту-репликатор MOMY копируем в MYSQL и запросы уже идут к нему.
sheknitrtch
К стати, в прошлом году сайт The Guardian переехал с MongoDB на PostgreSQL и отлично себя чувствует. Самое интересное, что после переезда они хранят JSONB документы в колонке PostgreSQL таблицы. То есть, производительность обработки JSONB в этой реляционной БД не хуже чем в Mongo.
RoykerZen
То же самое делаю у себя на работе: JSONB в PostgreSQL. Пока полет нормальный.
Paskin
Мы конечно не Гардиан — но переехали на MySQL пл тому же принципу и очень довольны результатом.
mkll
Небезызвестный Parse Server (наследство почившего в бозе parse.com), использующий MongoDB, при локальном хранении данных на пользовательских мобильных устройствах держит JSON в колонках sqlite.
YemSalat
А вы предлагаете пользователям на мобилки монгу поставить?
mkll
Я к тому, что хранение документов в колонках реляционной СУБД — уже повсеместная практика.
mkll
А, ну и еще можно добавить, что Parse Server из коробки использует монгу по-сути как реляционную СУБД.