PGConf.NN — конференция по PostgreSQL в Нижнем Новгороде

PG умеет фильтровать JSON на сервере и хранит его в бинарном виде. Иерархический формат записей много когда полезен, поэтому его лучше иметь в арсенале поддерживаемых нативно типов данных, чем не иметь.

Всмысле «хранит в бинарном виде»? JSON это и есть «вид» - текстовый. В бинарном виде может храниться ассоциативный массив key->value, но это никаким боком не JSON, если оно не записано в js-синтаксисе.

Чтобы снять вопросы:

https://www.postgresql.org/docs/13/datatype-json.html

The json and jsonb data types accept almost identical sets of values as input. The major practical difference is one of efficiency. The json data type stores an exact copy of the input text, which processing functions must reparse on each execution; while jsonb data is stored in a decomposed binary format that makes it slightly slower to input due to added conversion overhead, but significantly faster to process, since no reparsing is needed. jsonb also supports indexing, which can be a significant advantage.

Основное ограничение json/jsonb в том, что обновлять можно только весь документ целиком. Тогда как для обычных записей обновлять можно отдельно каждое поле. Ну и выбор доступных типов данных в документе скромненький.

Миллионы мух ты хотел сказать

руководитель отдела разработки БАРС Груп

Самая дурная группа разработчиков. В МИС БАРС (которая для врачей) можно проставить неправильно как болезнь, так и способ лечения. Например, ребенку до двух лет поставить астму и указать взрослый МЭС. На заявки поправить дебилизм не реагируют.

Иногда на форуме обсуждают метаданные и то как «космические корабли бороздят ЛОР».
Так вот ВСЕ СУБД это разновидности архитектур, использующих МЕТАДАННЫЕ …

Не много о JSON …

Пацаны и не знают, что эта абревиатура означает …

Я ВИДЕЛ СОН

Эшо …

Я помню чудное мгновенье:
Передо мной явился JSON,
Как мимолетное виденье,
Как гений чистой красоты.

Шли годы. Бурь порыв мятежный
Рассеял прежние мечты,
И я забыл JSON к счастью,
Его небесные черты.

В глуши, во мраке ЛОР-а
Тянулись тихо дни мои
Без радости, без вдохновенья,
Без слез, без жизни, без любви.

Душе настало пробужденье:
И разработал API,
Теперь с объектами все просто,
И рад об этом вам сказать.

Интересно о чем поведают в докладе
«JSON or not JSON» — Олег Бартунов, генеральный директор Postgres Professional;

ИМХО ребята «Слышали где звон» …

Интересно о чем поведают в докладе «JSON or not JSON» — Олег Бартунов, генеральный директор Postgres Professional

LOR, такой LOR. «Если не можешь выиграть у власти, надо ей нагадить» (с) МБХ.

Пацаны и не знают, что эта абревиатура означает …

Бери выше: Joseph Stalin ONline

ИМХО ребята «Слышали где звон» …

ИМХО неправильное развитие архитектуры ни к чему хорошему не приводит …

Раскроешь тему, что у них в архитектуре неправильно?

ну, да. в оригинале был fourth, но пришлось урезать до forth, а уж потом и до fort.

приятно видеть хоть кого-то, кто просто слышал об этом языке.

для интересующихся - один из самых компактных интерпретаторов. использовался, в частности, в sun-овском аналоге bios и как основа для postscript.

уже не вспомню где, но попадалась реализация fort, влезающая в 4096 байт. карл, интерпретатор в 4096 байт!

Раскроешь тему, что у них в архитектуре неправильно?

Речь не Postgresql в целом, а поддержка использования JSON.
Вы занимаетесь разработкой API для работы с объектами.
Так что вы и сами знаете о функциональной ограниченности и недостатках JSON.
Вообщем ребята

"Хотят", но не УМЕЮТ ...

Вообщем ребята «Хотят», но не УМЕЮТ …

Впрочем ни кто ведь не заставляет использовать в базе JSON.
Что касаемо JSON, то его архитектура предопределяет нишу задач в которой его целесообразно использовать.
Но YAML, XML, … удобны, но опять таки имеют много недостатков.
И первый из них - ТЕКСТОВЫЕ ФАЙЛЫ.
В целом конечно если «ДОЛГО МУЧИТЬСЯ», то можно на их основе спроектировать какую-нибудь УРОДЛИВУЮ СУБД.

