<div>Про перенос шард нашел интересную инфу в презентации по Redis Cluster. Там описан следующий алгоритм:<br></div><div><br></div><div>== Перенос шарда X с ноды A на ноду Б ==</div><div>Для каждого ключа K, принадлежащего X:</div>
<div>1. Залочить K на A</div><div>2. Скопировать K на Б</div><div>3. Пометить K на А, как "moved to Б"</div><div>4. Разлочить K</div><div>Когда перенос всех ключей выполнен, удалить X с A и произвести изменения на сервере-словаре (или серверах). Если на A приходит запрос данных для K, который уже был перенесен на Б, говорим "спроси у ноды Б (в этот единственный раз)".</div>
<div><br></div><div>Если переносить не спеша (небольшими порциями с паузами) в нужное время и с подходящим размером шардов, то, вроде, должно неплохо работать. Что думаете?</div><div><br></div><div class="gmail_quote">7 марта 2012 г. 21:50 пользователь Alexandr Gomoliako <span dir="ltr"><<a href="mailto:zzz@zzz.org.ua">zzz@zzz.org.ua</a>></span> написал:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 3/7/12, Ruslan Zakirov <<a href="mailto:ruz@bestpractical.com">ruz@bestpractical.com</a>> wrote:<br>

</div><div><div class="h5">> Мы мапим ключи на несколько нод, допустим это пользовательские<br>
> акаунты. Нужно решить вопрос добавления нод.<br>
><br>
> Ключей много, нод мало, то есть нужна карта соответствия. Можно по хэш<br>
> функции, а можно и другим способом, например: массив граничных<br>
> значений. Бинарным поиском можно найти ноду за O(lg(n)). Из<br>
> преимуществ - можно вычленить один ключ в отдельную записьв карте.<br>
> Пользуясь преимуществом можно переносить ключи между нодами по одному.<br>
><br>
> Возникает задача блокировки отдельных записей в карте, что может<br>
> повысить общую нагрузку. Блоки ключей в карте блокируются, только<br>
> когда меняется нода блока, а проверяется блок только при записи.<br>
> Алгоритм переноса следующий:<br>
><br>
> 1) Блокируем саму карту<br>
> 2) Отщепляем определенные ключи в отдельную запись карты.<br>
> 3) Снимаем блок<br>
> 4) Блокируем отщепленную запись<br>
> 5) Копируем данные<br>
> 6) Меняем запись в карте<br>
> 7) Снимаем блок<br>
> 8) Удаляем данные из старой ноды (тут нужно быть уверенным, что никто<br>
> уже не читает эти данные и не произойдет обратной миграции)<br>
> 9) При необходимости повторяем первые три пункта с объединением блоков в<br>
> карте<br>
><br>
> Если объем данных для ключа небольшой, то миграция займет разумное время.<br>
><br>
> Разумное решение? Не знаю. Возможно есть еще интереснее и полезней.<br>
<br>
</div></div>Не очень. Похоже на идеи из Chord/DHash, но это для p2p систем, не для<br>
датацентров. Хотя с блокированием ни для чего не подойдет.<br>
<br>
Мы не можем себе позволить копировать пол базы из ноды по одной записи<br>
в датацентре, это будет слишком большая нагрузка на дисковое IO. Но<br>
это приемлемо в p2p, где дисковое IO вообще не проблема, и даже<br>
наоборот, там важнее уменьшить трафик.<br>
<br>
Шардинг же мапит ключи на шарды (куски), а шарды на ноды, причем<br>
количество шард заранее известно и задается один раз. Это позволяет<br>
как перемещать шарды между нодами с небольшими затратами, так и<br>
избавиться от сложных алгоритмов перераспределения данных,<br>
соответственно повысив надежность.<br>
<div class="im"><br>
> Вопрос репликации не рассматривается. Он решается отдельно и никак не<br>
> противоречит с приведенным вариантом решения.<br>
<br>
</div>Как его решить отдельно? Допустим, что делать если отпал мастер для<br>
какой-то группы ключей? Или если там все равноправны и одна нода<br>
упала, то как узнать, на какой из реплик для какого-то ключа данные<br>
правильные, а на какой нет? Это уже не тривиально, нужно иметь<br>
какой-то порядок в системе (lamport timestamp, vector/matrix clock),<br>
чтобы четко знать, на какой ноде запись самая свежая. Или как-то<br>
выбирать мастера (paxos). В общем все очень тесно связано.<br>
<div class="HOEnZb"><div class="h5">--<br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>С уважением, Александр<br>Личный блог: <a href="http://eax.me/" target="_blank">http://eax.me/</a><br>Мой форум: <a href="http://it-talk.org/" target="_blank">http://it-talk.org/</a><br>
Мой Twitter: <a href="http://twitter.com/afiskon" target="_blank">http://twitter.com/afiskon</a><br><br>