#PostgreSQLRussia Москва, 23.12.2014 PostgreSQL-митап в офисе компании Parallels Ещё раз о JSON(b) в PostgreSQL 9.4 Николай Самохвалов ru@postgresql.org Twitter: @samokhvalov
● 1998-2007: МФТИ & ИСП РАН ● 2006: XML в PostgreSQL (8.3, c Peter Eisentraut) ● с 2007 — «Постгресмен», пресс- контакт PGDG в России, Highload++ ● с 2006 — стартапы, ● социальные сети Обо мне
● ГАИШ МГУ ● PostgreSQL hackers, ● major contributors: ○ GiST, GIN ○ hstore, intarray, etc ○ full-text search ○ kNN-search ○ JSON, JSONb Олег Бартунов и Фёдор Сигаев
● развитие GiST & GIN ● jsquery https://github.com/akorotkov/jsquery + Александр Коротков
JSONb: + Andrew Dunstan & Peter Geoghegan
РСУБД, SQL и все-все-все
Иерархическая модель Модели данных и история
Сетевая модель Модели данных и история
Реляционная модель Модели данных и история
● Иерархическая и сетевая: 50-е … середина 70-х ● Реляционная: конец 60-х … н.в. ○ реляционная алгебра Модели данных: история Edgar Codd — основал (1969-1970) Chris Date — развил, популяризировал
Модели данных: хронология ● Иерархическая и сетевая: 50-е … середина 70-х ● Реляционная: конец 60-х … н.в. ○ структура (отношения, кортежи) ○ целостность ○ манипуляции (рел. алгебра / рел. исчисление) ○ принцип ACID ○ SQL — с 1970-х (ANSI: 1986, ISO: 1987) PostgreSQL — преемник Ingres (UCB - Berkeley, CA), SQL – с 1995
Три вызова РСУБД
Реляционная модель: вызов #1 ● Реляционная: конец 60-х … н.в. ○ реляционная алгебра ● 90е — вызов #1: реляционная модель VS объектная модель → объектные СУБД, объектно-реляционный подход PostgreSQL — объектно-реляционная СУБД: ● объекты: БД, схемы, таблицы, индексы и т.д. ● расширяемость: типы данных, операторы, методы доступа ● наследование
Реляционная модель: вызов #2 ● Реляционная: конец 60-х … н.в. ○ реляционная алгебра ● 90е — вызов #1: реляционная модель VS объектная модель ● конец 90-х … середина 2000-х — вызов #2: XML («слабоструктурированные», иерархия!) → интеграция XML, XML СУБД 2008: PostgreSQL 8.3 — тип данных XML
Реляционная модель: вызов #2 ● Реляционная: конец 60-х … н.в. ● 90е — вызов #1: реляционная модель VS объектная модель ● конец 2000-х — 2010-е — вызов #2: noSQL → noSQL СУБД: key-value, document-oriented и т.д. — «очень» слабоструктурированные (иерархии! графы!) 2003: тип данных hstore 2012: PostgreSQL 9.2 — тип данных JSON 2014: PostgreSQL 9.4 — тип данных JSONb
Пары ключ-значение (без вложенности) SELECT * FROM test LIMIT 1; id | value ----+-------------------------------------------------------------------- 1 | "33"=>"923", "262"=>"181", "471"=>"658", "554"=>"916", "579"=>"472" ● Бинарное хранение ● Богатая поддержка индексов (см. далее) ○ функциональные индексы ○ GiST ○ GIN hstore: хранение key-value в реляционной среде Schema-less PostgreSQL
● Хранится в виде текста (как и XML) ● Сохраняет представление ○ порядок, ○ пробелы, ○ дубликаты) ● Индексы — только функциональные JSON в PostgreSQL
● Хранится бинарном виде /* как и hstore */ ● Убираются пробелы ● Убираются дубликаты (берутся последние значения) ● Ключи сортируются /* внутренняя кухня, порядок не определён */ ○ быстрый поиск ● Результат — в PostgreSQL 9.4 есть все эти типы: ○ hstore ○ XML ○ JSON ○ JSONb JSONb в PostgreSQL
-- JSONовскый примитивный тип данных "число" — аналог NUMERIC: SELECT '5'::jsonb = '5'::jsonb -- Например так: SELECT '["a", "b", 77]'::jsonb != '["a", "b", 77.00000000000000000000001]'::jsonb; -- Конечно же, нули в конце не имеют значения: SELECT '66'::jsonb = '66.000'::jsonb; -- Строковые примитивы ведут себя как постгресовые строки: SELECT j FROM jdocs ORDER BY j->'name' LIMIT 10; «Теневая» типизация в jsonb
Индексы
● линейный поиск, перебор (seqscan) - O(n) ● двоичное дерево ● АВЛ-деревья ● хэш Как искать?
● B+-деревья ○ <, >, = ● R-деревья ○ включён, включает, пересекается ● GiST — обобщённое дерево! Hellerstein, 1995 ○ произвольные операторы ○ реализовано в PostgreSQL Как искать: ближе к СУБД, ближе к PostgreSQL
По сравнению с GiST: ● намного быстрее поиск ● медленнее вставка GIN - обобщённый инвертированный индекс
● opclass (operator class) – «связь» между типом данных и индексом ● btree, hash — опклассы «по умолчанию» для скалярных типов → можно строить функциональные индексы над JSON и JSONb CREATE INDEX i_test ON table1 USING (btree(выражение)); PostgreSQL: opclass-ы
● опкласс по умолчанию CREATE INDEX i_test ON table1 USING gin(jcol); ● jsonb_path_ops CREATE INDEX i_test ON table1 USING gin(jcol jsonb_path_ops); ○ НАМНОГО меньше места ○ не поддерживает оператор «?» («существует»), т.е. менее гибок, чем опкласс по умолчанию GIN-индексирование jsonb
jsonb @> jsonb — содержит ли значение слева в себе значение справа? '{"a":1, "b":2}'::jsonb @> '{"b":2}'::jsonb jsonb <@ jsonb — содержится ли левое значение внутри правого значения? '{"b":2}'::jsonb <@ '{"a":1, "b":2}'::jsonb jsonb ? text — существует ли пара ключ-значение в JSON-значении? '{"a":1, "b":2}'::jsonb ? 'b' ?| text[] — существуют ли хоть какие-то из эти пар ключ-значение? '{"a":1, "b":2, "c":3}'::jsonb ?| array['b', 'c'] ?& text[] — существуют ли все приведённые пары ключ-значение? '["a", "b"]'::jsonb ?& array['a', 'b'] jsonb: базовые операторы
● jsonb_path_ops лучше подходит для вложенных структур, чем «дефолтовый» GIN ● почти всегда лучше выбрать jsonb_path_ops, но внимательнее с используемыми операторами! ● можно использовать «функциональный» подход для сужения области индексации! см. далее Индекс для JSONb — что выбрать?
Сравнение опклассов GIN для jsonb ● БД Delicios ● Табличный размер jsonb: 1.3 GB ● «Дефолтовый» jsonb_ops: 636 MB (без компрессии — 815 MB) ● jsonb_path_ops: 295 MB ● jsonb_path_ops (tags): 44 MB … USING gin((jb->'tags') jsonb_path_ops) ● jsonb_path_ops (tags.term): 1.6 MB
Сравнение опклассов + Mongo Подробнее — http://postgresmen.ru/meetup/2014-09-24-yandex
Сравнение от EnterpriseDB
● по-прежнему ОРСУБД, очень гибкая, надёжная и производительная ● платформа для разработки решений различной сложности и гибкости Что же такое PostgreSQL?
Кто использует в России
● О. Бартунов и А. Коротков, JSONb. Материалы митапа в Яндексе. http://postgresmen.ru/meetup/2014-09-24-yandex ● Peter Geoghegan. jsonb Deep Dive. Материалы митапа в Сан- Франциско (англ.) https://speakerd.s3.amazonaws. com/presentations/a79cd060deb20131ffed2ad9291baba4/jsonb- deep-dive.pdf ● PostgreSQL as a Schemaless Database. Christophe Pettus PostgreSQL Experts, Inc. (англ.) http://thebuild. com/presentations/pg-as-nosql-pgday-fosdem-2013.pdf ● Open Enterprise: The PostgreSQL Open Source Database Blog from EnterpriseDB http://blogs.enterprisedb.com/2014/09/24/postgres- outperforms-mongodb-and-ushers-in-new-developer-reality/ ● Крис Дейт. Введение в системы баз данных http://www.ozon. ru/context/detail/id/2309312/ ● Материалы митапов #PostgreSQLRussia http://postgresmen. ru/articles Ссылки
ru@postgresql.org Twitter: @samokhvalov Skype: postgresmen http://PostgreSQLRussia.org http://Postgresmen.ru Николай Самохвалов Спасибо!

