[Moscow.pm] Задачка на подумать, кому интересно...
Алексей Галаев
features.feat на gmail.com
Вт Дек 17 21:45:29 PST 2013
Memcached это тот который в памяти. На диске хранит Redis и то только
реплику, при этом сам висит в памяти.
Вроде ничего не напутал...
18 декабря 2013 г., 7:26 пользователь ksvs <ksvs1996 на ymail.com> написал:
>
> мемкешед - это тот, который в памяти или на диске?
> а чем плох киото?
> P.S. Думаю чем заменить берклевскую базу...
> Нужна hash и recno.
>
>
> On Tuesday, 3 December 2013, 22:01, Dmitry Simonov <dsimonov на gmail.com>
> wrote:
> Не хочу показаться предвзятым, но с точки зрения выбора стореджа при
> постоянных добавления-удалениях, Ты получишь проблемы уже при нагрузке в
> 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
>
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
Подробная информация о списке рассылки Moscow-pm