Резюме этого поста простое.

ИМХО YAML, XML, ... не нужно использовать в СУБД

Конечно скажут «А что скажете о Mongodb?» …
Скажу так

Разработчики реализовали ту архитектуру, которую посчитали целесообразной ...  

Еще раз акцентирую то, что YAML, XML, … имеют много недостатков.
Использование их для представления метаданных САМОЕ ТО, но не для ДАННЫХ …

Расширение системы типов (и расширяемая система типов) — не самоцель, и для того же jsonb её можно было бы предложить/внедрить. Вопрос в том, будут ли этим пользоваться, потому что тащить сложные системы типов сквозь время трудоемко. Особенно на С. Что, по моему мнению, и является основной архитектурной проблемой Postgres.

Я когда-то давно, еще в версии 9, им плотно интересовался. И даже изучил кодовую базу. Но, чем глубже я эту кодовую базу изучал, тем меньше я всем этим интересовался. А потом моя работа стала вообще связана с ETL и аналитическими БД, и PG я окончательно забросил. С тех пор прошло 10+ лет, и PG показал неплохой уровень переиспользования кодовой базы — на его основе наклепали довольно таки много всего. Но нетривиальные типы данных как были проблемой, так и остались. Шаблончиков-то в Си нету. Может на Rust перепишут, если перейти на C/C++, как это в Gcc сделали, такие ломки?

Использование их для представления метаданных САМОЕ ТО, но

Хотя это утверждение верно для некоторой ниши задач.
Все программы на C/C++ используют struct, архитектура которого
предоставляет возможность проектирования любых типов данных /любой сложности/.
Вспомним задачи, использующие мультимедию, графику, «числовые дробилки», …
Ниша ОГРОМНА.
Форматы представления данных YAML, XML, … можно ПРИСОБАЧИТЬ для вышеприведенных типов задач, но это СТУДЕНЧЕСКИЙ ПОДХОД.
Что касаемо СУБД, то их архитектура в основном направлена на эффективное представление однотипных данных и их обработку.
Вообщем это обширнейшая тема SQL и NOSQL.
К сожалению многие NOSQL проекты используют архитектуру ТЕКСТОВЫХ ФОРМАТОВ данных YAML, XML, … и в результате ГЕРОИЧЕСКИ устраняют недостатки этих форматов.

Опять таки речь не о том, что YAML, XML, … плохи, а о том что нужно понимать для каких их целесообразно использовать, а не предлагать

Стакан СКИПИДАРА для лечения всех болезней ...

PG показал неплохой уровень переиспользования кодовой базы — на его основе наклепали довольно таки много всего.

Это да.
Разработчики PG, MSSQL, Oracle, … конечно понимали, что архитектура их систем позволит эффективно использовать в большой
ниже задач.
В шутку скажу об этих задачах так

Дробилки данных

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

Уф.
Это обширнейшая тема, касаемая разработки объектных баз данных.

В моем API возможно использование всех простых типов данных https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/cc953fe1(v=vs.120) и много более.
В какой-то мере архитектуру метаданных можно сравнить с struct, но много более расширена.
Например, поля могут иметь свойства /и иметь любую сложность представления метаданных о свойстве поля, объекта, /, …
Этого в struct нет.
Да МНОГО ЧЕГО.

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

Ныне вот расширяю архитектуру для удобной и эффективной работы с иерархическими моделями данных …

На форуме не регистрируюсь потому, что забанят через день.
Почему?
Потому что не когда не скажу на ЧЕРНОЕ, что оно БЕЛОЕ.
А на форумах принято говорить

НЕ О ЧЕМ и главное ЛЕГИМИТИВНО 

При этом речь не о том, что грублю кому-то, политизирую …
Да и в целом мне

Мне в холодной землянке тепло с моим API ...

«JSON or not JSON» — Олег Бартунов, генеральный директор Postgres Professional;

Интересно будет познакомиться с тем как

JSON бороздит Большой PG
``

Но, чем глубже я эту кодовую базу изучал, тем меньше я всем этим интересовался.

А в новости о «тарантуле» ты утверждал, что С-лапша в lmdb ещё как-то понимаема. Неужели тут все настолько плохо?

