нет, интересует как мне жить через пол года на мускуле когда у меня каждый день по 50 млн записей -строк появляется

Зачем так жить? Если не нужны апдейты или они редкие и не нужны транзакции, а данные нужны только для хранения и анализа, то КХ подойдёт. Если вам нужно какие-то статусы менять точечно, то нет.

а ну логи кликов. Сорь, тупанул. Ок
Рефереры - айдишник реферера.
Клиенты - также айдишник клиента.
хз что за версии
ОС - опять же тупо айдишник
домен... ну норм люди уебут айдишник
география да опять же блин айдишник.
данные из кукисов - это уже many-to-many, которая даже не записывается в таблицу лога кликов.
Итого для наипиздатейшей метрики нам нужны 6 полей, содержащих лишь айдишники.

Ненене, никаких айдишников, все денормализовано и в сыром виде, как есть. Без джоинов или с минимальным количеством джоинов и то лучше всё-таки без них.

ну ок... вот у тебя 100 лярдов записей и тебе надо из этих 100 лярдов записей на хаусе получить список уникальных ОС тупо чтобы показать клиенту список по каким ОС можно отфильтровать логи. Ты ебанёшься по ним идти что вправо в КХ, что вниз в мускуле

Привет, подскажите где прописывать идентификационные данные для подключения к узлам clickhouse при использовании clickhouse-copier?

<Error> : virtual int DB::ClusterCopierApp::main(const std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >&): Code: 516, e.displayText() = DB::Exception: Received from test01.local:9000. DB::Exception: default: Authentication failed: password is incorrect or there is no user with such name.

то есть вы считаете что жить на мускуле при таких ежедневных объемах - будет не самое правильное ?

Почему? Вот у меня 3.5 млрд. Среди них есть около 760 уникальных значений в виде строк, на диске они занимают 3.6 MiB. Находятся так же достаточно быстро.

не, родной, никаких 3.5 лярдов. Мы же суперхайлоадяндексметрика с триллионами записей логов и у нас там ОС тупо указана строчкой в каждом логе.

Мне кажется ,через некоторое время, что мускуль, что постгрес на объемах в миллиарды записей на таблицу не очень удобно использовать. Новые записи вполне возможно ещё будут достаточно легко добавлятьсяи даже точечно редактироваться, но получить хоть какую-то полезную информацию из этих данных не будет представляться возможным за какое-то приемлемое время. То есть данные будут лежать мертвым грузом, не понятно зачем. Может я не прав, конечно и не умею готовить OLTP базы, но на обычном железе с такими объемами работать почти невозможно. Чтобы получить хоть какую-то полезную информацию нужно обязательно предагрегировать данные заранее.

Кликхаус позволяет при правильной организации из триллиона строк по условию WHERE вернуть запрос за меньше чем секунда.

Впрочем, судя по вашей лексике не уверен, что вы готовы слушать.

мускул при правильной организации в несколько лярдов строк вернёт ответ даже не задумавшись

Мсье путает разницу в объемах на 3 порядка?

Он может вернуть только пару записей точечно по конкретным айдишникам. GROUP BY по нескольким параметрам — вряд ли.

мускул при хранении в памяти связей many-to-many изнасилует ваш КХ даже не поперхнувшись

Я имел с РСУБД (postgresql) с миллиардами записями в 1 таблице, дернуть запись по индексу становится уже не так тривиально

когда у тебя индекс занимает гигабайт 20

Сколько будет занимать такая БД 200Гб?

нет