[Moscow.pm] Идеальный Map-ер и Reduce-ер

[Михаил Монашёв]

Здравствуйте, Руслан.

RZ> В доке к MCDB я увидел, что там репликация master->slave и так понял,
RZ> что репликация 1-н к 1-му. Вы предлагаете поднимать несколько MCDB и с
RZ> помощью C::M::F конектиться к ним без шаринга данных между этими БД?

Там один мастер пишет в несколько слейвов. Клиенты пишут в мастер, а
читают из слейвов и мастера. При этом есть возможность добиться, что
все слейвы и мастер ВСЕГДА имеют одинаковые данные. Т.е. пока все
слейвы не сохранят к себе ключик, мастер не скажет клиенту, что ключик
сохранён. При этом как я понял тромозов не наблюдается, ибо асинхронно
и сама запись в bdb быстрая.

У меня есть планы немного дописать C::M::F :-) Нужно добавить работу с
MemcacheDB и с Repcached.

Репликация  нужна  только для отказоустойчивости и увеличения скорости
чтения. Распределённость никто не отменял. Схема там простая. Раньше у
нас   было  несколько  мемкашедов.  Теперь  несколько  пар(или  троек)
MemcacheDB.  Т.е.  мы пишем ключики на несколько мастеров, а читаем со
всех мастеров и слейвов.

RZ> Тут возникает заковыка небольшая. Так как MCDB в общем не предназначен
RZ> для хранения больших записей, то ключ придется менять используя
RZ> main-key-xxx, где xxx атомарный счетчик иначе поле мапа записи могут
RZ> стать очень большими.

Я жду что ответит Стив Чу по поводу размера значений ключей.

Если  что,  можно использовать счётчик, как ты написал, или можно один
большой ключ распылять в фиксированное число мелких...

--

С уважением,
Михаил Монашёв, SoftSearch.ru
mailto:postmaster на softsearch.ru
ICQ# 166233339
http://michael.mindmix.ru/
Без бэкапа по жизни.