LINUX.ORG.RU

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

 , , , ,


0

2

30 сентября в Нижнем Новгороде пройдёт PGConf.NN - бесплатная техническая конференция по СУБД PostgreSQL. Организаторы — компания Postgres Professional и ассоциация IT-компаний iCluster. Начало докладов — в 14:30. Место проведения — технопарк «Анкудиновка» (ул. Академика Сахарова, д. 4).

Доклады:

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

  • «Обзор возможностей резервного копирования в PostgreSQL и Postgres Pro» — Иван Фролков, ведущий инженер Postgres Professional;

  • «SQL vs NoSQL» — Дмитрий Адмакин, руководитель отдела разработки БАРС Груп.

Регистрация на мероприятие открыта на сайте PGConf: https://pgconf.ru/202109

>>> Подробности



Проверено: hobbit ()

Ответ на: комментарий от firkax

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

aist1 ★★ ()
Ответ на: комментарий от aist1

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

firkax ()
Ответ на: комментарий от firkax

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

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.

aist1 ★★ ()
Ответ на: комментарий от aist1

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

aist1 ★★ ()

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

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

anonymous ()
Ответ на: комментарий от anonymous

Эшо …

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

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

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

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

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

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

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

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

powerguy ★★★ ()
Ответ на: комментарий от anonymous

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

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

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

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

dummy ★★ ()
Последнее исправление: dummy (всего исправлений: 7)
Ответ на: комментарий от aist1

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

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

"Хотят", но не УМЕЮТ ...
anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

aist1 ★★ ()
Ответ на: комментарий от anonymous

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

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

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

Стакан СКИПИДАРА для лечения всех болезней ...
anonymous ()
Ответ на: комментарий от aist1

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

JSON бороздит Большой PG
``
anonymous ()
Ответ на: комментарий от aist1

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от firkax

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

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

Miguel ★★★★★ ()
Ответ на: комментарий от Miguel

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

firkax ()
Ответ на: комментарий от firkax

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

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

Miguel ★★★★★ ()
Ответ на: комментарий от Miguel

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

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

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

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

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

firkax ()
Ответ на: комментарий от firkax

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

firkax ()
Ответ на: комментарий от firkax

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

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

anonymous ()
Ответ на: комментарий от aist1

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

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

theNamelessOne ★★★★★ ()
Ответ на: комментарий от aist1

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

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

theNamelessOne ★★★★★ ()
Ответ на: комментарий от theNamelessOne

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

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

aist1 ★★ ()
Ответ на: комментарий от firkax

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

aist1 ★★ ()
Ответ на: комментарий от aist1

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

{"var1":3,"var2":5,"var3":7}
Допустим, других полей не предполагается, тогда бинарное представление будет:
03 00 00 00 05 00 00 00 07 00 00 00
+ где-то 3 бита-флага что они не NULL. По-моему, эти 12 с половиной байт явно короче json'а. И это при том, что, возможно, оно и не 32-битное 8-битное, тогда будет 3 с половиной байта.

Усложним.

{"var1":3,"var10":5,"var15":7}
Допустим, бывают ещё var2..var9, var11..var14, var16..var1000 но обычно из них присутствуют лишь несколько и мы не хотим тратить целых 1000 бит (125 байт) на NULL-флаги для них. Тогда: 1) в описании таблицы - словарь типа 1=«var1», 2=«var2» итд 2) в данных:
01 00 03 00 00 00 0A 00 05 00 00 00 0F 00 07 00 00 00
Итого 18 байт - опять короче json'а, ну и читать это явно проще - названия столбцов вынесены в описание таблицы (они на логику влиять не должны), при этом гибкость в указании только нужных полей, и в динамическом расширении списка доступных - осталась, но при этом легко доступно индексирование. Сложность модификации - не более чем у обычных maybe-null полей.

firkax ()
Ответ на: комментарий от firkax

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

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

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

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

aist1 ★★ ()
Последнее исправление: aist1 (всего исправлений: 1)
Ответ на: комментарий от aist1

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

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

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

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

firkax ()
Ответ на: комментарий от firkax

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

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

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

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

aist1 ★★ ()
Ответ на: комментарий от aist1

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

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

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

anonymous ()