How to become an author
Search
Write a publication
Pull to refresh

Comments 72

UFO just landed and posted this here
А что значит документно-ориентированная?
Есть строчка «Поддержка общих форматов данных (MongoDB) JSON (Document), Key-Value, XML — (Postgres) JSON (Document), Key-Value, XML». Или вы что-то большее вкладываете в это понятие?
Total votes 12: ↑9 and ↓3+6
UFO just landed and posted this here
Гм, да, вы обвиняете Postgres в том что он строго типизированный. В общем случае это скорее плюс, нежели минус.
select * from users where (order->>'total')::int > 1000;
Total votes 21: ↑16 and ↓5+11
UFO just landed and posted this here
UFO just landed and posted this here
Т.к. общепринятый подход — все значимые с позиции бизнес логики поля добавлять в схему.

Это общепринятый для реляционных баз данных. Начиная использовать документные возможности Postgre, мы должны использовать и новые подходы, иначе в большинстве случаев не стоит и заморачиваться.

Да и вообще, документные поля введены скорее как замена EAV-костылей, чем основных схем, где даже Null значение имеет семантику бОльшую чем «пользователь оставил поле пустым»
Total votes 7: ↑6 and ↓1+5
UFO just landed and posted this here
Ну так Postgre уже по факту реляционно-объектно-документная база. В нём общепринято должно быть и то, и другое в зависимости от контекста использования.
Total votes 3: ↑1 and ↓2-1
Вы так говорите, как будто это что-то плохое :) Да, обычная практика для реляционных баз такая, но ведь никто не мешает хранить данные в json, если это имеет смысл. В postgres есть нужные возможности для обоих случаев — и для фиксированной схемы, и для «все данные в json», что только добавляет гибкости. Ниже вон писали, что успешно использовали postgres как json-хранилище безо всяких проблем.

Что же касается «если бы такая функция была сейчас», то она уже есть, хотя и в бета-версии. По надёжности бета-версия постгреса явно обойдёт стабильную монгу :)
Total votes 11: ↑7 and ↓4+3
UFO just landed and posted this here
а закончилось что все рассказывают что в Postgres документные возможности не хуже чем в MongoDB


Хуже. Но, во-первых, есть надежда, что Постгри будет догонять Монгу в этом плане, а, во-вторых, далеко не всегда нужна полноценная работа с документной частью записей, типа быстрого обновления конкретного поля.
Total votes 1: ↑0 and ↓1-1
Немного оффтоп: а вы уверены, что хотите сделать такую операцию по изменению данных, при то том что вам не гарантируется атомарность её исполнения и в случае ошибки у вас нет возможности определить, к каким записям в базе она была применена, а к каким нет? )
Total votes 9: ↑7 and ↓2+5
UFO just landed and posted this here
Неплохо бы в его модели иметь не историю операций для проверки баланса, а баланс, агрегируемый из операций :)
Total votes 3: ↑3 and ↓0+3
UFO just landed and posted this here
UFO just landed and posted this here
Какой интересный тест. Сравнивать новую версию постгреса (postgresql94-9.4beta1-1) и олд стейбл для монги (mongodb-org-2.6.3-1). Ещё неизвестно с каким движком.
Total votes 25: ↑24 and ↓1+23
Версия Монги 3.0 вышла 3 марта 2015. Оригинал статьи опубликован 24 февраля 2015.
Total votes 20: ↑11 and ↓9+2
А сегодня вышла MongoDB 3.2 в которой есть «left outer join» организаваный через $lookup в aggregation framework.
Если быть точным то 3.2 для enterprise была доступно еще раньше, сегодня появилась для остальных.
Total votes 8: ↑8 and ↓0+8
Круто, глядишь скоро и валадация с транзакциями появится.
Total votes 2: ↑2 and ↓0+2
Если интересно, результаты этого теста для 2.6 и для 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

Результаты для 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
This comment wasn’t rated yet0
Выбирая статью для перевода я понимал, что все кто постоянно использует Монго и очень хорошо относится к ней, воспримут эту информацию в штыки. Тем не менее, в статье не один раз встречается фраза типа «выбрать решение для своих потребностей». У каждой из вышеупомянутых систем есть свои плюсы, равно как и минусы — это вечный спор. А сам факт использования jsonов в Постгрес не может не радовать и не привлекать, хотя бы в качестве эксперимента. Для сравнения, для саморазвития. Тем более, если такое решение подойдет под потребности проекта, на котором преимущественно используется Постгрес.
Total votes 14: ↑7 and ↓70
За статью спасибо, саморазвитие — это хорошо, но также неплохо было бы публиковать актуальную информацию.
Total votes 13: ↑12 and ↓1+11
Для начала надо чтобы актуальная информация существовала. Свежайшей аналитики еще не видел, увы.

