Классификация систем хранения и обработки данных

Что общего в архитектуре любого
web-приложения среднего уровня?
у нас ~2.2 миллиона DAU, ~40kk php req, avg req time 0.03 ;-)
Обработка соединений (nginx, apache, node.js, tornado и т.п.)
Application Layer (php,python,v8, jvm, asp.net и т.п.)
СИСТЕМЫ ХРАНЕНИЯ ДАННЫХ (filesystem, memory, sql, nosql)
Наш (и не только) опыт показывает, что практически не важно какую технологию вы используете для Application Logic, узким местом является система хранения, причем зачастую не потому что «плохая», а потому что используется не правильно.

Как мы классифицируем системы хранения
1) где и сколько храним данных, протокол
Тип хранения
Где именно система хранит данные
RAM (быстро), SSD, SAS, HDD во всех проявлениях (медленнее)
Гибрид RAM+Диск (IMHO оптимально)
Доступность по сети (TCP\UDP)
Ограничение на размер данных
Соотношение размер\скорость работы. На текущий момент все рассматриваемые продукты имеют достаточно большие лимиты на максимальный размер данных, но для всех систем хранения есть предел, после которого «активная часть данных» начинает тормозить

Как мы классифицируем системы хранения
2) что и как пишем
Надежность записи (защита от сбоев, допустимая величина потерь, ACID)
Сложность структур данных, доступных для записи (таблицы, объекты, списки, массивы, хеши, деревья и т.п.)
Соотношение Размер структуры и Скорость записи в req/sec
Конкурентность и масштабируемость записи (горизонтальная желательно)
Возможность проверки консистентности данных на стороне системы хранения
Возможность BULK (BATCHING) записи
Возможность асинхронной (DELAYED) записи

Как мы классифицируем системы хранения
3) что и как читаем
Надежность чтения (актуальность данных на момент чтения, допустимые потери актуальности)
Сложность языка (api) запросов и структур данных, доступных для чтения (SQL, XQuery, REST, GET\SET)
Соотношение Размер «порции данных» (recordset, nodeset) и скорость чтения в req/sec
масштабируемость чтения (горизонтальная желательно) и конкурентность (где происходит блокировка, buzy lock и т.п.)

Как мы классифицируем системы хранения
4) как этим управлять
Переносимость (доступность для альтернативной win32 платформы ;) и легкость развертывания (пакеты, порты и т.п.)
Простота, гибкость и глубина конфигурирования
Управление масштабированием (из приложения или «коробочно» на уровне системы хранения)
Легкость (скорость и простота) backup\restore
Легкость операций по изменению структуры хранения данных
Доступность и глубина «мониторинга» (готовые шаблоны для cacti, nagios, munin, zabbix что можно мониторить и т.п.)
Возможности устранения failover

Как мы классифицируем «данные»
5) какой характер работы с данными
Соотношение чтение\запись?
Cложность выборок
Оперативные данные или «аналитика» (OLTP \ OLAP )?
Размер «активной части данных» (на запрос, на все приложение)
Легкость изменения структур данных (schema-lock, schema-less) и легкость (прозрачность) «re-sharding» в случае горизонтального масштабирования

Классификация на практике
Хранение

Классификация на практике
Запись (часть 1)

Классификация на практике
Запись (часть 2)

Классификация на практике
Запись (часть 3)

Классификация на практике
Чтение

Классификация на практике
Управляемость (часть 1)

Классификация на практике
Управляемость (часть 2)

Классификация на практике
Управляемость (часть 3)

Ок, а теперь «грабли» ;-)
MySQL InnoDB
Все просто замечательно, пока какой то тип нагрузки преобладает (чтение для классических сайтов, запись для логов или аналитики)
Как только надо много read+write из одного и того же места и нет времени на Replication Lag … после определенной concurency все равно наступает «жопа», 99% процентов выбирают Memcache для того чтобы упаковать в него «активную часть данных» и использует его как pesistent storage, а не как кеш ;-)
Также весьма популярен sharding, основная проблема в нем правильный выбор ключа для хеширования, при этом решардинг (ребалансировка) и schema change – тоже головная боль

Ок, а теперь «грабли» ;-)
memcache
Dog-pile эффекты (lock через add при записи)
Размер value одних ключей больше чем других. Следите на LRU, slubs и evicted
Некоторые ключи читаются\пишутся чаще чем остальные, не допускайте чтобы этих ключей было МАЛО (один) и они после хеширования ложились на ОДИН сервер =)
Пишите код с учетом того, что может навернуться канал связи в ДЦ (read\write\connect timeout) или вы можете просто упереться в потолок сетевухи
Память дешевая, но не бесконечно дешевая, не храните в кеше ЛИШНИХ данных =)

Ок, а теперь «грабли» ;-)
APC
ОЧЕНЬ быстрый, но Dog-pile эффекты никуда не делись (lock через apc_add есть забавный баг)
Shared memory сегмент «на процесс», кеш не общий, может получиться дублирование данных
МНОГО данных не положишь (гигабайты, сотни мегабайт на приложение) максимум десятки Mb
Нельзя использовать как pesistent storage потому что горизонтально не масштабируется
IMHO идеален для кеша read-only «справочных» данных

Ок, а теперь «грабли» ;-)
FileSystem, GlusterFS
Если «активная часть данных» умещается на SSD и есть деньги тащите туда. За минимизацией random seek будующее =)
csv, grep, sed, awk + pipes никто не отменял
GlusterFS непонятно еще как «мониторить», пока нет кластерных реализаций lsof и iostat и т.п.
IMHO идеально для UGC (не видео) + метаданные в более «быстром» хранилище
IMHO хранить (монтировать) лучше на Application серверах (запись+чтение) + Frontend (чтение)

Ок, а теперь «грабли» ;-)
Redis
Все что справедливо для Memcache
Single thread (пока еще) в век Multi Cure CPU и даже без worker pool management ;)
Дамп отдельным тредом (за сколько времени ваши диски зальют 8Gb ?)
Не устоявшийся набор команд и их поведение (пример сочетание SETEX + INCR)
Осторожнее с maxmemory
KEYS такой соблазнительный и такой «блокирующий» (RTFM юзайте SETS ;)
Дублирование данных и не всегда эффективное хранение в памяти (мониторинга распределения ключей нет)