Что быстрее: PostgreSQL против MongoDB на больших наборах данных JSON?

10

У меня есть большой набор данных с 9-метровыми объектами JSON по ~ 300 байт каждый. Это сообщения из агрегатора ссылок: в основном ссылки (URL, заголовок и идентификатор автора) и комментарии (текст и идентификатор автора) + метаданные.

Они вполне могут быть реляционными записями в таблице, за исключением того факта, что у них есть одно поле массива с идентификаторами, указывающими на дочерние записи.

Какая реализация выглядит более солидно?

Объекты JSON в базе данных PostgreSQL (всего одна большая таблица с одним столбцом, а именно объект JSON)
JSON-объекты на MongoDB
Разнесите объекты JSON в столбцы и используйте массивы в PostgreSQL

Я хочу максимизировать производительность в объединениях, поэтому я могу массировать данные и исследовать их, пока не найду интересные анализы, и в этот момент я думаю, что будет лучше преобразовать данные в форму, специфичную для каждого анализа.

— сине-дино
источник

Возможно, захотите оформить заказ на снежинку. Он может обрабатывать как структурированные, так и полуструктурированные данные вместе. www.snowflake.net

Я думаю, что вам нужно более подробно остановиться на том, что для вас означает «максимизировать производительность в соединениях» Присоединиться что?

— Spacedman

10

По загрузке данных Postgre превосходит MongoDB. MongoDB почти всегда быстрее при возврате количества запросов. PostgreSQL почти всегда быстрее для запросов, использующих индексы.

Проверьте этот сайт и этот тоже для получения дополнительной информации. У них есть очень подробные объяснения.

— untitledprogrammer
источник

Очень хорошие ссылки, особенно первая, которая выглядит более детально и тщательно. При поиске года (строки) и возвращении идентификатора записи (int), potgresql примерно в 4 раза быстрее, но при возврате автора порядок величины тот же. MongoDB только примерно на 20% медленнее при возвращении автора. Есть ли принципиальная разница между возвращением int и возвращением строки, которая могла бы объяснить это? То есть, если бы recid был строкой, было бы преимущество postgresql исчезать, и оба были бы примерно такими же, как в случае автора?

— MASL

1

Вы можете получить больше пользы от схемы без схемы Mongodb. Это означает, что очень легко изменять структуры данных на лету.

В Mongodb нет такой вещи, как объединение. Так что, как человек думает о данных и как их использовать, нужно изменить, чтобы они учитывали среды БД на основе документов и без схем.

Может быть, скорость становится менее важной по мере изменения перспективы и приоритетов.

Надеюсь, это поможет.

-Todd

— Тодд Кэнди
источник

В последних тестах, PostgreSQL полностью Принадлежащий MongoDB ...

— прекращал - Anony-мусс

@ Anony-Mousse: Интересно. Вы знаете какие-нибудь источники?

— Исаак

например, tiborsimko.org/postgresql-mongodb-json-select-speed.html и предпринятый.com/ postgres-plus-edb-blog/marc-linster/… из другого ответа. Основная причина в том, что у Postgres хорошие индексы, в то время как индексы в MongoDB этого не стоят. Кроме того, Postgres получил поддержку BSON и другие дополнения для обработки JSON, что значительно улучшило производительность. Именно поэтому он стал намного быстрее, чем в первых версиях.

— ВЫЙТИ - Anony-Mousse

0

Для чисел, которые вы упоминаете, я думаю, что все альтернативы должны работать (читай: вы сможете закончить анализ в разумные сроки). Я рекомендую дизайн, который может привести к значительно более быстрым результатам.

Как уже было сказано, postgresql работает быстрее, чем mongo, в несколько раз быстрее, чем в 4 раза. См. Например: http://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality

Вы сказали, что заинтересованы в улучшении производительности в соединениях. Я предполагаю, что вы заинтересованы в вычислении сходства между сущностями (например, пост, автор), поэтому вы будете в основном присоединяться к таблице самостоятельно (например, по посту или автору) и агрегировать.

Добавьте к этому тот факт, что после начальной загрузки ваша база данных будет доступна только для чтения, что делает проблему очень подходящей для использования индекса. Вы не будете платить за обновление индекса, так как у вас его не будет, и я думаю, у вас есть дополнительное место для индекса.

Я хотел бы использовать postgres и хранить данные в двух таблицах:

создавать сообщения в таблице (post_id integer, url varchar (255), author_id integer);

- Загрузить данные, а затем создать индексы. - Это приведет к более быстрой загрузке и улучшению показателей, изменению таблицы записей, добавлению ограничения posts_pk первичный ключ (post_id); создать индекс post_author для сообщений (author_id);

создавать комментарии к таблицам (целое число comment_id, целое число post_id, целое число author_id, комментарий varchar (255)); изменить таблицу комментариев добавить ограничение комментарии_pk первичный ключ (comment_id); создать индекс comment_author для комментариев (author_id); создать индекс comment_post для комментариев (post_id);

Затем вы можете вычислить сходство авторов на основе комментариев в запросах, таких как select m. author_id as m_author_id, a. author_id как a_author_id, считать (отличный m.post_id) как сообщения из комментариев, так как m присоединяются к комментариям как группа использования (post_id) от m.author_id, a. author_id

В случае, если вы заинтересованы в токенизации слов в комментарии для nlp, добавьте еще одну таблицу для этого, но помните, что это значительно увеличит объем ваших данных. Обычно лучше не представлять всю токенизацию в базе данных.

— Dal
источник