3 День второй
3.1 Sphinx в примерах и задачах
Мне ужасно стыдно, но я проспал. Хотя тема явно интересная, уже есть два эффективных бесплатных и опен-сорс движка полнотекстового поиска — Sphinx и встроенный поиск PostgreSQL. Очень интересно кто-кого, и даст ли «синергию» конкуренция и перекрестное опыление.
Например в некоторых наших внутренних MySQL-системах я уже подключил Sphinx для поиска, в некоторых — думаю подождать и сразу перейти на PostgreSQL, и делать полнотекстовый поиск с морфологией напрямую в БД.
3.2 Организация асинхронной обработки задач
Частично опоздал, но в целом доклад не оправдал моих ожиданий. Судя по названию можно было бы ждать опыта использования специализированных продуктов — от вендоров, типа Oracle Advanced Queuing (в тезисах говорилось про оракл), IBM WebSphere MQ,…, а может даже и опен-сорс. Увы, рассказали о простом самодельном решении на оракле. Как-то невозбуждающе.
3.3 Практическое использование Hadoop в системе интернет-статистики
Разумное и модное решение задачи параллельной обработки и агрегации логов посещения сайтов. Используется фреймворк Hadoop (параллельные вычисления в парадигме map/reduce), который для таких задач вроде как идеально предназначен, и в общем-то единственно доступный (опен-сорс), ибо гугловый аналог закрыт, а больше вроде ничего нет.
Кластер относительно небольшой (12 восьмиядерников с 8Gb памяти), но справляется. Два прохода:
Схлопывание текстовых многополевых атрибутов в idы (индексирование).
Обработка (агрегация разного рода) полученных индекс-файлов, получени отчетов.
Ну и всякие там хитрости, вроде все разумно. Опять таки, убьют наверно баннерорезки и этот бизнес.
3.4 CAS — сервер приложений C++
Как-то не. Ждал «сервер приложений C++». Оказалось, «не сервер», «не приложений», «не C++». То есть ребята написали очередной шаблонизатор, для вызова из скриптовых языков. Вроде как быстрый (судя по картинке-гистограмме с неподписанными осями и без единой цифре), но как-то не то, что ожидалось.
3.5 Виртуализация в среде highload servers
Вроде по содержанию маркетинговый доклад, подвигающий фишку виртуализации от SWSoft — вместо выполнения виртуальных машин целиком (VMWare, Hyper-V, Virtual PC, VirtualBox, …), на хост машине размещается одно ядро операционной системы, а виртуализуется все остальное — файловая система и все что на ней.
Для маркетингового доклада выглядел как-то вяло, но оказалось, что докладывал не маркетолог, а инженер техподдержки (для него это нормально).
Выгоды сферической виртуализации в вакууме понятны, угрозы тоже (взлом виртуальной машины высоковероятно приводет к взлому машины хостера, и конец всей сотне виртуальных машин). См. например An Empirical Study into the Security Exposure to Hosts of Hostile Virtualized Environments. Да и без всяких взломов, как выяснилось, трудно рулить физическими ресурсами — например можно ограничить виртуальную память каждой машине, но живую память квотировать нельзя — соответственно одна «оборзевшая» виртуальная машина может поставить «раком» остальных.
Сравнений с конкурентами тоже не было. Но тема интересная. Может доживем до момента, когда и монстры типа яндекса, будут жить на виртуальных серверах, переползающих с одного железа на другое.
3.6 Application Streaming
Жесткий маркетинговый («парилово») доклад от ENDEAVORS. Презентация с гламуром и анимацией, причем разработанная видимо зарубежом — ни слова по-русски (даже не локализовали).
Суть — очередные модели SaaS, не только как вебприложений, но как скачиваемых в специальную среду rich-приложений, работающих ограниченное время (за плату). Почему-то утверждалось, что CRM-системы на вебинтерфейсе невозможны (вроде как неправда).
Постоянно упоминались куча софтварных патентов, за которых этой конторе вынуждены отстегивать собственно производители типа Microsofта, технологии защиты цифрового контента, и прочие штуки, которые я ненавижу. Надеюсь в светлом будущем не придется арендовать фильмы в виде защищенного этой технологией одноразового приложения, а все эти технологии благополучно сдохнут. Пусть разве что останутся честные SaaSовсцы, предоставляющие (пусть за деньги) приложения на своем хостинге.
3.7 Архитектура Photofile.ru
История эволюции архитектуры фотохостинга, от совсем любительской (на одном сервере), до более-менее масштабируемой. В деталях, как появлялись разные узкие горла, и какими эвристиками с ними боролись — как включали второй сервер, как перетаскивали файлы, оставляя на их месте симлинки, как делали шардинг через Dynamic DNS и т.п.
Алсо, ругали Cache Smarty.
В общем, с появлением таких монстропроектов, как «я.фотки», «netprint.ru», с огромным машинным и человеческим ресурсом, с изначально масштабируемой архитектурой, фотофайлу наверно высокие нагрузки более не угрожают.
3.8 Архитектура и реализация сервиса печати фотографий netprint.ru
Крутые парни. Большой промышленный проект — практически уже монополия на фотопечать (почти все фотохостинги печатающие фотки, печатают через них), типичный пример, как централизованный онлайн-сервис убил все кустарные лаборатории.
Архитектура — Java, вроде как разваленная на вебсервисы (JMS), плюс PHP+XCACHE+LightHttpd для вебморды. Кстати, опять таки PostgreQL.
Максимальная асинхронность, все операции не более константной сложности, причем константу загоняют до нижнего предела:
вместо удаления — пометка об удалении, удаляет специальный демон потом;
перекодировка изображений — написали сами оптимизированный под Intel код, вроде как порвал ImageMagick в десятки раз.
Ребята не ведутся на марки, тренды и авторитетов:
бэкап делают на ленты, ибо посчитали, что чуть дешевле (для новых систем вроде как ленты лет уж пять как похоронили общемировым консенсусом).
опять таки самописная обработка изображений,
RAID — sucks.
тренировки по восстановлению в формате «внезапная пожарная тревога» (может шутили?),
изучение поведения системы под нагрузкой в дни естественных пиков (пост-праздники, НГ).
Попытался после конференции передать свои пожелания к системе. Например, печать EXIF-дат фото на обратной стороне. Когда я еще печатался в мелкой локальной фотолаборатории, моя самописная утилита переименовывала имена файлов под ISO-дату, и как-раз первые восемь символов имени файла печатались сзади. Очень удобно, легко понять, когда это фото и что. Когда начал печататься в нетпринте, халява закончилась — там все фотки при загрузке переименовывались. Это меня теперь сильно останавливает от печати — не хватало еще усугублять файловый бардак, бардаком с бумажными фото. Подождем, может сделают. На самом деле, им даже не нужно патчить софт в машинах-фотолабораториях, проще написать «переименовывающий фильтр» перед подачей этих файлов в машины.
3.9 Решение проблем высоких нагрузок на примере проекта Яндекс. Фотки
Сервис очень хороший, и докладчики наверно хорошие (редкий зверь — два докладчика, практически «парный конферанс»), но доклад вызвал раздражение и аллергию.
Презентация намеренно сделана «банально-попсовой», символы архитектуры заменены всякой порнографией (типа женский бюст — Cisco, банан с двумя апельсинами — сами додумайте и т.п.). Плюс дурацкие фото, как эмоциональная иллюстрация идей. Что-то похожее я видел на презентациях с конференции автоматизаторов торговых сетей — тупые и тривиальные тезисы слайдов засыпаны содержимым с fishki.net чуть более чем полностью.
Но возможно это лично мое извращенное мнение, аудитория вроде реагировала живо, наверно понравилось. По сути, конференция — это гибрид похода в кино, театр, тусовку и ресторан одновременно, и народ алкает зрелищ и развлечений.
А так типа все круто, масштабируемость, распределенные датацентры, супернадежность (мониторинг мониторинга) — остальным фотохостингам остается или закрыватся, или искать нишу (ЕВПОЧЯ).
3.10 Доставка контента пользователям
Обнаружил, что есть сервис smotri.com, позиционирующийся как самый крутой в рунете. Вообще в этой теме (протоколы передачи видео и т. п.) практически не разбираюсь, посмотрел архитектуру — местами «стандартно фотохостинговая», местами есть специальные гитики.
Средняя температура по больнице — 4 минуты на ролик, 250Кб/сек — доставка. Отметил, что пользуются WebDAVом для трансляции операций по загрузке и редактированию и не жалуются.
Слегка возбудился, когда докладчик начал утверждать, что маршрутизацию оптимального пути от хранилища видеоконтента до потребителя делают стандартным алгоритмом кратчайших путей на графе с весами обратными пропускной способности — очевидно должна получатся фигня. Тут надо либо специальный BFS-алгоритм использовать, либо вообще, учесть загрузку от передаваемых потоков, может даже линейным программированием попользоваться… — но оказалось (в беседе с автором), что там вообще все на глаз — просто «эксперт» разбрасывает целые оценки ребрам (плохой канал — побольше, хороший — поменьше), а потом кратчайшие пути.
Вроде всех все устраивает, другая оптимизация не нужна. Хотя может если видео пойдет в большем качестве, то наконец все упрется не в диски-память, а в сеть, и тут понадобится более серьезная оптимизация.
