Дим, я думаю, тут масштаб проблем не тот: "иногда по много штук сразу" явно не критерий для выбора того же Redis.
И в любом случае алгоритм не поменяется. это тупой хэш с разрешением коллизий. 3 декабря 2013 г., 23:00 пользователь Dmitry Simonov <[email protected]>написал: > Не хочу показаться предвзятым, но с точки зрения выбора стореджа при > постоянных добавления-удалениях, Ты получишь проблемы уже при нагрузке в > 2-3к цепочек в секунду на MySQL. Мы тут выбирали сторедж для таких задач и > отвалилось вообще всё кроме мемкешеда :) > > Ну и как следствие, отказ от MySQL в пользу NoSQL решения превратит Твою > задачку из сложной в тривиальную. > > П.С. моё предложение про отказ от MySQL Ты должен воспринять в штыки. Я > его тоже примерно также принял, пока не увидел результаты стрельб. Падало > вообще всё. > > П.П.С. киото тайкон - гавно. > > --- > Dmitriy V. Simonov, > Perl & Python programmer > > > 2013/12/2 Михаил Монашёв <[email protected]> > >> Здравствуйте. >> >> Есть таблица с объектами в mysql. Новые объекты туда добавляются, >> плохие объекты удаляются, бывает что по много штук сразу. Некоторые >> объекты имеют статус скрытых от всех, а все остальные доступны для >> всех. Т.е. в таблице равномерно растёт id объектов, но между соседними >> id могут быть дырки, причём большие. И некоторые объекты показывать >> нельзя. >> >> Даётся текстовая строка. В идеале нужно для этой строке максимально >> быстро выбрать из таблицы случайные 3 разных объекта, доступные для >> всех. Причём так, чтобы повторные выборы давали те же самые объекты и >> изменения таблицы минимально влияли на это. >> >> Т.е. надо из перла обратиться к mysql-ю минимальное количество раз, >> сделав максимально быстрые запросы. Самое важное - скорость. Ей нельзя >> жертвовать. Можно жертвовать, но крайне нежелательно, привязкой строки >> к объектам. Понятно, что таблица меняется и привязки строк к объектам >> будут меняться. Необходимо, чтобы эти изменения были минимальны. Можно >> жертвовать количеством выбираемых объектов, например выбирать иногда >> не 3, а 2 или 1, но не 0. Можно жертвовать степенью случайности между >> выбираемыми объектами, например, выбирая лишь один случайным способом, >> а остальные искать поблизости от первого. Нельзя жертвовать охватом >> объектов таблицы, т.е. выбираться объекты должны среди всех не скрытых >> объектов. >> >> -- >> С уважением, >> Михаил mailto:[email protected] >> >> -- >> Moscow.pm mailing list >> [email protected] | http://moscow.pm.org >> > > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org > >
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
