Базы данных. Haystack

HaystackКурс «Базы данных»

Цесько Вадим Александровичhttp://incubos.org

@incubos

Computer Science Center

14 октября 2013 г.

Цесько В. А. (CompSciCenter) Haystack 14 октября 2013 г. 1 / 53

Содержание

1 Введение

2 Background

3 Архитектура

4 Детали реализации

5 Заключение

6 Домашнее заданиеЦесько В. А. (CompSciCenter) Haystack 14 октября 2013 г. 2 / 53

Введение Материалы

Материалы

Doug Beaver, Sanjeev Kumar, Harry C. Li, JasonSobel, Peter Vajgel, Facebook Inc. Finding a needlein Haystack: Facebook’s photo storage. 2010


Введение Мотивация

Мотивация

Зачем мы это рассматриваем:Промышленная внедрённая технологияЛогика проектированияИнтересные проектные решенияПросто интересно, как делают взрослые дядьки


Введение Цифры

Цифры

На 2010 год:65 млрд. оригинальных фоток4х размера = 260 млрд. фоток = 20 ПБ+1 млрд. фоток (60 ТБ) каждую неделю1 Mrps в пикеВ проде 2 года


Введение Характер запросов

Характер запросов

Пишем — один разЧитаем — частоНикогда не перезаписываемУдаляем — редко


Введение Основные цели

Основные цели

High throughput and low latencyUGC, CDN, User Experience1 поиск по диску максимумМикрометаданные в памяти

Fault-tolerantUGCГеорепликация

Cost-effective$ / TB, read rps / TB$ / TB — на 28% меньше, read rps / TB — в 4раза больше vs NAS

Simple


Background Типичная архитектура

Путь запроса


Background Типичная архитектура

CDN

Клиент получает URL от Web ServerИдёт с URL’ом в CDNЕсли у CDN есть данные, то отдаётЕсли нет, то идёт в Photo Storage и кэшируетURL содержит необходимую CDN информацию


Background NFS

Главный урок

CDN не подходит для социальных фотосервисовЭффективно раздаёт «горячие» фотки (профилии свежие)Длинный хвост (непопулярные и/или старые)Длинный хвост невозможно кэшировать


Background NFS

Путь запроса


Background NFS

Хранение фоток

Каждая фотка в отдельном файле накоммерческом NASPhoto Store монтирует все разделы через NFSPhoto Store из URL вынимает путь, читает файлпо NFS и отдаёт CDN

ПроблемыТысячи файлов в каждом каталоге

Больше 10 дисковых операций на одну фоткуСотни файлов в каждом каталоге

Больше 3 дисковых операций на одну фотку(метаданные каталога, inode, содержимое файла)


Background NFS

Оптимизации

Кэш из имени файла в файловый дескрипторПропатчили ядро — системный вызовopen_by_filehandleНе сильно помогло на длинном хосте

ВыводКэш не всегда спасает


Background NFS

Альтернативы

Из используемого в Facebook:Аналог GFSMySQLHadoopФС (inode — сотни байт на файл)

ВыводВсё не очень подходит для длинного хвоста


Архитектура Новая версия

Новая версия

CDN для популярных фоток (пока что)Haystack для длинного хвоста


Архитектура Задача

Задача

Уменьшить нагрузку на дискТолько необходимые операцииУменьшить расход памяти на метаданныеДержать все метаданные в памяти


Архитектура Подход

Подход

HaystackОгромные файлы с кучей фоток в каждом


Архитектура Компоненты

Компоненты

StorePhysical volume (на каждой машине 100 х 100 ГБ =10 ТБ)Logical volume = Replica Set

DirectoryLogical volume → Physical volumeФотка → Logical volumeLogical volumes with free space

CacheПрикрывает StoreЗащищает при перезапуске CDNУменьшает зависимость от CDN



Чтение фоток



URL

CDN URLhttp://<CDN>/<Cache>/<Store>/<LV, Photo>

