🗊Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com

Категория: Технологии
Нажмите для полного просмотра!
Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №1Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №2Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №3Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №4Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №5Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №6Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №7Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №8Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №9Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №10Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №11Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №12Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №13Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №14Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №15Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №16Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №17Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №18Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №19Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №20Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com, слайд №21
Скачать

Содержание ▲

Вы можете ознакомиться и скачать Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com. Презентация содержит 21 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

Слайды и текст этой презентации

Слайд 1


Классификация систем хранения и обработки данных Климов Евгений aka Slach www.I-jet.ru http://slach.livejournal.com
Описание слайда:
Классификация систем хранения и обработки данных Климов Евгений 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, узким местом является система хранения, причем зачастую не потому что «плохая», а потому что используется не правильно.
Описание слайда:
Что общего в архитектуре любого 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) Ограничение на размер данных Соотношение размер\скорость работы. На текущий момент все рассматриваемые продукты имеют достаточно большие лимиты на максимальный размер данных, но для всех систем хранения есть предел, после которого «активная часть данных» начинает тормозить
Описание слайда:
Как мы классифицируем системы хранения 1) где и сколько храним данных, протокол Тип хранения Где именно система хранит данные RAM (быстро), SSD, SAS, HDD во всех проявлениях (медленнее) Гибрид RAM+Диск (IMHO оптимально) Доступность по сети (TCP\UDP) Ограничение на размер данных Соотношение размер\скорость работы. На текущий момент все рассматриваемые продукты имеют достаточно большие лимиты на максимальный размер данных, но для всех систем хранения есть предел, после которого «активная часть данных» начинает тормозить

Слайд 4


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

Слайд 5


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

Слайд 6


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

Слайд 7


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

Слайд 8


Классификация на практике Хранение
Описание слайда:
Классификация на практике Хранение

Слайд 9


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

Слайд 10


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

Слайд 11


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

Слайд 12


Классификация на практике Чтение
Описание слайда:
Классификация на практике Чтение

Слайд 13


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

Слайд 14


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

Слайд 15


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

Слайд 16


Ок, а теперь «грабли» ;-) MySQL InnoDB Все просто замечательно, пока какой то тип нагрузки преобладает (чтение для классических сайтов, запись для логов или аналитики) Как только надо много read+write из одного и того же места и нет времени на Replication Lag … после определенной concurency все равно наступает «жопа», 99% процентов выбирают Memcache для того чтобы упаковать в него «активную часть данных» и использует его как pesistent storage, а не как кеш ;-) Также весьма популярен sharding, основная проблема в нем правильный выбор ключа для хеширования, при этом решардинг (ребалансировка) и schema change – тоже головная боль
Описание слайда:
Ок, а теперь «грабли» ;-) 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) или вы можете просто упереться в потолок сетевухи Память дешевая, но не бесконечно дешевая, не храните в кеше ЛИШНИХ данных =)
Описание слайда:
Ок, а теперь «грабли» ;-) 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 «справочных» данных
Описание слайда:
Ок, а теперь «грабли» ;-) 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 (чтение)
Описание слайда:
Ок, а теперь «грабли» ;-) 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 ;) Дублирование данных и не всегда эффективное хранение в памяти (мониторинга распределения ключей нет)
Описание слайда:
Ок, а теперь «грабли» ;-) Redis Все что справедливо для Memcache Single thread (пока еще) в век Multi Cure CPU и даже без worker pool management ;) Дамп отдельным тредом (за сколько времени ваши диски зальют 8Gb ?) Не устоявшийся набор команд и их поведение (пример сочетание SETEX + INCR) Осторожнее с maxmemory KEYS такой соблазнительный и такой «блокирующий» (RTFM юзайте SETS ;) Дублирование данных и не всегда эффективное хранение в памяти (мониторинга распределения ключей нет)

Слайд 21


Ответы аудитории Серебренной пули нет ;) Из представленных систем хранения, по теореме CAP, MySQL это CA система, Redis, Memcache – AP Все что я сказал банально? Пожалуйста пройдемте к кулуары, я давно хотел поговорить с умным человеком ;-)
Описание слайда:
Ответы аудитории Серебренной пули нет ;) Из представленных систем хранения, по теореме CAP, MySQL это CA система, Redis, Memcache – AP Все что я сказал банально? Пожалуйста пройдемте к кулуары, я давно хотел поговорить с умным человеком ;-)

Скачать

Похожие презентации
Mypresentation.ru
Загрузить презентацию