Документ описывает архитектуру системы Nephilidae для обработки миллионов запросов к страницам сайтов с высокими нагрузками и минимальными задержками. Включает различные оптимизационные подходы по хранению и индексации страниц, а также проблемы, с которыми сталкивалась система. Основной задачей является разработка эффективной файловой системы, чтобы улучшить производительность и сократить трафик между датацентрами.

1. Хранение и отдача миллионов объектов Панков Александр, Бегун

2. Постановка задачи Принцип подбора объявлений в Автоконтексте Бегуна. Ключевая задача: быстро узнавать информацию о конкретной странице партнёрского сайта. Высокие нагрузки: несколько тысяч запросов в секунду, время отклика в среднем 10—15ms. 30% запросов о не знакомых системе страницах. Это только что появившиеся новые страницы форумов, досок объявлений, страницы сложного поиска по параметрам и т. д. Суточный кеш покрывает не более 60% запросов. 10% запросов — редкие страницы, но этих страниц в 100 раз больше, чем тех, которые запрашиваются часто.

3. Простейшая реализация: СУБД (SQL :) ) Хранение информации по страницам в СУБД Недостаток: неприемлемо медленная скорость работы. Кеширование запросов не спасёт: более 40% запросов постоянно будут обращаться к диску.

4. Архитектура: самописный демон (memcached-like) Хранение всей информации в памяти накладно: 1 страница — 1кб, 2—3 миллиона страниц — машинка. А у нас 500 миллионов страниц. Схема неминуемо натолкнёт к понятию «устаревания» страницы, очисткам хранилища, а значит и к потерям данных, которые в будущем могут пригодиться.

5. Архитектура nephilidae: требования Хранить всю информацию о всех известных страницах, не удалять. Надёжность системы при перегрузках и авариях. Гарантированный ответ в среднем за 15ms, и в пределах 150ms при старте одной из машин кластера на «чистый кеш». Автоматическое обновление: новая страница индексируется и сразу же попадает в хранилище. Минимальные задержки.

6. Архитектура nephilidae: первый черновой вариант Хранение сжатой (gzip) информации на диске (reiserfs, xfs) Однопоточный (nginx-like) отдающий демон Индексирующий демон Результат тестирования: даже при выключенной индексации система не справлялась с отдачей. Причина: блокировки от постоянного поиска несуществующих файлов на диске.

7. Архитектура nephilidae: второй черновой вариант Дополнительный демон страниц : храним summary о странице в несколько байт: когда, что и почему. Система не прошла тестирование: даже при выключенной индексации система не справлялась с отдачей. Причина: блокировки при чтении с диска. Однопоточность отменяется. Мечта: доступ к диску «в стиле epoll». Суровая реальность: в операционных системах Linux и BSD системный вызов open блокирует вызывающий процесс .

8. Архитектура nephilidae: третий черновой вариант Отдача информации многопоточным демоном. Новый самописный демон работает в несколько потоков. Два типа запросов — быстрые и медленные. При выключенной индексации прекрасно работает на отдачу. Возможная причина: ресурсы системы (диск?) или сеть(?). Тесты показали, что причина в шедулинге CPU: тестовый процесс, требующий CPU, увелививал время отклика на порядок. Самое разумное решение: разделить отдающие и индексирующие машины.

9. Архитектура nephilidae Nginx с модулем pages Ханилище и демон Индексатор

10. Архитектура nephilidae Всякий запрос идёт на nginx с нашим модулем, который знает все машины кластера. Запрос к соотв. демону страниц: что у нас есть и что нужно сделать. Если нужно — отправляем страницу на (пере)индексацию. Если у нас есть что-то по странице, то обращаемся соотв. машине кластера. Проверка на наличие страницы в кеше. Есть — хорошо. Если нет — проверяем, успеем ли мы прочитать с диска, или лучше честно сразу сказать, что не успеем. Это позволит не терять зря времени и подобрать объявления по другим источникам данных.

11. Организация дисковых систем. Дублирование данных в двух датацентрах: drdb. При выходе из строя диска или потери связи между датацентрами, автоматически начинает работать резервный диск, но только на чтение. Доступ к хранилищам с индексирующих машин осуществляется по nfs.

12. Что получилось? Система соответствует всем требованиям по нагрузке и надёжности. Первостепенная задача: написание своей файловой системы, специально заточенной под наши нужды. Вторая задача: уменьшение трафика между датацентрами.