[Moscow.pm] Задачка на подумать, кому интересно...

Akzhan Abdulin akzhan.abdulin на gmail.com
Вт Дек 3 11:43:23 PST 2013


Дим, я думаю, тут масштаб проблем не тот: "иногда по много штук сразу" явно
не критерий для выбора того же Redis.

И в любом случае алгоритм не поменяется. это тупой хэш с разрешением
коллизий.



3 декабря 2013 г., 23:00 пользователь Dmitry Simonov
<dsimonov на gmail.com>написал:

> Не хочу показаться предвзятым, но с точки зрения выбора стореджа при
> постоянных добавления-удалениях, Ты получишь проблемы уже при нагрузке в
> 2-3к цепочек в секунду на MySQL. Мы тут выбирали сторедж для таких задач и
> отвалилось вообще всё кроме мемкешеда :)
>
> Ну и как следствие, отказ от MySQL  в пользу NoSQL решения превратит Твою
> задачку из сложной в тривиальную.
>
> П.С. моё предложение про отказ от MySQL Ты должен воспринять в штыки. Я
> его тоже примерно также принял, пока не увидел результаты стрельб. Падало
> вообще всё.
>
> П.П.С. киото тайкон - гавно.
>
> ---
> Dmitriy V. Simonov,
> Perl & Python programmer
>
>
> 2013/12/2 Михаил Монашёв <postmaster на softsearch.ru>
>
>> Здравствуйте.
>>
>> Есть  таблица  с  объектами  в  mysql. Новые объекты туда добавляются,
>> плохие  объекты  удаляются,  бывает что по много штук сразу. Некоторые
>> объекты  имеют  статус  скрытых  от всех, а все остальные доступны для
>> всех. Т.е. в таблице равномерно растёт id объектов, но между соседними
>> id  могут  быть  дырки, причём большие. И некоторые объекты показывать
>> нельзя.
>>
>> Даётся  текстовая  строка.  В идеале нужно для этой строке максимально
>> быстро  выбрать  из  таблицы случайные 3 разных объекта, доступные для
>> всех.  Причём так, чтобы повторные выборы давали те же самые объекты и
>> изменения таблицы минимально влияли на это.
>>
>> Т.е.  надо  из  перла обратиться к mysql-ю минимальное количество раз,
>> сделав максимально быстрые запросы. Самое важное - скорость. Ей нельзя
>> жертвовать. Можно жертвовать, но крайне нежелательно, привязкой строки
>> к  объектам. Понятно, что таблица меняется и привязки строк к объектам
>> будут меняться. Необходимо, чтобы эти изменения были минимальны. Можно
>> жертвовать  количеством  выбираемых объектов, например выбирать иногда
>> не  3, а 2 или 1, но не 0. Можно жертвовать степенью случайности между
>> выбираемыми объектами, например, выбирая лишь один случайным способом,
>> а  остальные  искать  поблизости от первого. Нельзя жертвовать охватом
>> объектов таблицы, т.е. выбираться объекты должны среди всех не скрытых
>> объектов.
>>
>> --
>> С уважением,
>>  Михаил                          mailto:postmaster на softsearch.ru
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20131203/f0da4bf0/attachment.html>


Подробная информация о списке рассылки Moscow-pm