PD
А что с данными дальше будет происходить?
Size: a a a
2021 April 28
Y
по одной колонке поиск постоянно, по остальным раз в несколько месяцев
ES
Ну если у Вас 1 ярд таких ячеек, то это каких-то 40 гигов на диске, много?
PD
Постоянно - это сколько раз в секунду?
Так, если нужно минимизировать хранение, то можно посмотреть на тот же Clickhouse, там много вариантов настроить сжатие эффективным способом. Но если подойдут прочие его ограничения.
Но 40 Gb - это мало, конечно.
Так, если нужно минимизировать хранение, то можно посмотреть на тот же Clickhouse, там много вариантов настроить сжатие эффективным способом. Но если подойдут прочие его ограничения.
Но 40 Gb - это мало, конечно.
Y
ну в принципе не особо много, если это действительно так
Y
я думаю что писаться будет со скоростью 10к ячеек в секунду минимум, если железо выдержит. а по поводу поиска: на постоянку нужна только проверка уникальности, что я и имел ввиду под поиском(скорее всего не совсем был прав).
про кликхаус тоже думал в первую очередь, но не совсем понятно насколько он хорошо работает с добавлением значений в уже существующую строку
про кликхаус тоже думал в первую очередь, но не совсем понятно насколько он хорошо работает с добавлением значений в уже существующую строку
ES
Вы или что-то не договариваете или приукрашиваете, если по 10к записей в секунду летит - ярд записей в таблицу за пару дней навалится.
Y
дело в том, что кластер писателей пока не готов, поэтому точную скорость записи выдать сложно
сейчас на бумаге это выглядит так: есть одна таблица, с примерно 100 колонок.
1-я колонка ключевая, уникальная. в остальные колонки пишутся данные. либо сразу во все, либо в часть.
примерная скорость генерации данных - 10к ячеек в секунду.
сейчас на бумаге это выглядит так: есть одна таблица, с примерно 100 колонок.
1-я колонка ключевая, уникальная. в остальные колонки пишутся данные. либо сразу во все, либо в часть.
примерная скорость генерации данных - 10к ячеек в секунду.
PD
Если это не update, а переписывание - то нормально.
Если нужно именно обновить часть данных, то тоже есть инструменты.
Если нужно именно обновить часть данных, то тоже есть инструменты.
Y
запись может быть только в ячейку, в которой null, например было
стало:
010,111,null,101
стало:
010,111,110,101
ES
Возьмите тот же Постгрес, если транзакции не нужны - отключите журналирование таблицы, писать и обновлять будет моментом.
10к записей в сек вытянет на нормальном железе.
10к записей в сек вытянет на нормальном железе.
PD
Ну, можно писать пачками, тогда тоже будет быстро.
10 rps - это не проблема сейчас
10 rps - это не проблема сейчас
Y
Спасибо, попробую кликхаус, т. К. Давно хотел, ну и может потом уже в работе сравню с тем же постгрессом
n
Всем добрый день. Имею такую архитектуру БД. Есть пару вопросов. Таблица камеры и кабель имеют одни и те же название полей. И поля из этих таблиц ссылаются на таблицу описание. Как вы считайте, как лучше переделать эти моменты, и надо ли? Надо ли в таблице описание добавить и сделать поле ID ключевым?
ES
Чем Вас классика не устраивает, типа:
product_types(product_type_id, type);
products(product_id, product_type_id, name, description);
product_properties(product_property_id, product_id, property_name, property_value);
Зачем еще что-то мудрить?
product_types(product_type_id, type);
products(product_id, product_type_id, name, description);
product_properties(product_property_id, product_id, property_name, property_value);
Зачем еще что-то мудрить?
YS
Может, тем, что эта "классика" — это поганый EAV, и реляционной моделью не является? ;)
ES
Так Вам шашечки или ехать? (с))
YS
Ехать. Желательно, не в ад. ;)
n
Так я же сам делаю.можно по образу сделать, но это как копе пасте. Вообщем, кастом,
n
походу я с таблицей категория лажанул серьёзно