Браузер идёт на <CDN>CDN ищет у себя, используя <LV, Photo>Если не нашёл, отрезает <CDN> и идёт в <Cache>Cache ищет у себя, используя <LV, Photo>Если не нашёл, отрезает <CDN> и идёт в <Store>

Direct URLhttp://<Cache>/<Store>/<LV, Photo>



Добавление фоток


Архитектура Directory

Функции Directory

Отображение из логических томов в физическиеПри добавлении фотокПри конструировании URL’ов фоток

Балансирует нагрузкуЗапись по логическим томамЧтение по физическим томам

Определяет, кто будет отдавать: CDN или CacheПомечает логические тома как read-only

Эксплуатационные причиныНет свободного места



Write-enabling

Новые Store доступны на записьТолько на такие машины добавляются фоткиКогда место на машине кончается — помечаетсякак read-only

Внимание!Это влечёт определённые последствия



Устройство Directory

Хранит данные в реплицированной БДПростой сервис на PHPИспользует memcachedЕсли теряем Store, то удаляем соответствующееотображение и добавляем после замены машины


Архитектура Cache

Функции Cache

Получает HTTP-запросы от CDN и браузеровDHT: ключ — id фоткиЕсли нет в кэше, то идёт на StoreКэширует фотку только при выполнении двухусловий:

Запрос пришёл от пользователя, а не от CDNCDN сам закэширует

Фотка загружена с write-enabled StoreСвежие фотки более популярны — прикрываемwrite-enabled StoreФС на Store лучше работает, когда либо чтение, либозапись, но не смесь

Планируется push свежих фоток в Cache


Архитектура Store

Функции Store

Простой интерфейс — get, add, delete по <LV,Photo>На каждом Store множество PVКаждый PV содержит миллионы фотокPV — большой файл (100 ГБ)/hay/haystack_<LV_id>Получение имени файла, смещению и размерадля фотки не требует дисковых операцийОткрытые файловые дескрипторы для каждогоPVОтображение в памяти из id фотки в метаданные(файл, смещение и размер)


Детали реализации Store-файл

Store-файл

SuperblockПоследовательность needleNeedle — фотка



Формат



Поля needle



Индекс

In-memory(key, alternate-key) -> (flags, size,offset)Store может перестроить индекс при сбое


Детали реализации Запросы

Запросы

ReadWrite (Append)Delete



Read

Cache передаёт с запросом: LV_id, key,alternate_key, cookie

cookie генерируется и сохраняется в Directory призагрузке фоткиcookie защищает от атак с подбором URL’ов

Store извлекает метаданныеЕсли фотка не удалена, то читает needle с дискаПроверяет cookie и checksumВозвращает фотку Cache



Write

Web server передаёт с запросом: LV_id, key,alternate_key, cookie и данныеКаждый Store синхронно дописывает фотку вPV и обновляет индексМодификация фотки:

Либо в тот же LV с теми же key и alternate_key:для Store больший offset — свежее версияЛибо в другой LV: Directory обновляет метаданные ибольше не читает старую фотку



Delete

Store выставляет флаг в памяти и синхронно надискеЗапросы на чтение всегда проверяют флагФотка физически не удаляется


Детали реализации Index

Функции Index

Оптимизация при перезагрузке StoreИндекс для каждого томаИндекс содержит superblock и индексные записиПорядок индексных записей соответствует тому



Формат



Обновление

Write:Синхронное дописывание needle в томАсинхронное — в индекс

Delete:Синхронно выставляется флаг в томеИндекс не обновляется

Работает быстрее



Проблемы

Needle есть, а индексной записи нет (orphan)«Лечится» при перезапускеПоследняя запись в индексе — последнийnon-orphan needle

Индексные записи не отражают факт удаленияПри чтении всегда проверяется флаг deletedОбновляется индекс в памятиCache уведомляется, что фотка удалена


Детали реализации Оптимизации

Compaction

Выбрасывание удалённых и дублирующихсяneedlesКопирование в новый файл с пропуском мусораВ это время удаления идут в оба файлаДошли до конца — блокируем исходный файл наизменение и атомарно переключаемся