Тем лучше будут видны изменения в более свежей сравнительной характеристике на фоне этой.
Total votes 19: ↑8 and ↓11-3
На главной сайта MongoDB, наверное, уже месяц висел алерт «MongoDB 3.2 is coming» с перечислением всех будущих вкусняшек…

Будем ждать свежего, актуального сравнения, чтобы снова накинуться и растерзать автора =)
Total votes 12: ↑10 and ↓2+8
Это не побуждало многочисленных авторов такого рода сравнений к написанию чего-то нового. А я, увы и ах, не обладаю достаточным багажом знаний, дабы уместно и правильно сопоставлять и комментировать сходства и различии вышеупомянутых баз.
Total votes 12: ↑6 and ↓60
Сравнивать нужно для конкретных задач. Сравнивать фичи — дело неблагодарное, бесполезное и холиваное. Тем более без собственного багажа знаний по сравниваемым объектам.

Великую ценность имеют аргументы по использованию нужного инструмента в определенных условиях. Сравнения инструментов в вакууме не несут пользы.
Total votes 7: ↑5 and ↓2+3
>У каждой из вышеупомянутых систем есть свои плюсы, равно как и минусы — это вечный спор

Для продуктивного спора нужен контекст а не набор фич.
Total votes 4: ↑3 and ↓1+2
даже можно сказать не «контекст», а набор требований и тестов, которые проверяют метрики, согласно этому набору требований.
Total votes 1: ↑1 and ↓0+1
Дело даже не в том. Лично я с удовольствием использую и Монгу и Постгрес, но автор статьи не вникая в суть вопроса пытается строить какие-то таблички с да/нет, которые выглядят в результате притянутыми за уши.

То есть мотив написания статьи примерно такой — «многие люди хвалят Монгу, а я альтернативный чувак, похвалю Постгрес». А в результате фигня получается.
Total votes 5: ↑5 and ↓0+5
Если автор хотел показать альтернативу, то ему нужно было не писать холиварную статью на тему Postgres vs Mongo, а показать как Postgres позволяет решать задачи, которые я сегодня решаю на Mongo, приведя примеры разнообразных операций, свойственных для работы с документами. И желательно не слишком тривиальных примеров.
Общий месседж статьи остался не понятен. Переходить с Mongo на Postgres после этого я не стану, разве что усомнюсь в компетентности сообщества.
Total votes 6: ↑5 and ↓1+4
Вот кстати да, заметил, что многие кто утверждают что postgresql лучше, в процессе разговора выяснялось, что они с монгой либо не знакомы, либо знакомы поверхностно. Так же и с автором jsonb когда он участвовал в радио-т (хоть он и профи в своем деле), утверждал, что сделал «конкурента» монге, но при этом не знал фич монги.

Я около года-двух назад, для себя, делал сравнение — чтобы обновить одно поле json в postgresql, нужно было написать хранимую процедуру которая распаковывала весь json, меняла значение поля, потом запаковывала все обратно. Оно работало неожиданно быстро, но все равно медленней, как минимум, в 10-20 раз чем на монге. barsulka правильно упомянул — где сравнения с обновлением полей, массивов и т.п.? — все то что хорошо работает в монге.
Total votes 4: ↑4 and ↓0+4
Скорее общий мессадж такой:

1. Если вы используете Postgre как РСУБД, но вам нужны фичи, свойственные документным и(или) key-value СУБД, то не спешите думать о переходе (полностью или частично) на них, не изучив возможности Postgre в этой области.

2. Если вы используете Mongo как документную и(или) key-value СУБД, но вам жутко не хватает фич, свойственных РСУБД, то подумайте о переходе на Postgre.

