Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 72
А что значит документно-ориентированная?
Есть строчка «Поддержка общих форматов данных (MongoDB) JSON (Document), Key-Value, XML — (Postgres) JSON (Document), Key-Value, XML». Или вы что-то большее вкладываете в это понятие?
Есть строчка «Поддержка общих форматов данных (MongoDB) JSON (Document), Key-Value, XML — (Postgres) JSON (Document), Key-Value, XML». Или вы что-то большее вкладываете в это понятие?
Гм, да, вы обвиняете Postgres в том что он строго типизированный. В общем случае это скорее плюс, нежели минус.
select * from users where (order->>'total')::int > 1000;
Есть функция jsonb_set: www.postgresql.org/docs/9.5/static/functions-json.html. Правда только начиная с 9.5.
Т.к. общепринятый подход — все значимые с позиции бизнес логики поля добавлять в схему.
Это общепринятый для реляционных баз данных. Начиная использовать документные возможности Postgre, мы должны использовать и новые подходы, иначе в большинстве случаев не стоит и заморачиваться.
Да и вообще, документные поля введены скорее как замена EAV-костылей, чем основных схем, где даже Null значение имеет семантику бОльшую чем «пользователь оставил поле пустым»
Вы так говорите, как будто это что-то плохое :) Да, обычная практика для реляционных баз такая, но ведь никто не мешает хранить данные в json, если это имеет смысл. В postgres есть нужные возможности для обоих случаев — и для фиксированной схемы, и для «все данные в json», что только добавляет гибкости. Ниже вон писали, что успешно использовали postgres как json-хранилище безо всяких проблем.
Что же касается «если бы такая функция была сейчас», то она уже есть, хотя и в бета-версии. По надёжности бета-версия постгреса явно обойдёт стабильную монгу :)
Что же касается «если бы такая функция была сейчас», то она уже есть, хотя и в бета-версии. По надёжности бета-версия постгреса явно обойдёт стабильную монгу :)
а закончилось что все рассказывают что в Postgres документные возможности не хуже чем в MongoDB
Хуже. Но, во-первых, есть надежда, что Постгри будет догонять Монгу в этом плане, а, во-вторых, далеко не всегда нужна полноценная работа с документной частью записей, типа быстрого обновления конкретного поля.
Немного оффтоп: а вы уверены, что хотите сделать такую операцию по изменению данных, при то том что вам не гарантируется атомарность её исполнения и в случае ошибки у вас нет возможности определить, к каким записям в базе она была применена, а к каким нет? )
Какой интересный тест. Сравнивать новую версию постгреса (postgresql94-9.4beta1-1) и олд стейбл для монги (mongodb-org-2.6.3-1). Ещё неизвестно с каким движком.
Версия Монги 3.0 вышла 3 марта 2015. Оригинал статьи опубликован 24 февраля 2015.
А сегодня вышла MongoDB 3.2 в которой есть «left outer join» организаваный через $lookup в aggregation framework.
Если быть точным то 3.2 для enterprise была доступно еще раньше, сегодня появилась для остальных.
Если быть точным то 3.2 для enterprise была доступно еще раньше, сегодня появилась для остальных.
Круто, глядишь скоро и валадация с транзакциями появится.
Оу, валидацию уже добавили
docs.mongodb.org/manual/release-notes/3.2/#document-validation
docs.mongodb.org/manual/release-notes/3.2/#document-validation
Если интересно, результаты этого теста для 2.6 и для 3.2
3.2 даже хуже себя показала в плане чтения, но в плане занимаемого места улучшилась
3.2 даже хуже себя показала в плане чтения, но в плане занимаемого места улучшилась
Результаты для 2.6
PID: 762 [RUNTIME: 12-21-15 12:10:22] pg_nosql_benchmark: MongoDB Version 2.6.9
number of rows 300000
PG COPY (ns) 44236255959
PG INSERT (ns) 88188563366
PG SELECT (ns) 2574039893
PG SIZE (bytes) 446840832
MONGO IMPORT (ns) 111660482827
MONGO INSERT (ns) 272375249661
MONGO SELECT (ns) 5165320262
MONGO SIZE (bytes) 1450037248
number of rows 300000
PG COPY (ns) 44236255959
PG INSERT (ns) 88188563366
PG SELECT (ns) 2574039893
PG SIZE (bytes) 446840832
MONGO IMPORT (ns) 111660482827
MONGO INSERT (ns) 272375249661
MONGO SELECT (ns) 5165320262
MONGO SIZE (bytes) 1450037248
Результаты для 3.2
PID: 769 [RUNTIME: 12-21-15 12:30:11] pg_nosql_benchmark: MongoDB Version 3.2.0
number of rows 300000
PG COPY (ns) 43444811405
PG INSERT (ns) 88273595424
PG SELECT (ns) 2189972284
PG SIZE (bytes) 446840832
MONGO IMPORT (ns) 47870636213
MONGO INSERT (ns) 264580483269
MONGO SELECT (ns) 12043545412
MONGO SIZE (bytes) 112893952
number of rows 300000
PG COPY (ns) 43444811405
PG INSERT (ns) 88273595424
PG SELECT (ns) 2189972284
PG SIZE (bytes) 446840832
MONGO IMPORT (ns) 47870636213
MONGO INSERT (ns) 264580483269
MONGO SELECT (ns) 12043545412
MONGO SIZE (bytes) 112893952
Выбирая статью для перевода я понимал, что все кто постоянно использует Монго и очень хорошо относится к ней, воспримут эту информацию в штыки. Тем не менее, в статье не один раз встречается фраза типа «выбрать решение для своих потребностей». У каждой из вышеупомянутых систем есть свои плюсы, равно как и минусы — это вечный спор. А сам факт использования jsonов в Постгрес не может не радовать и не привлекать, хотя бы в качестве эксперимента. Для сравнения, для саморазвития. Тем более, если такое решение подойдет под потребности проекта, на котором преимущественно используется Постгрес.
За статью спасибо, саморазвитие — это хорошо, но также неплохо было бы публиковать актуальную информацию.
Для начала надо чтобы актуальная информация существовала. Свежайшей аналитики еще не видел, увы.
Тем лучше будут видны изменения в более свежей сравнительной характеристике на фоне этой.
Тем лучше будут видны изменения в более свежей сравнительной характеристике на фоне этой.
На главной сайта MongoDB, наверное, уже месяц висел алерт «MongoDB 3.2 is coming» с перечислением всех будущих вкусняшек…
Будем ждать свежего, актуального сравнения, чтобы снова накинуться и растерзать автора =)
Будем ждать свежего, актуального сравнения, чтобы снова накинуться и растерзать автора =)
Это не побуждало многочисленных авторов такого рода сравнений к написанию чего-то нового. А я, увы и ах, не обладаю достаточным багажом знаний, дабы уместно и правильно сопоставлять и комментировать сходства и различии вышеупомянутых баз.
Сравнивать нужно для конкретных задач. Сравнивать фичи — дело неблагодарное, бесполезное и холиваное. Тем более без собственного багажа знаний по сравниваемым объектам.
Великую ценность имеют аргументы по использованию нужного инструмента в определенных условиях. Сравнения инструментов в вакууме не несут пользы.
Великую ценность имеют аргументы по использованию нужного инструмента в определенных условиях. Сравнения инструментов в вакууме не несут пользы.
>У каждой из вышеупомянутых систем есть свои плюсы, равно как и минусы — это вечный спор
Для продуктивного спора нужен контекст а не набор фич.
Для продуктивного спора нужен контекст а не набор фич.
Дело даже не в том. Лично я с удовольствием использую и Монгу и Постгрес, но автор статьи не вникая в суть вопроса пытается строить какие-то таблички с да/нет, которые выглядят в результате притянутыми за уши.
То есть мотив написания статьи примерно такой — «многие люди хвалят Монгу, а я альтернативный чувак, похвалю Постгрес». А в результате фигня получается.
То есть мотив написания статьи примерно такой — «многие люди хвалят Монгу, а я альтернативный чувак, похвалю Постгрес». А в результате фигня получается.
Если автор хотел показать альтернативу, то ему нужно было не писать холиварную статью на тему Postgres vs Mongo, а показать как Postgres позволяет решать задачи, которые я сегодня решаю на Mongo, приведя примеры разнообразных операций, свойственных для работы с документами. И желательно не слишком тривиальных примеров.
Общий месседж статьи остался не понятен. Переходить с Mongo на Postgres после этого я не стану, разве что усомнюсь в компетентности сообщества.
Общий месседж статьи остался не понятен. Переходить с Mongo на Postgres после этого я не стану, разве что усомнюсь в компетентности сообщества.
Вот кстати да, заметил, что многие кто утверждают что postgresql лучше, в процессе разговора выяснялось, что они с монгой либо не знакомы, либо знакомы поверхностно. Так же и с автором jsonb когда он участвовал в радио-т (хоть он и профи в своем деле), утверждал, что сделал «конкурента» монге, но при этом не знал фич монги.
Я около года-двух назад, для себя, делал сравнение — чтобы обновить одно поле json в postgresql, нужно было написать хранимую процедуру которая распаковывала весь json, меняла значение поля, потом запаковывала все обратно. Оно работало неожиданно быстро, но все равно медленней, как минимум, в 10-20 раз чем на монге. barsulka правильно упомянул — где сравнения с обновлением полей, массивов и т.п.? — все то что хорошо работает в монге.
Я около года-двух назад, для себя, делал сравнение — чтобы обновить одно поле json в postgresql, нужно было написать хранимую процедуру которая распаковывала весь json, меняла значение поля, потом запаковывала все обратно. Оно работало неожиданно быстро, но все равно медленней, как минимум, в 10-20 раз чем на монге. barsulka правильно упомянул — где сравнения с обновлением полей, массивов и т.п.? — все то что хорошо работает в монге.
Скорее общий мессадж такой:
1. Если вы используете Postgre как РСУБД, но вам нужны фичи, свойственные документным и(или) key-value СУБД, то не спешите думать о переходе (полностью или частично) на них, не изучив возможности Postgre в этой области.
2. Если вы используете Mongo как документную и(или) key-value СУБД, но вам жутко не хватает фич, свойственных РСУБД, то подумайте о переходе на Postgre.
Обобщая: если вам нужны фичи, свойственные как РСУБД, так и документным и(или) key-value СУБД, то Postgre с двумя «режимами» может оказаться лучшим выбором, чем попытки использовать Mongo как РСУБД или использование двух СУБД.
1. Если вы используете Postgre как РСУБД, но вам нужны фичи, свойственные документным и(или) key-value СУБД, то не спешите думать о переходе (полностью или частично) на них, не изучив возможности Postgre в этой области.
2. Если вы используете Mongo как документную и(или) key-value СУБД, но вам жутко не хватает фич, свойственных РСУБД, то подумайте о переходе на Postgre.
Обобщая: если вам нужны фичи, свойственные как РСУБД, так и документным и(или) key-value СУБД, то Postgre с двумя «режимами» может оказаться лучшим выбором, чем попытки использовать Mongo как РСУБД или использование двух СУБД.
В своем проекте-стартапе я решил перейти на Постгрес с Монго, и это при том, что у меня специфика такая, что данные поступают в большом количестве из внешних источников в JSON виде. Что послужило причиной? Я использую Django и начали мы с Монго, т.к. легко потоки данных в него сохранять. Для этого Монго абсолютно устраивала.
НО появились проблемы: Монго достаточно новая, и мало доков по ней и ответов на Stackoverflow, долго разработка идет. Но главное, что решив локально задачу быстрого сохранения данных в json без создания структуры данных в бд, я лишился возможности использовать почти все модули Джанго, т.к. они все предполагают наличие реляционной базы: нет join и тп. А разработка этих модулей или адаптация их под Монго это долгий и сложный процесс, и не факт что получится.
Вот поэтому перешел на Постгре, хотя это может казаться нелогичным: ведь потом данные разрастутся. Конечно, пришлось пожертвовать некоторой частью собираемых данных, т.к. трудно повторить структуру json в базе, но что делать, берем только то, что нужно. Но с 9.5 есть поддержка Nosql и в случае, если это понадобится, легко можно будет переходить постепенно на нее, не меняя при этом базу на другую.
НО появились проблемы: Монго достаточно новая, и мало доков по ней и ответов на Stackoverflow, долго разработка идет. Но главное, что решив локально задачу быстрого сохранения данных в json без создания структуры данных в бд, я лишился возможности использовать почти все модули Джанго, т.к. они все предполагают наличие реляционной базы: нет join и тп. А разработка этих модулей или адаптация их под Монго это долгий и сложный процесс, и не факт что получится.
Вот поэтому перешел на Постгре, хотя это может казаться нелогичным: ведь потом данные разрастутся. Конечно, пришлось пожертвовать некоторой частью собираемых данных, т.к. трудно повторить структуру json в базе, но что делать, берем только то, что нужно. Но с 9.5 есть поддержка Nosql и в случае, если это понадобится, легко можно будет переходить постепенно на нее, не меняя при этом базу на другую.
Как-то странно читать статью про Mongo 2.6 на следующий день после релиза 3.2 c left join'ом и валидацией.
«left join'ом и валидацией»
Шел 2015 год…
Шел 2015 год…
..., но люди до сих пор забывают текущий год.
В каком году можно будет за 15 минут работы руками развернуть кластер postgresql на шести узлах, в котором данные шардятся на 6 частей, при этом пятикратное резервирование?
А еще, одним нажатием кнопки обновлять postgresql 9.5 до 9.6 на всех узлах, без остановки работы кластера?
Ок, это вопрос про горизонтальное масштабирование, видимо ниже пояса. Скажите, в каком году будет удобный инструмент для table partitioning? Судя по www.postgresql.org/docs/current/interactive/ddl-partitioning.html в том же 2015 году мне всё еще предлагают этим заниматься руками, писать самому триггеры и вот это всё.
А еще, одним нажатием кнопки обновлять postgresql 9.5 до 9.6 на всех узлах, без остановки работы кластера?
Ок, это вопрос про горизонтальное масштабирование, видимо ниже пояса. Скажите, в каком году будет удобный инструмент для table partitioning? Судя по www.postgresql.org/docs/current/interactive/ddl-partitioning.html в том же 2015 году мне всё еще предлагают этим заниматься руками, писать самому триггеры и вот это всё.
>Доступность обучающих ресурсов
>Трудно найти
Вы серьезно??
>Трудно найти
Вы серьезно??
Программирование на стороне сервера | Нет
Доступность обучающих ресурсов | Трудно найти
Вы меня простите, но это не сравнение, а ерунда с запахом холивара.
Кроме того, как и в других подобных статьях, тут ловко обходят стороной такую операцию, как «update одного значения в документе».
Судя по тестам mongodb 2.6 vs 3, версия 3 mongodb должна отставать не более чем в полтора раза, это гораздо менее страшно, чем в 3 раза с mongodb 2.6. Такими темпами скоро её можно будет не брать во внимание. Если бы в Postgres NoSQL появился бы лет 5 назад…
Очень странно видеть такие пункты как:
Легче найти обучения для postgresql, чем для mongodb?
Для mongodb все знают доступный и бесплатный официальный MOOC, а что там есть для postgresql… Ах да, сразу сертификации от EnterpriseDB с ценами от 200$.
Даже сложно определить, что доступнее…
То есть, эта таблица утверждает, что цепочка:
сложнее чем:
Если тут идется про существующие инструменты, то строчку стоило назвать по другому.
К тому же, тогда первый столбик уже давно устарел.
Доступность обучающих ресурсов
Легче найти обучения для postgresql, чем для mongodb?
Для mongodb все знают доступный и бесплатный официальный MOOC, а что там есть для postgresql… Ах да, сразу сертификации от EnterpriseDB с ценами от 200$.
Даже сложно определить, что доступнее…
Простая интеграция с другими источниками данных
То есть, эта таблица утверждает, что цепочка:
Получил данные в JSON -> запихнул их в mongodb
сложнее чем:
разработал схему таблиц для конкретного случая -> получил данные и собрал из них запрос (каким-то образом отложив невалидные и пустые данные) -> выполнил sql запрос
Если тут идется про существующие инструменты, то строчку стоило назвать по другому.
К тому же, тогда первый столбик уже давно устарел.
сложнее чем:
В последнее время всё чаще применяем при начале разработке схему: для новой сущности создаём таблицу с двумя полями: id uuid и raw_data jsonb и запихиваем туда данные. По сути полный аналог коллекций однотипных документов в NoSQL. Дальше по ходу дела анализируем юзкейсы и или часть полей дублируем в новых столбцах возможно в новых таблицах, заполняя их в приложении, а то и в insert/update триггерах, или накладываем индексы и ограничения прямо на jsonb, или тупо оставляем, если значения определенных полей нужны бизнесу только «на посмотреть» — они не участвуют в бизнес-логике приложения, нужны только операторам для принятия решений с неформализованными алгоритмами.
Тогда получается аналогично с MongoDB, причем функционал можно просто взять и перенести.
И там, и там json.
И там, и там json.
часть полей дублируем в новых столбцах возможно в новых таблицах, заполняя их в приложенииПри этом вы переписываете приложение (на новые поля), или за вас это делает orm?
Ведь хранить «перенесенные» поля в json смысла нет, а то и вредно если разойдутся с таблицей.
Какие есть подводные камни такого подхода? Интересуюсь, на случай если мне понадобится posgresql в проекте.
Ближе к переписыванию ORM, чем приложения. При желании интерфейсы объектов модели можно оставлять без изменений, типа get('some_property') или set('some_property'), но обычно сначала происходит такое изменение интерфейса, а лишь потом выделение столбцов на уровне базы данных.
Мы храним, даже если все поля перенесены. По разным причинам, в том числе оптимизация вывода сущностей в API и хранение ввода API как лога. Некоторая денормализация есть конечно, но в одних случаях можно вообще забить, в других достаточно периодических проверок/исправлений, в третьих — проверка при вставке-обновлении в пре-триггерах или констрэйтах. Но как показывает практика, обычно расхождения возникают только при лазании в базу «ручками».
Мы храним, даже если все поля перенесены. По разным причинам, в том числе оптимизация вывода сущностей в API и хранение ввода API как лога. Некоторая денормализация есть конечно, но в одних случаях можно вообще забить, в других достаточно периодических проверок/исправлений, в третьих — проверка при вставке-обновлении в пре-триггерах или констрэйтах. Но как показывает практика, обычно расхождения возникают только при лазании в базу «ручками».
А как насчет поиска по JSON полям в Postgresql? Мне кажется тут с Монгой тягаться сложно.
Есть полнотекстовый поиск и GIN индекс — они себя обычно ведут шустрее простого B-tree.
Если почитать прошлогодний https://www.pgcon.org/2014/schedule/events/696.en.html CREATE INDEX… USING VODKA, то это в принципе должно быть очевидно.
Если читать внимательно хабр, недавно выходила серия (4шт) хороших статей от the_unbridled_goose о специфике разработки документ-ориентированного API на PostgreSQL.
Если почитать прошлогодний https://www.pgcon.org/2014/schedule/events/696.en.html CREATE INDEX… USING VODKA, то это в принципе должно быть очевидно.
Если читать внимательно хабр, недавно выходила серия (4шт) хороших статей от the_unbridled_goose о специфике разработки документ-ориентированного API на PostgreSQL.
Есть чего-то похожее на docs.mongodb.org/manual/reference/operator/query?
Если почитать офф доки PostgreSQL'я http://www.postgresql.org/docs/9.5/static/functions-json.html
То станет понятно что там происходит ручная распаковка jsonb в один из существующих типов, можно даже в табличку или в представление, после чего можно выполнять любые доступные запросы.
То станет понятно что там происходит ручная распаковка jsonb в один из существующих типов, можно даже в табличку или в представление, после чего можно выполнять любые доступные запросы.
Давайте конкретно
JSON
'{«a»:«foo», «c»:{«d»:30}, «b»:«bar»}'
Напишите, пожалуйста, запрос, который вернет boolean значение истинно ли утверждение что c.d>30?
JSON
'{«a»:«foo», «c»:{«d»:30}, «b»:«bar»}'
Напишите, пожалуйста, запрос, который вернет boolean значение истинно ли утверждение что c.d>30?
Бэнчмарк чуть морально устарел, уже есть MongoDB 3.2, c нормальным MVCC.
Горизонтальное масштабирование у MongoDB это большой и толстый кот в мешке, с кучей заморочек, и их не меньше чем у PostgreSQL'я.
По производительности на одну ноду, понятное дело, лидирует PostgreSQL.
Мне вот один товарищ с пеной изо рта пытался доказать что MongoDB это «нереляционная, документо-ориентированная БД» — если бы это было бы действительно так, то в ней бы не использовался банальный B-tree индекс и она не подчинялась бы всем существующим правилам нормализации. По этому разводить документо-ориентированный трёп нет особо то и смысла — это выдуманное понятие, не более чем маркетинговый трюк для привлечения инвестиций.
Нужно понимать что MongoDB строилась по принципу: мы придумаем много новых умных слов, скажем что, мол, такие все инновационные NoSQL подонки, и пофигу что оно нифига не работает, — на нас ведь посыпется дождик вечнозелёных от наивных инвесторов, потом может когда-то починим, если будут громко орать и пускать лучи ненависти. И да, чинят, на самом деле, очень неохотно.
Извините, если оскорбил чувства свято верующих в бесконечное и неосязаемое величие MongoDB, считаю что пора вам спускаться на землю.
Горизонтальное масштабирование у MongoDB это большой и толстый кот в мешке, с кучей заморочек, и их не меньше чем у PostgreSQL'я.
По производительности на одну ноду, понятное дело, лидирует PostgreSQL.
Мне вот один товарищ с пеной изо рта пытался доказать что MongoDB это «нереляционная, документо-ориентированная БД» — если бы это было бы действительно так, то в ней бы не использовался банальный B-tree индекс и она не подчинялась бы всем существующим правилам нормализации. По этому разводить документо-ориентированный трёп нет особо то и смысла — это выдуманное понятие, не более чем маркетинговый трюк для привлечения инвестиций.
Нужно понимать что MongoDB строилась по принципу: мы придумаем много новых умных слов, скажем что, мол, такие все инновационные NoSQL подонки, и пофигу что оно нифига не работает, — на нас ведь посыпется дождик вечнозелёных от наивных инвесторов, потом может когда-то починим, если будут громко орать и пускать лучи ненависти. И да, чинят, на самом деле, очень неохотно.
Извините, если оскорбил чувства свято верующих в бесконечное и неосязаемое величие MongoDB, считаю что пора вам спускаться на землю.
Вот интересно! Как это использование B-tree автоматически делает базу реляционной?
Документарные базы не отменяют необходимость нормализации для создания отношений, как и сами отношения. Суть в том поддерживается ли реляционная модель на уровне движка.
А MongoDB строилась по принципу хранения документов с произвольной структурой с использованием JS и v8.
Я бы советовал вам для начала разобраться в понятиях прежде чем советовать другим спускаться на землю.
Документарные базы не отменяют необходимость нормализации для создания отношений, как и сами отношения. Суть в том поддерживается ли реляционная модель на уровне движка.
А MongoDB строилась по принципу хранения документов с произвольной структурой с использованием JS и v8.
Я бы советовал вам для начала разобраться в понятиях прежде чем советовать другим спускаться на землю.
Потому что B-tree, по определению, хранит ключи которые определяют отношение между существующими сущностями, это помогает получить неглубокое дерево, первые 2-3 три уровня ключей которого могут хранится в оперативке, а остальные на винте. Что собственно позволяет значительно уменьшить количество дисковых операций. Ещё там фигурируют разнообразные cache-oblivious вещи, но это уже тема отдельной статьи.
Так как информация которую хранит B-tree априори требует определения отношений между существующими сущностями — любую СУБД, которая использует его для индексации, можно назвать реляционной.
Если сравнивать с другими структурами, типа lsm-tree(sstable) / R-tree / X-tree / MVP-tree / Fusion-tree, то у них совсем другие задачи, они не хранят отношений и их ключи используются сугубо для адресации. Соответственно их использование совсем не связано с реляционными моделями.
Так как информация которую хранит B-tree априори требует определения отношений между существующими сущностями — любую СУБД, которая использует его для индексации, можно назвать реляционной.
Если сравнивать с другими структурами, типа lsm-tree(sstable) / R-tree / X-tree / MVP-tree / Fusion-tree, то у них совсем другие задачи, они не хранят отношений и их ключи используются сугубо для адресации. Соответственно их использование совсем не связано с реляционными моделями.
Потому что B-tree, по определению, хранит ключи которые определяют отношение между существующими сущностями
Можно с таким определением ознакомиться?
Как это внезапно алгоритм (b-tree) для доступа к записи на двух сильно отличающихся по скорости средах (ram/disk) вдруг стал напрямую связан с отношениями между сущностями?
https://ru.wikipedia.org/wiki/B-дерево
Может стоит научится читать, хотя бы википедию?
B-дерево может применяться для структурирования (индексирования) информации на жёстком диске (как правило, метаданных). Время доступа к произвольному блоку на жёстком диске очень велико (порядка миллисекунд), поскольку оно определяется скоростью вращения диска и перемещения головок. Поэтому важно уменьшить количество узлов, просматриваемых при каждой операции. Использование поиска по списку каждый раз для нахождения случайного блока могло бы привести к чрезмерному количеству обращений к диску, вследствие необходимости осуществления последовательного прохода по всем его элементам, предшествующим заданному; тогда как поиск в B-дереве, благодаря свойствам сбалансированности и высокой ветвистости, позволяет значительно сократить количество таких операций.
Может стоит научится читать, хотя бы википедию?
Таблица сравнений не актуальна для версии монги 3.2. относительно Ограничения данных или Объединения данных. Появились частичные индексы и LeftJoin.
Плюс я бы выпилил такие оценочные строки как «Мощный язык запросов» и т.д.
Плюс я бы выпилил такие оценочные строки как «Мощный язык запросов» и т.д.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Postgres NoSQL лучше, чем MongoDB?