Презентация Классификация систем хранения и обработки данных Климов Евгений aka Slach www. I-jet. ru http://slach. livejournal. com онлайн
На нашем сайте вы можете скачать и просмотреть онлайн доклад-презентацию на тему Классификация систем хранения и обработки данных Климов Евгений aka Slach www. I-jet. ru http://slach. livejournal. com абсолютно бесплатно. Урок-презентация на эту тему содержит всего 21 слайд. Все материалы созданы в программе PowerPoint и имеют формат ppt или же pptx. Материалы и темы для презентаций взяты из открытых источников и загружены их авторами, за качество и достоверность информации в них администрация сайта не отвечает, все права принадлежат их создателям. Если вы нашли то, что искали, отблагодарите авторов - поделитесь ссылкой в социальных сетях, а наш сайт добавьте в закладки.
Оцените презентацию от 1 до 5 баллов!
- Тип файла:ppt / pptx (powerpoint)
- Всего слайдов:21 слайд
- Для класса:1,2,3,4,5,6,7,8,9,10,11
- Размер файла:287.50 kB
- Просмотров:63
- Скачиваний:0
- Автор:неизвестен
Слайды и текст к этой презентации:
№1 слайд
Содержание слайда: Классификация систем хранения и обработки данных
Климов Евгений aka Slach
www.I-jet.ru
http://slach.livejournal.com
№2 слайд
Содержание слайда: Что общего в архитектуре любого
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, узким местом является система хранения, причем зачастую не потому что «плохая», а потому что используется не правильно.
№3 слайд
Содержание слайда: Как мы классифицируем системы хранения
1) где и сколько храним данных, протокол
Тип хранения
Где именно система хранит данные
RAM (быстро), SSD, SAS, HDD во всех проявлениях (медленнее)
Гибрид RAM+Диск (IMHO оптимально)
Доступность по сети (TCP\UDP)
Ограничение на размер данных
Соотношение размер\скорость работы. На текущий момент все рассматриваемые продукты имеют достаточно большие лимиты на максимальный размер данных, но для всех систем хранения есть предел, после которого «активная часть данных» начинает тормозить
№4 слайд
Содержание слайда: Как мы классифицируем системы хранения
2) что и как пишем
Надежность записи (защита от сбоев, допустимая величина потерь, ACID)
Сложность структур данных, доступных для записи (таблицы, объекты, списки, массивы, хеши, деревья и т.п.)
Соотношение Размер структуры и Скорость записи в req/sec
Конкурентность и масштабируемость записи (горизонтальная желательно)
Возможность проверки консистентности данных на стороне системы хранения
Возможность BULK (BATCHING) записи
Возможность асинхронной (DELAYED) записи
№5 слайд
Содержание слайда: Как мы классифицируем системы хранения
3) что и как читаем
Надежность чтения (актуальность данных на момент чтения, допустимые потери актуальности)
Сложность языка (api) запросов и структур данных, доступных для чтения (SQL, XQuery, REST, GET\SET)
Соотношение Размер «порции данных» (recordset, nodeset) и скорость чтения в req/sec
масштабируемость чтения (горизонтальная желательно) и конкурентность (где происходит блокировка, buzy lock и т.п.)
№6 слайд
Содержание слайда: Как мы классифицируем системы хранения
4) как этим управлять
Переносимость (доступность для альтернативной win32 платформы ;) и легкость развертывания (пакеты, порты и т.п.)
Простота, гибкость и глубина конфигурирования
Управление масштабированием (из приложения или «коробочно» на уровне системы хранения)
Легкость (скорость и простота) backup\restore
Легкость операций по изменению структуры хранения данных
Доступность и глубина «мониторинга» (готовые шаблоны для cacti, nagios, munin, zabbix что можно мониторить и т.п.)
Возможности устранения failover
№7 слайд
Содержание слайда: Как мы классифицируем «данные»
5) какой характер работы с данными
Соотношение чтение\запись?
Cложность выборок
Оперативные данные или «аналитика» (OLTP \ OLAP )?
Размер «активной части данных» (на запрос, на все приложение)
Легкость изменения структур данных (schema-lock, schema-less) и легкость (прозрачность) «re-sharding» в случае горизонтального масштабирования
№8 слайд
Содержание слайда: Классификация на практике
Хранение
№9 слайд
Содержание слайда: Классификация на практике
Запись (часть 1)
№10 слайд
Содержание слайда: Классификация на практике
Запись (часть 2)
№11 слайд
Содержание слайда: Классификация на практике
Запись (часть 3)
№12 слайд
Содержание слайда: Классификация на практике
Чтение
№13 слайд
Содержание слайда: Классификация на практике
Управляемость (часть 1)
№14 слайд
Содержание слайда: Классификация на практике
Управляемость (часть 2)
№15 слайд
Содержание слайда: Классификация на практике
Управляемость (часть 3)
№16 слайд
Содержание слайда: Ок, а теперь «грабли» ;-)
MySQL InnoDB
Все просто замечательно, пока какой то тип нагрузки преобладает (чтение для классических сайтов, запись для логов или аналитики)
Как только надо много read+write из одного и того же места и нет времени на Replication Lag … после определенной concurency все равно наступает «жопа», 99% процентов выбирают Memcache для того чтобы упаковать в него «активную часть данных» и использует его как pesistent storage, а не как кеш ;-)
Также весьма популярен sharding, основная проблема в нем правильный выбор ключа для хеширования, при этом решардинг (ребалансировка) и schema change – тоже головная боль
№17 слайд
Содержание слайда: Ок, а теперь «грабли» ;-)
memcache
Dog-pile эффекты (lock через add при записи)
Размер value одних ключей больше чем других. Следите на LRU, slubs и evicted
Некоторые ключи читаются\пишутся чаще чем остальные, не допускайте чтобы этих ключей было МАЛО (один) и они после хеширования ложились на ОДИН сервер =)
Пишите код с учетом того, что может навернуться канал связи в ДЦ (read\write\connect timeout) или вы можете просто упереться в потолок сетевухи
Память дешевая, но не бесконечно дешевая, не храните в кеше ЛИШНИХ данных =)
№18 слайд
Содержание слайда: Ок, а теперь «грабли» ;-)
APC
ОЧЕНЬ быстрый, но Dog-pile эффекты никуда не делись (lock через apc_add есть забавный баг)
Shared memory сегмент «на процесс», кеш не общий, может получиться дублирование данных
МНОГО данных не положишь (гигабайты, сотни мегабайт на приложение) максимум десятки Mb
Нельзя использовать как pesistent storage потому что горизонтально не масштабируется
IMHO идеален для кеша read-only «справочных» данных
№19 слайд
Содержание слайда: Ок, а теперь «грабли» ;-)
FileSystem, GlusterFS
Если «активная часть данных» умещается на SSD и есть деньги тащите туда. За минимизацией random seek будующее =)
csv, grep, sed, awk + pipes никто не отменял
GlusterFS непонятно еще как «мониторить», пока нет кластерных реализаций lsof и iostat и т.п.
IMHO идеально для UGC (не видео) + метаданные в более «быстром» хранилище
IMHO хранить (монтировать) лучше на Application серверах (запись+чтение) + Frontend (чтение)
№20 слайд
Содержание слайда: Ок, а теперь «грабли» ;-)
Redis
Все что справедливо для Memcache
Single thread (пока еще) в век Multi Cure CPU и даже без worker pool management ;)
Дамп отдельным тредом (за сколько времени ваши диски зальют 8Gb ?)
Не устоявшийся набор команд и их поведение (пример сочетание SETEX + INCR)
Осторожнее с maxmemory
KEYS такой соблазнительный и такой «блокирующий» (RTFM юзайте SETS ;)
Дублирование данных и не всегда эффективное хранение в памяти (мониторинга распределения ключей нет)
№21 слайд
Содержание слайда: Ответы аудитории
Серебренной пули нет ;)
Из представленных систем хранения, по теореме CAP, MySQL это CA система, Redis, Memcache – AP
Все что я сказал банально? Пожалуйста пройдемте к кулуары, я давно хотел поговорить с умным человеком ;-)
Скачать все slide презентации Классификация систем хранения и обработки данных Климов Евгений aka Slach www. I-jet. ru http://slach. livejournal. com одним архивом:
