Косякнул, из одной СУБД в другую. Из не-клика в клик

а чем принципиально отличается от delete? я имею в виду внутреннюю реализацию. я так понял и то и другое мутация, выше писали, что мутации не надежны и могут просто не работать. я понял, что быстрее, но имеет ли ту же надежность (ну или ненадежность :) ) ?

>буду изучать можно ли менять бизнес требования
>бизнес требования таковы, что все существующий данные по этому датчику за указанный период нужно заменить. т.е. не дописать строки, а все что есть удалить (или сделать недействительным)

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

UPDATE одной маленькой UInt8 колонки сильно быстрее, чем удаление данных

ok, буду пробовать. спасибо большое!

Так как лучше всего заливать данные например из MSSQL в ClickHouse, используя питон?

быстрее всего через bcp экспортировать в TSV и заливать через clickhouse-client
https://docs.microsoft.com/ru-ru/sql/relational-databases/import-export/import-and-export-bulk-data-by-using-the-bcp-utility-sql-server?view=sql-server-ver15

если одноразово
если нет, то можно и через python
нормально большими батчами

да, но bcp не умеет экранировать, поэтому можно убить кучу времени на него впустую. Я пробовал с одним клиентом, в итоге написали генератор CSV файлов на go который читал MSSQL и писал CSV.
python конечно тут использовать бессмысленно, только CPU насиловать

а кто-то использует clickhouse для хранения timeseries когда нужны низкие задержки на чтение?
имеется талица device_id UInt32, date_time DateTime, series_id UInt32, value Float32 ORDER BY (device_id, series_id, date_time).
колич строк ~ 1×10^12
все запросы простые - select * from table where device_id = ? and series_id = ? and date_time between ? and ? limit a offset b
rps низкий - 10-20 req/sec, но нужна latency на уровне сотен ms.
подходит ли clickhouse для этого? (чисто интуитивно - да, но это пока на уровне интуиции). кто-то имеет похожие случаи?

а если из вертики? Тоже через TSV?

я из вертики импорчу как TSV

по моему личному опыту из вертики быстро и удобно экспортировать в паркет.

а по скорости как? я может что делал не так, но экспорт в csv долго работал

быстро, я не мерял особо, я делаю так

echo "select * from " |Vsql -q -t -P format=unaligned | clickhouse-client

Parquet на ClickHouse импортится сейчас медленее TSV

Кстати, если уж тут идёт беседа про обновления данных. Мы в конторе планируем посадить на кликхаус систему финансовой аналитики. Там тоже возникают ситуации, когда с бирж приходят корректировки, и надо старые данные "обновить". Ну так вот, во время тестов на относительно небольшом куске данных в 80 миллиардов строк выяснилось, что делать выборку из ReplacingMergeTree правильным способом (с гарантией отсутствия дубликатов) получается как-то слишком медленно.

В качестве обходного пути мы сделали вот что: в таблице, где эти данные лежат, есть колонка с версией. Собственно версии хранятся в отдельной базе данных, в кликхаус периодически подгружаются как словарь и используются в запросах через dictGet. Обновление, в итоге, перестаёт быть обновлением, так как старые данные никогда не меняются.

Работает это гораздо быстрее чем ReplacingMergeTree, но мне интересно, возможно ли это сделать проще?

КХ читает и разжимает десятки мегабайт, даже если надо прочитать одну строку.

Ну и хотелось бы периодически старые версии подчищать в пределах одной partition. Но, читая этот чат, как-то страшно становится 😂

Да, решили.
Пользователю не хватало прав. А "клонов" сбросили перезапуском сервера.

а через пандас датафрейм имеет смысл пробовать или это плохая идея? Без файлов.