|
БД для очереди задач
|
|||
---|---|---|---|
#18+
Добрый день. Каким образом можно организовать очередь задач, не используя SQL базу? Есть вполне конкретная задача, учет показов, т.е. надо сложить показ куда-то в легкое временное хранилище на первом сервере, а потом постфактум по крону перенести и посчитать в MySQL на втором сервере. Сейчас сервер 1 кладет показ в сервер 2 в MySQL в таблицу типа MEMORY, но этот вариант нас не устраивает, необходимо полностью изолировать первый и второй сервер. Пробовали Memcached приспособить для этих целей, но во-первых есть лимит по размеру одного ключа, а если хранить по схеме 1 ключ = 1 показ, то надо где-то хранить карту индексов, а эта карта может разрастаться в пиковые часы и опять же не влезть в key-value БД по лимиту, плюс карта из-за мгновенно доступа может вымываться. В общем, интересует какое-нибудь легкое хранилище или модуль к мемкэшу, в общем простое решение без экзотики. Кто что посоветует? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2013, 14:39 |
|
БД для очереди задач
|
|||
---|---|---|---|
#18+
Очередь сообщений - JMS. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2013, 14:47 |
|
БД для очереди задач
|
|||
---|---|---|---|
#18+
Потестили сегодня RabbitMQ и как-то не очень обнадежило: 1. Громоздко. 2. Медленно. 3. Кушает CPU и память. 4. При вставке от 1 млн строк начинаются проблемы. Может быть есть какие-то решения полегче? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2013, 04:21 |
|
БД для очереди задач
|
|||
---|---|---|---|
#18+
itstrueДобрый день. Каким образом можно организовать очередь задач, не используя SQL базу? Кто что посоветует? Написать самому ;-) Например: Java + HasMap<Ваш объект>+servlet+JSON ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2013, 11:40 |
|
БД для очереди задач
|
|||
---|---|---|---|
#18+
Нужен вариант проще. Неужели это настолько уникальный вопрос, чтобы начать изобретать велосипед? По сути нужна быстрая легкая база, куда можно быстро вставлять/извлекать большое количество мелких данных. Сегодня протестировали редис: 100k строк с данными: редис: Вставка = 22.3 s Чтение = 7.3 s Чтение + удаление = 47.5 s мускул: Вставка = 67.439 s. Чтение = 8s Чтение + удаление = 43s У редиса очень быстрая вставка, но все остальное такое как у MySQL. Этот момент очень огорчил. Порекомендуйте как поступить. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2013, 22:34 |
|
БД для очереди задач
|
|||
---|---|---|---|
#18+
Если ставить тип MEMORY у таблицы MySQL, то рекурсивное удаление выполняется за 37с. Получается, что у редиса, кроме как быстрой вставки больше плюсов нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2013, 23:07 |
|
БД для очереди задач
|
|||
---|---|---|---|
#18+
itstrueПо сути нужна быстрая легкая база, куда можно быстро вставлять/извлекать большое количество мелких данных. Для этого не нужна база, достаточно любым способом организовать очередь в ОЗУ. От списков до кольцевого буфера. Первый курс программирования. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2013, 23:23 |
|
БД для очереди задач
|
|||
---|---|---|---|
#18+
Заменили клиент для редиса с редиски на phpredis и ужаснулись, запись и чтение выросло в 7-8 раз! Теперь понятно, почему были такие ужасные показатели. Но с удалением скорость не изменилась. Как можно ускорить его процесс? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.09.2013, 22:16 |
|
БД для очереди задач
|
|||
---|---|---|---|
#18+
itstrue, А чем файловая система не устраивает? Писать пачками по сколько-нибудь записей в один файл, заполненные файлы копировать на вторую машину и удалять. Куда уж быстрее ) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2013, 12:42 |
|
БД для очереди задач
|
|||
---|---|---|---|
#18+
Интересный вариант, а копировать с помощью чего? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2013, 14:02 |
|
БД для очереди задач
|
|||
---|---|---|---|
#18+
itstrueИнтересный вариант, а копировать с помощью чего? Да хоть rsync ;) Уж способов копирования файлов на удаленную машину - дофига. Главное - не копировать те, что еще пишутся, но это можно сделать фильтрацией по размеру или дате или названию или чему-нибудь еще. Т.е. вообще все реализуется внутри шелла ) Ну а писать - хорошим логгером, например, если он есть в выбранном языке. Основная проблема - как писать из кучи потоков с минимальными задержками. Но это все не безумно сложно ) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.09.2013, 00:24 |
|
БД для очереди задач
|
|||
---|---|---|---|
#18+
DPH3Главное - не копировать те, что еще пишутся, но это можно сделать фильтрацией по размеру или дате или названию или чему-нибудь еще. Название рулит. Нормальные люди создают файл с расширением .tmp, а после завершения записи - переименовывают. Переименование в ОСи - более-менее атомарная операция, так что кусок ACID-а обеспечен. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
16.09.2013, 01:49 |
|
|
start [/forum/topic.php?fid=35&msg=38393052&tid=1552437]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
others: | 252ms |
total: | 379ms |
0 / 0 |