Successfully reported this slideshow.

Highload Begun Pankov

1,866 views

Published on

Published in: Technology, News & Politics
  • Be the first to comment

  • Be the first to like this

Highload Begun Pankov

  1. 1. Хранение и отдача миллионов объектов Панков Александр, Бегун
  2. 2. Постановка задачи <ul><li>Принцип подбора объявлений в Автоконтексте Бегуна. </li></ul><ul><li>Ключевая задача: быстро узнавать информацию о конкретной странице партнёрского сайта. </li></ul><ul><li>Высокие нагрузки: несколько тысяч запросов в секунду, время отклика в среднем 10—15ms. </li></ul><ul><li>30% запросов о не знакомых системе страницах. Это только что появившиеся новые страницы форумов, досок объявлений, страницы сложного поиска по параметрам и т. д. </li></ul><ul><li>Суточный кеш покрывает не более 60% запросов. </li></ul><ul><li>10% запросов — редкие страницы, но этих страниц в 100 раз больше, чем тех, которые запрашиваются часто. </li></ul>
  3. 3. Простейшая реализация: СУБД (SQL :) ) <ul><li>Хранение информации по страницам в СУБД </li></ul><ul><li>Недостаток: неприемлемо медленная скорость работы. </li></ul><ul><li>Кеширование запросов не спасёт: более 40% запросов постоянно будут обращаться к диску. </li></ul>
  4. 4. Архитектура: самописный демон (memcached-like) <ul><li>Хранение всей информации в памяти накладно: 1 страница — 1кб, 2—3 миллиона страниц — машинка. А у нас 500 миллионов страниц. </li></ul><ul><li>Схема неминуемо натолкнёт к понятию «устаревания» страницы, очисткам хранилища, а значит и к потерям данных, которые в будущем могут пригодиться. </li></ul>
  5. 5. Архитектура nephilidae: требования <ul><li>Хранить всю информацию о всех известных страницах, не удалять. </li></ul><ul><li>Надёжность системы при перегрузках и авариях. </li></ul><ul><li>Гарантированный ответ в среднем за 15ms, и в пределах 150ms при старте одной из машин кластера на «чистый кеш». </li></ul><ul><li>Автоматическое обновление: новая страница индексируется и сразу же попадает в хранилище. Минимальные задержки. </li></ul>
  6. 6. Архитектура nephilidae: первый черновой вариант <ul><li>Хранение сжатой (gzip) информации на диске (reiserfs, xfs) </li></ul><ul><li>Однопоточный (nginx-like) отдающий демон </li></ul><ul><li>Индексирующий демон </li></ul><ul><li>Результат тестирования: даже при выключенной индексации система не справлялась с отдачей. </li></ul><ul><li>Причина: блокировки от постоянного поиска несуществующих файлов на диске. </li></ul>
  7. 7. Архитектура nephilidae: второй черновой вариант <ul><li>Дополнительный демон страниц : храним summary о странице в несколько байт: когда, что и почему. </li></ul><ul><li>Система не прошла тестирование: даже при выключенной индексации система не справлялась с отдачей. </li></ul><ul><li>Причина: блокировки при чтении с диска. Однопоточность отменяется. </li></ul><ul><li>Мечта: доступ к диску «в стиле epoll». </li></ul><ul><li>Суровая реальность: в операционных системах Linux и BSD системный вызов open блокирует вызывающий процесс . </li></ul>
  8. 8. Архитектура nephilidae: третий черновой вариант <ul><li>Отдача информации многопоточным демоном. Новый самописный демон работает в несколько потоков. Два типа запросов — быстрые и медленные. </li></ul><ul><li>При выключенной индексации прекрасно работает на отдачу. </li></ul><ul><li>Возможная причина: ресурсы системы (диск?) или сеть(?). </li></ul><ul><li>Тесты показали, что причина в шедулинге CPU: тестовый процесс, требующий CPU, увелививал время отклика на порядок. </li></ul><ul><li>Самое разумное решение: разделить отдающие и индексирующие машины. </li></ul>
  9. 9. Архитектура nephilidae Nginx с модулем pages Ханилище и демон Индексатор
  10. 10. Архитектура nephilidae <ul><li>Всякий запрос идёт на nginx с нашим модулем, который знает все машины кластера. </li></ul><ul><li>Запрос к соотв. демону страниц: что у нас есть и что нужно сделать. </li></ul><ul><li>Если нужно — отправляем страницу на (пере)индексацию. </li></ul><ul><li>Если у нас есть что-то по странице, то обращаемся соотв. машине кластера. </li></ul><ul><li>Проверка на наличие страницы в кеше. Есть — хорошо. </li></ul><ul><li>Если нет — проверяем, успеем ли мы прочитать с диска, или лучше честно сразу сказать, что не успеем. Это позволит не терять зря времени и подобрать объявления по другим источникам данных. </li></ul>
  11. 11. Организация дисковых систем. <ul><li>Дублирование данных в двух датацентрах: drdb. При выходе из строя диска или потери связи между датацентрами, автоматически начинает работать резервный диск, но только на чтение. </li></ul><ul><li>Доступ к хранилищам с индексирующих машин осуществляется по nfs. </li></ul>
  12. 12. Что получилось? <ul><li>Система соответствует всем требованиям по нагрузке и надёжности. </li></ul><ul><li>Первостепенная задача: написание своей файловой системы, специально заточенной под наши нужды. </li></ul><ul><li>Вторая задача: уменьшение трафика между датацентрами. </li></ul>

×