Интересное наблюдениеСвежие фотки удаляются чаще25% фоток/год



Оперативная память

20% экономии:Вместо флагов у удалённых фоток offset равен 0cookie не хранятся в памяти, а проверяютсякаждый раз после чтения needle

В итоге10 байт на фотку (в среднем) vs 536 байт наxfs_inode_t



Batch

Диски любят последовательную записьЗагрузка альбомов — основной случай


Заключение Нагрузка

Нагрузка

98% чтений — лента новостей и альбомыВозраст 2 дня — резкий спад числа обращенийCDN и Cache довольно эффективны, но длинныйхвост80% — Cache hit rateHaystack отвечает на 10% нагрузки CDNЗагрузка каждой фотки — 12 needles (4 размера х3 реплики)См. стресс тесты в оригинальной статье1

1Doug Beaver, Sanjeev Kumar, Harry C. Li, Jason Sobel, Peter Vajgel,Facebook Inc. Finding a needle in Haystack: Facebook’s photo storage. 2010Цесько В. А. (CompSciCenter) Haystack 14 октября 2013 г. 42 / 53


Распределение трафика



Рассмотрели

Архитектура HaystackОсновные компоненты: Directory, Cache, StoreИнтересные решения



Уроки

Особенности реальной нагрузкиВо что упираетесьKISS2

2http://en.wikipedia.org/wiki/KISS_principleЦесько В. А. (CompSciCenter) Haystack 14 октября 2013 г. 45 / 53

http://en.wikipedia.org/wiki/KISS_principle

Домашнее задание Промежуточные итоги

Промежуточные итоги

Студент FR0 FR1 FR2Бакрадзе Л. XГрязнов С. ?Егоров Д. XЕршов В. X XX XКоролёв Д. ?Суворов Е. X XТолстопятов В. ?Фёдоров К. X X XХомутов В. ?Шашкова Е. X


Домашнее задание Feature Requests

Feature Requests

FR 14.10 21.10 28.10 04.11 11.11FR1 XFR2 XFR3 X XFR4 X X XFR5 X X XFR6 X X X XFR7 X X X X X



FR5: Compaction

Развитие FR1Размер на диске не больше чем 2хАвтоматический запускРучной запускЛогиТестыСгорает — 2013-10-28



FR6: Migration

Развитие FR4Автоматическая балансировка при добавленииузлаРучная балансировка при удалении узлаВозможность смотреть и редактировать кольцоЛогиТестыСгорает — 2013-11-04



FR7: Replication

Развитие FR4Репликация по кольцуКлиент задаёт количество нод при записи/чтенииТестыСгорает — 2013-11-11


Домашнее задание Общее

Общее

Внятные сообщения при коммитахУказывайте FR в коммитах, README и/или issueREADME3: форматы, API, структура и т. д.INSTALL: сборка клиента и сервера, конфигурацияи примеры, запуск и т. д.Добавьте пользователяhttps://github.com/GabolЗадавайте вопросы: в комментариях к FR4, вissues, в почте или личноПишите логи, например: slf4j-api + logback

3http://en.wikipedia.org/wiki/Markdown4http://incubos.org


https://github.com/Gabol

http://en.wikipedia.org/wiki/Markdown

http://incubos.org

Домашнее задание Тулзы

Тулзы

IntelliJ IDEA Community Edition5

.idea, *.ipr, *.iml, *.iws, *.dat в .gitignoreДля SBT есть плагин sbt-idea

5http://www.jetbrains.com/idea/free_java_ide.htmlЦесько В. А. (CompSciCenter) Haystack 14 октября 2013 г. 52 / 53

http://www.jetbrains.com/idea/free_java_ide.html

Вопросы?

Вопросы?

http://incubos.org/contacts/Общие вопросы — в Twitter: @incubosВопросы по лекциям — в комментариях:http://incubos.org/blog/Частные вопросы — в почту[email protected]


http://incubos.org/contacts/

https://twitter.com/incubos

http://incubos.org/blog/

mailto:[email protected]

Technology

Базы данных. Haystack