Size: a a a

DBA - русскоговорящее сообщество

2021 April 16

9ૐ

911RS ૐ in DBA - русскоговорящее сообщество
Пфф
источник

9ૐ

911RS ૐ in DBA - русскоговорящее сообщество
101
источник

9ૐ

911RS ૐ in DBA - русскоговорящее сообщество
Наше все
источник

9ૐ

911RS ૐ in DBA - русскоговорящее сообщество
Нужен же запас
источник

9ૐ

911RS ૐ in DBA - русскоговорящее сообщество
источник
2021 April 18

Y

Yaroslav in DBA - русскоговорящее сообщество
Коллеги, спрошу у Вас совета, по поводу дизайна таблиц.

Есть события, у каждого события есть тип type и его метаданные meta, хранящиеся как jsonb: достаточно увесистые, и одинаковые по структуре для каждого типа события. Хочется это нормализовать - хранить вместо meta поле external_data_id, а при получении события делать join силами бекенда: по type выбирать таблицу, а по external_data_id вытаскивать нужные данные. Что думаете по поводу такой реализации? Сталкивались ли с таким? Какие могут быть проблемы?
источник

MZ

Maxim Zadonskiy in DBA - русскоговорящее сообщество
Посоветуйте, на чём можно потренировать экстракты?
источник

MZ

Maxim Zadonskiy in DBA - русскоговорящее сообщество
Может где-то БД есть для этого
источник

TV

The Vladimir in DBA - русскоговорящее сообщество
а как в запросе выбрать таблицу для конкретного type? в запросе же указывается четкий перечень таблиц
источник

Y

Yaroslav in DBA - русскоговорящее сообщество
в следующем запросе к бд: после получения данных от первого запроса, смотрим на тип сущности, по типу определяем таблицу и идем в бд и забираем данные из нужной таблицы
источник

TV

The Vladimir in DBA - русскоговорящее сообщество
если запросы так генерятся на лету - прекрасно, должно сработать, но в чем цель разбиения общей кучи событий на подтаблицы? с каждым типом событий будет отдельная работа?
источник

TV

The Vladimir in DBA - русскоговорящее сообщество
оно в общем то и в общей куче может хорошо лежать, смотря какая субд, смотря какие объемы и как быстро надо выборку производить
источник

Y

Yaroslav in DBA - русскоговорящее сообщество
большой средий размер сущности - по 5КБ и прилетает их по 20млн в день, поэтому цель - избавится от дублирования произведя частичную нормализацию
источник

TV

The Vladimir in DBA - русскоговорящее сообщество
не заметил по описанию избавления от дублирования, простая разбивка кучи на подкучи. Выигрыш будет если этих подкуч не сильно много, чтобы их можно было раскидать по разным файлам/дискам например. И если выборка будет из меньшего объема только одного type - уже хорошо
источник

TV

The Vladimir in DBA - русскоговорящее сообщество
если запросы генерятся на лету (считай динамический sql) - можно и так спокойно жить, а если в будущем будет переход на ORM или фиксированный SQL тут придется подумать, но даже перепроектировать думаю не проблема будет, т к удобно, что есть одна заголовочная (шапочная) таблица событий
источник

PD

Phil Delgyado in DBA - русскоговорящее сообщество
Ну, вроде бы нагрузки мало, не совсем понимаю, чем "зонтик" будет удобнее схемы с jsonb
источник

TV

The Vladimir in DBA - русскоговорящее сообщество
95 гигов в день прирастает однако)
источник

PD

Phil Delgyado in DBA - русскоговорящее сообщество
5KB - это в базе живет или размер json?
jsonb изрядно переделывает входящий json для внутреннего хранения
и не понятно, почему хранение в таблицах будет сильно выгоднее.
источник

PD

Phil Delgyado in DBA - русскоговорящее сообщество
Проще формат внутреннего json переделать, уменьшить размер ключей, например.
Но не вижу причин, по которым выигрыш в схеме с зонтиком был бы реально заметен.
источник

Y

Yaroslav in DBA - русскоговорящее сообщество
А почему зонтик? :)

Да, 5кб это полный документ в json строкой, jsonb в 10 раз меньше, что уже не так критично. Там выигрыш будет в том, что можно дедуплицировать много того, что хранится в jsonb (например, приходит 1млн событий с одинаковым и большим текстом). Но если понадобится это можно сделать просто заменив этот текст на какую-нибудь ссылку на другую таблицу. Благодарю за помощь!
источник