Но реляционные СУБД не позволяют эффективно решать задачи в которых прикладные объекты весьма изменчивы, взаимосвязаны и разнообразны.

Изменчивость,взаимосвязь и разнообразие обьектов существует только у тебя в голове. В реальности же 3 рубля - всегда просто 3 рубля, без всякой обьектной чуши.

на ютабе будет видосы?

Задача базы - хранить данные максимально эффективно, занимая минимум места на хранение и времени на обработку, и то и то достигается только двоичным форматом.

Удачного дебага.

Дебага чего? Задача базы, всё же, именно такая как я написал. Если из-за этого её сложнее отлаживать - ну, качественный продукт всегда делать сложнее чем некачественный. Хотя «точка отсчёта» заявлена интересная: хранить данные в текстовой мусорке это «норма», а нативный хороший формат - видимо верх сложности.

Какая связь между «бинарный», «нативный», и «хороший»?

Аргумент про «качественный продукт» сильно напоминает классический довод сторонников ассемблера: «зато можно оптимизировать по максимуму». Ну да, можно. Лет через двадцать.

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

классический довод сторонников ассемблера

Ассемблер перестали использовать не потому, что оптимизации не нужны, а потому, что компиляторы научились делать примерно то же самое сами, из кода на Си.

зато можно оптимизировать по максимуму

Тут речь далеко не про финальные оптимизации, а про вставку мусорного функционала.

Дебага запроса.

Вот запилил ты вторую нормальную форму, все круто. Только запрос работает минутами на продакшн объемах.

Или надо расширить схему, поле какое-то добавилось в бизнес-объект. А после миграции все данные грохнулись. Или (что более вероятно) при откате.

«бинарный» и «нативный» это синонимы

Близко не лежали.

вставку мусорного функционала

Tom-ah-to, tom-ay-to.

Хранение данных в текстовом формате ничем тут не поможет.

Ну почитай ответ аиста. Поможет фильтрацией/обработкой этого самого текста на сервере.

Во-вторых, формат не текстовый, а бинарный. Опять же, почитай, что выше писали.

Не надо меня держать за слепого или идиота. Всё что выше писали я читал.

1) Повторюсь: JSON - это формат представления ассоциативного массива (в т.ч. многоуровневого) с использованием javascript-синтаксиса. Есть много других форматов представления ассоциативных массивов, как текстовых, но в другом синтаксисе (например: php array, php serialize, lua), так и бинарных (например: asn1, nbt). Все они могут взаимно друг в друга более-менее конвертироваться, но не надо показывать свою неграмотность, обзывая всё это json'ом.

2) SQL (язык запросов), сам по себе, как известно, текстовый, и часто запрос прямо так в текстовом виде и отправляется на сервер. Но там, где всё стараются делать аккуратно и хорошо, имеется тенденция прекомпилировать запросы, и отправлять их на сервер уже в двоичном виде. Хотите расширить синтаксис запросов, добавив туда поддержку js-синтаксиса описания данных? Ок, но при чём тут сама база? Запрос надо точно так же скомпилировать в бинарный вид и отправить на сервер. Поля из json-массива это по сути просто обычные колонки таблицы, с возможностью отсутствия (т.е. могут быть NULL). Можно сделать даже дополнительное свойство «скорее всего NULL», чтобы не выделять даже 1 бит данных под это в строках где этой колонки нет. Хранить заголовок колонки, разумеется, надо там же где и остальные - в описании формата таблицы. Колонку можно будет индексировать как нормальную колонку таблицы. Причём тут json? Да почти ни при чём, только выше было пожелание поддерживать его в синтаксисе запросов. А от хранения этого всего в настоящем json или в каком-то другом неудобном формате - никакой пользы не будет.

Но там, где всё стараются делать аккуратно и хорошо, имеется тенденция прекомпилировать запросы, и отправлять их на сервер уже в двоичном виде.

Вы точно не путаете компиляцию и трансляцию?

Запрос надо точно так же скомпилировать в бинарный вид и отправить на сервер

Наркомания.

а про некое PostgresPro, которое ещё недавно пиарилось интеграцией базы с блокчейнами и какой-то криптовалютой

Ага, и в которой ещё работает куча core-разрабов постгри.

и то и то достигается только двоичным форматом

JSONB вполне себе двоичный.

Основное ограничение json/jsonb в том, что обновлять можно только весь документ целиком

Пока… В «JSON or not JSON» расскажут про то, что в некоторых случаях скоро можно будет обновлять и частично.

Подожди, потом он узнает про то, что текст он тоже бинарный.

А я вот с этого пассажа лоллирую:

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

хранить данные максимально эффективно, занимая минимум места на хранение и времени на обработку, и то и то достигается

Достигается. Точка.

И что? Ты осознаешь, что иногда «минимум места на хранение» означает неоправданное увеличение «времени на обработку»?

Это был сарказм.

расскажут про то, что в некоторых случаях скоро можно будет обновлять и частично

Чисто технически — никаких проблем. Проблема в том, что мы обычно можем иметь либо быстрое чтение, либо возможность делать inplace updates.

«Нативный хороший формат» вовсе не обязательно будет существенно лучше «текстовой мусорки» даже просто на чтение. И во многих случаях она будет более компактна, чем эквивалентные бинарные форматы.

Ну вот примеры.

{"var1":3,"var2":5,"var3":7}

03 00 00 00 05 00 00 00 07 00 00 00

Усложним.

{"var1":3,"var10":5,"var15":7}

01 00 03 00 00 00 0A 00 05 00 00 00 0F 00 07 00 00 00

Я тебе подскажу. Тебе нужно определить цель, для чего ты создаешь формат. Это может быть аналитика. Тогда формат должен обеспечивать минимальную трудоемкость доступа к элементам. В идеале — O(1) traversal без сериализации (когда запросы можно выполнять прямо над сырыми блоками памяти, поднятыми из хранилища). Или ты хочешь обеспечить минимальный размер хранилища. Тогда надо смотреть в сторону сжатых структур данных.

Это может быть обработка транзакций, и тогда хорошо бы иметь возможность обновлять документы за логарифмическое (от их размера) время. И это будет, опять же, совсем другая история. Поскольку мы не можем иметь O(1) одновременно и на чтение, и на вставку в произвольную позицию динамического массива.

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

И вот если ответы на эти все вопросы у тебя «я пока что не знаю», то твои эксперименты с «ужиманием» json-а могут дать совершенно контринтуитивные результаты. Поэтому, обычно предоставляют два формата: неоптимизированный текстовый и оптимизированный для общего случая O(1) traversal бинарный. Последнему, обычно, еще требуется и выравнивание элементов данных по границам блоков в 8 байт, так что он вряд ли будет компактным в плане затрат памяти.

Так зачем это всё переизобретать, если имеющийся движок базы уже всё, или почти всё, поддерживает, и безо всяких json'ов? Или мы сначала внедряем новый модный формат, потом обнаруживаем что он далёк от идеала и подпираем его костылями?

Само понятие «документа» - чуждое для реляционной базы данных. Оно не помогает ничему, вообще ничему. Если какое-то поле участвует в запросе - это колонка таблицы, и для неё уже давно придуманы все способы её оптимизировать в зависимости от нужд. Засовывание же её внутрь какого-то парсящегося формата - чистое вредительство.

Последнему, обычно, еще требуется и выравнивание элементов данных по границам блоков в 8 байт, так что он вряд ли будет компактным в плане затрат памяти.

А можно ещё выравнивание по 4096 байт сделать, тогда точно компактным не будет.

Оно не помогает ничему, вообще ничему.

Угу. Давай поговорим про представление иерархически структурированных данных в РСУБД и связанные с этим накладные расходы.

А можно ещё выравнивание по 4096 байт сделать, тогда точно компактным не будет.

Смысла нет. Раньше 16 байт делали, но сейчас для SIMD и 8 достаточно.

Вообще раз уж человеку нужно именно компактное хранение, то можно и какое-нибудь сжатие поверх поля прикрутить, как например snappy в leveldb.

Судя по комментам ничего другого не требуется. Хотя мне интересно, как бы он с таким форматом трансформацию базы делал бы.

Да и получить значение поля, если надо всегда вычислять оффсет по маске - не самая быстрая процедура. И это хорошо, когда схема известна (например те же flatbuffers). А когда общий случай? Да те же fb хранят не просто биты, а оффсеты, что опять же трата места.