Memcached это тот который в памяти. На диске хранит Redis и то только реплику, при этом сам висит в памяти.
Вроде ничего не напутал... 18 декабря 2013 г., 7:26 пользователь ksvs <[email protected]> написал: > > мемкешед - это тот, который в памяти или на диске? > а чем плох киото? > P.S. Думаю чем заменить берклевскую базу... > Нужна hash и recno. > > > On Tuesday, 3 December 2013, 22:01, Dmitry Simonov <[email protected]> > wrote: > Не хочу показаться предвзятым, но с точки зрения выбора стореджа при > постоянных добавления-удалениях, Ты получишь проблемы уже при нагрузке в > 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 > -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
