JSONB з індексуванням до hstore

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

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

AFAIK (будь ласка, не соромтеся виправляти):

1. Як правило, у Postgres, як відомо, hstore працює краще, ніж інші типи даних. Ця презентація від FOSDEM PGDAY має цікаву статистику (у другій половині слайдів). https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf

2. Перевагою hstore є швидке індексування (GiN або GiST). Однак за допомогою JSONB, GiN та GiST індексація також може бути застосована до даних JSON.

3. У цьому щоденнику професіонала на другому квадранті сказано: «Напевно, варто замінити використання hstore на jsonb у всіх нових програмах» (прокручуйте до кінця): http://blog.2ndquadrant.com/postgresql-anti-patterns-unne необходимо -jsonhstore-динамичні стовпці /

Тому я хотів би визначитися з наступним:

1. Для основної (структурованої) частини даних: вона повинна містити пару реляційних таблиць (порівняно велика з багатьма стовпцями), чи це має бути ряд ключових сховищ, що використовують hstore?
2. Якщо дані про спеціальні (внесені / неструктуровані користувачем) дані повинні бути в JSON або сховищах ключових значень в hstore (з ключами, що зберігаються в одній з основних реляційних таблиць)?

Реляційні бази даних розроблені навколо об'єднань та оптимізовані для того, щоб зробити їх добре.

Якщо у вас немає вагомих причин не використовувати нормалізовану конструкцію, використовуйте нормалізовану конструкцію.

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

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

Це я сказала у своєму дописі в блозі , який стосується саме цієї теми. Будь ласка, прочитайте весь пост . Пункт, який ви цитували, вказує, що якщо ви обираєте динамічну структуру, вам слід вибрати jsonb над hstore, але решта публікації в блозі стосується того, чому ви зазвичай віддаєте перевагу моделюванню у реляційному режимі, якщо можете.

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

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

Важливо зрозуміти: індекси GiST та GIN, як ті, що використовуються на jsonb, як правило, набагато менш ефективні, ніж звичайний індекс b-дерева. Вони більш гнучкі, але індекс b-дерева у звичайному стовпчику майже завжди буде набагато, набагато швидшим.