<div dir="ltr">Дим, я думаю, тут масштаб проблем не тот: "иногда по много штук сразу" явно не критерий для выбора того же Redis.<div><br></div><div>И в любом случае алгоритм не поменяется. это тупой хэш с разрешением коллизий.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">3 декабря 2013 г., 23:00 пользователь Dmitry Simonov <span dir="ltr"><<a href="mailto:dsimonov@gmail.com" target="_blank">dsimonov@gmail.com</a>></span> написал:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Не хочу показаться предвзятым, но с точки зрения выбора стореджа при постоянных добавления-удалениях, Ты получишь проблемы уже при нагрузке в 2-3к цепочек в секунду на MySQL. Мы тут выбирали сторедж для таких задач и отвалилось вообще всё кроме мемкешеда :)<div>
<br></div><div>Ну и как следствие, отказ от MySQL в пользу NoSQL решения превратит Твою задачку из сложной в тривиальную.</div><div><br></div><div>П.С. моё предложение про отказ от MySQL Ты должен воспринять в штыки. Я его тоже примерно также принял, пока не увидел результаты стрельб. Падало вообще всё.</div>
<div><br></div><div>П.П.С. киото тайкон - гавно.</div></div><div class="gmail_extra"><br clear="all"><div>---<br>Dmitriy V. Simonov,<br>Perl & Python programmer</div><div><div class="h5">
<br><br><div class="gmail_quote">2013/12/2 Михаил Монашёв <span dir="ltr"><<a href="mailto:postmaster@softsearch.ru" target="_blank">postmaster@softsearch.ru</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Здравствуйте.<br>
<br>
Есть таблица с объектами в mysql. Новые объекты туда добавляются,<br>
плохие объекты удаляются, бывает что по много штук сразу. Некоторые<br>
объекты имеют статус скрытых от всех, а все остальные доступны для<br>
всех. Т.е. в таблице равномерно растёт id объектов, но между соседними<br>
id могут быть дырки, причём большие. И некоторые объекты показывать<br>
нельзя.<br>
<br>
Даётся текстовая строка. В идеале нужно для этой строке максимально<br>
быстро выбрать из таблицы случайные 3 разных объекта, доступные для<br>
всех. Причём так, чтобы повторные выборы давали те же самые объекты и<br>
изменения таблицы минимально влияли на это.<br>
<br>
Т.е. надо из перла обратиться к mysql-ю минимальное количество раз,<br>
сделав максимально быстрые запросы. Самое важное - скорость. Ей нельзя<br>
жертвовать. Можно жертвовать, но крайне нежелательно, привязкой строки<br>
к объектам. Понятно, что таблица меняется и привязки строк к объектам<br>
будут меняться. Необходимо, чтобы эти изменения были минимальны. Можно<br>
жертвовать количеством выбираемых объектов, например выбирать иногда<br>
не 3, а 2 или 1, но не 0. Можно жертвовать степенью случайности между<br>
выбираемыми объектами, например, выбирая лишь один случайным способом,<br>
а остальные искать поблизости от первого. Нельзя жертвовать охватом<br>
объектов таблицы, т.е. выбираться объекты должны среди всех не скрытых<br>
объектов.<br>
<span><font color="#888888"><br>
--<br>
С уважением,<br>
Михаил mailto:<a href="mailto:postmaster@softsearch.ru" target="_blank">postmaster@softsearch.ru</a><br>
<br>
--<br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org" target="_blank">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
</font></span></blockquote></div><br></div></div></div>
<br>--<br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
<br></blockquote></div><br></div>