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

Ruslan Zakirov ruz на bestpractical.com
Ср Мар 7 03:07:50 PST 2012


2012/3/6 Alexandr Gomoliako <zzz на zzz.org.ua>:
> On Tue, Mar 6, 2012 at 6:46 AM, Alexandr Alexeev <afiskon на gmail.com> wrote:
>> Значит вы все-таки говорите о динамическом распределении данных, а не
>> статическом? Тогда да, решается проблема с добавлением новых нод (не только
>> увеличение их числа в два раза) и даже перераспределения нагрузки между
>> нодами, если, к примеру, на нодах используется разное железо.
>
> Нет, шарды не перераспределяются динамически, а только с добавлением
> нод. Но да, можно на какие-то ноды больше шард ложить, на какие-то
> меньше.

Это как реализовать. Если использовать что-то в дополнение к хеш
функции или вместо, то можно в сравнительно небольшом объеме памяти
хранить карту соответствия записей к нодам.

При необходимости переноса карта расщепляется, лочится и данные
переносятся с ноды на ноду. Даунтайм только для относительно
небольшого количества пользователей. Объем данных для переноса
небольшой.

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

>> Потому и странно, что нет готовой абстракции. Но я начинаю догадываться, что
>
> Почему странно? Шардинг здесь самое простое и отдельно особого ничем не поможет.
>
>> не там ищу - нужно смотреть в сторону MySQL Proxy и тп.
>
> Лучше в сторону Riak и т.п.
>
>> Кстати, раз уж я поднял этот вопрос. Скажите, граждане, а как у половины
>> планеты принято переносить данные между нодами, сохраняя работоспособность
>> приложения? Есть ли способ сделать это, не лишая приложение даже небольшой
>> части функционала?
>
> Синхронизация между репликами, кроме репликации, например с помощью
> Merkle дерева.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org



-- 
Best regards, Ruslan.


Подробная информация о списке рассылки Moscow-pm