Как устроен Instagram ?! Часть 1.
UniLecs
Что такое Instagram, думаю, знают все, но все же приведем небольшое описание сервиса. Это социальная сеть, которая позволяет пользователям загружать свои фотографии и видео и делиться ими с другими пользователями. Пользователи Instagram могут по своему выбору делиться информацией публично или в частном порядке. Любое общедоступное содержимое может быть просмотрено любым другим пользователем, и в то же время общедоступное содержимое может быть доступно только определенному набору людей.
Требования и цели системы
Немного упростим архитектуру для нашего разбора. Возьмем более упрощенную версию функционала. Пользователь может делиться фотографиями, а также подписываться на других пользователей. Лента сети для каждого пользователя будет состоять из лучших фотографий людей, на которые он подписан.
Функциональные требования
1. Пользователи могут загружать / скачивать / просматривать фотографии.
2. Пользователи могут выполнять поиск по названиям фото / видео.
3. Пользователи могут подписаться на других пользователей.
4. Система должна уметь генерировать и отображать новостную ленту пользователя, состоящую из лучших фотографий людей, на которые подписан пользователь.
Нефункциональные требования
1. Сервис должен быть высокодоступным.
2. Минимальная задержка системы ~200 мс для генерации новостной ленты.
3. Система должна быть надежной, т.е. любая загруженная фотография или видео никогда не должны быть утеряны.
Также стоит отметить такие фичи, как добавление тегов к фотографиям, поиск фотографий по тегам, комментирование фотографий, пометка пользователей на фотографиях и т.д. Система будет загружена для чтения, поэтому мы сосредоточимся на создании системы, которая сможет быстро получать фотографии.
Оценка мощностей и ограничения
Допустим, что у нас:
- Всего 500 миллионов пользователей, а ежедневно - 1 миллион активных пользователей.
- 2 миллиона новых фотографий каждый день, 20 новых фотографии каждую секунду.
- Средний размер файла фотографии => 200 КБ
- Общее пространство, необходимое для фотографий в течении 1 дня:
2 миллиона * 200 KB => 400 ГБ - Общий объем памяти, необходимый для 10 лет:
400 ГБ * 365 (дней в году) * 10 (лет) ~ = 1425 ТБ
Общая архитектура системы
В общем случае есть два сценария, которые мы должны поддерживать:
1. Загрузка фотографий
2. Просмотр / поиск фотографий.
Сервису потребуются некоторые серверы для хранения фотографий, а также несколько серверов баз данных для хранения метаданных о фотографиях.
База данных
Итак, в базе данных нам нужно хранить:
1. Данные о пользователях (их профиль);
2. Загруженные фотографии пользователей и информацию о других подписчиках, на которых они подписаны.
Хочу отметить, что (PhotoLatitude, PhotLongitude) - данные о геолокации загружаемой фотографии, а (UserLatitude, UserLongitude) - данные о геолокации пользователя, который загружает фотографию.
Можно воспользоваться обычной СУБД, например, MySQL. Но реляционные базы имеют свои недостатки, особенно когда нам нужно их масштабировать. Поэтому мы воспользуемся NoSQL подходом.
Нам нужно хранить отношения между пользователями и фотографиями, чтобы знать, кому принадлежит какая фотография. Нам также нужно сохранить список людей, на которых подписан пользователь.
Оценка размера данных
Итак, теперь давайте сделаем примерную оценку размера базы данных. Посмотрим, сколько данных будет входить в каждую таблицу и сколько общего хранилища нам понадобится в течение 10 лет.
Таблица User: предположим, что каждое значение "int" и "dateTime" составляет четыре байта, а каждая запись в таблице будет состоять примерно из 68 байтов:
Т.е. Id пользователя (4 байта) + Имя (20 байтов) + электронная почта (32 байта) + DateOfBirth (4 байта) + CreationDate (4 байта) + LastLogin (4 байта) = 68 байтов. Здесь мы взяли примерные значения количество байт, которые обычно требуются в базе данных, чтобы сохранить такие данные, как имя пользователя, email, дату рождения, дату создания профиля и т.д.
В итоге получаем, что если у нас 500 миллионов пользователей, нам потребуется 32 ГБ общего хранилища: 500 миллионов * 68 байт ~ = 32 ГБ
Таблица Photo: здесь каждая запись в таблице Photo будет иметь примерный размер 284 байта:
Т.е. ID (4 байта) + UserId (4 байта) + Path (256 байтов) + PhotoLatitude (4 байта) + PhotoLongitude (4 байта) + UserLatitude (4 байта) + UserLongitude (4 байта) + CreationDate (4 байта) = 284 байта
Если ежедневно загружаются 2 млн. новых фотографий, то нам потребуется 0,5 ГБ дискового пространства на один день: 2 миллиона * 284 байта ~ = 0,5 ГБ в день. А уже на 10 лет нам понадобится 1,88 ТБ памяти.
Таблица UserFollow: каждая запись в таблице UserFollow будет состоять из 8 байтов.
У нас есть 500 миллионов пользователей и, предположим, что в среднем каждый пользователь будет подписан на 500 подписчиков. Нам понадобится 1,82 ТБ памяти для таблицы UserFollow: 500 миллионов пользователей * 500 подписчиков * 8 байт ~ = 1,82 ТБ.
Итого получаем, что общее дисковое пространство, необходимое для всех таблиц в течение 10 лет, составит 3,7 ТБ: 32 ГБ + 1,88 ТБ + 1,82 ТБ ~ = 3,7 ТБ