1. Введение в проблематику: файловые хранилища, их классификация и ключевые характеристики - по версии докладчика.
1.1. Термины и определения: файл, хранилище, POSIX file system, документ-ориентированное хранилище, области применимости и условия эксплуатации.
1.2. Классификация по размеру: количество записей, количество байт, количество запросов, количество обновлений и сочетание этих параметров, позволяющее назвать хранилище “большим”.
1.3. Требования бизнеса: бизнесу нужна информация, а не ее хранилища.
2. Два с половиной года эксплуатации в проекте Setup.Ru: попытка систематизации опыта.
2.1. Исторический экскурс.
2.1.1. Начало 2012: традиционный подход, локальная FS и rsync.
2.1.2. Середина 2012: проблема обеспечения отказоустойчивости, первая версия binstore (PostgreSQL based).
2.1.3. Весна 2013: проблемы самописной синхронизации и длинных транзакций.
2.1.4. Весна 2014: исчерпаны возможности вертикального масштабирования, требуется внедрение шардинга.
2.1.5. Начало 2015: проблемы эксплуатации LoeFS и поиски альтернативного решения.
2.1.6. Весна 2015: отказоустойчивое версионированное транзакционное документ-ориентированное хранилище на базе NoSQL кластера (на момент написания тезисов находится на этапе внедрения, выход на промышленную эксплуатацию намечен на 30 апреля 2015 года).
2.2. Эволюция наших представлений об отказоустойчивости и распределении нагрузки.
2.2.1. Меры по обеспечению отказоустойчивости, традиционный подход дал сбой: короткий downtime важнее 100% сохранности данных.
2.2.2. Меры по обеспечению должной производительности на большом общем объеме и маленьком hot set: все упирается в файловый кэш.
2.2.3. Распределенные системы хранения как решение проблем и как источник новых.
2.2.3.1. Проблемы асинхронной репликации: eventual consistency.
2.2.3.2. Проблемы синхронной репликации: задержки.
2.2.3.3. Проблемы систем с выделенной master node: отказоустойчивость.
2.2.3.4. Проблемы систем shared nothing: консистентность.
2.2.3.5. Ребалансинг: почему он создает проблемы, и почему от него нельзя отказаться.
2.3. Поиск решения: проблема, решение, ожидаемый результат, побочные эффекты.
2.3.1. РСУБД PostgreSQL.
2.3.1.1. Очень хорошо для маленьких файлов.
2.3.1.2. Очень плохо для больших файлов в BLOB.
2.3.1.3. Слишком легко сделать сложно: дополнительные индексы потребляют память, сложные join потребляют процессор.
2.3.2. Собственная репликация: изобретение велосипеда.
2.3.2.1. Репликация v1: внешняя line-by-line асинхронная.
2.3.2.2. Репликация v2: длинные транзакции, sequences и eventual consistency.
2.3.2.3. Отказ от собственной репликации: наше представление о распределенных хранилищах не выдержали столкновения с реальностью.
2.3.3. Большое хранилище и проблема удаления файла.
2.3.3.1. Как ни странно, сама поддержка такой возможности резко усложняет систему.
2.3.3.2. Защита авторских прав: поддержка удаления неизбежна.
2.3.4. Технологические ловушки.
2.3.4.1. Невозможно сменить технологию в спокойном режиме.
2.3.4.2. java лучше, чем erlang.
2.4. Современное состояние дел: в каких условиях и для решения каких задач создается новое хранилище.
2.4.1. Горизонтальное масштабирование: других вариантов нет.
2.4.2. Индексы должны помещаться в память.
2.4.3. Кластер должен:
2.4.3.1. обеспечивать replication factor 3;
2.4.3.2. обеспечивать ребалансинг при добавлении новой нод;
2.4.3.3. выполнять полезную работу во время ребалансинг;
2.4.3.4. отвечать на запросы до последней живой реплики!
3. Попытки поиска альтернативы.
3.1. Большая отказоустойчивая СХД: дорого.
3.2. Распределенные POSIX-совместимые файловые системы: созданы под другие задачи.
3.3. Общие проблемы:
3.3.1. минимизация стартовых вложений;
3.3.2. минимизация технологической новизны.
3.4. Попытка анализа стоимости внедрения и владения для разных вариантов.
4. Заключение и выводы:
4.1. Краткое описание разработанной нами системы: отказоустойчивое версионированное транзакционное документ-ориентированное хранилище на базе NoSQL кластера.
4.1.1. Базовая СУБД.
4.1.2. Сценарии использования.
4.1.3. Возможные узкие места.
4.1.4. Цифры и графики: объемы и производительность.
4.2. Прогноз развития событий на ближайший год.