[Moscow.pm] Что стало с модулем DBIx::DBCluster?

[Alexandr Alexeev]

Про перенос шард нашел интересную инфу в презентации по Redis Cluster. Там
описан следующий алгоритм:

== Перенос шарда X с ноды A на ноду Б ==
Для каждого ключа K, принадлежащего X:
1. Залочить K на A
2. Скопировать K на Б
3. Пометить K на А, как "moved to Б"
4. Разлочить K
Когда перенос всех ключей выполнен, удалить X с A и произвести изменения на
сервере-словаре (или серверах). Если на A приходит запрос данных для K,
который уже был перенесен на Б, говорим "спроси у ноды Б (в этот
единственный раз)".

Если переносить не спеша (небольшими порциями с паузами) в нужное время и с
подходящим размером шардов, то, вроде, должно неплохо работать. Что думаете?

7 марта 2012 г. 21:50 пользователь Alexandr Gomoliako <zzz на zzz.org.ua>написал:

> On 3/7/12, Ruslan Zakirov <ruz на bestpractical.com> wrote:
> > Мы мапим ключи на несколько нод, допустим это пользовательские
> > акаунты. Нужно решить вопрос добавления нод.
> >
> > Ключей много, нод мало, то есть нужна карта соответствия. Можно по хэш
> > функции, а можно и другим способом, например: массив граничных
> > значений. Бинарным поиском можно найти ноду за O(lg(n)). Из
> > преимуществ - можно вычленить один ключ в отдельную записьв карте.
> > Пользуясь преимуществом можно переносить ключи между нодами по одному.
> >
> > Возникает задача блокировки отдельных записей в карте, что может
> > повысить общую нагрузку. Блоки ключей в карте блокируются, только
> > когда меняется нода блока, а проверяется блок только при записи.
> > Алгоритм переноса следующий:
> >
> > 1) Блокируем саму карту
> > 2) Отщепляем определенные ключи в отдельную запись карты.
> > 3) Снимаем блок
> > 4) Блокируем отщепленную запись
> > 5) Копируем данные
> > 6) Меняем запись в карте
> > 7) Снимаем блок
> > 8) Удаляем данные из старой ноды (тут нужно быть уверенным, что никто
> > уже не читает эти данные и не произойдет обратной миграции)
> > 9) При необходимости повторяем первые три пункта с объединением блоков в
> > карте
> >
> > Если объем данных для ключа небольшой, то миграция займет разумное время.
> >
> > Разумное решение? Не знаю. Возможно есть еще интереснее и полезней.
>
> Не очень. Похоже на идеи из Chord/DHash, но это для p2p систем, не для
> датацентров. Хотя с блокированием ни для чего не подойдет.
>
> Мы не можем себе позволить копировать пол базы из ноды по одной записи
> в датацентре, это будет слишком большая нагрузка на дисковое IO. Но
> это приемлемо в p2p, где дисковое IO вообще не проблема, и даже
> наоборот, там важнее уменьшить трафик.
>
> Шардинг же мапит ключи на шарды (куски), а шарды на ноды, причем
> количество шард заранее известно и задается один раз. Это позволяет
> как перемещать шарды между нодами с небольшими затратами, так и
> избавиться от сложных алгоритмов перераспределения данных,
> соответственно повысив надежность.
>
> > Вопрос репликации не рассматривается. Он решается отдельно и никак не
> > противоречит с приведенным вариантом решения.
>
> Как его решить отдельно? Допустим, что делать если отпал мастер для
> какой-то группы ключей? Или если там все равноправны и одна нода
> упала, то как узнать, на какой из реплик для какого-то ключа данные
> правильные, а на какой нет? Это уже не тривиально, нужно иметь
> какой-то порядок в системе (lamport timestamp, vector/matrix clock),
> чтобы четко знать, на какой ноде запись самая свежая. Или как-то
> выбирать мастера (paxos). В общем все очень тесно связано.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением, Александр
Личный блог: http://eax.me/
Мой форум: http://it-talk.org/
Мой Twitter: http://twitter.com/afiskon
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20120307/78ed92b5/attachment-0001.html>