Обобщая: если вам нужны фичи, свойственные как РСУБД, так и документным и(или) key-value СУБД, то Postgre с двумя «режимами» может оказаться лучшим выбором, чем попытки использовать Mongo как РСУБД или использование двух СУБД.
Total votes 4: ↑3 and ↓1+2
В своем проекте-стартапе я решил перейти на Постгрес с Монго, и это при том, что у меня специфика такая, что данные поступают в большом количестве из внешних источников в JSON виде. Что послужило причиной? Я использую Django и начали мы с Монго, т.к. легко потоки данных в него сохранять. Для этого Монго абсолютно устраивала.
НО появились проблемы: Монго достаточно новая, и мало доков по ней и ответов на Stackoverflow, долго разработка идет. Но главное, что решив локально задачу быстрого сохранения данных в json без создания структуры данных в бд, я лишился возможности использовать почти все модули Джанго, т.к. они все предполагают наличие реляционной базы: нет join и тп. А разработка этих модулей или адаптация их под Монго это долгий и сложный процесс, и не факт что получится.
Вот поэтому перешел на Постгре, хотя это может казаться нелогичным: ведь потом данные разрастутся. Конечно, пришлось пожертвовать некоторой частью собираемых данных, т.к. трудно повторить структуру json в базе, но что делать, берем только то, что нужно. Но с 9.5 есть поддержка Nosql и в случае, если это понадобится, легко можно будет переходить постепенно на нее, не меняя при этом базу на другую.
Total votes 4: ↑2 and ↓20
Но с 9.5 есть поддержка Nosql

В текущем стабле 9.4 поддержка jsonb есть давно.
Total votes 2: ↑1 and ↓10
Как-то странно читать статью про Mongo 2.6 на следующий день после релиза 3.2 c left join'ом и валидацией.
Total votes 20: ↑19 and ↓1+18
..., но люди до сих пор забывают текущий год.
Total votes 6: ↑6 and ↓0+6
В каком году можно будет за 15 минут работы руками развернуть кластер postgresql на шести узлах, в котором данные шардятся на 6 частей, при этом пятикратное резервирование?
А еще, одним нажатием кнопки обновлять postgresql 9.5 до 9.6 на всех узлах, без остановки работы кластера?

Ок, это вопрос про горизонтальное масштабирование, видимо ниже пояса. Скажите, в каком году будет удобный инструмент для table partitioning? Судя по www.postgresql.org/docs/current/interactive/ddl-partitioning.html в том же 2015 году мне всё еще предлагают этим заниматься руками, писать самому триггеры и вот это всё.
Total votes 7: ↑7 and ↓0+7
>Доступность обучающих ресурсов
>Трудно найти

Вы серьезно??
Total votes 25: ↑25 and ↓0+25
Программирование на стороне сервера | Нет
Доступность обучающих ресурсов | Трудно найти

Вы меня простите, но это не сравнение, а ерунда с запахом холивара.
Кроме того, как и в других подобных статьях, тут ловко обходят стороной такую операцию, как «update одного значения в документе».
Total votes 22: ↑22 and ↓0+22
И такие, как map-reduce :)
Total votes 15: ↑15 and ↓0+15
Это вы с козырей сразу зашли. Тут тогда можно и про шардинг вспомнить, но я в данном случае умиляюсь именно отсутствию в сравнительных анализах такой простой и, как ни крути, базовой процедуры, как update части документа.
Total votes 9: ↑9 and ↓0+9
Судя по тестам mongodb 2.6 vs 3, версия 3 mongodb должна отставать не более чем в полтора раза, это гораздо менее страшно, чем в 3 раза с mongodb 2.6. Такими темпами скоро её можно будет не брать во внимание. Если бы в Postgres NoSQL появился бы лет 5 назад…
Total votes 8: ↑5 and ↓3+2
Очень странно видеть такие пункты как:
Доступность обучающих ресурсов


Легче найти обучения для postgresql, чем для mongodb?
Для mongodb все знают доступный и бесплатный официальный MOOC, а что там есть для postgresql… Ах да, сразу сертификации от EnterpriseDB с ценами от 200$.

Даже сложно определить, что доступнее…

Простая интеграция с другими источниками данных


То есть, эта таблица утверждает, что цепочка:
Получил данные в JSON -> запихнул их в mongodb

сложнее чем:
разработал схему таблиц для конкретного случая -> получил данные и собрал из них запрос (каким-то образом отложив невалидные и пустые данные) -> выполнил sql запрос

Если тут идется про существующие инструменты, то строчку стоило назвать по другому.
К тому же, тогда первый столбик уже давно устарел.
Total votes 6: ↑6 and ↓0+6
сложнее чем:

