Д
На счет строк не в курсе. Ребят, в компании биг дата . Поэтому размах такой
Size: a a a
2019 July 05
PG
Но 10к полей в принципе плохая практика, как с точки зрения хранения, возможна больша разреженность, так и с точки зрения порога входа в витрину
PG
Разве что на вход моделей
RM
Они хотят все в одной витрине видеть и обращаться к ней. То есть в последующем они будут только эту витрину юзать. И на основании ее дальше строит другие витрины.
Одна максимально «широкая» таблица в общем случае - антипаттерн. В частном случае - имеет право на жизнь. Ваш случай - пока непонятен. 😬
Д
Rustem Mannanov
Одна максимально «широкая» таблица в общем случае - антипаттерн. В частном случае - имеет право на жизнь. Ваш случай - пока непонятен. 😬
Мне как архитектору сказали , поразмыслить. Пока точное количество не сказали. Будет ясно в конце месяца :) а пока живем
PG
В hbase 1000+ столбцов вроде делают и это нормально. Сам не делал, рассказывали)
S
я уж молчу про гемор разработки и доставки кода для etl на кафке
почему?
S
в чем гемор?
VS
Ну так не sqlки писать же надо будет...
S
Ну так не sqlки писать же надо будет...
Ksqlки)
2019 July 07
LV
Они хотят все в одной витрине видеть и обращаться к ней. То есть в последующем они будут только эту витрину юзать. И на основании ее дальше строит другие витрины.
Смотря какие данные. Если у вас в одной сущности 12000 атрибутов (у нас так условно),это одна история. Если 1000 сущностей по 12 атрибутов - другая
LV
У нас elastic search для поиска, minio для хранения исходных и может что-то еще будет
RM
Смотря какие данные. Если у вас в одной сущности 12000 атрибутов (у нас так условно),это одна история. Если 1000 сущностей по 12 атрибутов - другая
Что за сущность и примерно что в атрибутах можете озвучить? Интересно.
LV
Записи росреестра. Там хитро. Для нас сущность это любая запись росреестра, хотя по факту их порядка 30. Но из-за хитро сделанного наследования и переиспользования типов внутри, фактически к нам они приходит в одном формате и если разложить построить дерево всех окончательных атрибутов, их будет порядка 15 000. Форматом хранения мы не управляем.
PD
Я бы поставил тест на том же CH и на вертике. Или хотя бы в профильных чатиках спросил.
RM
Записи росреестра. Там хитро. Для нас сущность это любая запись росреестра, хотя по факту их порядка 30. Но из-за хитро сделанного наследования и переиспользования типов внутри, фактически к нам они приходит в одном формате и если разложить построить дерево всех окончательных атрибутов, их будет порядка 15 000. Форматом хранения мы не управляем.
Спасибо за пояснение, стало понятнее. Активное «наследование сущностей» действительно иногда становится болью для хранилища. Тут наверное только тест, причем я бы возможно, еще проверил бы не только субд, но и 2-3 гипотезы «нормализации» данной схемы в хранилище. Хоть и входом не управляете - етл то надеюсь в пределах досягаемости) Гипотезы скорее будут «специфичными» для конкретной субд. Те же самые массивы в кх например - вполне вариант на подумать и проверить. В вертике - поиграть с разными проекциями и типами. Исходя из тех данных которые есть - вертика и кх хороший выбор. Гринплам - насколько помню имеет-таки ограничения по количеству возможных полей, ибо постгрес под ногами, но это не точно )
2019 July 09
GM
Добрый день! Поделитесь опытом как вы отображаете данные в модели информационного взаимодействия между системами?
GM
может быть есть какие-то шаблоны модели, либо можете по сути того что и как там должно быть отображено подскажете
e
excel
2019 July 12
CO
Всем приветик))