2014.12.23 Николай Самохвалов, Ещё раз о JSON(b) в PostgreSQL 9.4

  • 1.
    #PostgreSQLRussia Москва, 23.12.2014 PostgreSQL-митап в офисекомпании Parallels Ещё раз о JSON(b) в PostgreSQL 9.4 Николай Самохвалов ru@postgresql.org Twitter: @samokhvalov
  • 2.
    ● 1998-2007: МФТИ& ИСП РАН ● 2006: XML в PostgreSQL (8.3, c Peter Eisentraut) ● с 2007 — «Постгресмен», пресс- контакт PGDG в России, Highload++ ● с 2006 — стартапы, ● социальные сети Обо мне
  • 3.
    ● ГАИШ МГУ ●PostgreSQL hackers, ● major contributors: ○ GiST, GIN ○ hstore, intarray, etc ○ full-text search ○ kNN-search ○ JSON, JSONb Олег Бартунов и Фёдор Сигаев
  • 4.
    ● развитие GiST& GIN ● jsquery https://github.com/akorotkov/jsquery + Александр Коротков
  • 5.
    JSONb: + Andrew Dunstan& Peter Geoghegan
  • 6.
    РСУБД, SQL ивсе-все-все
  • 7.
  • 8.
  • 9.
  • 10.
    ● Иерархическая исетевая: 50-е … середина 70-х ● Реляционная: конец 60-х … н.в. ○ реляционная алгебра Модели данных: история Edgar Codd — основал (1969-1970) Chris Date — развил, популяризировал
  • 11.
    Модели данных: хронология ●Иерархическая и сетевая: 50-е … середина 70-х ● Реляционная: конец 60-х … н.в. ○ структура (отношения, кортежи) ○ целостность ○ манипуляции (рел. алгебра / рел. исчисление) ○ принцип ACID ○ SQL — с 1970-х (ANSI: 1986, ISO: 1987) PostgreSQL — преемник Ingres (UCB - Berkeley, CA), SQL – с 1995
  • 12.
  • 13.
    Реляционная модель: вызов #1 ●Реляционная: конец 60-х … н.в. ○ реляционная алгебра ● 90е — вызов #1: реляционная модель VS объектная модель → объектные СУБД, объектно-реляционный подход PostgreSQL — объектно-реляционная СУБД: ● объекты: БД, схемы, таблицы, индексы и т.д. ● расширяемость: типы данных, операторы, методы доступа ● наследование
  • 14.
    Реляционная модель: вызов #2 ●Реляционная: конец 60-х … н.в. ○ реляционная алгебра ● 90е — вызов #1: реляционная модель VS объектная модель ● конец 90-х … середина 2000-х — вызов #2: XML («слабоструктурированные», иерархия!) → интеграция XML, XML СУБД 2008: PostgreSQL 8.3 — тип данных XML
  • 15.
    Реляционная модель: вызов #2 ●Реляционная: конец 60-х … н.в. ● 90е — вызов #1: реляционная модель VS объектная модель ● конец 2000-х — 2010-е — вызов #2: noSQL → noSQL СУБД: key-value, document-oriented и т.д. — «очень» слабоструктурированные (иерархии! графы!) 2003: тип данных hstore 2012: PostgreSQL 9.2 — тип данных JSON 2014: PostgreSQL 9.4 — тип данных JSONb
  • 16.
    Пары ключ-значение (безвложенности) SELECT * FROM test LIMIT 1; id | value ----+-------------------------------------------------------------------- 1 | "33"=>"923", "262"=>"181", "471"=>"658", "554"=>"916", "579"=>"472" ● Бинарное хранение ● Богатая поддержка индексов (см. далее) ○ функциональные индексы ○ GiST ○ GIN hstore: хранение key-value в реляционной среде Schema-less PostgreSQL
  • 17.
    ● Хранится ввиде текста (как и XML) ● Сохраняет представление ○ порядок, ○ пробелы, ○ дубликаты) ● Индексы — только функциональные JSON в PostgreSQL
  • 18.
    ● Хранится бинарномвиде /* как и hstore */ ● Убираются пробелы ● Убираются дубликаты (берутся последние значения) ● Ключи сортируются /* внутренняя кухня, порядок не определён */ ○ быстрый поиск ● Результат — в PostgreSQL 9.4 есть все эти типы: ○ hstore ○ XML ○ JSON ○ JSONb JSONb в PostgreSQL
  • 19.
    -- JSONовскый примитивныйтип данных "число" — аналог NUMERIC: SELECT '5'::jsonb = '5'::jsonb -- Например так: SELECT '["a", "b", 77]'::jsonb != '["a", "b", 77.00000000000000000000001]'::jsonb; -- Конечно же, нули в конце не имеют значения: SELECT '66'::jsonb = '66.000'::jsonb; -- Строковые примитивы ведут себя как постгресовые строки: SELECT j FROM jdocs ORDER BY j->'name' LIMIT 10; «Теневая» типизация в jsonb
  • 20.
  • 21.
    ● линейный поиск,перебор (seqscan) - O(n) ● двоичное дерево ● АВЛ-деревья ● хэш Как искать?
  • 22.
    ● B+-деревья ○ <,>, = ● R-деревья ○ включён, включает, пересекается ● GiST — обобщённое дерево! Hellerstein, 1995 ○ произвольные операторы ○ реализовано в PostgreSQL Как искать: ближе к СУБД, ближе к PostgreSQL
  • 23.
    По сравнению сGiST: ● намного быстрее поиск ● медленнее вставка GIN - обобщённый инвертированный индекс
  • 24.
    ● opclass (operatorclass) – «связь» между типом данных и индексом ● btree, hash — опклассы «по умолчанию» для скалярных типов → можно строить функциональные индексы над JSON и JSONb CREATE INDEX i_test ON table1 USING (btree(выражение)); PostgreSQL: opclass-ы
  • 25.
    ● опкласс поумолчанию CREATE INDEX i_test ON table1 USING gin(jcol); ● jsonb_path_ops CREATE INDEX i_test ON table1 USING gin(jcol jsonb_path_ops); ○ НАМНОГО меньше места ○ не поддерживает оператор «?» («существует»), т.е. менее гибок, чем опкласс по умолчанию GIN-индексирование jsonb
  • 26.
    jsonb @> jsonb— содержит ли значение слева в себе значение справа? '{"a":1, "b":2}'::jsonb @> '{"b":2}'::jsonb jsonb <@ jsonb — содержится ли левое значение внутри правого значения? '{"b":2}'::jsonb <@ '{"a":1, "b":2}'::jsonb jsonb ? text — существует ли пара ключ-значение в JSON-значении? '{"a":1, "b":2}'::jsonb ? 'b' ?| text[] — существуют ли хоть какие-то из эти пар ключ-значение? '{"a":1, "b":2, "c":3}'::jsonb ?| array['b', 'c'] ?& text[] — существуют ли все приведённые пары ключ-значение? '["a", "b"]'::jsonb ?& array['a', 'b'] jsonb: базовые операторы
  • 27.
    ● jsonb_path_ops лучшеподходит для вложенных структур, чем «дефолтовый» GIN ● почти всегда лучше выбрать jsonb_path_ops, но внимательнее с используемыми операторами! ● можно использовать «функциональный» подход для сужения области индексации! см. далее Индекс для JSONb — что выбрать?
  • 28.
    Сравнение опклассов GIN дляjsonb ● БД Delicios ● Табличный размер jsonb: 1.3 GB ● «Дефолтовый» jsonb_ops: 636 MB (без компрессии — 815 MB) ● jsonb_path_ops: 295 MB ● jsonb_path_ops (tags): 44 MB … USING gin((jb->'tags') jsonb_path_ops) ● jsonb_path_ops (tags.term): 1.6 MB
  • 29.
    Сравнение опклассов + Mongo Подробнее— http://postgresmen.ru/meetup/2014-09-24-yandex
  • 30.
  • 31.
    ● по-прежнему ОРСУБД,очень гибкая, надёжная и производительная ● платформа для разработки решений различной сложности и гибкости Что же такое PostgreSQL?
  • 32.
  • 33.
    ● О. Бартунови А. Коротков, JSONb. Материалы митапа в Яндексе. http://postgresmen.ru/meetup/2014-09-24-yandex ● Peter Geoghegan. jsonb Deep Dive. Материалы митапа в Сан- Франциско (англ.) https://speakerd.s3.amazonaws. com/presentations/a79cd060deb20131ffed2ad9291baba4/jsonb- deep-dive.pdf ● PostgreSQL as a Schemaless Database. Christophe Pettus PostgreSQL Experts, Inc. (англ.) http://thebuild. com/presentations/pg-as-nosql-pgday-fosdem-2013.pdf ● Open Enterprise: The PostgreSQL Open Source Database Blog from EnterpriseDB http://blogs.enterprisedb.com/2014/09/24/postgres- outperforms-mongodb-and-ushers-in-new-developer-reality/ ● Крис Дейт. Введение в системы баз данных http://www.ozon. ru/context/detail/id/2309312/ ● Материалы митапов #PostgreSQLRussia http://postgresmen. ru/articles Ссылки
  • 34.