В последнее время всё чаще применяем при начале разработке схему: для новой сущности создаём таблицу с двумя полями: id uuid и raw_data jsonb и запихиваем туда данные. По сути полный аналог коллекций однотипных документов в NoSQL. Дальше по ходу дела анализируем юзкейсы и или часть полей дублируем в новых столбцах возможно в новых таблицах, заполняя их в приложении, а то и в insert/update триггерах, или накладываем индексы и ограничения прямо на jsonb, или тупо оставляем, если значения определенных полей нужны бизнесу только «на посмотреть» — они не участвуют в бизнес-логике приложения, нужны только операторам для принятия решений с неформализованными алгоритмами.

Total votes 2: ↑2 and ↓0+2
Тогда получается аналогично с MongoDB, причем функционал можно просто взять и перенести.
И там, и там json.
Total votes 1: ↑1 and ↓0+1
В начале, да, аналогично. Почти. Если не считать возможностей SQL в плане транзакций, ссылочной целостности и прочего ACID.

Total votes 3: ↑2 and ↓1+1
часть полей дублируем в новых столбцах возможно в новых таблицах, заполняя их в приложении
При этом вы переписываете приложение (на новые поля), или за вас это делает orm?
Ведь хранить «перенесенные» поля в json смысла нет, а то и вредно если разойдутся с таблицей.

Какие есть подводные камни такого подхода? Интересуюсь, на случай если мне понадобится posgresql в проекте.
Total votes 1: ↑1 and ↓0+1
Ближе к переписыванию ORM, чем приложения. При желании интерфейсы объектов модели можно оставлять без изменений, типа get('some_property') или set('some_property'), но обычно сначала происходит такое изменение интерфейса, а лишь потом выделение столбцов на уровне базы данных.

Мы храним, даже если все поля перенесены. По разным причинам, в том числе оптимизация вывода сущностей в API и хранение ввода API как лога. Некоторая денормализация есть конечно, но в одних случаях можно вообще забить, в других достаточно периодических проверок/исправлений, в третьих — проверка при вставке-обновлении в пре-триггерах или констрэйтах. Но как показывает практика, обычно расхождения возникают только при лазании в базу «ручками».
This comment wasn’t rated yet0
UFO just landed and posted this here
А как насчет поиска по JSON полям в Postgresql? Мне кажется тут с Монгой тягаться сложно.
Total votes 2: ↑2 and ↓0+2
Есть полнотекстовый поиск и GIN индекс — они себя обычно ведут шустрее простого B-tree.
Если почитать прошлогодний https://www.pgcon.org/2014/schedule/events/696.en.html CREATE INDEX… USING VODKA, то это в принципе должно быть очевидно.

Если читать внимательно хабр, недавно выходила серия (4шт) хороших статей от the_unbridled_goose о специфике разработки документ-ориентированного API на PostgreSQL.
Total votes 3: ↑2 and ↓1+1
Если почитать офф доки PostgreSQL'я http://www.postgresql.org/docs/9.5/static/functions-json.html
То станет понятно что там происходит ручная распаковка jsonb в один из существующих типов, можно даже в табличку или в представление, после чего можно выполнять любые доступные запросы.
Total votes 2: ↑1 and ↓10
Давайте конкретно
JSON

'{«a»:«foo», «c»:{«d»:30}, «b»:«bar»}'

Напишите, пожалуйста, запрос, который вернет boolean значение истинно ли утверждение что c.d>30?

