Проблема миграции данных в Big Data

Решил написать маленькую пятничную статью, целью которой является предупредить всех, кто дует щеки и через слово вставляет Big Data. Сколько бы я не читал статей или не общался с товарищами, которые претендуют на использование действительно больших объемов данных у себя в приложении, никто из них не упоминает миграцию данных. Говорят о скорости чтения и записи, масштабировании, шардинге и прочих важных вещах. А о миграции ни слова.

Почему же эта самая миграция так важна? Когда ваш проект только стартовал или начал набирать обороты, вам действительно важнее всего обеспечить сохранность данных и быстрый доступ к ним. Но потом время идет, все развивается и вот в вашем хранилище данных уже не гигабайты, а десятки и сотни терабайт. И тут встает задача разделения или миграции данных. Причиной может быть шардинг данных по новому критерию, сегментация рынка с выделением отдельной инсталляции для некоторых клиентов, ускорение доступа данных для некоторых особо важных клиентов и т.д.

Когда такая задача возникает, может оказаться, что вы уже у разбитого корыта и сделать по этому поводу ничего нельзя. К примеру, вы генерируете идентификаторы записей, которые могут быть использованы только с соседними записями. Или ваши данные распределены по хранилищу таким образом, что для их миграции нужно блокировать все хранилище целиком. Или ваша структура данных не позволяет собрать цельный кусок большого объема без перелопачивания всех данных, что может занять недели. Тогда вы смело берете в руки костыли и начинаете строить из них аккуратную пирамидку, которая вот-вот рухнет и вы всеми силами поддерживаете ее.

Чтобы избежать подобных проблем, стоит в самом начале задать себе вопрос: “а что будет, если понадобится перенести данные для одного пользователя/клиента/проекта/заказчика/… в другое место?”. Еще более полезным вопросом при проектировании вашего хранения данных и выборе хранилища будет: “а какие данные у нас являются независимыми и как мы обеспечим эту независимость при хранении?”. Это гораздо более продуманный путь чем взять бездумно MongoDB или Cassandra только потому, что это модные технологии. Помните, успех проекта принесет новые, часто неожиданные задачи и проблемы…

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Обсуждение (0)

Leave a Reply

Your email address will not be published. Required fields are marked *