Clickhouse как основное хранилище? (as primary storage?)

[Юрий Андрющенко]

Привет!

Подходит ли Clickhouse как основное (долговременное) хранилище информации? 

Для примера можно рассмотреть вашу Метрику. Вы raw данные в clickhouse или уже подготовленные?

Если подготовленые данные, то где храните raw данные?

Спасибо.

[Александр Ат]

Добрый день, я не сотрудник яд. но пhочитав доку понял, если сильно хочется то можно, но у вас не будет возможности изменить данные после сохранения также как и удалить запись ( дорогая операция сaфеделит рулит )
Но можно это дело обойти, сделать версии данных и показывать последний ревизию документа, естественно все это нужно будет контролировать самим на уровне программы.

Плюсы в движке это обрабатывать данные за промежуток времени с быстрой скоростью выборки и вставки.
Идеально подходит для логов,статы/счетчиков, можно еще использовать в объявлениях

[man...@gmail.com]

В Метрике мы храним в ClickHouse подготовленные данные. Но эти данные (почти) не содержат потери информации по сравнению с сырыми данными и, наоборот, являются "обогащёнными" - то есть, содержат больше информации, чем сырые данные.

В ClickHouse мы храним данные за всё время, и данные за всё время храним только в ClickHouse.

ClickHouse удобно использовать для долговременного хранения данных, по следующим причинам:

- данные хранятся сравнительно компактно, и поэтому эффективность хранения может быть выше, чем при использовании других решений;

- в отличие от archive storage, подходящего только для "холодных" данных, ClickHouse позволяет выполнять аналитику по данным, быстрые выборки и т. п. в той же системе.

Кроме Метрики, есть применение в нескольких отделах, следующего вида:

- устанавливается несколько серверов с дисковыми полками максимального размера;

- туда записываются все логи некоторого сервиса и хранятся неограниченное время;

- запросов на чтение небольшое количество - по сути, система работает как архивное хранилище;

- система позволяет относительно быстро что-либо выяснить, когда возникают проблемы: корректность каких-то операций, исследовать проблемы со скоростью работы сервиса, находить причины ошибок и т. п.

[Юрий Андрющенко]

Спасибо за подробный ответ!

1. Какие возможны варианты при ошибочной вставке?

    - может ли произойти так, что произойдет вставка части пакета данных?

    - или если произошла ошибка, то гарантированно весь пакет данных не вставился?

2. Как вы реализуете отказоустойчивость операции вставки?

[man...@gmail.com]

1. При вставке, из потока данных сервер формирует блоки размером не более max_insert_block_size, по-умолчанию, 1 048 576 строк.
Если в одном запросе INSERT меньше строк, то данные будут вставлены одним блоком.
Вставка каждого блока атомарна - он либо полностью вставится, либо полностью не вставится.
В случае ошибки, ни одна строка не вставится.

2. Репликация в ReplicatedMergeTree работает в режиме multi-master: данные можно писать на любую доступную реплику (но только среди тех реплик, которые имеют сессию с ZooKeeper, то есть, из сегмента сети которых доступно большинство кластера ZooKeeper).

Также в ReplicatedMergeTree реализована идемпотентность вставки. Это значит, что при повторной вставке одного и того же блока данных (в том числе, возможно, запросом на другую реплику), блок данных будет записан только один раз.

При вставке блока данных, возможно три варианта:
- сервер вернул код 200 и данные успешно записаны;
- сервер вернул ошибку - тогда мы знаем, что данные не записаны;
- произошла сетевая ошибка и соединение разорвано - в этом случае данные либо полностью записаны, либо полностью не записаны, но мы не знаем, какой из этих двух вариантов произошёл.

В случае любой ошибки следует повторить попытку записи того же самого блока данных, возможно, обратившись к другой живой реплике. Когда мы получим успешный код ответа, мы знаем, что данные были записаны и знаем, что данные были записаны ровно один раз.

Таким образом, запись данных является отказоустойчивой. За исключением случаев, когда (при network partition) попытка записи происходит изнутри изолированного сегмента сети, из которого недоступен кворум кластера ZooKeeper. Пример: один из датацентров потерял связность с остальными и оказался изолирован. Обычно это не проблема, так как в таком сегменте сети нет новых данных для записи, либо запись данных можно отложить.

[Юрий Андрющенко]

Спасибо!

[Igor Spirin]

И все же интересно, можно ли в будущем добавить возможность изменения/удаления или только удаления хотя бы для администрирования? В чем проблематичность реализации этой фичи? 

Например в процессе работы что то пошло не так и в базу попали некорректные данные. Соответственно их надо удалить или подправить. В этом случае получается надо всю таблицу перекопировать, внося походу дела нужные изменения в нужные записи, что неудобно и не быстро. 

[man...@gmail.com]

Да, мы хотим добавить возможность удаления.
У нас тоже периодически возникает такая потребность, также есть заказ от нескольких отделов внутри.
Значит придётся делать.

[Max Lapshin]

Звонят люди и просят раскликать клики из яндекс метрики обратно? =)

[Nick]

Когда приблизительно можно ожидать функционал удаления строк из MergeTree?

[man...@gmail.com]

Нескоро. Я даже не уверен, что получится до следующего года.

[Ruslan]

А в чем сложность пометить данные как удаленные на уровне движка и не отображать их в выводе? По факту сам ключ будет скрытой колонкой типа Bool/UInt8, и при удалении значение 0 сменится на 1. Это никак не скажется на фрагментации данных на диске и не повлияет на производительность. Или я ошибаюсь?

вторник, 16 августа 2016 г., 1:33:07 UTC+5 пользователь man...@gmail.com написал:

[man...@gmail.com]

Всё верно. Это один из способов реализовать удаление данных, причём именно его мы рассматриваем как основной вариант.
Сложность в том, чтобы аккуратно протащить это через механизм репликации. Есть неудобства.