DC
в EmbeddedRocksDB можно менять строки инсертом
Size: a a a
2021 February 25
PK
в EmbeddedRocksDB можно менять строки инсертом
Не работал с этим инструментом, изучу, спасибо!
DC
или ReplacingMergeTree + optimize final
DC
Всем привет! У меня такой пайплайн: Есть таблица MergeTree, в которую сыпятся данные по 5млн товаров несколько раз в день. Эта таблица не меняется, только дополняется. Для того, чтобы cэкономить место, данные по товарам (названия, категории, поставщики и пр.), я сохраняю в отдельную таблицу с движком Join. Это позволяет и экономить место и делать разные аггрегации. Однако, я хотел бы в таблице Join менять только изменяющиеся данные, а не перезаливать 5млн товаров несколько раз в день (например, обновить только 100тыс товаров). Мне продолжать сидеть на Join или лучше смотреть в другие движки, например ReplacingMergeTree (которые удаляет дубликаты, но не сразу)
кстати откуда данные берутся? Может просто словарь все сам сделает? И заливать вообще не надо
PK
или ReplacingMergeTree + optimize final
А подскажите, в документации не совсем понятно, OPTIMIZE сразу по окончании выполнения обеспечивает отсутствие дублей?
PK
Или это фоновая задача?
DC
А подскажите, в документации не совсем понятно, OPTIMIZE сразу по окончании выполнения обеспечивает отсутствие дублей?
синхронно выполняется, optimize final вернет управление когда мерж закончится
PK
кстати откуда данные берутся? Может просто словарь все сам сделает? И заливать вообще не надо
Данные агрегируются из Postgres предварительно
DC
Данные агрегируются из Postgres предварительно
ну так можно словарем ходить во вью в PG
DC
и не хранить это в КХ вообще
PK
Ну если данные не будут храниться в КХ, такой скорости, как при работе с таблицой Join для аггрегации не получится же?
PK
Поизучаю EmbeddedRocksDB, интересно)
PK
Спасибо за помощь!
S
Ну если данные не будут храниться в КХ, такой скорости, как при работе с таблицой Join для аггрегации не получится же?
вы про словари подробнее почитайте и про функцию dictGet вместо JOIN
они будут либо кешироваться в памяти clickhouse
либо целиком лежат в зависимости от layout словаря
они будут либо кешироваться в памяти clickhouse
либо целиком лежат в зависимости от layout словаря
PK
вы про словари подробнее почитайте и про функцию dictGet вместо JOIN
они будут либо кешироваться в памяти clickhouse
либо целиком лежат в зависимости от layout словаря
они будут либо кешироваться в памяти clickhouse
либо целиком лежат в зависимости от layout словаря
Почитаю, спасибо!
DC
Ну если данные не будут храниться в КХ, такой скорости, как при работе с таблицой Join для аггрегации не получится же?
словарь как и engine=join хранит данные в озу CH в хештаблице
PK
словарь как и engine=join хранит данные в озу CH в хештаблице
Ага, и как прочитал из документации, можно настроить обновление при изменении поля (например, дата обновления). Похоже на то, что нужно
DC
Ага, и как прочитал из документации, можно настроить обновление при изменении поля (например, дата обновления). Похоже на то, что нужно
можно даже обновлять частично.
если в PG есть поле updated_at (или типа того)
можно в КХ словарь втягивать where updated_at > дата_пред_обновления
с помощью update_field
<source>
<mysql>
<update_field>updated_at</update_field>
если в PG есть поле updated_at (или типа того)
можно в КХ словарь втягивать where updated_at > дата_пред_обновления
с помощью update_field
<source>
<mysql>
<update_field>updated_at</update_field>
PK
Да, есть такое поле, тоже как раз прочитал об этом. Буду пробовать)
CO
Всем привет, не подскажите что такое metadata
Хочу сделать копии парочки таблиц в другую БД.
В доках рекомендуют также это копировать, но не понятно зачем и для чего )
Хочу сделать копии парочки таблиц в другую БД.
В доках рекомендуют также это копировать, но не понятно зачем и для чего )