NewSQL: SQL никуда не уходит / Константин Осипов (tarantool.org)Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 12:00
Тезисы:
http://backendconf.ru/2017/abstracts/2788.html
Что такое NewSQL, почему NoSQL-движение превращается в NewSQL, и что эта трансформация привносит в SQL?
Попробуем разобраться, почему NoSQL-вендоры добавляют всё больше SQL-возможностей, почему стандарт SQL не пользуется популярностью, и куда это всё идёт.
Рассмотрим новые диалекты языка SQL, такие как:
- Cassandra QL
- Couchbase NQL
- Elastisearch
и сравним их с подходом MongoDB & RethinkDB, добавляющим новый язык работы с данными.
Останется ли в мире СУБД что-то ценного от NoSQL-движения?
Ну и, наконец, рассмотрим новый вызов реляционной модели: multi-model databases.
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
NewSQL: SQL никуда не уходит / Константин Осипов (tarantool.org)Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 12:00
Тезисы:
http://backendconf.ru/2017/abstracts/2788.html
Что такое NewSQL, почему NoSQL-движение превращается в NewSQL, и что эта трансформация привносит в SQL?
Попробуем разобраться, почему NoSQL-вендоры добавляют всё больше SQL-возможностей, почему стандарт SQL не пользуется популярностью, и куда это всё идёт.
Рассмотрим новые диалекты языка SQL, такие как:
- Cassandra QL
- Couchbase NQL
- Elastisearch
и сравним их с подходом MongoDB & RethinkDB, добавляющим новый язык работы с данными.
Останется ли в мире СУБД что-то ценного от NoSQL-движения?
Ну и, наконец, рассмотрим новый вызов реляционной модели: multi-model databases.
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
Бинарные (файловые) хранилища- страшная сказка с мрачным концомDaniel Podolsky
1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочетаний требований решение есть!
4.3. А для остальных - решения нет.
5. Так что же все-таки делать? (заключение)
5.1. искать бюджет
5.2. все-таки сложить все файлы в базу - личное мнение докладчика
5.3. написать свое
5.3.1. не так это и сложно!
5.3.2. но все же довольно сложно
My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)Ontico
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
Кэширование данных в web приложениях. Использование memcached / Юрий Красноще...Ontico
Каждый разработчик web приложений рано или поздно сталкивается с довольно типичной проблемой: перед ним стоит задача построить фабрику по производству омнониевых торсиометров.
Фабрика производит омнониевые торсиометры очень быстро, но для калибровки прибора (как известно) необходим омноний, за которым приходится летать на Андромеду.
Пока корабль летит до Андромеды, фабрика простаивает.
Самый очевидный выход из ситуации - построить склад омнониума прямо рядом с фабрикой.
Терминология кэширования
Выбор места для кэширования в WEB
Выбор данных для кэширования
Кэширование на стороне бэкенда
Отдельный кэширующий сервис
Пара слов о memcached
Пара слов о Redis
1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочет�
NoSQL - коротко о главном / Сергей Туленцев (TextMaster)Ontico
В последнее время сайты и веб-приложения растут всё быстрее, а задачи, стоящие перед БД, эволюционируют. Поэтому для (успешных) проектов традиционная реляционная СУБД часто не может удовлетворить все нужды. В ответ на эту проблему возникло большое количество разнообразных решений, очень различающихся по функциональности и характеристикам. При этом они все заносятся под один большой зонтик "NoSQL", что не способствует пониманию вещей. Запутанные веб-разработчики пытаются взять текущую модную и обсуждаемую NoSQL БД и приспособить её под свои нужды, не всегда понимая, нужную ли технологию они выбрали (референс к MongoDB is Web Scale http://www.youtube.com/watch?v=b2F-DItXtZs).
Целью доклада является упорядочение хаоса в головах разработчиков.
- Обзор популярных БД и их классификация (KV store, document store, columnar, etc).
- CAP-теорема и её применение к выбору БД (где-то параметры можно настроить, где-то подпереть сбоку костылем, где-то - увы).
- Типичные примеры применения.
- Антипаттерны применения (из личного опыта и тысяч прочитанных вопросов на stackoverflow :) ).
Бинарные (файловые) хранилища- страшная сказка с мрачным концомDaniel Podolsky
1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочетаний требований решение есть!
4.3. А для остальных - решения нет.
5. Так что же все-таки делать? (заключение)
5.1. искать бюджет
5.2. все-таки сложить все файлы в базу - личное мнение докладчика
5.3. написать свое
5.3.1. не так это и сложно!
5.3.2. но все же довольно сложно
My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)Ontico
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
Кэширование данных в web приложениях. Использование memcached / Юрий Красноще...Ontico
Каждый разработчик web приложений рано или поздно сталкивается с довольно типичной проблемой: перед ним стоит задача построить фабрику по производству омнониевых торсиометров.
Фабрика производит омнониевые торсиометры очень быстро, но для калибровки прибора (как известно) необходим омноний, за которым приходится летать на Андромеду.
Пока корабль летит до Андромеды, фабрика простаивает.
Самый очевидный выход из ситуации - построить склад омнониума прямо рядом с фабрикой.
Терминология кэширования
Выбор места для кэширования в WEB
Выбор данных для кэширования
Кэширование на стороне бэкенда
Отдельный кэширующий сервис
Пара слов о memcached
Пара слов о Redis
1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочет�
NoSQL - коротко о главном / Сергей Туленцев (TextMaster)Ontico
В последнее время сайты и веб-приложения растут всё быстрее, а задачи, стоящие перед БД, эволюционируют. Поэтому для (успешных) проектов традиционная реляционная СУБД часто не может удовлетворить все нужды. В ответ на эту проблему возникло большое количество разнообразных решений, очень различающихся по функциональности и характеристикам. При этом они все заносятся под один большой зонтик "NoSQL", что не способствует пониманию вещей. Запутанные веб-разработчики пытаются взять текущую модную и обсуждаемую NoSQL БД и приспособить её под свои нужды, не всегда понимая, нужную ли технологию они выбрали (референс к MongoDB is Web Scale http://www.youtube.com/watch?v=b2F-DItXtZs).
Целью доклада является упорядочение хаоса в головах разработчиков.
- Обзор популярных БД и их классификация (KV store, document store, columnar, etc).
- CAP-теорема и её применение к выбору БД (где-то параметры можно настроить, где-то подпереть сбоку костылем, где-то - увы).
- Типичные примеры применения.
- Антипаттерны применения (из личного опыта и тысяч прочитанных вопросов на stackoverflow :) ).
Golang в действии: Как нам удается писать highload приложение на (не?)подходя...Daniel Podolsky
Последние 2 года язык Go является моим - нашим - основным средством заработка на хлеб. Хватает, в общем-то, и на хлеб, и на масло, а иногда и на красную икру.
Не покривив душой, я могу сказать, что мы относимся к языку Go и его создателям с симпатией и уважением.
Однако, при всем нашем уважении, заявить, что Go предназначен для "тяжелых" проектов, я, не покривив душой, не могу.
Во-первых, Go молодой язык, для которого еще не известны паттерны и - что важнее - антипаттерны. Тем, кто пишет на Go тяжелое приложение сегодня, приходится тратить существенное время на тесты и оптимизации
Во-вторых, выразительные средства Go довольно скудны, что приводит к появлению в коде ужасающего количества boilerplate, за которым эффективно прячется бизнес-логика. Программу на Go бывает трудно охватить взглядом и поместить ее модель себе в голову просто из-за количества строк, которые надо для этого прочесть.
В-третьих, у Go есть проблемы с эффективностью кода. У Go плохой оптимизатор. У Go плохо с "заточкой" под железо - вспомним хотя бы историю с патчем CloudFlare для TLS. Патч ведь так и не попал в основную ветку...
Возникает вопрос - почему же, не по наслышке зная о вышеперечисленных проблемах, мы пишем наш реально тяжелый проект именно на Go?
Ответ прост: Go не идеален, но под наши задачи он подходит лучше всего.
Раньше мы строили разные тяжелые бекенды на perl, python, java, groovy и даже lua+nginx. Нам есть, с чем сравнивать.
Во-первых, Go достаточно быстр. Во всяком случае, он быстрее perl и python на нашем профиле нагрузки.
Во-вторых, и это важнее, Go предоставляет вполне достаточные средства контроля за потреблением как RAM, так и CPU. Например, регулярные выражения Go не такие гибкие, как pcre, и, по моим наблюдениям, медленнее, чем pcre. Но! регулярные выражения в Go всегда отрабатывают за предсказуемое время!
В-третьих, создатели языка не врут нам - они, действительно, постарались сделать язык, на котором человекочитаемую программу написать проще, чем нечитаемую. И у них - с некоторомы оговорками - получилось! Даже пресловутый boilerplate не способен этому помешать.
Наконец, Go просто сумел нам понравиться, чего уже давно не случалось с языками программирования.
Итак, на основании опыта, полученного при создании пилотной версии проекта inCaller.org я расскажу о том, как мы писали на Go тяжелое приложение.
Миллионы одновременных персистентных websocket соединений, десятки тысяч коннектов по ssl в секунду, сотни тысяч в секунду обновлений записей в БД.
Я расскажу об антипаттернах, нами обнаруженных, о методике тестирования производительности, анализа проблем и способах с проблемами справиться.
Доклад рассчитан на backend-программистов, как на языке Go, так и на других.
20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения ...IT-Portfolio
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков (ведущий разработчик Cezurity)
Аннотация
Когда команда разработчиков собирается написать новый сервис, у нее, как правило, отсутствует свободное время, но есть необходимый энтузиазм. Из-за нехватки времени многие архитектурные решения приходится принимать, руководствуясь общими соображениями, так как провести всесторонние тесты имеющихся на рынке средств в краткие сроки невозможно. Мы, специалисты компании Cezurity, начали свой проект не вчера, и уже накопили некоторый опыт использования технологий, появившихся сравнительно недавно - таких как Skytools, Node.JS, RabbitMQ и Redis. О том, какие возникли проблемы при внедрении этих средств, и какие их ограничения пришлось преодолевать и учитывать - мой доклад. Кроме того, я расскажу о новом направлении в нашей деятельности - внедрении HBase для хранения большого объема данных.
Биография
Докладчик - узкий специалист широкого профиля, относит себя к виду, называемому в современной англоязычной литературе термином "DevOps". Любит принимать участие в создании сложных систем и постоянно это делает. Никогда не работал в Яндексе, компенсировав это работой в Mail.Ru и некоторых других местах.
Open source субд глазами обычного программистаSlach
Попытался "быстренько" пробежаться по всем СУБД с которыми работал за 20 лет и постараться вложить слушателям мысль что СУБД надо выбирать под нагрузку
и что для СУБД надо знать "алгоритмы" и "эксплуатацию"
Слон желтого цвета и его друзья (эксплуатация Hadoop-стека в федеральном прое...Ontico
Налог на добавленную стоимость — важнейшее средство пополнения бюджета страны, а проверка корректности налоговых деклараций — важнейшая задача Федеральной Налоговой Службы. Естественно, в наше время эти задачи не выполняются вручную. На помощь приходит автоматизированная система, работающая на основе стека технологий Hadoop. При разработке и эксплуатации этой системы пришлось столкнуться с огромным количеством трудностей, были перепробованы самые разные варианты, от классических map-reduce задач на базе YARN до Impala, последних версий Spark и технологии долгоживущих исполнителей LLAP, которая пока существует только в версии для разработчиков.
В борьбе за производительность мы выработали и проверили десятки гипотез. Одной из особенностей проекта является отсутствие подключения вычислительных мощностей к сети Интернет, другая особенность — необходимость обслуживать как интерактивные запросы от пользователей на местах, так и аналитические запросы, продолжительность которых — не один час.
Отдельного рассказа заслуживает система сбора метрик кластера и взаимодействие приложений с ней.
Михаил Корепанов "Инкрементальные обновления на клиенте. Ловкость рук и никак...Yandex
С развитием веб-технологий сайты стали уже не просто информационными ресурсами, а полноценными приложениями. Такие приложения используют большое количество статических ресурсов, общий объем которых часто превышает 1 МБ. При условии частых обновлений встает вопрос: "Как наиболее эффективно загружать ресурсы при выходе новых версий?". В докладе будет рассказано про существующие техники обновления, которые позволяют загружать не целиком новые ресурсы, а только «разницу» между новой и старой версией.
Рельсы прекрасный инструмент, но в некоторых ситуациях они не справляются.
В этом докладе рассказывается о таких ситуациях и одном из вариантов решения
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Эксплуат...IT-Portfolio
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Эксплуатация HBase на паре жизненных примеров", Александр Чистяков (ведущий разработчик Git in Sky)
Владимир Русинов, Алексей Капранов "Яндекс.Диск: архитектура, синхронизация и...Yandex
Доклад о том, как решалась задача надёжного хранения файлов и данных миллионов пользователей. Рассказ про развитие архитектуры кластера Диска: от первого черновика к реальности
5. Предыстория
● HighLoad 2012 – https://clck.ru/9Lutd (не я)
● DevConf 2014 – https://clck.ru/9Lutw (уже я)
● Клиент – Setup.ru (конструктор сайтов)
● 100+ млн. пользовательских файлов
●Метаинформация в PostgreSQL
● Сами файлы – в PostgreSQL через LO API
6. Наше время
● Проект на Perl (был когда-то такой язык)
● Хостинг – Hetzner (лучше уж Perl)
● Текущая конфигурация машин в Hetzner не
имеет дисков достаточного объема (8
терабайт - максимум)
●Мы должны были уметь хранить больше
чем 8Тб файлов уже вот прямо вчера
7. Как быть?
● Делегировать эту задачу Amazon
● Построить свой Amazon:
● Elliptics
● OpenStack Swift
● Ceph Object Gateway
● Riak CS
● LeoFS
8. Общее для всех
● HTTP REST или Amazon S3 интерфейс
● Автоматическая репликация
● Автоматическая отказоустойчивость
● Легкое добавление новых узлов
9. Устройство любого object storage
● Узлы, на которых хранятся данные
● Узлы, на которых хранятся метаданные
●Маршрутизаторы запросов к первым двум
● Background workers
● Как я уже говорил однажды в Омске:
Любой* NoSQL – несколько локальных
хранилищ + роутер запросов к ним
*не любой
10. Надо сделать выбор
● Erlang – как Python, только лучше*
●Mnesia и LevelDB – как SQLite, только лучше*
● DuckDuckGo – как Yandex, только лучше*
● Интегрированный механизм кэширования
лучше*, чем его отсутствие
● LeoFS: Erlang, Mnesia, LevelDB, не Yandex,
интегрированное кэширование
*не лучше
11. Последствия выбора
● Примерно как у свадьбы, только
развестись гораздо сложнее
● Помехи при выборе:
● Эффект Даннинга-Крюгера
● Ошибка выживших
● Недостаточность и плохое качество
информации о решении в Интернете
12. Устройство LeoFS
● LeoFS manager – хранит метаданные
● LeoFS storage – хранит данные
● LeoFS gateway – маршрутизирует запросы и
кэширует контент локально
● LeoFS manager – единая точка отказа
● Поэтому их делают два: master и slave
13. Устройство LeoFS
● LeoFS manager использует Mnesia
● LeoFS storage использует LevelDB
●Mnesia – распределенная СУБД из
стандартной поставки Erlang
● LevelDB – key-value storage, разработана в
Google, представляет собой LSM-tree
14. Устройство LeoFS
● Внутренние процессы:
● LevelDB нужно компактить*
● При добавлении/удалении нод нужно
перестраивать кольцо маршрутизации
●Можно временно включать/выключать
узел
● К счастью, все это делается вручную
* не всем
15. Развертывание LeoFS
● Для развертывания чего угодно я
использую Ansible
● Playbooks для LeoFS: https://clck.ru/9Lx73
● (По ссылке старая версия, сейчас все
переделано на установку через роли)
16. То, ради чего все затевалось
● Отказоустойчивость:
● В конфигурационном файле задается
количество реплик и
● Количество успешных операций
● Чтения
● Записи
● Удаления
17. Как это выглядит у нас
● Данные хранятся на 5 узлах, 8
потребителей
●
18. Что мы храним
● Все хранимые объекты больше 64
килобайт
● Всего хранится 7 терабайт таких объектов
● Только 15-20% запросов идет в LeoFS,
объекты размером менее 64К по-
прежнему отдаются из PostgreSQL
19. Домашняя работа
● Найдите на графике момент отказа*:
* я и сам не найду
23. Плюсы
● 12 июня – начало выбора технологии
● Через пару дней – начало внедрения
● К августу развернут параллельный
“старому” новый сторадж на LeoFS
● В сентябре переезд полностью состоялся
● В августе умер один из пяти узлов –
заменили целиком, юзеры не заметили
25. Подводные камни
● Клиентские библиотеки S3 все плохого
качества
● При отказе узла latency еще возрастает
● Если на gateways включено кэширование
на диск, и на диске кончается место –
latency возрастает неимоверно
● Балансировка контента не автоматически
(и это плюс)
26. Границы применимости
●Мы храним статический контент
●Мы никогда не модифицируем, всегда –
новый URL
●Мы никогда не удаляем контент
● Наши пользователи лояльно относятся к
latency (это обусловлено тем, что
существует два типа контента)
27. Выводы
● Нельзя просто так взять и заменить
RDBMS (FS, whatever) на NoSQL
28. Спасибо за внимание!
● С вами был Александр Чистяков
● Из компании Git in Sky
● http://gitinsky.com
● alex@gitinsky.com
● http://twitter.com/noatbaksap
● http://meetup.com/DevOps-40