Comments 19
А где же комменты, критика и прочие безобразия?
Недавно Twitter выпустил некий Storm — github.com/nathanmarz/storm — и описания вашей задачи и этого шторма по крайней мере похожи. К сожалению, я так пока и не понял что именно делает этот шторм, и что конкретно у вас за задача; в частности, почему именно выбор пал на Redis&K (сравнения, показатели, функционал…).
Вопросы: Не пробовали ли? Не примеряли ли? Как и почему подходит или не подходит? Мне на среднюю перспективу тоже нужна реал-таймовая система обработки большого потока событий, вот и смотрю на чужие опыты на этой полянке.
Вопросы: Не пробовали ли? Не примеряли ли? Как и почему подходит или не подходит? Мне на среднюю перспективу тоже нужна реал-таймовая система обработки большого потока событий, вот и смотрю на чужие опыты на этой полянке.
Не пробовал. Не примерял. Сейчас почитал, мне не подходит. Причины. 1 — это Java, следовательно оперативки будет кушать аж жуть, а мне под Redis она нужна (начинать буду с одного хостинга), ну и С++ не так прожорлив. 2 — то, что описал я — это часть решения задачи сбора данных, основная нагрузка ляжет на tornado (python), собственно непосредственно в вебе данные будут отображаться, а реалтаймовое изменение данных скорее всего будет реализовано через jabber-протокол и javascript. 3 — мне не нужны распределенные вычисления и кластеризация (ну разве что только для Redis).
Почему именно Redis — в самом начале было сказано, что у меня данные плохо структурируются в таблицы или документы — это почти самый главный аргумент, плюс быстродействие, Redis способен обрабатывать 10к запросов в секунду. Да, не без минусов, вся база хранится в оперативной памяти и периодически делается сливание на диск, вобщем есть шанс данные потерять, ну и оперативка может быстро закончиться.
Почему именно Redis — в самом начале было сказано, что у меня данные плохо структурируются в таблицы или документы — это почти самый главный аргумент, плюс быстродействие, Redis способен обрабатывать 10к запросов в секунду. Да, не без минусов, вся база хранится в оперативной памяти и периодически делается сливание на диск, вобщем есть шанс данные потерять, ну и оперативка может быстро закончиться.
То есть, как я понял между строк, для вас важна именно предельная пропускная способность при достаточно жёсткой структуре потока (в том плане что вы не будете его сильно и постоянно менять/расширять).
Мне как раз наоборот: нужна легко изменяемая структура, а ещё лучше мульти-структурность, а сопутствующие потери производительности готов покрывать масштабированием; ну и плюс не хочу привносить лишних человеческих компетенций (читай, С/С++) без нужды.
А неструктурированные данные, в принципе, поддерживаются почти везде. Это как раз не проблема — можно и эмулировать через текстовое поле.
Про redis, кстати, читал замеры — он выдаёт много (3-5-10K/sec — забыл) только на push-операциях; а вот на pull он такой же медленный как и все остальные (1-2К/sec).
Мне как раз наоборот: нужна легко изменяемая структура, а ещё лучше мульти-структурность, а сопутствующие потери производительности готов покрывать масштабированием; ну и плюс не хочу привносить лишних человеческих компетенций (читай, С/С++) без нужды.
А неструктурированные данные, в принципе, поддерживаются почти везде. Это как раз не проблема — можно и эмулировать через текстовое поле.
Про redis, кстати, читал замеры — он выдаёт много (3-5-10K/sec — забыл) только на push-операциях; а вот на pull он такой же медленный как и все остальные (1-2К/sec).
Ну да, мне именно нужна предельная скорость на потоке данных. И если у меня будет эмуляция данных в текстовом поле, я буду терять время либо на парсинге, либо на генерации этих текстовых данных.
Что касается push и pull. Тут мне как раз важны push-операции + я буду использовать рассылки, которые поддерживаются в Redis. Этим будет обеспечиваться приближение к реалтайму получаемых пользователем данных, ну конечно же при использовании jabber-протокола и javascript. Что касается pull — не страшно, если пользователь подождет 1-2-3 секунды, пока прогрузится непосредственно страница ресурса, ну или если пользователь захочет посмотреть исторические данные.
Что касается push и pull. Тут мне как раз важны push-операции + я буду использовать рассылки, которые поддерживаются в Redis. Этим будет обеспечиваться приближение к реалтайму получаемых пользователем данных, ну конечно же при использовании jabber-протокола и javascript. Что касается pull — не страшно, если пользователь подождет 1-2-3 секунды, пока прогрузится непосредственно страница ресурса, ну или если пользователь захочет посмотреть исторические данные.
делал что-то похожее, за что очень приятно было почитать, но я пошел другим путем:
использовал credis — простая но производительная библиотека — именно то, что нужно. Нет ничего лишнего.
Из событийно ориентированных использую libevent c multithread (использовал в двух проектах). Хотел кинуть ссылку на github, но там оказались старые релизы, с еще однопоточной реалзацией libevent. Как сделать её многопоточной — я изучал из исходников memcached. Думаю пруфлинк излишен.
еще раз за статью спасибо.
использовал credis — простая но производительная библиотека — именно то, что нужно. Нет ничего лишнего.
Из событийно ориентированных использую libevent c multithread (использовал в двух проектах). Хотел кинуть ссылку на github, но там оказались старые релизы, с еще однопоточной реалзацией libevent. Как сделать её многопоточной — я изучал из исходников memcached. Думаю пруфлинк излишен.
еще раз за статью спасибо.
Напишите свою статью, прямо таки просьба, ибо хотя бы будет из чего выбирать, а то как-то со статьями по Redis + EventLoop + multithread весьма не очень хорошо, откровенно.
На счет написания статей накладно, так как загружен собственными разработками.
Очевидно я не так выразился, я credis использовал не в демоническом режиме,
а вот про EventLoop + multithread можно написать статью: использовал в трех разработках.
Очевидно я не так выразился, я credis использовал не в демоническом режиме,
а вот про EventLoop + multithread можно написать статью: использовал в трех разработках.
Это тоже очень нужно. Рунет пока беден на подобные статьи.
заявка принята, но как прпавило такие статьи нужны только паре разработчиков, а сил при их подготовке нужно вкладывать много. На Хабре на ура идут статьи как настроить Сфинкс или php-fpm
Кстати может ссылочка тебе и пригодится libscgi — библиотека для создания WEB приложений на С++
кажется даже была статья на Хабре:
В ближайшее время буду переписывать на несколько потоков и неблокируемый режим, хотя и с блокируемым отличная производительность.
кажется даже была статья на Хабре:
В ближайшее время буду переписывать на несколько потоков и неблокируемый режим, хотя и с блокируемым отличная производительность.
сслылка libscgi
Спасибо за ссылку, но я пожалуй пока все же на tornado остановлюсь для веба. А там посмотрим, может быть что-то буду переделывать. Правила разработки гласят: сначала напиши, чтобы работало, а потом хоть заоптимизируйся.
Sign up to leave a comment.
Redis, hiredis, libev и multithread. Часть 1