Обзорный доклад про базовое внутреннее устройство любого современного поискового движка. Про сжатые списки документов и позиций, как затем с ними работает поиск совпадающих документов (и разные операторы), как устроено ранжирование найденных документов, как бывают устроены и работают с фильтрацией и агрегацией дополнительные (нетекстовые) атрибуты документов. По возможности, упоминание всех известных вариантов реализаций (как, вообще, можно, как сделано в Sphinx, как в Lucene).
Sphinx 3.0, поиск 15 лет спустя / Андрей Аксенов (Sphinx)Ontico
За 15 лет разработки концепция немного поменялась и, начиная со Sphinx 3.0, мы теперь, если задуматься, вполне себе самостоятельная распределенная база (с фокусом на полнотекстовый поиск), а не только лишь добавочный к основному хранилищу поисковый движок.
Порядка 2 лет уже пилим ряд больших внутренних переделок под флагом 3.0 и, вот, наконец-то, доделываем. (На момент подачи тезисов "наполовину" готов новый клевый формат индекса; к моменту проведения конференции рассчитываем выложить публично доступную альфу).
Уже приделано всякое интересное:
* новый формат индекса, компактный и быстрый (в разы быстрее индексация и поиск);
* дисковое хранилище для документов и всяких спец. данных;
* полноценные B-tree индексы по атрибутам;
* репликация индексов.
Сделаю краткий обзор внутренней реализации этого всего, расскажу, как мы переложили битики и байтики, и что и почему это дало функционально.
Бенчмарков "а почему не Elastic" сделать не успеем, для этого нужны добровольцы. Добровольцы, подайте 1 громкий зеленый email вверх.
Как устроена MySQL-репликация / Андрей Аксенов (Sphinx)Ontico
Какая вообще в природе бывает репликация (sync vs. async vs. semisync, master-master vs. master-slave), как оно устроено конкретно в MySQL, в каких версиях что добавили. Про binary/relay log, про SBR/RBR/mixed форматы, про глупости с позициями и про GTID, про то, как из-за всяких бед возникают дополнительные продукты типа Tungsten и Galera. Несколько занятных фактов и парочка фокусов, которые можно учинять конкретно с MySQL-репликацией.
Доклад вчистую про внутреннее устройство, по результатам должно появляться общее понимание того, как оно работает внутри и почему именно так. Конкретные SQL-операторы подробно рассматривать НЕ будем, эти скучные мелочи необходимо будет затем самостоятельно смотреть в документации (или не смотреть).
Обзорный доклад про базовое внутреннее устройство любого современного поискового движка. Про сжатые списки документов и позиций, как затем с ними работает поиск совпадающих документов (и разные операторы), как устроено ранжирование найденных документов, как бывают устроены и работают с фильтрацией и агрегацией дополнительные (нетекстовые) атрибуты документов. По возможности, упоминание всех известных вариантов реализаций (как, вообще, можно, как сделано в Sphinx, как в Lucene).
Sphinx 3.0, поиск 15 лет спустя / Андрей Аксенов (Sphinx)Ontico
За 15 лет разработки концепция немного поменялась и, начиная со Sphinx 3.0, мы теперь, если задуматься, вполне себе самостоятельная распределенная база (с фокусом на полнотекстовый поиск), а не только лишь добавочный к основному хранилищу поисковый движок.
Порядка 2 лет уже пилим ряд больших внутренних переделок под флагом 3.0 и, вот, наконец-то, доделываем. (На момент подачи тезисов "наполовину" готов новый клевый формат индекса; к моменту проведения конференции рассчитываем выложить публично доступную альфу).
Уже приделано всякое интересное:
* новый формат индекса, компактный и быстрый (в разы быстрее индексация и поиск);
* дисковое хранилище для документов и всяких спец. данных;
* полноценные B-tree индексы по атрибутам;
* репликация индексов.
Сделаю краткий обзор внутренней реализации этого всего, расскажу, как мы переложили битики и байтики, и что и почему это дало функционально.
Бенчмарков "а почему не Elastic" сделать не успеем, для этого нужны добровольцы. Добровольцы, подайте 1 громкий зеленый email вверх.
Как устроена MySQL-репликация / Андрей Аксенов (Sphinx)Ontico
Какая вообще в природе бывает репликация (sync vs. async vs. semisync, master-master vs. master-slave), как оно устроено конкретно в MySQL, в каких версиях что добавили. Про binary/relay log, про SBR/RBR/mixed форматы, про глупости с позициями и про GTID, про то, как из-за всяких бед возникают дополнительные продукты типа Tungsten и Galera. Несколько занятных фактов и парочка фокусов, которые можно учинять конкретно с MySQL-репликацией.
Доклад вчистую про внутреннее устройство, по результатам должно появляться общее понимание того, как оно работает внутри и почему именно так. Конкретные SQL-операторы подробно рассматривать НЕ будем, эти скучные мелочи необходимо будет затем самостоятельно смотреть в документации (или не смотреть).
Бинарные (файловые) хранилища- страшная сказка с мрачным концом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. но все же довольно сложно
Где живут Ваши объявления / Тюрин Михаил (Avito)Ontico
Авито с 2010 года — с момента запуска на широкую аудиторию — прошел уже немалый путь, успев собрать более 600 миллионов объявлений со всех уголков страны, и став при этом крупнейшим классифайдом в Европе.
В докладе будет дан обзор архитектуры ядра системы с ретроспективой, перечислены основные компоненты обработки объявлений, приведены оценки параметров функционирования от "продуктовых" "количество объявлений за единицу времени" до количества запросов на разные уровни стека (веб, базы, поиск, очереди) и степени утилизации железа.
Будут также продемонстрированы примеры реализаций классических паттернов веба: кэш, прокси, денормализация и репликация, шардинг, очереди и удаленный вызов процедур — подходы, уже более 5 лет лежащие в основе нашей архитектуры. При этом будут приведены неочевидные, на взгляд автора, особенности внедрения данных подходов.
Доклад должен заинтересовать соотнесением масштабов и ключевых слов.
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
Отладка производительности приложения на Erlang / Максим Лапшин (Erlyvideo)Ontico
Байткод эрланга выполняет очень хорошо отлаженная виртуальная машина BEAM, которая превосходно работает даже на современных 72-х и более ядерных компьютерах.
Ключевая возможность эрланга в том, чтобы использовать все ядра в одном приложении, т.е. иметь в памяти одни и те же данные и обеспечивать к ним доступ без запуска кучи экземпляров одного и того же приложения по количеству ядер.
С ростом обрабатываемого трафика данных начинают возникать проблемы с многоядерным доступом к данным, возникают бутылочные горлышки и более низкоуровневые проблемы синхронизации.
В этом докладе будет рассказано, какие есть методы поиска, анализа, замера и устранения различных проблем, связанных с многотредностью: синглтонные процессы, простаивания на мьютексах и т.п.
Open source субд глазами обычного программистаSlach
Попытался "быстренько" пробежаться по всем СУБД с которыми работал за 20 лет и постараться вложить слушателям мысль что СУБД надо выбирать под нагрузку
и что для СУБД надо знать "алгоритмы" и "эксплуатацию"
Cоциальный граф "Одноклассников" в myTargetOleg Tsarev
Задача выглядит обманчиво простой — рядом с баннером игры из Одноклассников показывать текстовый тизер «эту игру играет Кот Матроскин и ещё 5 твоих друзей» (имя и количество берутся из друзей пользователя на Одноклассниках).
Как обрабатывать граф друзей проекта Одноклассники для этой задачи?
На этот простой вопрос дают разные ответы:
- взять графовую базу данных
- использовать матрицу инцидентности
- использовать список смежных вершин.
Если уточнить, что сырые данные занимают полтора терабайта, в графе 200 миллионов вершин и 13 миллиардов связей, то ручные решения сразу отметаются.
«Графовая база данных!» Стоит озвучить нагрузку в десятки тысяч запросов секунду и требования отвечать за миллисекунды (тысячные доли секунды!) как графовые базы сразу оказываются за бортом — типичное время ответа на простые запросы — единицы секунд.
Экс-разработчик MySQL и SciDB, ныне ведущий разработчик myTarget Олег Царёв расскажет, как решалась эта непростая задача в рамках проекта.
101 способ приготовления RabbitMQ и немного о pipeline архитектуре / Филонов ...Ontico
Архитектурный шаблон проектирования конвейер (pipeline) хорошо зарекомендовал себя при проектировании высоконагруженных (highload) систем. Использование шины сообщений (message bus) при реализации каналов взаимодействия позволяет достигать хороших показателей масштабируемости (scalability), но при этом появляются дополнительные накладные расходы, которые сказываются на показателях производительности (performance).
В докладе обсуждаются варианты использования системы обмена сообщениями RabbitMQ в качестве связующего программного обеспечения (middleware) для построения конвейерной архитектуры. Рассматриваются вопросы производительности и масштабирования как stateless так и statefull фильтров.
В качестве примера рассматривается реализация системы обработки сложных событий (complex event processing) применительно к управлению журналированием (log management).
MyRocks Табличный Движок для MySQL / Алексей Майков (Facebook) / Сергей Петру...Ontico
Facebook использует MySQL в качестве основного хранилища данных. MySQL работает на десятках тысяч серверов в нескольких ЦОДах. В качестве дисков используются Flash-накопители. Они дают большую производительность, но дорогой ценой — MySQL хранит данные на диске в структуре B-tree, которая использует flash-диск неоптимальным образом. В масштабах Facebook'a цена вопроса измеряется миллионами долларов.
Для оптимального использования Flash-дисков в Facebook была разработана библиотека RocksDB. Она основана на LSM-деревьях и оптимизирована для работы в условиях высокой загрузки. Чтобы использовать ее из MySQL, [совместно с MariaDB] был разработан табличный движок — MyRocks.
Данный доклад посвящен RocksDB и MyRocks. Мы расскажем о принципах их работы и преимуществах, как их настраивать, и какие возможны подводные камни.
Авторы доклада — ведущие разработчики MyRocks от Facebook и MariaDB.
RocksDB и MyRocks доступны на GitHub для свободного использования, участие в разработке также приветствуется.
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 :) ).
Andrew Aksyonoff "Архитектура вокруг поиска"Fwdays
Начиная с определенного масштаба, вокруг любого базового поискового движка плюс рядом с ним неизбежно вырастает изрядная куча всяких интересных прослоек и сервисов. Особенно, когда одним лишь поиском по ключевым словам (либо вообще булевым, либо с простеньким ранжированием по формуле) дело ограничиваться перестает. Расскажу, как сегодня выглядит архитектура сервисов “вокруг и около поиска” у нас в Авито (числа и слова для привлечения внимания: 40M+ активных объявлений, тысячи RPS, ML ранжирование, пляски с анализом и доставкой данных, и всё такое).
Осваиваем Tarantool 1.6 / Евгений Шадрин (Sberbank Digital Ventures)Ontico
Tarantool - отечественная Opensource NoSQL база данных.
В докладе мы обсудим:
- Какое место занимают NoSQL базы данных в highload проектах?
Почему и для чего вам стоит NoSQL решения?
Какие NoSQL решения вы можете использовать?
- Рассмотрим, что из себя представляет Tarantool 1.6 - база данных и сервер приложений в одном лице.
Какие основные особенности Tarantool как NoSQL базы данных?
Lua как встроенный язык сервера приложений.
- Посмотрим, как можно начать использовать Tarantool в своих проектах, и сделаем первые шаги.
Как установить Tarantool.
Первый запуск и основы конфигурирования.
Модель данных.
Как создавать и работать с хранилищем данных.
Как использовать пакеты tarantool.
- Узнаем об интересных модулях и фичах Tarantool
Чем полезен application server
Tarantool http
Tarantool queue
- Познакомимся с сообществом Tarantool opensource
Почему сообщество - это важно?
Чем полезны opensource проекты начинающему разработчику?
libfpta: в памяти, с персистентностью, быстрее хайпаLeonid Yuriev
Представление "Позитивных таблиц" – нового C/C++ движка, выполняющего до полумиллиона пишущих транзакций в секунду к табличным и key-value данным, и одновременно до миллиона читающих запросов на каждом ядре процессора.
libfpta обеспечивает полностью параллельно выполнение запросов чтения/поиска без блокировок внутри БД и без атомарных операций, а также реализует эффективное хранение multi-value значений. Поэтому интегрально libfpta опережает по производительности и Tarantool и RocksDB. А разница с такими "быстрыми" решениями как Hazelcast или Apache Ignite достигает иногда 10-ти и более раз.
PG Day'14 Russia, PostgreSQL в avito.ru, Михаил Тюринpgdayrussia
Доклад был представлен на официальной российской конференции PG Day'14 Russia, посвященной вопросам разработки и эксплуатации PostgreSQL.
С момента старта проекта на PostgreSQL были возложены серьёзные задачи. Это во многом предопределило успешное развитие всего продукта. Вокруг СУБД выстроены основные компоненты архитектуры, при этом сами базы берут на себя львиную долю обработки пользовательских запросов. Набор фич и расширений, легендарная надёжность PostgreSQL, наличие встроенной репликации, средств резервирования и архивирования — весь потенциал нашел своё воплощение, а наличие открытого профессионального комьюнити не оставляет шансов к неэффективной реализации.
В докладе будет дан обзор развития подсистем, сосредоточенных вокруг PostgreSQL, представлены параметры и режимы функционирования. Будут описаны успешные решения в рамках отдельного PostgreSQL-кластера и при распределенной обработке данных, приведены текущие вызовы, связанные с продолжающимся активным ростом проекта.
Бинарные (файловые) хранилища- страшная сказка с мрачным концом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. но все же довольно сложно
Где живут Ваши объявления / Тюрин Михаил (Avito)Ontico
Авито с 2010 года — с момента запуска на широкую аудиторию — прошел уже немалый путь, успев собрать более 600 миллионов объявлений со всех уголков страны, и став при этом крупнейшим классифайдом в Европе.
В докладе будет дан обзор архитектуры ядра системы с ретроспективой, перечислены основные компоненты обработки объявлений, приведены оценки параметров функционирования от "продуктовых" "количество объявлений за единицу времени" до количества запросов на разные уровни стека (веб, базы, поиск, очереди) и степени утилизации железа.
Будут также продемонстрированы примеры реализаций классических паттернов веба: кэш, прокси, денормализация и репликация, шардинг, очереди и удаленный вызов процедур — подходы, уже более 5 лет лежащие в основе нашей архитектуры. При этом будут приведены неочевидные, на взгляд автора, особенности внедрения данных подходов.
Доклад должен заинтересовать соотнесением масштабов и ключевых слов.
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
Отладка производительности приложения на Erlang / Максим Лапшин (Erlyvideo)Ontico
Байткод эрланга выполняет очень хорошо отлаженная виртуальная машина BEAM, которая превосходно работает даже на современных 72-х и более ядерных компьютерах.
Ключевая возможность эрланга в том, чтобы использовать все ядра в одном приложении, т.е. иметь в памяти одни и те же данные и обеспечивать к ним доступ без запуска кучи экземпляров одного и того же приложения по количеству ядер.
С ростом обрабатываемого трафика данных начинают возникать проблемы с многоядерным доступом к данным, возникают бутылочные горлышки и более низкоуровневые проблемы синхронизации.
В этом докладе будет рассказано, какие есть методы поиска, анализа, замера и устранения различных проблем, связанных с многотредностью: синглтонные процессы, простаивания на мьютексах и т.п.
Open source субд глазами обычного программистаSlach
Попытался "быстренько" пробежаться по всем СУБД с которыми работал за 20 лет и постараться вложить слушателям мысль что СУБД надо выбирать под нагрузку
и что для СУБД надо знать "алгоритмы" и "эксплуатацию"
Cоциальный граф "Одноклассников" в myTargetOleg Tsarev
Задача выглядит обманчиво простой — рядом с баннером игры из Одноклассников показывать текстовый тизер «эту игру играет Кот Матроскин и ещё 5 твоих друзей» (имя и количество берутся из друзей пользователя на Одноклассниках).
Как обрабатывать граф друзей проекта Одноклассники для этой задачи?
На этот простой вопрос дают разные ответы:
- взять графовую базу данных
- использовать матрицу инцидентности
- использовать список смежных вершин.
Если уточнить, что сырые данные занимают полтора терабайта, в графе 200 миллионов вершин и 13 миллиардов связей, то ручные решения сразу отметаются.
«Графовая база данных!» Стоит озвучить нагрузку в десятки тысяч запросов секунду и требования отвечать за миллисекунды (тысячные доли секунды!) как графовые базы сразу оказываются за бортом — типичное время ответа на простые запросы — единицы секунд.
Экс-разработчик MySQL и SciDB, ныне ведущий разработчик myTarget Олег Царёв расскажет, как решалась эта непростая задача в рамках проекта.
101 способ приготовления RabbitMQ и немного о pipeline архитектуре / Филонов ...Ontico
Архитектурный шаблон проектирования конвейер (pipeline) хорошо зарекомендовал себя при проектировании высоконагруженных (highload) систем. Использование шины сообщений (message bus) при реализации каналов взаимодействия позволяет достигать хороших показателей масштабируемости (scalability), но при этом появляются дополнительные накладные расходы, которые сказываются на показателях производительности (performance).
В докладе обсуждаются варианты использования системы обмена сообщениями RabbitMQ в качестве связующего программного обеспечения (middleware) для построения конвейерной архитектуры. Рассматриваются вопросы производительности и масштабирования как stateless так и statefull фильтров.
В качестве примера рассматривается реализация системы обработки сложных событий (complex event processing) применительно к управлению журналированием (log management).
MyRocks Табличный Движок для MySQL / Алексей Майков (Facebook) / Сергей Петру...Ontico
Facebook использует MySQL в качестве основного хранилища данных. MySQL работает на десятках тысяч серверов в нескольких ЦОДах. В качестве дисков используются Flash-накопители. Они дают большую производительность, но дорогой ценой — MySQL хранит данные на диске в структуре B-tree, которая использует flash-диск неоптимальным образом. В масштабах Facebook'a цена вопроса измеряется миллионами долларов.
Для оптимального использования Flash-дисков в Facebook была разработана библиотека RocksDB. Она основана на LSM-деревьях и оптимизирована для работы в условиях высокой загрузки. Чтобы использовать ее из MySQL, [совместно с MariaDB] был разработан табличный движок — MyRocks.
Данный доклад посвящен RocksDB и MyRocks. Мы расскажем о принципах их работы и преимуществах, как их настраивать, и какие возможны подводные камни.
Авторы доклада — ведущие разработчики MyRocks от Facebook и MariaDB.
RocksDB и MyRocks доступны на GitHub для свободного использования, участие в разработке также приветствуется.
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 :) ).
Andrew Aksyonoff "Архитектура вокруг поиска"Fwdays
Начиная с определенного масштаба, вокруг любого базового поискового движка плюс рядом с ним неизбежно вырастает изрядная куча всяких интересных прослоек и сервисов. Особенно, когда одним лишь поиском по ключевым словам (либо вообще булевым, либо с простеньким ранжированием по формуле) дело ограничиваться перестает. Расскажу, как сегодня выглядит архитектура сервисов “вокруг и около поиска” у нас в Авито (числа и слова для привлечения внимания: 40M+ активных объявлений, тысячи RPS, ML ранжирование, пляски с анализом и доставкой данных, и всё такое).
Осваиваем Tarantool 1.6 / Евгений Шадрин (Sberbank Digital Ventures)Ontico
Tarantool - отечественная Opensource NoSQL база данных.
В докладе мы обсудим:
- Какое место занимают NoSQL базы данных в highload проектах?
Почему и для чего вам стоит NoSQL решения?
Какие NoSQL решения вы можете использовать?
- Рассмотрим, что из себя представляет Tarantool 1.6 - база данных и сервер приложений в одном лице.
Какие основные особенности Tarantool как NoSQL базы данных?
Lua как встроенный язык сервера приложений.
- Посмотрим, как можно начать использовать Tarantool в своих проектах, и сделаем первые шаги.
Как установить Tarantool.
Первый запуск и основы конфигурирования.
Модель данных.
Как создавать и работать с хранилищем данных.
Как использовать пакеты tarantool.
- Узнаем об интересных модулях и фичах Tarantool
Чем полезен application server
Tarantool http
Tarantool queue
- Познакомимся с сообществом Tarantool opensource
Почему сообщество - это важно?
Чем полезны opensource проекты начинающему разработчику?
libfpta: в памяти, с персистентностью, быстрее хайпаLeonid Yuriev
Представление "Позитивных таблиц" – нового C/C++ движка, выполняющего до полумиллиона пишущих транзакций в секунду к табличным и key-value данным, и одновременно до миллиона читающих запросов на каждом ядре процессора.
libfpta обеспечивает полностью параллельно выполнение запросов чтения/поиска без блокировок внутри БД и без атомарных операций, а также реализует эффективное хранение multi-value значений. Поэтому интегрально libfpta опережает по производительности и Tarantool и RocksDB. А разница с такими "быстрыми" решениями как Hazelcast или Apache Ignite достигает иногда 10-ти и более раз.
PG Day'14 Russia, PostgreSQL в avito.ru, Михаил Тюринpgdayrussia
Доклад был представлен на официальной российской конференции PG Day'14 Russia, посвященной вопросам разработки и эксплуатации PostgreSQL.
С момента старта проекта на PostgreSQL были возложены серьёзные задачи. Это во многом предопределило успешное развитие всего продукта. Вокруг СУБД выстроены основные компоненты архитектуры, при этом сами базы берут на себя львиную долю обработки пользовательских запросов. Набор фич и расширений, легендарная надёжность PostgreSQL, наличие встроенной репликации, средств резервирования и архивирования — весь потенциал нашел своё воплощение, а наличие открытого профессионального комьюнити не оставляет шансов к неэффективной реализации.
В докладе будет дан обзор развития подсистем, сосредоточенных вокруг PostgreSQL, представлены параметры и режимы функционирования. Будут описаны успешные решения в рамках отдельного PostgreSQL-кластера и при распределенной обработке данных, приведены текущие вызовы, связанные с продолжающимся активным ростом проекта.
Основные тренды развития систем управления контентом, что такое контент, почему Drupal отлично подходит для крупных международных проектов
Подписывайтесь на нас!
VK: https://vk.com/drupalsib
FB: https://facebook.com/groups/drupalsib
Twitter:
https://twitter.com/SibDrupalCamp
https://twitter.com/DrupalSib
Instagram: https://instagram.com/drupalsib
Доклад Сардора Хасанова - менеджера проектов Центра программистов BePro на семинаре в Центре развития и внедрения компьютерных и информационных технологий UZINFOCOM 26 июня 2013 г.
Евгений Ильин. Drupal + Solr: Яндекс.Маркет своими рукамиDrupalSib
DrupalCafe#9@Novosibirsk https://vk.com/drupalcafe9
Drupal + Solr или как сделать Яндекс маркет своими руками
Требования к интернет каталогам товаров и инструменты Drupal для создания современных каталогов.
Как сделать каталог, который будет продавать
-----
Сайт сибирского сообщества друпаллеров ДрупалСиб drupalsib.ru
Группа сибирского сообщества друпаллеров Вконтакте vk.com/drupalsib
Партнер Группа компаний И20 i20.biz
Производительность параметрического поиска на основе опенсорс-платформыYandex
В докладе рассматриваются особенности системы параметрического поиска, построенной на базе опенсорс-плаформы Apache Solr. Речь пойдёт о проблемах производительности такой системы и некоторых методах их решения — в том числе о применении различных способов построения запросов для уменьшения времени ответа системы.
В данном выступлении будет рассказно об общих принципах организации систем полнотекстового поиска на примере движка Sphinx. Будут рассмотрены структура и организация поискового индекса, на примере разобраны различные механимзы индексирования. Речь пойдет также и о продвинутых методиках работы со Sphinx: индексы реального времени, атрибуты с несколькими значениями, дельта-индексирование. Все это будет не только описано но и продемонстрировано, а желающие смогут проделывать все операции у себя на ноутбуках параллельно с докладчиком (см. описание программных требований).
Вторая часть будет посвящена непосредственно поиску и взаимодействию с движком Sphinx из программного кода на языке C#. Будут использованы механизмы обращения к Sphinx как используя нативный протокол, так и через MySQL-адаптер. Будет показано применение библиотек Sphinx.Client, Scarab и ByndyuSoft.Infrastructure.Sphinx, две из которых созданы автором мастер-класса. Также будут рассмотрены типовые ситуации использования Sphinx и шаблоны организации поиска.
Движение по хрупкому дну / Сергей Караткевич (servers.ru)Ontico
Сегодня Интернет увлечен микросервисами, контейнерами и immutable-инфраструктурой. Очень сложно не поддаться искушению внедрить что-то подобное в компании, в которой вы работаете сейчас. Я попытаюсь отговорить вас использовать эти технологии во вред приложению, себе и бизнесу компании в целом. Я расскажу о типовом проекте, который был запущен в 20 странах за 4 месяца, проблемах, которые я встретил, и выводах, которые я сделал.
- Почему микросервисы не спасут, а похоронят ваш проект.
Я расскажу на основе собственного опыта, почему не стоит увлекаться микросервисами для небольших проектов, почему благие намерения — упрощение деплоя и увеличение числа деплоев, увеличение доступности и улучшение масштабирования ведут к отсутствию гибкости и критическому уменьшению стабильности системы.
- Почему ваша система слишком сложна для своих задач.
Я расскажу, почему не стоит усложнять систему, почему, скорее всего, ваша система слишком сложна для задач, которые она решает и почему вы не контролируете то, что происходит в системе. Я объясню, почему вы потратите все свое время на отладку сложной системы, вместо того чтобы решать задачи бизнеса.
- Почему Docker используется неправильно.
Будут предоставлены реальные примеры использования Docker для нового проекта и для портированного проекта, я объясню, с какими проблемами сталкиваются операторы при работе с Docker на живых примерах, объясню, почему вы, скорее всего, используете Docker неправильно, и предложу варианты, как этого избежать.
- Почему immutable слишком статичен для вашей компании.
Я расскажу про свой опыт работы с immutable и объясню, почему, на мой взгляд, переход к подобной инфраструкт
Если не считать объем информации проблемой, то трудности начинаются с необходимости хранить и обрабатывать записи, разнообразие которых постоянно увеличивается и стремится к показателям реального мира.
Рассмотрим проблемы _очень_ сложных схем/моделей данных и использование RDF Storage в качестве варианта решения.
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 - для некоторых сочет�
Машинное обучение в электронной коммерции - практика использования и подводны...Ontico
РИТ++ 2017, секция ML + IoT + ИБ
Зал Белу-Оризонти, 5 июня, 16:00
Тезисы:
http://ritfest.ru/2017/abstracts/2532.html
Простыми словами расскажем о популярных, эффективных и используемых в нашей компании техниках применения машинного обучения для привлечения и удержания клиентов:
- кластеризации товарного каталога,
- классификации клиентов (готовых перейти на платный тариф, готовых уйти, способных принести прибыль),
- повышении релевантности e-mail-рассылок.
Особое внимание уделим технике использования популярных платформ и библиотек:
- Apache Spark,
- Spark MLlib,
- Hadoop,
- Amazon Kinesns.
Отдельно остановимся на особенностях обработки "больших данных", выборе и разработке параллельных алгоритмов.
Tagless Final подход остаётся горячей темой в ФП-комьюнити. До сих пор практически не существовало инструментов, способных облегчить жизнь TF-адепту. Библиотека Tofu пытается решить эту проблему, предоставляя удобные абстракции для создания простого, честного и тестируемого ФП-кода.
Объем информации не является проблемой, построить большое хранилище уже несложно. Трудности начинаются с необходимости хранить и обрабатывать записи, разнообразие которых постоянно увеличивается и стремится к показателям реального мира (бесконечности). Рассмотрим проблему и пути её решения.
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2964.html
Одноклассники состоят из более чем восьми тысяч железных серверов, расположенных в нескольких дата-центрах. Каждая из этих машин была специализированной под конкретную задачу - как для обеспечения изоляции отказов, так и для обеспечения автоматизированного управления инфраструктурой.
...
Масштабируя DNS / Артем Гавриченков (Qrator Labs)Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/3032.html
Протокол DNS на семь лет старше, чем Всемирная паутина. Стандарты RFC 882 и 883, определяющие основную функциональность системы доменных имён, появились в конце 1983 года, а первая реализация последовала уже годом позже. Естественно, что у технологии столь старой и при этом по сей день активнейшим образом используемой просто не могли не накопиться особенности, неочевидные обыкновенным пользователям.
...
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/3010.html
В этом докладе я расскажу, как BigData-платформа помогает трансформировать Почту России, как мы управляем построением и развитием платформы. Расскажу про найденные удачные решения, например, как разбиение на продукты с понятными SLA и интерфейсами между ними помогло нам сохранять управляемость с ростом масштабов проекта.
...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2914.html
Казалось бы, что нужно для организации тестового окружения? Тестовая железка и копия боевого окружения - и тестовый сервер готов. Но как быть, когда проект сложный? А когда большой? А если нужно тестировать одновременно много версий? А если все это вместе?
Организация тестирования большого развивающегося проекта, где одновременно в разработке и тестировании около полусотни фич - достаточно непростая задача. Ситуация обычно осложняется тем, что иногда есть желание потрогать еще не полностью готовый функционал. В таких ситуациях часто возникает вопрос: "А куда это можно накатить и где покликать?"
...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2854.html
Из этого доклада вы узнаете о возможностях репликации и автофейловера PostgreSQL, в том числе о возможностях, ставших доступных в PostgreSQL 10.
Среди прочих, будет затронуты следующие темы:
* Виды репликации и решаемые с ее помощью проблемы.
* Настройка потоковой репликации.
* Настройка логической репликации.
* Настройка автофейловера / HA средствами Stolon и Consul.
После прослушивания доклада вы сможете самостоятельно настраивать репликацию и автофейловер PostgreSQL.
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/3096.html
PostgreSQL is the world’s most advanced open source database. Indeed! With around 270 configuration parameters in postgresql.conf, plus all the knobs in pg_hba.conf, it is definitely ADVANCED!
How many parameters do you tune? 1? 8? 32? Anyone ever tuned more than 64?
No tuning means below par performance. But how to start? Which parameters to tune? What are the appropriate values? Is there a tool --not just an editor like vim or emacs-- to help users manage the 700-line postgresql.conf file?
Join this talk to understand the performance advantages of appropriately tuning your postgresql.conf file, showcase a new free tool to make PostgreSQL configuration possible for HUMANS, and learn the best practices for tuning several relevant postgresql.conf parameters.
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/3115.html
During this session we will cover the last development in ProxySQL to support regular expressions (RE2 and PCRE) and how we can use this strong technique in correlation with ProxySQL's query rules to anonymize live data quickly and transparently. We will explain the mechanism and how to generate these rules quickly. We show live demo with all challenges we got from the Community and we finish the session by an interactive brainstorm testing queries from the audience.
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2957.html
Расскажем о нашем опыте разработки модуля межсетевого экрана для MySQL с использованием генератора парсеров ANTLR и языка Kotlin.
Подробно рассмотрим следующие вопросы:
— когда и почему целесообразно использовать ANTLR;
— особенности разработки ANTLR-грамматики для MySQL;
— сравнение производительности рантаймов для ANTLR в рамках задачи синтаксического анализа MySQL (C#, Java, Kotlin, Go, Python, PyPy, C++);
— вспомогательные DSL;
— микросервисная архитектура модуля экранирования SQL;
— полученные результаты.
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3114.html
ProxySQL aims to be the most powerful proxy in the MySQL ecosystem. It is protocol-aware and able to provide high availability (HA) and high performance with no changes in the application, using several built-in features and integration with clustering software. During this session we will quickly introduce its main features, so to better understand how it works. We will then describe multiple use case scenarios in which ProxySQL empowers large MySQL installations to provide HA with zero downtime, read/write split, query rewrite, sharding, query caching, and multiplexing using SSL across data centers.
MySQL Replication — Advanced Features / Петр Зайцев (Percona)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2954.html
MySQL Replication is powerful and has added a lot of advanced features through the years. In this presentation we will look into replication technology in MySQL 5.7 and variants focusing on advanced features, what do they mean, when to use them and when not, Including.
When should you use STATEMENT, ROW or MIXED binary log format?
What is GTID in MySQL and MariaDB and why do you want to use them?
What is semi-sync replication and how is it different from lossless semi-sync?
...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3120.html
Количество разработчиков мобильных приложений Сбербанк Онлайн с начала 2016 года выросло на порядок. Для того чтобы продолжать выпускать качественный продукт, мы кардинально перестраиваем процесс разработки.
Количество внутренних заказчиков тех или иных доработок в какой-то момент выросло настолько, что разработчики стали узким местом. Мы внедрили культуру разработки, которую можно условно назвать "внутренним open-source", сохранив за собой контроль над архитектурой и качеством проекта, но позволив разрабатывать новые фичи всем желающим.
...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2836.html
При использовании Eventually Consistent распределенных баз данных нет гарантий, что чтение возвращает результаты последних изменений данных, если чтение и запись производятся на разных узлах. Это ограничивает пропускную способность системы. Поддержка свойства Causal Consistency снимает это ограничение, что позволяет улучшить масштабируемость, не требуя изменений в коде приложения.
...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/2858.html
Аудитория Одноклассников превышает 73 миллиона человек в России, СНГ и странах дальнего зарубежья. При этом ОК.ru - первая социальная сеть по просмотрам видео в рунете и крупнейшая сервисная платформа.
Качественный и количественный рост DDoS-атак за последние годы превращает их в одну из первоочередных проблем для крупнейших интернет-ресурсов. В зависимости от вектора атаки “узким” местом становится та или иная часть инфраструктуры. В частности, при SYN-flood первый удар приходится на систему балансировки трафика. От ее производительности зависит успех в противостоянии атаке.
...
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/3008.html
Никогда не было и вот снова случилось! Компания Google в результате перенаправления трафика сделала недостпуными в Японии несколько тысяч различных сервисов, большинство из которых никак не связано с самой компанией Google. Однако, подобные инциденты происходят с завидной регулярностью, вот только не всегда попадают в большие СМИ. У таких инцидентов могут быть разные причины, начиная от ошибок сетевых инженеров и заканчивая государственным регулированием.
...
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2925.html
Облака и виртуализация – современные тренды развития IT-технологий. Операторы связи строят свои TelcoClouds на стандартах NFV (Network Functions Virtualization) и SDN (Software-Defined Networking). В докладе начнем с основ виртуализации, далее разберемся, для чего используются NFV и SDN, потом полетим к облакам и вернемся на землю для решения практических задач!
...
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/3045.html
Как мы заставили Druid работать в Одноклассниках.
«Druid is a high-performance, column-oriented, distributed data store» http://druid.io.
Мы расскажем о том, как, внедрив Druid, мы справились с ситуацией, когда MSSQL-based система статистики на 50 терабайт стала:
- медленной: средняя скорость ответа была в разы меньше требуемой (и увеличилась в 20 раз);
- нестабильной: в час пик статистика отставала до получаса (теперь ничего не отстает);
- дорогой: изменилась политика лицензирования Microsoft, расходы на лицензии могли составить миллионы долларов.
...
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2905.html
Прошло более года с того момента, как Microsoft выпустила первую версию своего нового фреймворка для разработки web-приложений ASP.NET Core, и с каждым днем он находит все больше поклонников. ASP.NET Core базируется на платформе .NET Core, кроссплатформенной версии платформы .NET c открытым исходным кодом. Теперь у С#-разработчиков появилась возможность использовать Mac в качестве среды разработки, и запускать приложения на Linux или внутри Docker-контейнеров.
...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2913.html
Изначально будут раскрыты базовые причины, которые заставили появиться такой части механизма СУБД, как кэш результатов, и почему в ряде СУБД он есть или отсутствует.
Будут рассмотрены различные варианты кэширования результатов как sql-запросов, так и результатов хранимой в БД бизнес-логики. Произведено сравнение способов кэширования (программируемые вручную кэши, стандартный функционал) и даны рекомендации, когда и в каких случаях данные способы оптимальны, а порой опасны.
...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2947.html
Apache Ignite — Open Source платформа для высокопроизводительной распределенной работы с большими данными с применением SQL или Java/.NET/C++ API. Ignite используют в самых разных отраслях. Сбербанк, ING, RingCentral, Microsoft, e-Therapeutics — все эти компании применяют решения на основе Ignite. Размеры кластеров разнятся от всего одного узла до нескольких сотен, узлы могут быть расположены в одном ЦОД-е или в нескольких геораспределенных.
...
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3005.html
Когда мы говорим о нагруженных системах и базах данных с большим числом параллельных коннектов, особый интерес представляет практика эксплуатации и сопровождения таких проектов. В том числе инструменты и механизмы СУБД, которые могут быть использованы DBA и DevOps-инженерами для решения задач мониторинга жизнедеятельности базы данных и ранней диагностики возможных проблем.
...
2. Про что доклад
• Надо поиск, какой взять?
– Дык в MySQL/Postgres/Mongo чота типа есть и агонь
– Взять Sphinx, C++ не подведёт
– Взять Lucene/Solr/Elastic, Java не подведёт
– Самим всё написать, мы ж мужики
– Купить крутейший коммерческий, например
3. Про что доклад
• Надо поиск, какой взять?
• Чем и как MySQL vs Postgres vs Mongo vs Sphinx vs
Lucene vs … оно всё внутри вообще отличается?
• Как правильно бенчмаркать?
• Что ещё нужно сравнивать?
4. Про что доклад
• Надо поиск, какой взять?
– Разумеется, Sphinx!
– Разумеется, с контрактом на поддержку!
– Разумеется, чем больше нулей, тем лучше!
– Всё, доклад окончен, расходимся
6. Самописный поиск за 1 час
• create table X (
keyword varchar(255) not null,
docid integer primary key not null );
• insert into X values (“hello”, 123), (“world”, 123);
• select * from X a, X b where
a.keyword=“hello” and
b.keyword=“world” and
a.docid=b.docid
7. Самописный поиск за 1 вечер
• Можно даже успеть вкрутить еще всякое!
– Стеммер, libstemmer и его порты
– Морфология, pyrmophy2, phpmorphy (aot нельзя)
– Ранжирование, BM25
• alter table X add column termfreq integer
• create table D (keyword varchar(255), docfreq integer)
• select …
8. Встроенный в базу поиск
• Согласно вендору базы, Дичайше Круче Всех
• На самом деле, Неизбежно Выйдет Говнецо (*)
– Все базы в первую очередь про OLAP, ох
– Великие Древние ещё также умеют транзакции, ууух
– Типично муторно масштабировать
– Синтаксис, ранжирование, эффективность? Не, не слышали
(*) Разумеется, именно Ваш Любимый Вендор не такой!
9. Самописный поиск за 10 лет
• Можно успеть вкрутить ещё всякое!!!
– Внятный формат индекса
– Поддержка атрибутивки
– Синтаксис запросов
– Ранжирование
– Кластеризация
• Каждый пункт = N переделок, M лет
10. Внешний поиск
• FOSS (free, open source)
– Sphinx
– Lucene + сервера поверх (Solr, Elastic)
• Коммерческие
– FAST, Endeca, Autonomy, Verity… куча вендоров
– Отдельный мир, обязательно Sharepoint и 4-5 нулей
– Интеграция, поддержка, функционал часто хтонические
11. Так своё писать или как!?
• Как ни странно, иногда надо
– Core product (Google, Yandex, Bing…)
– Спецтребования (“хочу взлетать в 16 KB памяти…”)
• Ключевое, осознавать масштаб бедствия
– У нас вот получается довольно компактно
– Sphinx 0.1 = ~1K LOC, Sphinx 2.x = ~120K LOC
– Больше фичей и-или “сопливый” код = ~1..10M+ LOC
12. Так своё писать или как!?
• 99%, что вам – не надо
– Мало усилий => так себе и получится
– Много усилий => это зачем?
• Берите базу, берите Sphinx, берите Lucene & spawn
• Бегите от “заказчиков”, у которых нету $10 на VPS!!!
14. А чем НеСвои отличаются-то?
• Ууу…
• Отличаются метод доставки данных; форматы
индекса; скорость индексации; размеры индекса;
требования к RAM; механизмы масштабирования;
API доступа; функционал текстового поиска; скорость
текстового поиска, причем от вида запроса; скорость
НЕтекстового поиска; добавочные функции (геопоиск,
фасеты, подсказки, сниппеты); ранжирование;
расширяемость…
19. Что сравнивать?
• Сравнивать надо фактически важное
– Не умеют не только лишь все
– Мало кто может это делать
• У каждого свои требования, они ортогональны
– Качество поиска VS супербыстрый булев поиск?
– Текстовый поиск VS атрибутивка?
– Масштабирование на терабайты VS индекс на 1 GB?
20. Про отличия чуть подробнее
• Совсем подробно нельзя – уйдет 3 дня
• Поэтому – очень кратко, по верхам
• 3 категории = (1) базы, (2) FOSS, (3) commercial
• 4 мегаоси = (1) эффективность, (2) функционал,
(3) масштабируемость, (4) интеграция
22. Правильно читаем таблицу
• Типичная база = хреновенькие скорость, функционал,
масштабируемость… зато отличная интеграция!
• Типичный FOSS = хорошо или отлично С/Ф/М;
интеграция окей (но очевидно хуже встроенного)
• Commercial = возможны адовые попадосы по любому
параметру за свои же деньги, в целом не впечатляет
• DIY = в общем будет очень плохо; но в частностях,
возможно, невероятно хорошо
24. Sphinx vs Lucene
• Поговорим немного про “а что внутри”
• Какие сходства, откуда растут отличия
• Sphinx = сервер, C++ (библиотека “как бы” есть)
• Lucene = библиотека, Java
• Solr = сервер, Java
• Elastic = сервер, Java
25. Sphinx 2.x vs 3.x
• Долго делаем, всякому научились
• Теперь переделываем внутри много всего
• Некоторые переделки Поменяют Всё, поэтому!
26. Sphinx vs Lucene
• Что одинаковое?
– Идеология “инвертированный файл”
– Всё начинается от текстового поиска
– Отдельно довески про атрибутивку
• Что это значит?
– “Тупо поиск” работает принципально одинаково
– Детали реализации, однако, могут менять всё
27. Sphinx vs Lucene
• Что разное внутри?
– Формат хранения ключевиков, постингов
– Формат хранения атрибутов
– “Привычки” внутреннего кеширования
– “Фокус” матчилки
• Что это значит?
28. Про формат постингов
• Sphinx 2.x = общие словари, списки по всем полям
• Lucene = отдельные по каждому полю
– Матчинг в “редком” поле = Lucene “О-быстрее”
– Матчинг по куче полей = Lucene “О-медленнее”
– Матчинг со взвешиванием = Lucene “О-медленнее”
– Нумерация полей = Sphinx 2.x ограничен 256 полями,
индекс “О-больше” по размеру
– Куча полей, куча уникальных “слов” = плохо везде (словарь)
29. Про формат атрибутов
• Sphinx 2.x = in-memory, row-based attr-only table
• Lucene = on-disk, row-based docstore + кеш кеш кеш
– Доступ в Sphinx = in-memory hash lookup
– Доступ в Lucene = как бы disk read, поэтому кеш кеш кеш
– Sphinx = можно смешать schemaful/schemaless
– Lucene = полный schemaless, поэтому кеш кеш кеш
– Зато у нас в 2.x дурацкие исторические ограничения
30. Про формат документов
• Lucene = хранилка документов есть
• Sphinx 2.x = хранилки документов нет
• Sphinx 3.x = хранилка документов тоже есть
– Тоже перерастаем в странную СУБД
– Тоже disk based, тоже LZ4
– Принципиально улучшить не удалось
31. Про кеширование
• Sphinx = запрос надо уметь считать адово быстро
• Lucene = скорость вторична, всё закешируем!
– Sphinx = внутренних кешей почитай нет
– Lucene = кешируется ВСЁ, местами хрен отключишь
– Делать адекватные бенчмарки это местами АД
• Xapian (внезапно) = оптимизация под дефолтный,
непрактичный юзкейс
32. Про “фокус” матчилки
• Sphinx 2.x = позиции! ранжирование! релевантность!
фиксированный бюджет памяти!
• Lucene = не-не-не, булев матчинг и может BM25;
памяти побольше тупо ставь
– Sphinx 2.x = неидеально c булевым поиском
– Sphinx 3.x = думаем про отдельный lightweight code path…
и убрать бюджетирование, муахахаха
– Lucene = неидеально с ранжированием/позициями
33. Итого
• Концептуально одинаково (инвертированный файл)
• Довольно разные реализации
• “Детали реализации” меняют всё, в разы
35. Что на этаж выше?
• Sphinx vs Solr/Elastic, что одинаковое?
– Везде некий API (SphinxQL, REST/XML, REST/JSON)
– Везде завелись RT индексы
– Везде развелся schemaless/JSON (в разной мере)
– Везде как минимум агрегация результатов с кластера
– Везде поддержка атрибутивки, ряда допфункций
– Везде, что странно, “просто поиск” как-то работает!!!
– Коммодитизация…
36. Что на этаж выше?
• Sphinx vs Solr/Elastic, что разное?
– S/E, репликация, автошардинг, REST, “реверсные” поиски,
менеджмент кластера (почти всё тоже делаем для 3.0)
– Sphinx, встроенная морфология, “сложное” ранжирование,
считалка выражений
• Всегда разный “эзотерический” (?) функционал
– Sphinx, плохо помню! Zones, blend_chars, итп?
– S/E, плохо знаю! Per-field mappings, nested docs итп?
43. Как “правильно” бенчмаркать
• На оценку 3 = берем разные системы, делаем к ним
одинаковый запрос, сравниваем время
• На оценку 4 = повторяем запрос N раз, считаем
среднее время, чтобы кеш прогрело и не дрожало
• На оценку 5 = выкидываем 1й прогон всегда и даже
выкидываем outliers, считаем среднее без них
44.
45. Тёплое != мягкое
• Где ошибка?
• “берем разные системы, делаем к ним одинаковый
запрос”…
• Одинаковый запрос
• ОДИНАКОВЫЙ ЗАПРОС
46. Marketing-driven defaults 1
• “Одинаковый запрос” по умолчанию очень разный
• Sphinx, поиск по умолчанию = strict-AND, “среднее”
proximity+bm15 ранжирование, анализ позиций
• Lucene, поиск по умолчанию = OR (вроде), “легкое”
bm25 ранжирование, почти булев поиск
• Xapian (внезапно!) = top-N по ихнему bm25!!!
• …и это еще цветочки!!!
47. Marketing-driven defaults 2
• Повторные запросы?
• Sphinx = честно вычисляем всё заново, кешируется
только дисковое чтение, да и то на уровне OS
• Lucene = на всех уровнях есть внутренние кеши,
некоторые невозможно отключить никак
– Нужна долбежка многими разными запросами
– Повтор 1 запроса подряд = обмеряем отдачу из кеша
– Повтор пакета из 10-20 запросов = в общем-то тоже
48. Marketing-driven defaults 3
• Сниппеты, прям шедевр!
• “А чё у вас в N раз медленнее, чем Solr?”
– Поддержка синтаксиса VS bag-of-words
– Произвольный текст VS только преиндексированный
– И ключевая “оптимизация” Solr...
– Зачем подсвечивать всё, если можно первые 64 KB?!
49. Мы на горе всем буржуям
• Поломаем совместимость!!!
• Но исправим дефолты
52. Идеальная Ситуация
• Определяем реальные ключевые требования
• Слегка изучаем все сравниваемые системы (увы!)
• Делаем действительно сходные запросы
• Моделируем боевую нагрузку, помним про кеши
• Смотрим функционал (что реально критично?)
• Прикидываем TCO
53. Помним Общие Моменты
• База = забудь про функционал и скорость, но удобно
• Sphinx, Lucene et al = ср. быстро и функционально; по
разным виды запросов могут сильно отличаться
– Несколько разный функционал и, похоже, “фокус”
– Сравнивать и мерить нужное, иначе (уже+пока) никак
• Коммерческие = неожиданные подвохи, TCO
• Дефолтные настройки могут удивить
54. Делаем Правильный Выбор
• Выбираем систему X, т.к.
– Друг Вася пользуется!
– Знакомый Петя хвалил!
– На Хабре чота писали вроде крутое!
– В компанию пришел интерн с опытом! (делал homepage)
• Выбираем систему Y, т.к.
– Она дорогая от известного мега-производителя
– И деньги очень нужны имеет убедительные плюсы