Total votes 1: ↑1 and ↓0+1
А в чём проблема-то, вы на приведённые доки смотрели вообще? Будет что-то вроде 
(obj#>>'{c,d}')::int > 30

где obj — название поля в таблице, где этот json лежит.
Total votes 2: ↑1 and ↓10
понял, синтаксис адовый конечно
Total votes 3: ↑3 and ↓0+3
Не без этого. Но может использоваться в индексах. Хоть как (obj#>>'{c,d}')::int, хоть как (obj#>>'{c,d}')::int > 30, хоть как WHERE (obj#>>'{c,d}')::int > 30
Total votes 1: ↑1 and ↓0+1
Бэнчмарк чуть морально устарел, уже есть MongoDB 3.2, c нормальным MVCC.
Горизонтальное масштабирование у MongoDB это большой и толстый кот в мешке, с кучей заморочек, и их не меньше чем у PostgreSQL'я.
По производительности на одну ноду, понятное дело, лидирует PostgreSQL.

Мне вот один товарищ с пеной изо рта пытался доказать что MongoDB это «нереляционная, документо-ориентированная БД» — если бы это было бы действительно так, то в ней бы не использовался банальный B-tree индекс и она не подчинялась бы всем существующим правилам нормализации. По этому разводить документо-ориентированный трёп нет особо то и смысла — это выдуманное понятие, не более чем маркетинговый трюк для привлечения инвестиций.

Нужно понимать что MongoDB строилась по принципу: мы придумаем много новых умных слов, скажем что, мол, такие все инновационные NoSQL подонки, и пофигу что оно нифига не работает, — на нас ведь посыпется дождик вечнозелёных от наивных инвесторов, потом может когда-то починим, если будут громко орать и пускать лучи ненависти. И да, чинят, на самом деле, очень неохотно.

 Извините, если оскорбил чувства свято верующих в бесконечное и неосязаемое величие MongoDB, считаю что пора вам спускаться на землю.
Total votes 16: ↑7 and ↓9-2
Вот интересно! Как это использование B-tree автоматически делает базу реляционной?

Документарные базы не отменяют необходимость нормализации для создания отношений, как и сами отношения. Суть в том поддерживается ли реляционная модель на уровне движка.

А MongoDB строилась по принципу хранения документов с произвольной структурой с использованием JS и v8.

Я бы советовал вам для начала разобраться в понятиях прежде чем советовать другим спускаться на землю.
Total votes 7: ↑7 and ↓0+7
Потому что B-tree, по определению, хранит ключи которые определяют отношение между существующими сущностями, это помогает получить неглубокое дерево, первые 2-3 три уровня ключей которого могут хранится в оперативке, а остальные на винте. Что собственно позволяет значительно уменьшить количество дисковых операций. Ещё там фигурируют разнообразные cache-oblivious вещи, но это уже тема отдельной статьи.

Так как информация которую хранит B-tree априори требует определения отношений между существующими сущностями — любую СУБД, которая использует его для индексации, можно назвать реляционной.

Если сравнивать с другими структурами, типа lsm-tree(sstable) / R-tree / X-tree / MVP-tree / Fusion-tree, то у них совсем другие задачи, они не хранят отношений и их ключи используются сугубо для адресации. Соответственно их использование совсем не связано с реляционными моделями.
Total votes 9: ↑2 and ↓7-5
Потому что B-tree, по определению, хранит ключи которые определяют отношение между существующими сущностями


Можно с таким определением ознакомиться?
Total votes 5: ↑4 and ↓1+3
Кормена можно почитать и ознакомиться.
Total votes 3: ↑1 and ↓2-1
Как это внезапно алгоритм (b-tree) для доступа к записи на двух сильно отличающихся по скорости средах (ram/disk) вдруг стал напрямую связан с отношениями между сущностями?
Total votes 6: ↑6 and ↓0+6
Я думаю мне бесполезно писать о том как формируется иерархия ключей Б-дерева на основе существующих отношений схемы БД.
Total votes 2: ↑0 and ↓2-2
https://ru.wikipedia.org/wiki/B-дерево

B-дерево может применяться для структурирования (индексирования) информации на жёстком диске (как правило, метаданных). Время доступа к произвольному блоку на жёстком диске очень велико (порядка миллисекунд), поскольку оно определяется скоростью вращения диска и перемещения головок. Поэтому важно уменьшить количество узлов, просматриваемых при каждой операции. Использование поиска по списку каждый раз для нахождения случайного блока могло бы привести к чрезмерному количеству обращений к диску, вследствие необходимости осуществления последовательного прохода по всем его элементам, предшествующим заданному; тогда как поиск в B-дереве, благодаря свойствам сбалансированности и высокой ветвистости, позволяет значительно сократить количество таких операций.

Может стоит научится читать, хотя бы википедию?
Total votes 3: ↑0 and ↓3-3
И где тут про отношения между сущностями?
Total votes 1: ↑1 and ↓0+1
Таблица сравнений не актуальна для версии монги 3.2. относительно Ограничения данных или Объединения данных. Появились частичные индексы и LeftJoin.
Плюс я бы выпилил такие оценочные строки как «Мощный язык запросов» и т.д.
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr