Как, используя Lucene, построить высоконагруженную систему поиска разнородных...odnoklassniki.ru
Lucene - это популярный движок для построения полнотекстовых поисков. Им пользуются Twitter, LinkedIn, Apple и ряд других немаленьких компаний. В 2009 году Одноклассники запустили первый поиск на Lucene, и за два года к поиску пользователей добавились еще 5 других поисковых сервисов. В докладе будет рассказано о том, как устроены эти поисковые сервисы.
Так же в докладе расскажем о системе, которая одновременно ищет во всех индексах, а так же использует информацию о пользователе чтобы улучшить релевантность выдачи. Система обрабатывает более 60 млн запросов в день, и на каждый ответ тратит в среднем 90мс.
Видео на ютубе в 3 частях:
1 - http://youtu.be/htt2FIQolOs , 2 - http://youtu.be/qhj4Voy0nYU , 3 - http://youtu.be/FFk_6CprDNc
Как, используя Lucene, построить высоконагруженную систему поиска разнородных...odnoklassniki.ru
Lucene - это популярный движок для построения полнотекстовых поисков. Им пользуются Twitter, LinkedIn, Apple и ряд других немаленьких компаний. В 2009 году Одноклассники запустили первый поиск на Lucene, и за два года к поиску пользователей добавились еще 5 других поисковых сервисов. В докладе будет рассказано о том, как устроены эти поисковые сервисы.
Так же в докладе расскажем о системе, которая одновременно ищет во всех индексах, а так же использует информацию о пользователе чтобы улучшить релевантность выдачи. Система обрабатывает более 60 млн запросов в день, и на каждый ответ тратит в среднем 90мс.
Видео на ютубе в 3 частях:
1 - http://youtu.be/htt2FIQolOs , 2 - http://youtu.be/qhj4Voy0nYU , 3 - http://youtu.be/FFk_6CprDNc
There is a problem of finding the best instance of a service in distributed systems with dynamic configuration. Nowadays, there are many products for the configuration storage and service discovery. It should be mentioned at least Netflix Eureka, Consul, etc or good old Zookeeper. These products can keep and give configuration, manage service instances lifecycle and some of them even can be as dynamic DNS service. But main question is not about what instance may be called at the certain time. It is about what instance is better for call? This means that smart load balancing top on service discovery is required. Spring Cloud project allows to integrate these products to your project and provides powerful solutions for typical problems, that make cloud native services developing easier. This talk will review the internal structure of SpringCloud implementation of Client-Side Service Discovery and Client Load Balancing patterns. It also will include specific details of concrete implementations with examples from official libraries and the author’s own library.
Docker Containers orchestrators: Kubernetes vs. SwarmDmitry Lazarenko
Обзор рынка оркестраторов Docker. Детальное технологическое сравнение Docker Swarm и Kubernetes. Обзор архитектуры и возможностей каждогого из них. Кто лучше справляется с построением масштабируемых микросервисных архитектур
smart balancing with nginx+lua / Андрей Кононов (IPONWEB)Ontico
В этом докладе я планирую осветить следующие проблемы:
- Почему стандартных механизмов балансировки бывает недостаточно.
- Как выбирать фундамент для решения, и какие принципы проектирования использовались.
- Как формировались требования для решения, которое работает сейчас в продакшне и пропускает через себя ощутимое количество.
Расскажу, как без помощи сторонних сессионных хранилищ и довольно за дёшево организовать "sticky balancing", и как это работает с точки зрения науки. Покажу пример отказоустойчивой геораспределённой системы, расскажу, что мониторить и как правильно это делать при помощи специального расширения для nginx и не только. Расскажу о том, как было организовано нагрузочное и функциональное тестирование конечного продукта. Также расскажу про полный жизненный цикл этого весьма критичного для инфраструктуры приложения.
Поскольку мы живём в публичных облаках, я по ходу доклада расскажу, как мы тестировали и сравнивали AWS и GCP, а также про некоторые сугубо практические особенности организации in-house балансировки внутри публичного облака.
The last couple of years the technology of containerization via Docker has gained incredible popularity. Many teams already successfully use infrastructure services, staging, testbed in containers, but many people are afraid of using containers to deploy applications in production. The community still lacks success-stories, especially for applications without microservice architecture. The huge number of approaches and recipes does not as well add confidence in what you are doing.
This report is about our fears, successes and solutions for the dockerization of the classical monolith in production..
ORM технологии в .NET (Nhibernate, Linq To SQL, Entity Framework)Pavel Tsukanov
Расскажу зачем они вообще нужны. Пройдемся по технологиям и промоем им косточки. Рассмотрим достоинства и недостатки, а также где и когда лучше всего применять ту или иную ORM.
Распространенные ошибки применения баз данныхSergey Xek
Распространенные ошибки применения баз данных. Сергей Аверин, Badoo.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются раз- работчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, ко- торые потом в реальной жизни никогда не понадобится.
• Или проектируется архитектура, которая якобы дает отказоустойчи- вость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологиче- ская» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки собы- тий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и неболь- ших команд, техническим руководителям.
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 года, а первая реализация последовала уже годом позже. Естественно, что у технологии столь старой и при этом по сей день активнейшим образом используемой просто не могли не накопиться особенности, неочевидные обыкновенным пользователям.
...
More Related Content
Similar to Поисковая система Одноклассники.ру (Андрей Шевчук)
There is a problem of finding the best instance of a service in distributed systems with dynamic configuration. Nowadays, there are many products for the configuration storage and service discovery. It should be mentioned at least Netflix Eureka, Consul, etc or good old Zookeeper. These products can keep and give configuration, manage service instances lifecycle and some of them even can be as dynamic DNS service. But main question is not about what instance may be called at the certain time. It is about what instance is better for call? This means that smart load balancing top on service discovery is required. Spring Cloud project allows to integrate these products to your project and provides powerful solutions for typical problems, that make cloud native services developing easier. This talk will review the internal structure of SpringCloud implementation of Client-Side Service Discovery and Client Load Balancing patterns. It also will include specific details of concrete implementations with examples from official libraries and the author’s own library.
Docker Containers orchestrators: Kubernetes vs. SwarmDmitry Lazarenko
Обзор рынка оркестраторов Docker. Детальное технологическое сравнение Docker Swarm и Kubernetes. Обзор архитектуры и возможностей каждогого из них. Кто лучше справляется с построением масштабируемых микросервисных архитектур
smart balancing with nginx+lua / Андрей Кононов (IPONWEB)Ontico
В этом докладе я планирую осветить следующие проблемы:
- Почему стандартных механизмов балансировки бывает недостаточно.
- Как выбирать фундамент для решения, и какие принципы проектирования использовались.
- Как формировались требования для решения, которое работает сейчас в продакшне и пропускает через себя ощутимое количество.
Расскажу, как без помощи сторонних сессионных хранилищ и довольно за дёшево организовать "sticky balancing", и как это работает с точки зрения науки. Покажу пример отказоустойчивой геораспределённой системы, расскажу, что мониторить и как правильно это делать при помощи специального расширения для nginx и не только. Расскажу о том, как было организовано нагрузочное и функциональное тестирование конечного продукта. Также расскажу про полный жизненный цикл этого весьма критичного для инфраструктуры приложения.
Поскольку мы живём в публичных облаках, я по ходу доклада расскажу, как мы тестировали и сравнивали AWS и GCP, а также про некоторые сугубо практические особенности организации in-house балансировки внутри публичного облака.
The last couple of years the technology of containerization via Docker has gained incredible popularity. Many teams already successfully use infrastructure services, staging, testbed in containers, but many people are afraid of using containers to deploy applications in production. The community still lacks success-stories, especially for applications without microservice architecture. The huge number of approaches and recipes does not as well add confidence in what you are doing.
This report is about our fears, successes and solutions for the dockerization of the classical monolith in production..
ORM технологии в .NET (Nhibernate, Linq To SQL, Entity Framework)Pavel Tsukanov
Расскажу зачем они вообще нужны. Пройдемся по технологиям и промоем им косточки. Рассмотрим достоинства и недостатки, а также где и когда лучше всего применять ту или иную ORM.
Распространенные ошибки применения баз данныхSergey Xek
Распространенные ошибки применения баз данных. Сергей Аверин, Badoo.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются раз- работчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, ко- торые потом в реальной жизни никогда не понадобится.
• Или проектируется архитектура, которая якобы дает отказоустойчи- вость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологиче- ская» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки собы- тий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и неболь- ших команд, техническим руководителям.
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. Одноклассники в цифрах
• Что у нас есть:
– 185 млн аккаунтов;
– 7 млн групп;
– .....
• 5.5 млн пользователей онлайн;
• В секунду:
– 250 000 страниц, 260 000 фото, 150 Гбит;
– 8 000 сообщений и комментариев;
– 3 000 поисковых запросов.
1
3. Задачи поисковой системы
Видео
Музыка
Группы
Пользователи Подарки
групп
Пользователи
Помощь Сообщества
Интересы Мероприятия
Города
2
4. Выбор нового решения
• У нас уже работал поиск пользователей на MS SQL,
что упростило определение технических
требований.
• Нужен был OpenSource-проект, написанный на
Java.
• Тестировали Solr, но он нас совсем не устроил.
• Используя Solr, провели необходимые
эксперименты с Lucene.
• Прототип на Lucene превзошел ожидания.
3
5. Как устроен Lucene?
The bright Term DocId DocId Values
blue blue 1,2 1 333, Author A
Index Reader & Searcher & Query parser
butterfly bright 1,2 2 777, Author C
hangs on
Tokenizers & Filters & IndexWriter
butterfly 1
the breeze
breeze 1
hangs 1
Under blue
sky, in bright need 2
sunlight, search 2
one need sky 2
not search
around
Term DocId DocId Values
It’s best to best 1 1 555, Author C
forget the forget 1
great sky
great 1
and to retire
from every retire 1
wind sky 1
wind 1
4
6. Что мы реализовали в Lucene за 3 года:
• собственную репликацию;
• хранение индексов в памяти;
• выполнение поиска на индексах;
• загрузку хранимых полей;
• новые виды запросов.
5
7. От MS SQL к Lucene
• На Indexer хранится база с данными для индекса.
• Indexer готовит индекс и рассылает изменения.
• Query-сервера исполняют запросы на индексе.
Search Presentation
Event
Cache Search processing Get Entity cache Services
Update
Query
Query service Replication Indexer service + DB
6
8. Эксплуатация первой версии
• Если вам что-то не нравится при нагрузочном
тестировании, лучше найдите причину
• Если что-то нужно, сделайте это регулярным
Search Presentation
Event
Cache Search processing Get Entity cache Services
Update
Query
Query service Replication Indexer service + DB
7
9. Мгновенный поиск и социальный граф
• Одновременный поиск по трём
большим индексам.
• Временные персональные
индексы, разделенные на: друзья,
друзья друзей, мои группы,
группы друзей и т.д.
• Первые выдачи из тулбара
полностью идут из персонального
индекса.
• Во многих разделах сайта есть
подсказки по друзьям,
работающие на персональном
индексе.
8
10. Семеро одного не ждут
• В персональный индекс
дольше всего собираются Get session for Schema
группы и сообщества.
• Быстрее всего собираются Schedule queries
друзья и друзья друзей. Execute queries
• Дольше всего идет поиск waitAll ()
waitFor (queries complete)
по пользователям. waitAtLeast (result items)
• Быстрее всего – по Reduce results
сообществам. Load results
11. Эффективность кэширования
• Кэшируются только 5% запросов.
• Попадание в кэш доходит до 60%.
• На топ 1000 запросов приходится < 2%.
Presentation
Search
Event
Cache Search processing
Get Get Entity cache
Services Services
Update
Query
Query service Replication Indexer service + DB
10
12. Кэширование и нагрузка
Cache Cache
*2 *2 *2
Service Service Service
Service 0-19 Service 20-39 Service 40-59 Service 60-79 Service 80-99
37
11
13. Разделять или совмещать?
• Пока систем и опыта мало, лучше разделять:
+ системы не влияют друг на друга;
+ проще тестировать и выкладывать.
• Когда однотипных систем становится много,
лучше начать их объединение:
+ проще следить за работой;
+ везде одна версия и настройки;
- каждый раз нужно тестировать все;
- сложнее решать возникающие проблемы.
12
14. Поиск пользователей группы
• Пользователи и состав групп находятся в разных сервисах.
• Размеры групп варируются от нескольких человек до
миллионов.
• Для заиндексированых групп применяются обновления.
• Маленькие группы «забываются» через час.
Сервисы
Пользователи портала
Основная
память
Поисковая Внешняя
Группы система Маленькие память
группы
13
15. Поиск пользователей онлайн
• В первой версии искали в индексе пользователей
+ легко запустить;
+ надежно работает;
– медленно работает;
– сложная логика.
• Сейчас ищем по отдельному индексу, в котором
только пользователи онлайн
+ быстро работает;
+ простая логика;
– более 200.000 изменений в минуту;
– система зависит от индексирующего сервера.
14
За 3 с половиной года мы прошли путь от поиска пользователей в MSSQL до поиска по дюжене индексов, и использования соц графа при выдаче результатов. Так же поиск неявно используется в работе некоторых разделов портала.Это основные виды данных которые мы индексируем. Кроме непосредственно поиска, ПС обеспечивает множество фич сайта, в том числе: всевозможные подсказки друзей, поиск среди сейчас на сайте, витрина мероприятий, расчет топов в музыке.
Поиск поMSSQL занимал более 10 секунд. НедавноSQLперестал искать по именам даже в админкеСмотерли только OpenSource Java чтобы была возможность вмешиваться в работу технологииСперва тестировали Solr,но остались недовольны всем, чем можно: ботелнэки, репликация на bash-скриптах, качество кода... Поняв, что Solrнегоден для продакшена, сосредоточились именно на поведении Luceneи остались довольны результатами. Тестов было много: нас интересовало изменение производительности с размером индекса, как меняется производительность с изменением числа апдейтов в индекс, как меняется время запросов. В тестах на 37млн аккаунтов и 1.5 GB с одного сервера на ?8ядер? смогли снять 370 запросов в секунду. На нашем прототипе Luceneпоказала производительность уже в 800 з/c.
Инвертированый индекс - это индексная структура, которая хранит не отдельные поля документов, а данные из этих полей: слова, цифры и т.д. Через такую структуру можно быстро находить документы, содержащие необходимые слова, все или часть из них.
Luceneактивно читает файлы во время поиска.Пробовали: HDD,RamDrive,LuceneRamDirectory, OffHeapDirectory. Выбрали HeapDirectоry,файлы как byte[] в хипеМедленная работа с хранимыми полямиПричина: при считывании хранимого поля создается много мусора и производятся ненужные операцииРешение: считывать значение в нужный тип сразу из byte[]Результат: на порядок быстрее стали операции с хранимыми полями; время GC упало в 2 раза
Первым запускали поиск пользователей. Данные которые мы хотели в него положить, нужно было собирать из разных баз – притом без возможности быстро собрать инфу на пользователя. Поэтому появилась промежуточная база рядом с Indexer. В случае с новыми пользователями, основная информация индексировалась сразу, и ставилась задача в очередь на доиндексацию. У Search DB есть Slave для резервирования.По результатам тестов решили сразу запускать 2 партиции.Почему выбрали Master + Slave такую схему, а не Preprocessor + (indexer + index) сервера? Так проще поддерживать ноды консистентными. Так же исключается проблема с разной производительностью нод, из-за разной структуры индексов. Кроме того Index ноды не занимаются постороенней работой. На первый взгляд у нашей схемы появляется ботелнек, но на самом деле в схеме с Preprocessor тоже есть сервер поломка которого ломает индексацию. Опять же, при Master+Slaveпроще сделать восстоновление после проблем и реиндексацию – она 99% времени аффектит только индексер. Хотя за Mster+slaveприходится платить чуть большим трафиком, но пока это проблем не создавало.
Мы провели тщательное нагрузочное тестирование сиситемы на реальных запросах в фоновом режиме. В нагрузочных тестах было видно что GC работает неравномерно, не то чтобы критично, но как то странно. Через пол года эта странность начала быстро прогрессировать, и разобраться на продакшен системе было уже гораздо тяжелее. В целом даже многократная нагрузка в НТ, не гарантирует отсутствие поблем в первые часы после запуска.Мы сделали регулярную реиндексацию, что быть уверенными что в любой момент сможем пересоздать индекс. Это может понадобиться к примеру чтобы помеять схему индексации. И не раз это нас предупреждало о том что мы начинаем терять эту возможность. При этом мы посчитали что регулярная синхронизация нам не нужна – у нас все надежно и ничего не будет теряться Еще была проблема в том, что выбраный механизм для наполнения индекса, не подходил для регулярного выполнения.Search Dbбыл нужен только для пользователей???Большой хип может работать быстро, если в нем мало объектов. Поэтому делая навороченное кэширование, легко проиграть в производительности – всю экономию съест GC.
Сессии хранятся offheap
Бытсро расло как количество данных, так и количество форматов в которых могут приходить запросы. Так же все больше было запросов использующих только часть сессии. Переход на схемы, чтобы снизить лишний трафик. Асинхроноое наполнение индекса – пока он наполняется, уже исполняются запросы в большие индексы. Запросы допускающие ответ раньше чем отработают все подзапросы.
Кэш результатов, да и промежуточный сервис, были лишними. Вполне можно было обойтись без них и сэкономить уйму времени. По крайней мере, в случае с поиском наша статистика указывает на низкую эффективность кэширования запросов. Особенно с ростом интерактивности интерфейса. Сделать кэширование в такой системе не просто, и, скорее всего, это потребует отдельных серверов, что усложняет систему и снижает ее надежность. Кроме того, время, потраченое нами на реализацию кэширования, можно было не тратить или потратить на оптимизацию исполняющей части.Мы применили ту же схему и для поиска групп и поиска сообществ, там лишними была еще и Search DB. В тот момент это было сделано из соображений приемствености и унификации, но это принесло больше проблем, чем пользы.
Вариант с ремоут-кэшами еще плох и тем, что он очень чувствителен к сбоям и перегрузке сети. Трафик запросов и загрузки данных гораздо ниже и рассредоточение.
Риски vsудобство. Разделенное тяжелее сломать целиком, но когда «похожих» систем много, возникает путаница, проблемы с деплойментом и поддержкой в рабочем состоянии на всех средах. Еще становится тяжело за всем уследить, и возникшие проблемы для не центральных сервисов могут быть пропущены. Объединение позволяет все централизировать, сэкономить время на поддержку сред и оптимизировать железо не создавая сложных деплойментов на серверах. Так же унифицированая система более устойчива к изменеению нагрузки, т.к. ее легче перебалансировать.