Що швидше: PostgreSQL проти MongoDB на великих наборах даних JSON?

У мене великий набір даних з 9м JSON-об'єктів по ~ 300 байт кожен. Це повідомлення з агрегатора посилань: в основному посилання (URL, назва та ідентифікатор автора) та коментарі (текст та ідентифікатор автора) + метадані.

Вони цілком можуть бути реляційними записами в таблиці, за винятком того, що вони мають одне поле масиву з ідентифікаторами, що вказують на дочірні записи.

Яка реалізація виглядає більш солідною?

1. Об'єкти JSON в базі даних PostgreSQL (лише одна велика таблиця з одним стовпцем, а саме об'єкт JSON)
2. JSON об'єкти на MongoDB
3. Експлуатуйте об'єкти JSON в стовпці та використовуйте масиви на PostgreSQL

Я хочу досягти максимальної продуктивності приєднань, тому можу масажувати дані та досліджувати їх, поки не знайду цікавих аналізів, і тоді я думаю, що буде краще перетворити дані у форму, специфічну для кожного аналізу.

Щодо завантаження даних, Postgre перевершує MongoDB. MongoDB майже завжди швидше, коли повертається кількість запитів. PostgreSQL майже завжди швидший для запитів із використанням індексів.

Перевірте цей сайт і цей один теж для отримання додаткової інформації. Вони мають дуже детальні пояснення.

Можливо, ви отримаєте більше користі від схематичного дизайну Mongodb. Це означає, що дуже легко змінювати структури даних на льоту.

Не існує такого поняття, як приєднання в Mongodb. Тож, як можна думати про дані та як їх використовувати, потрібно змінити для обліку даних на базі документів та безсхемових середовищ DB.

Можливо, швидкість стає менш важливою у міру зміни перспективи та пріоритетів.

Я сподіваюся, що це допомагає.

-Тод

Щодо згаданих вами цифр, я думаю, що всі альтернативи повинні працювати (читайте: ви зможете закінчити свій аналіз в розумний час). Я рекомендую такий дизайн, який може призвести до значно швидших результатів.

Як було сказано раніше, загалом postgresql швидше, ніж mongo, в кілька разів більше, ніж у 4 рази швидше. Див. Наприклад: http://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality

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

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

Я б використовував postgres і зберігав дані у двох таблицях:

створення публікацій таблиці (ціле число post_id, url varchar (255), ціле число автора_id);

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

створити коментарі до таблиці (integer integer, comment_id integer, post_id integer, author_id integer, comment varchar (255)); змінити коментарі до таблиці, додайте обмеження первинного ключа comments_pk (comment_id); створити індекс comment_author на коментарях (author_id); створити індекс comment_post на коментарях (post_id);

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

Якщо ви зацікавлені в маркіруванні слів у коментарі до nlp, додайте іншу таблицю для цього, але пам’ятайте, що це значно збільшить обсяг ваших даних. Зазвичай краще не представляти всю токенізацію в базі даних.