И спам

В принципе, пацаны строят continuous delivery...

никак не построят?)

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

Коллеги, а в chef в рецепте можно определить с какой роли его запустили ?

Коллеги вот было задумано использовать редис как базу данных. Раньше редис юзал и как-то не задумывался че к чему .ибо хранил хрень всякую. мало объема и мало вставок и чтения. Сейчас понадобилось много вставок и много чтения.... и тут я узнал, что редис однопоточный.... что означает, что пока не запишется все, что надо - чтения не будет и наборот. Это че правда так? Может кто пояснить в двух словах есть ли многопоточность или оно как-то обходиться. я читал про типа много процессов на разных портах.... это тоже лажа какая-то

видимо все работают:)

Все так и есть

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

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

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

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

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

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

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

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

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

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

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

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

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

+1 к идеи выше

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И как писатт

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

кх с диска

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

сейчас опишу

у нас очень ограничена инфраструктура. у нас уже есть сервер без реплик кх. читает так себе. там конечно стоят 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 строке