Человеческая психология устроена так, что мы не задумаемся о привычных вещах до тех пор, пока эти вещи не сломаются.

Люди не думают про электричество, пока не погаснет свет.
Люди не думают про здоровое питание, пока не подхватят диарею.
Люди не думают о хранении файлов, пока данные не сгинут вместе со сломавшимся сервером.

Что объединяет все эти случаи? То, что последствия проблем можно было бы уменьшить, если заранее подумать о возможных решениях. Как организовать диету — обсудите со своим врачом, а сегодня ответим на все основные вопросы о хранении данных.


Ох уж эти данные

Вопрос размещения большого объёма пользовательских данных неизменно встает как перед безусыми, так и седобородыми разработчиками серверных приложений. С текстовыми и числовыми данными более-менее все ясно — для их хранения уже есть множество стандартных решений типа баз данных и key-value хранилищ.

С файлами же всегда есть ряд сложностей:

  1. Файлы могут быть очень большими. Настолько большими, что они не поместятся даже на самый большой диск самого мощного сервера.
  2. Их может быть настолько много, что вы упретесь в лимит количества файлов, которые операционная система может хранить на диске. Например, у популярной файловой системы ext4 этот лимит составляет 4,294,967,295 файлов. Это много для одного человека, но очень мало для, скажем социальной сети. Например, если в вашем приложении с красивыми фотофильтрами живёт 10 миллионов активных юзеров, и они создают по, скажем, 100 фотографий в день — одного сервера на ext4 вам уже не хватит.
  3. Не стоит забывать и о том, что сохранить файлы — это только полдела. После сохранения их нужно ещё найти, прочитать и вернуть пользователю по запросу. А это уже куда более сложная проблема.
  4. Компьютерное железо иногда умирает вместе с вашими данными, поэтому на каждый пользовательский файл нужно иметь еще и резервную копию. Минимум одну. А в норме таких копий должно быть несколько.

Конечно, вы можете возразить и сказать, что, пока вы делаете маленькое приложение и у вас не планируется ничего такого. Но karma is a bitch и, если приложение станет успешным и аудитория вырастет до того, как вы озаботитесь хранением данных, ваш бизнес может оказаться под угрозой провала из-за этой одной маленькой технической незадачи. Ведь, чем позже вы начинаете работать над решением, тем сложнее будет вносить изменения в систему и тем больше разных граблей стукнет вам по разным частям тела.


Что же делать, как же быть?

Самое простое решение, с которого начинают почти все неискушенные разработчики — хранить файлы на том же сервере, где работает приложение. Очень удобный вариант — в одной папке лежит код, в другую пишутся файлы. Записал, открыл, прочитал, отдал пользователю — красота!

Но — нет. Проблемы начинаются довольно быстро. Либо — из-за того, что мощности одного сервера не хватает для обработки всех пользователей, приходится ставить второй, третий, пятый сервер. И запомнить, на каком диске чьи файлы записаны, будет всё сложнее.

Если же такую многосерверную систему хранения файлов придется перевозить из одного дата-центра в другой — тут вообще начнётся тихий ад.

Второй случай — мощности сервера хватает, но файлы перестают влезать на диск из-за своего размера или количества. В этом случае приходится выделять несколько отдельных серверов для хранения данных и писать данные на них по сети. И, конечно же, помнить, где на каком сервере кластера какие файлы лежат. И не забывать про резервные копии. (Уф).

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

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


Простой Сервис Хранения для Самых Сложных Щей

Внешне облачное хранилище выглядит как веб-сервис, доступный через API и/или специальные библиотеки для популярных языков программирования. Разработчики подключаются к хранилищу из своего приложения с помощью специальных ключей доступа. После этого все тяжелые операции с файлами перекладываются на плечи сервиса. Все протоколы взаимодействия с такими сервисами описываются негласным стандартом S3 — Simple Storage Service (Простой Сервис Хранения).

Допустим, вы разрабатываете приложение, помогающее хранить фотографии. Пользователи загружают файлы в приложение, а вы подхватываете их и передаете в веб-сервис облачного хранилища. После этого у вас остаются метаданные загруженного файла — его размер, имя и расположение на сервере хранилища. Файл можно сделать публичным, тогда у вас будет еще и открытая ссылка, доступная пользователям интернета. Например, можно поделиться с миром фотографией своей кошки: https://hb.bizmrg.com/pickcher/35975265_10214685772051445_2474113123427024896_n%20(1).jpg

Та-дам! Тонна ваших проблем была только что решена.


Ещё 5 классных фактов об облачных хранилищах

  1. Облачные хранилища — резиновые. Они могут принимать в себя миллиарды файлов. Количество данных и их размер — больше не ваша проблема.
  2. Переезжать с таким хранилищем из одного дата-центра в другой — легче лёгкого. Вам нужно перевезти ваше приложение и базу данных, а все файлы так и останутся в облаке. Просто подключитесь к хранилищу из нового дата-центра — и все ваши данные переедут в точности в том же порядке, в каком и были. Кстати, файлы, доступные по ссылкам, во время переезда не уйдут в офлайн — они будут доступны все время.
  3. Надежность облачного хранилища намного выше, чем надежность ваших решений. Сотни высококлассных спецов круглосуточно следят за состоянием здоровья серверов хранения.
  4. Резервное копирование также упрощается. Теперь вы сможете создавать копии облаков всего парой кликов. Или вовсе настроить автоматическое резервное копирование для постоянной поддержки резервных копий в актуальном состоянии. Кстати, необходимость в количестве копий тоже падает — ведь надежность облака намного выше, чем надежность вашей системы. Допустим, если вы привыкли делать по четыре копии у себя на сервере, в случае с облаком можно будет обойтись одной.
  5. Нагрузка на вашу систему уменьшится. Хранилище способно отдавать файлы вашим пользователям за вас, не беспокоя ваши рабочие сервера пустяковыми запросами на скачивание данных.


Облачное импортозамещение. Что? Да!

Хранение файлов в облачных хранилищах — стандартная практика для всех ведущих мировых IT компаний. Облачные системы хранения уже реализованы во многих дата-центрах и инженерное сообщество накопило гигантский опыт в эксплуатации этих решений.

Впрочем, мир не идеален — и даже у облаков есть минус. Дело в том, что все услуги по работе с файлами по протоколу S3 исторически предоставляются в зарубежных дата-центрах. А это значит, что пользователь из Москвы будет ходить за файлами в ближайший дата-центр, который находится где-то в Амстердаме. Такие походы занимают время, и приложение будет работать медленней.

Для решения этой проблемы используйте S3 хранилище от VK, которое обеспечивает высокую скорость работы для пользователей российского сегмента сети. Дата-центры VK находятся внутри страны, поэтому скорость обмена информацией будет максимальной. Это означает полный комфорт для разработчиков и намного большее быстродействие системы, чем у европейских и американских провайдеров.

Некоторые данные нужно еще и обрабатывать различными тяжелыми алгоритмами. Например, делать классификацию изображений нейронными сетями. Для таких задач нужны миллионы картинок хорошего качества, а такие данные как раз очень удобно хранить в облаке. VK позволяет запускать вычислительные кластеры для задач машинного обучения в тех же дата-центрах, где находятся S3 хранилища. Географическая близость файловых серверов и серверов нейронных сетей ускоряет обучение во много раз — практически исчезают задержки на чтение данных по сети между серверами.