Your SlideShare is downloading. ×
0
Highload Begun Pankov
Highload Begun Pankov
Highload Begun Pankov
Highload Begun Pankov
Highload Begun Pankov
Highload Begun Pankov
Highload Begun Pankov
Highload Begun Pankov
Highload Begun Pankov
Highload Begun Pankov
Highload Begun Pankov
Highload Begun Pankov
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Highload Begun Pankov

1,588

Published on

Published in: Technology, News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,588
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
64
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Хранение и отдача миллионов объектов Панков Александр, Бегун
  • 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. Простейшая реализация: СУБД (SQL :) ) <ul><li>Хранение информации по страницам в СУБД </li></ul><ul><li>Недостаток: неприемлемо медленная скорость работы. </li></ul><ul><li>Кеширование запросов не спасёт: более 40% запросов постоянно будут обращаться к диску. </li></ul>
  • 4. Архитектура: самописный демон (memcached-like) <ul><li>Хранение всей информации в памяти накладно: 1 страница — 1кб, 2—3 миллиона страниц — машинка. А у нас 500 миллионов страниц. </li></ul><ul><li>Схема неминуемо натолкнёт к понятию «устаревания» страницы, очисткам хранилища, а значит и к потерям данных, которые в будущем могут пригодиться. </li></ul>
  • 5. Архитектура nephilidae: требования <ul><li>Хранить всю информацию о всех известных страницах, не удалять. </li></ul><ul><li>Надёжность системы при перегрузках и авариях. </li></ul><ul><li>Гарантированный ответ в среднем за 15ms, и в пределах 150ms при старте одной из машин кластера на «чистый кеш». </li></ul><ul><li>Автоматическое обновление: новая страница индексируется и сразу же попадает в хранилище. Минимальные задержки. </li></ul>
  • 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. Архитектура 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. Архитектура nephilidae: третий черновой вариант <ul><li>Отдача информации многопоточным демоном. Новый самописный демон работает в несколько потоков. Два типа запросов — быстрые и медленные. </li></ul><ul><li>При выключенной индексации прекрасно работает на отдачу. </li></ul><ul><li>Возможная причина: ресурсы системы (диск?) или сеть(?). </li></ul><ul><li>Тесты показали, что причина в шедулинге CPU: тестовый процесс, требующий CPU, увелививал время отклика на порядок. </li></ul><ul><li>Самое разумное решение: разделить отдающие и индексирующие машины. </li></ul>
  • 9. Архитектура nephilidae Nginx с модулем pages Ханилище и демон Индексатор
  • 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. Организация дисковых систем. <ul><li>Дублирование данных в двух датацентрах: drdb. При выходе из строя диска или потери связи между датацентрами, автоматически начинает работать резервный диск, но только на чтение. </li></ul><ul><li>Доступ к хранилищам с индексирующих машин осуществляется по nfs. </li></ul>
  • 12. Что получилось? <ul><li>Система соответствует всем требованиям по нагрузке и надёжности. </li></ul><ul><li>Первостепенная задача: написание своей файловой системы, специально заточенной под наши нужды. </li></ul><ul><li>Вторая задача: уменьшение трафика между датацентрами. </li></ul>

×