Ще ми трябват някои заявки във формата "списък на всички обекти, където едно от алтните е 'foobar'." Очакваният размер на таблицата е от порядъка на няколко милиона записа. За това могат да се използват Postgres JSON заявки, а също и да се индексират (Индекс за намиране на елемент в JSON масив, например). Въпреки това ТРЯБВА ЛИ да се направи по този начин или това е извратено решение, което не се препоръчва?
То може да се направи по този начин, но това не означава, че трябва. В известен смисъл най-добрата практика вече е добре документирана (вижте например използване на hstore срещу използване на XML срещу използване на EAV срещу използване на отделна таблица) с нов тип данни, който, за всички намерения и практически цели (освен валидиране и синтаксис), не се различава от предишни неструктурирани или полуструктурирани опции.
Казано по друг начин, това е същото старо прасе с нов грим.
JSON предлага възможност за използване на индекси на обърнато дърво за търсене , по същия начин, както правят hstore, типовете масиви и tsvectors. Те работят добре, но имайте предвид, че са предназначени основно за извличане на точки в квартал (мисля за типове геометрия), подредени по разстояние, а не за извличане на списък със стойности в лексикографски ред.
За да илюстрирате, вземете двата плана, които очертава отговорът на Роман:
- Този, който извършва индексно сканиране преглежда дискови страници директно, извличайки редовете в реда, посочен от индекса.
- Този, който извършва сканиране на индекс на растерна карта започва с идентифициране на всяка дискова страница, която може да съдържа ред, и ги чете така, както се появяват на диска, сякаш (и всъщност точно като) извършва последователно сканиране, което пропуска безполезни области.
Връщайки се към въпроса ви:Претрупани и големи индекси на обърнато дърво наистина ще подобри производителността на вашето приложение, ако използвате Postgres таблици като гигантски JSON магазини. Но те също не са сребърен куршум и няма да ви стигнат до правилния релационен дизайн, когато се справяте с тесните места.
Изводът в крайна сметка не се различава от това, което бихте получили, когато решите да използвате hstore или EAV:
- Ако има нужда от индекс (т.е. често се появява в клауза where или, още по-важно, в клауза за присъединяване), вероятно искате данните в отделно поле.
- Ако е основно козметичен, JSON/hstore/EAV/XML/whatever-vakes-you-sleep-at-night работи добре.
