Яндекс Субботник | 03.12.2011 #yasubbotnik
В эти выходные я был в Питере на достаточно интересном мероприятии. Компания Яндекс устраивает подобного формата конференции с 2009 года, но в этом году Питерский офис компании впервые (и причем дважды) принял участников субботника, за что им огромное спасибо!
Первые впечатления о формате мероприятия:
1) молодая аудитория, не заметил кого-то старше 30
2) соотношение субъективно полезных докладов к неполезным 50/50
3) есть возможность спросить и узнать как работает Яндекс изнутри
Кратко о докладах (часть из них я пропустил):
Кир вцелом рассказал о том, как меняется взаимодействие пользователя с мобильным устройством и привел пример реализции 'почти нативного' слайдера средствами CSS3, это как раз та фишка, которую я каждый день использую, читая новости с iphone.
Тема тач-интерфейсов достаточно сложная, учитывая зоопарк используемых мобильных платформ, но web, определенно, уходит на мобильные устройства и пользователям просто необходимы привычные им тач и жесты в мобильном браузере.
Серьезный подход в разработке UI, основанный на таргетированной статистике по карте кликов. Каждый слайд презентации на своем месте, ничего лишнего, все последовательно и по шагам.
Вот почему Яндексом так удобно пользоваться, вы теперь знаете, что Анастасия Ларкина следит за тем, куда вы кликаете.
Sandbox, иногда называют Staging режим приложения, доступный только для пре-продакшн использования программистами, админами и тестировщиками. Тесты прогоняются в окружении, очень близком к продакшну. Доклад интересный и полезный.
Ольга описала механизм работы сервисов типа Amazon Mechanical Turk и то, как Яндекс решает проблему оценки качества поисковой выдачи. Теперь все знают, что степень достоверности пессимистичных оценок намного выше оптимистичных, так что можете доверять негативным отзывам больше.
В стиле Стива Джобса, максимально доступно с перефразированием каждой фразы по 3 раза, но очень интересно.
Мы ждали от Сергея, что он скажет что-то новое, что решит проблемы распределения нагрузки в нагруженном User Generated Content проекте. Нового мы не услышали, зато освежили типичные паттерны масштабирования в данной задачи, а именно:
- вынести всю работу с данными в модель, так как сервера приложений в отличии от баз данных
горизонтально масштабируются как горячие пирожки
- остерегайтесь триггеров и хранимых процедур, так как версионность работы с ними не так проста, как на уровне приложения
- никаких JOIN-ов, только простые запросы, которые легко загоняются в кэш
- аггрегировать данные по минимально-возможному ключу
- инвалидация кэша по колбэку
- пиши в master, читай со slave, но помни про replication lag
- кэшировать только часто используемые данные, так как накладные расходы на кэширования "всего подряд" не только высоки, но также польза от них сомнительна, если cache hit будет низким
- промежуточное кэширования аггрегированных функций, например, счетчиков с последующим
периодическим пересчетом, кроме того, с счетчиками лучше работать через методы increment, decrement
- PubSub - подписка на изменения во френдленте, но годится не всегда и не везде
- в UGC проектах вместо готового html предпочтительно кэширование промежуточных
"сырых данных", которые удобно реиспользовать в разных блоках с разным уровнем доступа
- на каждый сервер с приложением поставить промежуточный кэширующий бэкенд, чтобы разгрузить базу на чтение, кэшировать можно при первом запросе к базе - прозрачно для приложения.
Технический интересный доклад. Алексей рассказал про суровые будни борьбы с гигантским трафиком, обращения правообладателей и разницу в шейпинге потока конечному пользователю и региональному кэширующему прокси. В данному случае инвалидация кэша решается пока только перезапуском nginx с обнулением кэша конкретной ноды. Когда вылетает часть кластера, то данный узел останавливают целиком для сохранения целостности файловой системы, прав пользователей и ограничение входящего трафика.
Вот и самое главное, зачем я поехал на #yasubbotnik.
Не могу вспомнить сколько вопросов я задал Екатерине, но на каждый из них получил компетентный ответ.
Тема горизонтального масштабирования хранилища данных нетривиальна и не имеет конкретных паттернов решения задачи, каждый метод (High Availability, High Performance) имеет свои наборы типовых практик, но,
опять же, здесь все намного сложнее, чем кажется на первый взгляд.
Одним из моих главный вопросов были:
- нагрузка, нагрузка и еще нагрузка - справляется ли MySQL с поставленными ему задачами
- MySQL еще актуален или смотреть в сторону PostgreSQL, либо NoSQL решения
- как реплицировать и правильно "пилить", то есть шардить/партиционировать базу
- как бэкапить без блокировок
- есть ли какие специфичные конфиги mysql и используют ли Яндекс сборку от Percona
Ответы:
1) master-slave репликации с записью в мастер, чтение со слейвов хорошо показывает себя на работе с огромными объемами данных, таким образом подобные типовые решения ложатся и на такие нагрузки
2) MongoDB используется в продакшне и ведет себя достаточно неплохо, особенно учитывая Replica Sets с автоматической отказоустойчивостью
3) в основном используется MySQL 5.1-5.5, стандартная сборка - достаточно хорошо себя ведет на продашкне с очень-очень большими объемами (надо просто уметь ее готовить)
4) специального тюнинга innodb нет, по большей части стандартные оптимизации, о которых знают все, например больше памяти для innodb кэша
5) из-за больших объемов бэкапы делаются на уровне файловой системы (rsync, tar)
6) шардирование - почти-серебряная-пуля, если знаешь по какому признаку шардить. отказойчивость мета-базы предлагается master-master репликаций и разным offset-ом
Общее впечатление о конференции и компетентности сотрудников Яндекса - 10/10. Планирую посещать субботники настолько часто, насколько это возможно
