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

[Ruslan Zakirov]

2012/3/7 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) При необходимости повторяем первые три пункта с объединением блоков в карте

Если объем данных для ключа небольшой, то миграция займет разумное время.

Разумное решение? Не знаю. Возможно есть еще интереснее и полезней.

Вопрос репликации не рассматривается. Он решается отдельно и никак не
противоречит с приведенным вариантом решения.

> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

-- 
Best regards, Ruslan.