Re: Особый способ хранения в базах Postgres - Mailing list pgsql-ru-general
| From | Igor Polishchuk |
|---|---|
| Subject | Re: Особый способ хранения в базах Postgres |
| Date | |
| Msg-id | 2C12266B-7581-49F3-8B56-798974B09677@gmail.com Whole thread Raw |
| In response to | Re: Особый способ хранения в базах Postgres (Dmitriy Resnyanskiy <zubosem@gmail.com>) |
| List | pgsql-ru-general |
Michael, Sorry for the English, but with the Google Translator, should not be a problem I guess.
if you care to answer, Russian would be good to me to read, too :-)
Have you considered using JSONB for the schema flexibility (storying all the fields that might be changed or aded on the fly)?
Wouldn't it solve most of your problems?
What you described below is clever, but seems complex. I suspect people who need to support such a solution may have many complexity related issues.
It might be difficult to understand well, no? Has somebody besides the original authors looked at it and was comfortable with supporting it?
The proposed approach seems the archetype of all the RDBMS schema anti-patterns. The described solution is not using strong side of RDBMS provided with normalization, like automatic relational consistency enforcement for example. In such case, why use Postgres at all? Why not consider lighter weigh key-value store?
You mentioned the performance tests worked ok to you. Did you test on a high scale? Does your approach still perform well with hundreds of millions of records and few hundred gigabytes of data? I suspect, it may have problems.
Perhaps, you decided the you don't need it, and your application will never grow that big. Well, in the 1960s, the computer engineers never thought we would need more than two digits for a year. It caused a lot of issue 40 years later. I guess, you not always can guarantee that your application wil never reach sustain size.
I don't want to rain on your parade. If it works for you, great. You just asked about opinions, and this is what I've thought about this solution.
Thank you
Igor Polishchuk
On Jun 15, 2021, at 09:52, Dmitriy Resnyanskiy <zubosem@gmail.com> wrote:Спасибо всем вам за ваши ответы. Приятно слышать, что мы не совсем дичь сделали :) Мы проверяли эту структуру на Фиасе, работает очень шустро. Правда, очевидно, что этому предшествовала недельная загрузка данных. Хотя нас это по-моему не пугает.Хочется, конечно, услышать от вас гипотетические проблемы, которые могут возникнуть от такого размещения данных, ну кроме увеличенного времени вставки объектов. Я, к примеру, знаю, что постгрес открывает на каждую существующую таблицу и индексы файловый дескриптор. А в операционных системах, насколько мне известно, их количество ограничено. И еще хотелось бы узнать, почему постгрес "проседает", если сортировать ORDER BY по нескольким индексированным свойствам разных таблиц одновременно? Хотелось бы узнать техническую причину такого поведения. Я себе представляю, что для такой сортировки постгрессом создаётся временная таблица, я правильно мыслю?Спасибо.вт, 15 июн. 2021 г., 8:35 Михаил <m.nasedkin@gmail.com>:Я тоже такими вещами занимался, когда по молодости кровь кипела, а
проектов толком не было. Вариаций на данную тему миллион. Вашу работу
одобряю. Мало кто захочет ее применять, потому что, например, я сейчас
в около средней конторе, где бэк-программисты вообще не видят чистого
скуля, с БД оперируют модельные обертки. А мне приходится смотреть на
это в тоске и печали.
Благ и удачи.
27.05.2021, Dmitriy Resnyanskiy<zubosem@gmail.com> написал(а):
> Всем привет!
>
> Меня зовут Дмитрий, я решился написать сюда, надеюсь, что попал правильно.
> При проектировании БД нередко сталкиваешься с проблемами хранения:
>
> 1. Хранение и расширение каких-нибудь профайлов чревато альтерами (ALTER
> TABLE) в разрастающихся таблицах.
> 2. Непонятно, как изящно связывать части профайлов, объектов, как
> собирать и прочее.
> 3. Возникают сложности с индексацией, потому что хочется искать по всем
> полям, а индексы на всю таблицу не повесишь, ну или это создаст другие
> проблемы.
> 4. Всегда хочется единый идентификатор для всей номенклатуры объектов в
> базе данных, чтобы, например, в Кликхаус поставить на него ссылку и
> легко
> забирать исчерпывающие данные из внешнего словаря.
>
> Использовать обычную реляционную схему проектирования проблематично по
> каждому указанному пункту. Поэтому у нас появилась идея разбить поля по
> отдельным таблицам (таблицам значений), в которых поле значения
> индексировано.
>
> 1. Запись о существовании объекта создается в таблице объектов - тут же
> и создаются уникальные идентификаторы для всех объектов в системе
> (PRIMARY
> KEY id).
> 2. Все таблицы значения имеют поля с идентификатором объекта, которому
> это значение принадлежит.
> 3. Поля и типы объектов описываются в специальных таблицах для типа и
> ключа соответственно.
> 4. Специальные триггеры при вставке записи в таблицы типа и ключа
> создают новую уникальную таблицу в системе, где будут храниться значения
> объектов.
> 5. В системе созданы функции, которые собирают объекты и сохраняют,
> распределяя данные по таблицам значений.
> 6. Для контроля целостности данных из нескольких полей создаются
> специальные таблицы с составными индексами, которые вместе со
> специальными
> триггерами позволяют правильно записывать и контролировать уникальные
> поля
> объектов.
> 7. Трехэтажными джоинами по индексированным полям можно быстро
> "дотянуться" до любых данных объекта.
>
> Нам очень интересно ваше мнение о проделанной работе. Пожалуйста, взгляните
> на нее экспертным взглядом и укажите на проблемы и недостатки такого
> подхода.
> Возможно, уже давно есть технологии, фреймворки, которые отталкиваются от
> тех же задач и проблем, пожалуйста, дайте ссылки на них почитать.
> Код не претендует на совершенство и, скорее всего, стоит надеть специальный
> костюм ассенизатора, прежде чем туда заглянуть ;)
> Не судите строго, большое спасибо.
>
--
---
С уважением,
Михаил Наседкин
pgsql-ru-general by date: