Все так и есть

Он синг тред. Не просто один процесс, а прям и один поток

И как бы редис как бд так се затея

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

объем данных не очень большой.

оперативы хватает.

Это называется кеш, но данные лучше еще где-то хранить

ну я думал данные хранить в тех файлах, которые редис сам и создает

Рассматривай redis как memcached.

ну я думал данные хранить в тех файлах, которые редис сам и создает

Как только все бд не влезет в память (а такое таки когда-то наступит), то будет печально

А так редис можно масштабировать на чтение слейвами

кассандру в руки ?

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

+1 к идеи выше

Редис однопоточен, кстати - если память позволяет, ребята часто поднимают несколько редисов прямо на одном серваке, как раз с репликацией

Редис однопоточен, кстати - если память позволяет, ребята часто поднимают несколько редисов прямо на одном серваке, как раз с репликацией

Это скейлит чтение путем дублирования данных в памяти. Такое се.

такое, но очень быстрое)

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

А нужен ли для этого тул? Ну в том плане что делаешь insert в бд и сразу же в редис данные добавляешь? Прогревать только при рестарте редиса надо будет.

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

+100500 редис - in-memory кэш для "горячих" данных, которые есть где-то ещё и которые не жалко про... протерять, в общем.

А нужен ли для этого тул? Ну в том плане что делаешь insert в бд и сразу же в редис данные добавляешь? Прогревать только при рестарте редиса надо будет.

Это все равно тулинг, пусть и встроенный в ваш код )

Я скорее подразумевал что какой то функционал, который наполняет редис, где он будет вопрос третий

а что посоветуете из многопотомчного?

бд, которую ты знаешь?

ты про кликхаус?

или я не понял вопроса)

по факту готов разобраться в любой БД. думал может есть какая-то класика

надо часто писать и и редко, Но сложно читать

Вопрос в том как надо читать

И как писатт

Апдейты, делиты

никаких апдейтов и деликтов

только инсерт и селект

по сути это статистика

пишем часто, читаем по запросу

ты про кликхаус?

Ну тогда он выглядит нормально, как раз под статистику и аналитику

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

оператива на скорость не влияет.

она нужна - много - но не влияет.

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

Дисковый кэш тебя несколько спасет)

касандра смотрится по очень неплохо по одной из записей конфы

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

посмотри аэроспайк правда он счас платным стал

платный сразу нет:(

ну или кх тоже подходит

интересно, что б ыстрей кх или касандра

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

кх с диска

что быстрей сишечка или жава

я понимаю что вопрос такой себе

да и задачи они разные решают

оператива по идее намного быстрей отдает. плюс в кх много лишнего

Хм... а кх умеет в оперативу складывать данные? ну типа кеша какого нить

интересно, что б ыстрей кх или касандра

кх будет быстрее при грамотном использовании (судя по тому чт оты описал). Интереснее сравнить со сциллой

Хм... а кх умеет в оперативу складывать данные? ну типа кеша какого нить

https://clickhouse-docs.readthedocs.io/ru/latest/table_engines/memory.html

но не очень понятно зачем тебе это

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

ибо вероятно что тебя все устроит и тебе будет плевать что там диск

оператива по идее намного быстрей отдает. плюс в кх много лишнего

опиши задачу подробнее, тогда можно будет подсказать что ты понимаешь не так, что понимаешь так и сделать предположения как оно у тебя будет

мне просто кажется ты не понимаешь что хочешь

у нас очень ограничена инфраструктура. у нас уже есть сервер без реплик кх. читает так себе. там конечно стоят hdd диски в raid 10

и страдаешь преждевременной оптимизацией

сейчас опишу

ERROR: S client not available

у нас очень ограничена инфраструктура. у нас уже есть сервер без реплик кх. читает так себе. там конечно стоят hdd диски в raid 10

какого рода запросы? какие индексы? что значит "так себе"?

Ко м не приходят данные из очереди. Приходит строка. паршу строку и полчаю около 10 параметров со значениями. по сути 9 из этих 10 параметров являются набором, по которому нужно хранить список 10ого параметра. Грубо говорят количество уникальных записаей этого (10ого) параметра. И в дальнейшем, чтобы можно было быстро получать кол-во уникальных записей 10ого параметра по запросу-фильтру, который может в себя включать любой из 9 параметров, что в ключе или все сразу.

думаю сложно описал)

Ко м не приходят данные из очереди. Приходит строка. паршу строку и полчаю около 10 параметров со значениями. по сути 9 из этих 10 параметров являются набором, по которому нужно хранить список 10ого параметра. Грубо говорят количество уникальных записаей этого (10ого) параметра. И в дальнейшем, чтобы можно было быстро получать кол-во уникальных записей 10ого параметра по запросу-фильтру, который может в себя включать любой из 9 параметров, что в ключе или все сразу.

у тебя в ключе все 9 параметров и выборка всегда по всем 9и?

выборка может быть по любому из них или нескольким

и нужно делать какую-то математику (условный uniq() ) 10-ого в зависимости от того какие первые 9?

что запросят по тому и фильтровать

ну КХ не любит множественные индексы во первых. В смысле если у тебя есть прям типичные группы параметров которые есть всегда (или почти всегда) в where, их стоит вынести в индекс, а остальные, возможно, даже не надо перечислять. Или даже сделать 9 таблиц с разными индексами (по каждой из колонок)

это раз

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

вставки щас как раз решаются как делать. но вообще не пробелма сделать раз в 5 секунд закидывать агрегарированные данные

вставки щас как раз решаются как делать. но вообще не пробелма сделать раз в 5 секунд закидывать агрегарированные данные

можно и сырые данные, главное помнить что кликхаусу намного прям легче работать когда у тебя 1 инсерт на 1М строк, чем когда 1М инсертов по 1 строке

и это же ускоряет чтение в том числе

и хотя бы буффер-таблица для вставок, или нативное чтение из кафки - поможет.

или чтобы писатели писали пореже

Владимир спасибо. Что касается лучше сразу много, чем много раз по одному - это вообщем-то известно). это касается почти всех баз в разумной мере. мне видимо не хватает знаний по кх. а тчо значит нативное чтение из кафки?

@Civiloid

Владимир спасибо. Что касается лучше сразу много, чем много раз по одному - это вообщем-то известно). это касается почти всех баз в разумной мере. мне видимо не хватает знаний по кх. а тчо значит нативное чтение из кафки?

https://clickhouse.yandex/docs/en/single/index.html#document-table_engines/kafka

ваще @clickhouse_ru там есть и разработчик и комьюнити большое

https://clickhouse.yandex/docs/ru/single/#kafka или так

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

Владимир спасибо. Что касается лучше сразу много, чем много раз по одному - это вообщем-то известно). это касается почти всех баз в разумной мере. мне видимо не хватает знаний по кх. а тчо значит нативное чтение из кафки?

у КХ это просто более ярко выражено. Фактически каждый инсерт - 1 файл. Есть фоновый процесс который склеивает файлы в более жирные, но он фоновый.

файлы сортированы внутри по индексу

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

это несколько менее больно во многих других базах просто

@asya_ivanova будет жить. Поприветствуем!

@dvragulin будет жить. Поприветствуем!

@Zaklad71 будет жить. Поприветствуем!

Тонкая настройка балансировки нагрузки https://habr.com/post/423085/