Insight IT

Нам два годика

Иван Блинков — Sun, 03 Jan 2010 23:59:00 +0300

В общем судя по всему я решил считать 3 января 2008 года Днем Рождения Insight IT, так что как раз самое время написать очередной бестолковый "праздничный" пост, по совместительству выполняющий роль "новогоднего" (надо же поздравить всех читателей с Наступившим, хоть и несколько поздновато; отметил я просто замечательно и три дня провел без интернета). В повестке дня у нас сегодня обзор основных событий прошедшего года и планы на наступивший, кому интересно - читаем дальше ;)

Как не сложно увидеть по датам постов - первые 10 месяцев года прошли очень пассивно для данного блога. Я был весь в работе и учебе, постов писал мало, на комментарии отвечал редко - в общем халтурил по полной программе. Впрочем время для меня зря не прошло - успел получить степень бакалавра Бизнес-Информатики и поступить в магистратуру на программу "Электронный бизнес". В дополнение к общему затишью ложку дегтя добавлял теперь уже бывший хостинг провайдер (по прежнему не хочу устраивать анти-рекламу, российская компания с доменом из двух букв, кому было интересно уже наверное давно успели посмотреть) - возможно кто-то из читателей помнит эти регулярные проблемы с доступностью сайта, некоторые из которых даже доходили до простоев более двух недель подряд.

На этом в общем-то негативные стороны заканчиваются, так что перейдем к положительным моментам. Во-первых, блог переехал-таки на новый хостинг в США: там существенно более ответственно относятся к клиентам, отличная техподдержка, пока никаких сбоев, современное оборудование, никаких фиксированных ограничений по трафику/дисковому пространству/процессорному времени/чему-то еще в этом духе - в целом пока вижу в данном решении почти только плюсы, из минусов разве что чуть больший пинг и цена на 500р./год выше. Во-вторых, в октябре я остался без работы - про это я уже рассказывал достаточно подробно, повторяться не буду. В общем у меня стало появляться существенно больше свободного времени, которое я мог позволить себе тратить на блог. Не трудно заметить возросшую активность как в постах, так и в комментариях, циферки в статистике Google Analytics, Feedburner и Wordpress.com Stats достаточно резво растут вверх и я надеюсь, что эта тенденция продолжится и на протяжении всего наступившего года. Уже накопилась масса идей для новых постов - осталось только найти в себе силы материализовать их.

Вообще я уже почти три месяца сижу без работы и почему-то чем дальше - тем менее активно ищу новую. Некоторое время назад, примерно одновременно с принятием решения о смене хостинга, мне пришла в голову идея попробовать зарабатывать на Insight IT, чтобы позволить себе оттягивать процесс поиска работы как можно дальше. Сначала попробовал наиболее "гуманный" по отношению к читателям метод, который более-менее сносно работал в 2008 году - поставил побольше блоков Google AdSense. Оказалось больше не работает, цены за клик упали в 3-5 раз, да и CTR ниже плинтуса. Этот факт подтолкнул меня создать появившуюся в меню навигации несколько дней назад страничку "Реклама" (возможно кто-то уже успел ознакомиться), основная идея - я готов размещать ту или иную форму рекламы напрямую, без посредников в виде бирж или каких-то других автоматизированных систем. Очень надеюсь, что кто-то заинтересуется и откликнется, иначе у меня останется только очень не нравящийся мне самому вариант со всяким бредом из области SEO: вроде продажи ссылок на биржах, размещении чужих статей и тому подобного... Либо вообще отказываться от затеи с монетизацией блога и возвращаться к поиском "офисной" работы, но вообще мне очень не хотелось бы снова забрасывать Insight IT, одно из самых любимых хобби как-никак.

Основные темы блога мне по-прежнему очень интересны: как информационные технологии в целом, так и архитектуры высоконагруженных систем в частности. Мне наверное еще предстоит поэкспериментировать с различными форматами изложения информации, более узкими темами и вопросами, чтобы подстроиться под наверняка изменившиеся за прошедший год интересы аудитории блога, я по прежнему рад комментариям, письмам и другим видам обратной связи. По старинке хочется порекомендовать всем, кто этого еще не сделал, подписаться на RSS.

До новых встреч!

Новый Google: интернет-гигант проливает свет на темы поиска в реальном времени, локального поиска, облачных вычислений и освобождения данных

Иван Блинков — Tue, 29 Dec 2009 18:17:00 +0300

Когда речь заходит о продуктовых и бизнес стратегиях, Google обычно становится одной из самых скрытных и секретных компаний. Но не смотря на это, интернет-гигант некоторое время назад согласился дать серию интервью, в основном с участием высшего продуктового менеджмента, работающего в штабквартире в Mountain View, CA.

В четырех отдельных интервью, сотрудники Google окунулись в самые насущные темы, наиболее актуальные для компании в целом. Среди них оказались различные вопросы, начиная с поиска в реальном времени, локального поиска, и заканчивая облачными вычислениями, а также так называемой возможностью освобождения данных. Под освобождением данных имеется ввиду комплекс мер, направленных на предоставлении пользователям возможности экспортировать их файлы и другую цифровую информацию из продуктов Google (если они сами этого захотят, конечно же).

Достаточно любопытный факт: менеджеры Google реально очень скучные. И им правда нравится выглядеть именно так (по крайней мере пока их PR-коллеги находятся рядом). Они не разговаривают о конкурентах. Они не делают прогнозов о развитии индустрии. И они не говорят конкретно кто над чем работает внутри Google. Просто-напросто они фокусируются на совершенствовании своих продуктов, особенно в направлении удобства использования пользователями, разве этого не достаточно?

Возможно Jack Menzel, старший продукт-менеджер, лучше всего это выразил, когда пошутил о "неблагодарности" работы над веб-поиском в Google: "Вы демонстрируете [новую функцию поиска] людям, а они говорят: 'Да, вроде она работает, ну и что?'" (Как быстро все мы забываем, каково это было искать информацию в Интернете всего несколько лет назад.) Что ж, без дальнейших предисловий, перейдем к основным моментам, связанным с различными аспектами работы Google.

По мотивам статьи на xconomy.com, автор Gregory T. Huang.

Поиск в реальном времени

Google активно работает над максимально оперативным обновлением результатов поиска по сети Интернет, в том числе и по социальным медиа вроде Twitter или Facebook, практически так же быстро, как такая информация и публикуется.

Menzel, бывший сотрудник Microsoft, который изучал компьютерное ремесло в University of Washington, возглавляет продуктовую группу на данном фронте. Он говорит, что компания Google работала над ускорением процесса индексации и ранжирования на протяжении уже многих лет: когда-то данные обновлялись раз в месяц, потом обновление стало ежедневным, чтобы поспевать за блогами и новостными сайтами. В течении прошлого года Twitter стал популярен и, как следствие, появилась достаточно критичная потребность в обновлении информации за считанные секунды или в крайнем случае минуты. "Мы двигались по направлению к тому, чтобы становиться все быстрее и быстрее, на протяжении уже достаточно длительного периода времени", говорит Menzel. "Данная траектория развития была выбрана уже давно. Каждый шаг в данном направлении приводит к все новым и новым проблемам и трудностям. Мы верим, что именно получение доступа к свежей информации является одним из ключевых факторов, являющихся залогом успеха Google." (В число остальных факторов, относящихся к самому поиску, входят такие показатели как релевантность, быстрота получения результата и полнота контента.)

Menzel считает, что самой сложной задачей является не просто быстродействие, а релевантность результатов потребностям пользователей (возможно, кто-то привык называть этот показатель словом "пертинентность"). "Это очень, очень непросто собирать свежий короткоживущий контент и ранжировать его рядом с, скажем, статьями из New York Times или просто постами из блогов." Стоит заметить, что когда контент появился буквально только что, обычно на него еще практически никто не успел сослаться, а значит Google не может полноценно использовать PageRank, их классическую технологию.

Вместо этого, они "тяжело опираются на все то, что они выявили в течении последних 10 лет", говорит Menzel. Это включает в себя, например, способы отбрасывания контента, который скорее всего является иррелевантным или спамом, в более общем случае. Помимо этого он упоминал "совершенно новые сигналы", скажем "новые языковые модели", которые позволяют понять какие обновления являются релевантными, а какие - просто горстка никому не нужных данных от какого-нибудь ученого-океанографа, или методы определения насколько тот или иной создатель контента авторитетен в своей области.

Говоря о будущем, Menzel повторил то, что казалось бы на сегодняшний день говорят все о поиске: еще рано. "На самом деле мы лишь начали работать над данной задачей и у нас все еще очень долгий путь впереди". Он надеется, что в течении 5 лет Google сделает поиск намного более персонализированным, чем он есть сегодня. Например, Google будет знать что ты увлекаешься футболом, но привык называть его не "soccer", а "football", то есть помимо прочего поисковая система должна понимать кем является каждый ее конкретный пользователь, как и с кем он связан, кем он является в реальной жизни, где находится, и, тем самым, помогать ему организовывать всю информацию вокруг него.

"Поиск - все еще очень далекая от решения проблема," - говорит Menzel. "Существует еще масса вещей, которые очень не просто найти в Интернете."

Локальный поиск

В эту категорию попадают все виды поисковых запросов, так или иначе связанных с географической информацией, скажем "отели в Гонг-Конге" или "рестораны в Сиэттле", а также запросы с мобильных устройств на поиск близлежащих мест, заведений, достопримечательностей и прочих объектов.

Carter Maslan, директор продуктового менеджмента в области локального поиска в Google, называет эту область "организацией мировой информации географически" , или созданием быстрого и простого гида по "гео-Интернету". Самым сложным моментом в данном вопросе по его мнению является отображение всех этих различных способов выражения пользовательского запроса на очень большой массив локализированных данных, а также возвращение правильного ответа на полученный запрос в минимальные сроки.

Maslan, еще один экс-сотрудник Microsoft, говорит, что Google обрабатывает большое количество поисковых запросов для анализа того, как люди предпочитают искать локальную информацию, и как с географической точки зрения создаются ссылки на различные вещи. По его мнению конечная цель заключается в том, чтобы сделать поиск и обнаружение мест рядом с собой практически не требующим от пользователя каких-либо усилий. Наиболее знакомые сценарии, это помощь в ориентировании в новом окружении, скажем после приземления в аэропорту, или поиск баров во время ночной прогулки по пригородам Нью-Йорка.

Складывается впечатление, что все это должно плотно вписываться в более широкую стратегию Google, связанную с мобильными технологиями. "Ваш телефон знает многое" - говорит Maslan. "Он знает где Вы сейчас находитесь, он может определить в каком направлении Вы направляетесь. Все не ограничивается только текстом в окошке для поискового запроса. Мы хотим вывести мобильную информацию на передний план." Существующим на данный момент примером является Google Goggles, приложение, которое позволяет сфотографировать логотип, достопримечательность или какое-то место и мгновенно получить информацию о нем.

Maslan считает, что основной отличительной чертой Google в области локального поиска является "открытость для всех источников", что достаточно сложно с технической точки зрения. Это включает в себя пребывание в состоянии "активной глобальности", а не просто в индексировании информации о ключевых станциях метро. "Масштаб, с которым Google работает с картографическими и гео-кодированными данными, в совокупности с пониманием принципов работы Интернета является ключем для успешной работы в данной области".

Возможно в скором будущем мы увидим вещи вроде карт и списков компаний или мест от Google в еще большем количестве мест и языков по всему миру, с еще более точной информацией, чутко реагирующей на локальные события вроде открытия, закрытия или перемещения предприятий и организаций. "Мы четко понимаем, какие именно вещи у нас получаются лучше всего" - говорит Maslan. "У нас есть небольшие команды из людей, фанатично настроенных на реализацию их наиболее правильным образом".

Облачные вычисления

Наверняка все наслышаны о знаменитых вычислениях "в облаках", то есть с использованием программного обеспечения, работающем на удаленных серверах, часто нескольких одновременно и в виртуализированном окружении, а не прямо на персональном компьютере. В этом ключе Google наиболее интересует выполнение повседневных задач, таких как работа с электронной почтой, составление расписаний и управление документами. На самом деле это всего лишь часть более широкой стратегии Google по облачным вычисления - именно она создает видимость того, что потребители, предприятия и организации арендуют вычислительный мощности и хранилища данных через Интернет, так как это дешевле и более эффективно для многих приложений.

Ken Norton, старший продукт-менеджер Google (а также выпускник Boston University и бывший предприниматель), поведал о Google Apps и стратегии компании в области облачных вычислений. Команда Norton'а работает конкретно над Google Calendar, но Google Apps также включают в себя и другие продукты, такие как Gmail, Google Talk, Google Docs и Google Sites. “Сеть выигрывает на том, как приложения будут потребляться” - он сказал.

Ключевым преимуществом Google на данном фронте является масштаб и инфраструктура. "У нас есть настолько много серверов и датацентров по всему миру, что мы можем содержать их достаточно дешево и эффективно" - говорит Norton. Это преимущество оказывает влияние и на индивидуальные устройства, так как оно "открывает новые возможности" для потребителей, возможность использовать веб-приложения с любого типа устройств, будь то смартфон, нетбук или обычный полноразмерный ноутбук.

Работа Google в области облачных вычислений сфокусирована на двух уровнях: на первом располагаются готовые программные продукты вроде Google Apps, направленные на прямое потребление конечными пользователями (как индивидуальными, так и корпоративными); второй же уровень занимает App Engine, "облачная" платформа, предназначенная для использования разработчиками программного обеспечения для эффективного построения их собственных веб-продуктов.

Относительно прогнозов на следующий год на фронте облачных вычислений, Norton сказал, что "мы постоянно совершенствуемся". В 2009 году было запущенно более 100 основных новых функциональных возможностей в Google Apps - таких вещей, как видео чат в GTalk или Gmail offline. Он считает, что Google "продолжит делать акцент на коммуникационных предложениях". Помимо развития Gmail и Calendar, это включает в себя доведение до ума Google Docs и придание более завершенного вида набору их возможностей. Norton говорит, что Google также ищет возможности по расширению своих предложений в области коллаборации, в том числе в виде продуктов для крупного бизнеса, совместимыми с различными системами обеспечения безопасности для аутентификации.

Подведем черту: все выглядит как-будто Google совершает переход от фокусирования на бесплатных потребительских продуктах, работающих в "облаках", к более активной работе над платными облачными сервисами для бизнес-пользователей.

Освобождение данных

Последнее время в компании все больше внимания уделяется предоставлению пользователям легко экспортировать их данные из продуктов Google, таких как Blogger, Google Maps, Google Docs, Chrome и App Engine (пользовательские данные разработчиков). На первый взгляд это может показаться очередным капризом PR-менеджеров, но на самом деле за этим фактом стоит более глубокая и интересная инновационная стратегия.

Brian Fitzpatrick, ветеран opensource разработок, возглавляет двухлетний проект от офисов Google в Чикаго. Основная идея заключается в оказании помощи пользователям, если они хотят получить свои файлы и другие данные из облака Google, чтобы у них была возможность перейти на какую-то другую систему, если они захотят. "Большинство людей не думает о возможности экспорта данных до тех пор пока не станет слишком поздно" - говорит Fitzpatrick. "Мы надеемся, что если вы прекратите использование одного нашего продукта сегодня, то у вас будет возможность попробовать другой продукт завтра."

Помимо "создания правильных возможностей для пользователей" существует и другая мотивация. "Мы, как компания, старательно работаем над такими вещами, как поиск. Если пользователи становятся привязанным к вашим продуктам, то вы становитесь более самодовольными, расслабленными. Если же уйти достаточно просто, то вы будете серьезно мотивированны делать свои продукты как можно лучше, чтобы избежать ухода пользователей любой ценой."

Что ж, теперь у нас есть эта возможность. Google считает, что эта открытость с точки зрения пользовательских данных, заставит компанию работать более старательно для удержания пользовательской базы. Fitzpatrick не знает других компаний, которые бы открыто заявляли об инициативе создания подобных возможностей для своих пользователей.

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

DMOZ.org

Иван Блинков — Mon, 19 May 2008 17:14:00 +0400

Возможно Вы уже обратили внимание, что в начале мая данный блог был добавлен в один из крупнейших (если не самый крупнейший) каталог интернет-ресурсов - DMOZ.org, также известный как Open Directory Project. Само по себе это событие достаточно значимо для любого сайта, но я почему-то не счел нужным писать по этому поводу отдельный пост, видимо просто так как других слов кроме как "Ура! Мой блог попал в DMOZ!!!" у меня тогда не нашлось.

Сегодня же произошло другое событие, связанное с этим крупным каталогом: я стал редактором очень небольшого его раздела - World/Russian/Компьютеры/Программирование/Блоги. Раздел и правда оказался очень маленький - сегодняшним же утром за часок-другой разгреб все заявки, которые там лежали нерасмотренными. В целом впечатления от данного процесса очень положительные - нашел несколько интересных сайтов в заявках, которые потом еще достаточно долго читал просто так, уже после принятия решения о добавлении в каталог. Хотелось бы конечно раздел побольше, но я думаю всему свое время. Если у кого-нибудь из Вас есть блоги, подходящие под тематику выделенного мне раздела - добавляйте их, с удовольствием рассмотрю.

hCard

Иван Блинков — Sun, 13 Apr 2008 22:51:00 +0400

hCard представляет собой реализацию спецификации RFC 2426 (более известной как vCard) в виде микроформата. Основной его целью является предоставление стандарта оформления персональных данных на просторах Сети, но помимо этого имеется возможность указания информации об компаниях, организациях или местах. Как и любой другой микроформат, hCard реализуется без нарушения стандартов XHTML с помощью атрибутов тэга class, причем какие именно тэги используются - не важно. Для оформления данных используя этот микроформат достаточно лишь объявить какой-либо тэг hCard объектом с помощью class="vcard" и разместить внутри него все тэги, обозначающие какое-либо свойство объекта. Большая часть информации, предоставляемой в соответствии с этим микроформатом является опциональной, единственным обязательным свойством является имя объекта - class="fn". Помимо этого в атрибуте profile тэга <head> принято указывать адрес http://www.w3.org/2006/03/hcard.

В целом все свойства объектов hCard можно поделить на семь групп:

идентификационные: – различные варианты имен объекта.
адресные: – указания различных адресов, каким-либо образом ассоциирующихся с объектом: место жительство, работы и тому подобные.
телекоммуникационные: – любые формы контактной информации: номера телефонов, факс, адреса электронной почты и так далее.
географические: – месторасположение объекта.
организационные: – информация о должности и компании или организации, в которой работает объект.
уточняющие: – любая дополнительная информация об объекте.
безопасность: – ограничение доступа к информации в hCard.

Значением каждого свойства является видимый пользователю текст, получающийся в результате обработки документа браузером (или другим парсером данных). Но стоит несколько остановиться на свойстве photo, так как для него действуют несколько другие правила размещения значения:

при использовании свойства photo в тэге <a>, значением является адрес из атрибута href;
в тэге <img>, значением является само изображение, то есть значение атрибута src
в <object>, значением является атрибут `data, то есть его источник данных.

Раз уж зашла речь об размещении значений свойств, то сразу хочется сказать об небольшом исключении в виде тэга <abbr>, где оно задается в атрибуте title, а внутри самого тэга - некое более удобное для чтения людьми его представление.

Если тэг, обозначенный любым свойством, содержит какую-либо информацию помимо самого значения свойства, то для отделения релевантного контента от лишней информации можно разместить внутри тэга свойства дочерние объекты, обозначив их атрибутом class="value". Это даст понять парсеру микроформата, что собрав воедино (методом конкатенации) все значения помеченных таким образом объектов он сможет получить значение исходного свойства. Описание получилось несколько запутанным, так что лучше продемонстрировать этот принцип на примере, в котором значению свойства fn будет присвоено значение "Иван Блинков":

<div class="vcard">
  <div class="fn">
    <span class="value">Иван </span>подпрыгнул три раза на месте,
    обернулся и увидел написанную на стене
    свою фамилию: <span class="value">Блинков</span>.
  </div>
</div>

Как не трудно заметить, значение свойства разбавлено массой ненужной информации, но с помощью тэгов с атрибутом class="value" мне удалось выделить лишь важную информацию, не поменяв при этом внешний вид документа. Парсер микроформатов, читая этот документ, соединит обе части и получит в итоге как раз "Иван Блинков", что и будет соответствовать желаемому имени объекта.

Вы заметили в предыдущем примере пробел после моего имени? Он был поставлен для того, чтобы при конкатенации составные части значения не слились в одно слово "ИванБлинков", не самый удобный подход к решению проблемы, но у него есть альтернатива в виде тэга <abbr> (не забываем про упомянутое чуть выше исключение):

<div class="vcard">
  <abbr class="fn" title="Иван Блинков">
    Иван
  </abbr>
  подпрыгнул три раза на месте,
  обернулся и увидел написанную на стене
  свою фамилию: Блинков.
</div>

Общей информации на сегодня хватит, так что перейду к деталям реализации.

Идентификационные свойства

Свойство	Описание
fn	полное имя объекта (formatted name)
n	имя, используется для идентификации составных частей fn (name)
nickname	прозвище
bday	день рождения в формате YYYY-MM-DD (birthday)
photo	фотография

Свойство fn уже успели слегка обсудить, так что перейдем сразу к n. Как уже было сказано, используется он для детализации составных частей полного имени объекта, для чего оно имеет ряд подсвойств, используемых в дочерних элементах:

given-name: – имя.
additional-name: – отчество.
family-name: – фамилия.
honorific-preffix: – какой-либо префикс к имени, отображающий социальный статус человек.
honorific-suffix: – суффикс с тем же смыслом.

Выглядит это все примерно так, ничего сложного:

<div class="vcard">
  <div class="n">
    <span class="given-name">Иван</span>
    <span class="additional-name">Иванович</span>
    <span class="family-name">Блинков</span>
  </div>
</div>

Адресные свойства

Адрес может быть указан в двух формах:

adr - структурированной (с указанием составных частей);
label - не структурированной.

Для структурированного адреса используются подсвойства по аналогии с n:

Свойство	Описание
post-office-box	почтовый адрес
extended-address	полный адрес (с номером подъезда, квартиры и т.д.)
street-address	улица
locality	город
region	регион, штат или провинция
postal-code	индекс
type	тип адреса, то есть то, как он связан с исходным идивидом, должен принимать одно из значений: dom, parcel, home, work, pref

label же используется просто для написания адреса по тому же принципу, как если бы Вы писали его, например, на конверте традиционного письма. Возможно использование подсвойства type как и в adr.

С телекоммуникационными свойствами все проще:

телефон - tel;
адрес электронной почты - email;
почтовый клиент - mailer (не понятно - и зачем он тут сдался?).

Телефонный номер может иметь тип (type):

home - домашний
msg - имеется автоответчик
work - рабочий
pref - предпочтительный
voice - голосовой
fax - факс
cell - мобильный aka сотовый
video - для видеоконференций
pager - пэйджер
bbs - bulletin board system
modem - возможно использование модема
isdn - integrated services digital network
pcs - personal communication service

Географические свойства также не отличаются особой сложностью:

tz - временная зона
long - широта
lat - долгота

С ручным заполнением этих свойств могут возникнуть некоторые проблемы, но при интеграции веб-приложения с сервисом вроде Google Earth - должно быть вполне удобно.

Свойства, описывающие индивида с точки зрения работы, немногочисленны:

title - должность
role - роль
logo - ссылка на логотип компании
agent - указание представителя индивида, например секретаря, например в виде ссылки на его hCard
org - название компании

Дополнительные свойства:

category - категория, то есть чем по сути является данный hCard, например - визитка
note - какие-либо замечания к остальным свойствам
rev - время последнего редактирования hCard, то есть время на которое данная информация является актуальной
sort-string - отмечает какая часть hCard (обычно часть имени), которая будет использована при сортировке списка из нескольких hCard
sound - адрес, указывающий на звуковой файл с правильным произношением имени индивида
url - адрес персонального или корпоративного сайта
uid - уникальный идентификационный номер в каком-либо специфицированном IANA формате (подсвойство type указывает в каком именно)

Для обеспечения ограничения доступа к данным из hCard используется два свойства - class и key. class определяет уровень доступа по примерно тому же принципу, что и в ООП: public или confidentional. А свойство key предоставляет публичный ключ, для расшифровки данных с закрытым доступом.

Хочется добавить, что благодаря своей структурированной архитектуре данный микроформат может использоваться в более широком спектре случаев, чем просто предоставление персональных данных, например, можно описывать и просто организацию или какое-либо место. Те же самые принципы могут быть использованы и при оформление персональных данных в формате XML - достаточно лишь использовать те же самые атрибуты hCard для произвольных тэгов XML.

В заключение хочу сказать, что в качестве источников информации для данной статьи были использованы официальная вики и презентация от Robert Costello, а подписаться на RSS можно вот ТУТ.

Архитектура Digg

Иван Блинков — Tue, 01 Apr 2008 20:49:00 +0400

Трафик, генерируемый более чем 1.2 миллионами пользователей Digg, знаменитых своей жаждой информации, способен загнать любой невинный сайт за рамки его вычислительных ресурсов и пропускной способности канала. Как же сам Digg справляется с такой нагрузкой?

Источники информации

Этот текст - перевод статьи, автор - Todd Hoff.

Платформа

Статистика

Проект стартовал в конце 2004 года на одном сервере под управлением Linux с использованием Apache 1.3, PHP 4 и MySQL 4.0 (со стандартной системой хранения данных - MyISAM).
Более 1.2 миллиона пользователей.
Более 200 миллионов просмотров страниц в месяц.
100 серверов расположены в нескольких датацентрах, из них: – 20 серверов баз данных; – 30 веб-серверов; – несколько поисковых серверов, использующих Lucene; – остальные используются для обеспечения избыточности.
30 GB данных.
Ни одна из проблем, с которыми пришлось столкнуться проекту не была связана с PHP, в основном они касались базы данных.
Легковесная природа PHP позволила переместить вычислительные работы из базы данных в приложение для улучшения производительности.

Что внутри?

Балансировщик нагрузки равномерно распределяет запросы между PHP серверами.
MySQL используется по принципу master-slave: - Сервера, обрабатывающие большое количество транзакций, используют движок InnoDB. - Сервера, выполняющие аналитическую обработку данных в реальном времени, используют MyISAM. - Снижения производительности при переходе с MySQL 4.1 на версию 5 замечено не было.
Для кэширования используется Memcached.
Используется сегментирование баз данных.
Особенности использования Digg существенно облегчают процесс масштабирования. Большинство посетителей просто просматривают главную страницу и уходят. Это приводит к тому, что 98% запросов к базе данных являются операциями чтения. Такое соотношение операций чтения и записи позволяет не беспокоиться о комплексной работе по проектированию операций записи, что позволяет намного проще масштабировать проект.
Возникали проблемы, связанные с системой хранения данных, которые сообщали, что данные уже записаны на диск, когда на самом деле это было не так. Контроллеры делали это для создания впечатления более высокой производительности. Но на практике это приводило лишь к проблемам с целостностью данных. Это достаточно распространенная проблема, которую порой не так уж просто решить, правда все зависит от используемого оборудования.
Для облегчения нагрузки на базы данных используется кэширование и APC PHP Accelerator.
С использованием рабочих потоков Apache2, FastCGI и PHP акселератора возможно избежать необходимости каждый раз заново интерпретировать и компилировать PHP скрипты: скрипт компилируется только при первом обращении, что существенно ускоряет скорость его выполнения при последующих обращениях.

Подводим итоги

Используйте возможность выбора движка для MySQL. Если Вам нужны транзакции - используйте InnoDB, если нет - MyISAM. Например, если на master сервере расположены транзакционные таблицы, то для slave серверов можно использовать и MyISAM.
В определенный момент рост стал невозможен путем добавления дополнительной оперативной памяти, пришлось продолжать рост путем изменения архитектуры.
Люди часто жалуются, что Digg медлителен. Скорее это вызвано их огромными JavaScript библиотеками, чем работой их серверной системы.
Стоит тщательно выбирать какие именно приложения развертывать. Они приложили все усилия, чтобы не использовать приложения, требующие больших вычислительных мощностей. Очевидно, что Digg работает на совершенно стандартной LAMP архитектуре, но тем не менее реализована она достаточно интересно. У инженеров часто возникает желание реализовать какой-либо дополнительный функционал, но всегда стоит иметь ввиду, что они могут разрушить инфраструктуру, если она не сможет расти теми же темпами. Так что с этим стоит повременить до тех пор пока система сможет выдерживать все необходимые нагрузки. Это приводит к планированию ресурсов, особенно большое внимание этому аспекту уделяет Flickr.
Вам остается лишь догадываться, сможет ли Digg удержать свои позиции, если и дальше будет ограничивать добавление новых возможностей, или уступит более активно развивающимся сервисам социальных закладок? Возможно если бы была возможность увеличивать масштабы более простыми методами, более быстрое добавление новых функций и возможностей позволило бы более эффективно конкурировать на этом рынке? С другой стороны, просто добавление новых возможностей может и не поменять ситуацию кардинальным образом.
Основные проблемы с масштабируемостью и производительностью связаны с обработкой данных и в большинстве случаев они не зависят от используемого языка программирования. Вы столкнетесь с ними при работе с Java, PHP, Ruby, или подставьте сюда Ваш любимый язык программирования.

Архитектура Friends for Sale

Иван Блинков — Mon, 17 Mar 2008 21:44:00 +0300

За три коротких месяца Friend for Sale (рейтинговая система в условиях рыночной экономики) попала в десятку лучших приложений Facebook, непринужденно обрабатывая 200 запросов в секунду и демонстрируя шокирующее количество просмотров страниц, за месяц достигающее 300 миллионов просмотров. Все это дело рук двух разработчиков, работающих не полный рабочий день, которые смогли создать успешное веб-приложение, имея в своем распоряжении лишь кластер из дюжины серверов и Ruby on Rails.

Как Friends for Sale масштабируется для того, чтобы обеспечить торговлю всеми этими красивыми людьми? Как Вы думаете, сколько стоят Ваши друзья на открытом рынке?

Источники информации

Традиционная пара фраз, чтобы отдать должное оригиналу и его автору. Продолжаем:

Ответы на стандартный набор вопросов от Siqi Chen и Alexander Le, создателей Friends for Sale;
Virality on Facebook.

Платформа

Ruby on Rails
CentOS (64 bit)
Capistrano - для обновлений и перезапусков серверов
Memcached
MySQL
nginx
Starling - распределенный сервер очередей
Softlayer - хостинг
Pingdom - мониторинг
LVM - Magic Multi-Connections Gem - разделение операций чтения и записи между серверами

Статистика

Это Facebook приложение находится в десятке наиболее популярных;
Около 600 тысяч активных пользователей;
Полмиллиона уникальных посетителей ежедневно, и эта цифра неуклонно растет;
Темпы роста проекта достигают 300% в месяц;
200 запросов в секунду;
5 TB трафика в месяц;
Над проектом работают 2 разработчика и 1 админимтратор баз данных.
4 сервера баз данных, 6 серверов приложений, 1 тестовый сервер и 1 сервер для балансировки нагрузки:
- Каждый из серверов приложений содержит 4 ядра и 8 GB оперативной памяти.
- На каждом из них работает 16 сервисов mongrel (в сумме - 96).
- 4 GB оперативной памяти на каждом из них отведено под memcached.
- Сервера баз данных имеют более серьезное оборудование: при тех же 4-х ядрах, они имеют 32 GB оперативной памяти и RAID 10 массив из четырех 15000rpm SCSI дисков, работающих в режиме "master/slave".

Давайте знакомиться

Для чего нужна ваша система?

Наша система разработана в качестве платформы для нашего Facebook приложения, Friends for Sale. В целом оно представляет собой аналог рейтинговой системы Hot-or-Not с некоторым добавлением рыночной экономики. В момент проведения интервью это приложение было на 10-м месте по популярности среди приложений Facebook.

Описание этого приложения на самом Facebook гласит:

Покупайте и продавайте своих друзей как питомцев! Вы можете научить их толкаться, отправлять подарки или просто представлять Вас в выгодном свете. Зарабатывайте как практичный инвестор в питомцев или как популярный товар!

Почему вы решили построить эту систему?

Мы разработали ее скорее как эксперимент для того, чтобы проверить удалось ли нам понять концепции и измерения вирусного эффекта в рамках Facebook. Мне кажется нам это удалось. :)

С какими конкретными сложными задачами, связанными с дизайном, архитектурой или реализацией системы, вам пришлось столкнуться при построении системы?

Как и в любом Facebook приложении, каждый запрос является динамическим, так что кэширование страниц невозможно. Так как приложение является интерактивным, со множеством операций записи, определенные трудности вызвало масштабирование базы данных.

Каковы были ваши

действия, направленные для решения этих задач?

С самого начала мы активно использовали memcached - для перезагрузки страницы совсем не требуется выполнение SQL запросов. В основном мы использовали кэширование фрагментов Rails с индивидуальной логикой актуальности.

Как вы оцениваете размеры вашей системы?

Вчера статистика показала более полумиллиона уникальных посетителей, и эта цифра неуклонно растет. За этот месяц было зарегистрировано более 300 миллионов просмотров страниц.

Каковы показатели использования пропускной способности интернет-канала?

В прошлом месяце было потрачено 3 терабайта трафика, но в этом месяце ожидается цифра не меньше 5 терабайт. Эти цифры состоят по большей части из XHTML / CSS и нескольких небольших иконок.

Как много документов используется в системе? Сколько изображений? Какой объем данных?

По большому счету у нас нет уникальных документов... но зато у нас есть около 10 миллионов профилей пользователей. Единственными используемыми изображениями являются несколько статических иконок.

Как вы оцениваете темпы роста вашей системы?

Месяц назад за сутки просматривалось около трех миллионов страниц, на данный момент эта цифра достигла 10 миллионов в сутки. Из чего можно сделать вывод, что ориентировочные темпы роста проекта составляют 300% в месяц. Если говорить о ежесекундной нагрузке, то на данный момент она составляет около 200 запросов в секунду.

Какая часть посетителей платит вам за участие в вашем проекте?

Он абсолютно бесплатен для пользователей.

Каковы показатели "текучести" пользователей?

В среднем около 1% в сутки, с ежедневным ростом в 3% от этой цифры, если говорить в терминах новых установок .

Как много учетных записей активно принимали участие в проекте за последний месяц?

По данным Google за последний месяц проект посетил 2.1 миллион уникальных пользоывтелей.

Какова архитектура вашей системы?

Она представляет собой относительно стандартный Rails кластер. В качестве интерфейса между запросами пользователей и серверами приложений используется proxy балансировщик нагрузки, который перенаправляет запросы напрямую шести четырехядерным серверам приложений. На каждом сервере приложений запущено 16 mongrel'ов, что в сумме дает 96. Балансировщик нагрузки перенаправляет запросы напрямую на порты серверов mongrel. В дополнение к этому на каждом сервере приложений выделено 4 GB оперативной памяти под memcached, а также работает локальный сервер распределенного менеджера очередей Starling и несколько менее важных фоновых процессов.

СУБД работает на двух серверах (четыре ядра, 32 GB оперативной памяти, четыре 15000rpm SCSI диска в RAID 10) в режиме "master/slave". Для организации распределения операций чтения и записи между серверами используется Magic Multi-Connections Gem от Dr Nic.

На данный момент ведется работа над добавлением дополнительных серверов, работающих в роли "slave", для обеспечения более эффективного распределения нагрузки, избыточности и политик хранения запасных копий данных. Помимо этого нам помогают Percona (ребята из mysqlperformanceblog) с удаленной работой над архитектурой базы данных.

Нашим хостинг-провайдером является Softlayer - он просто фантастический. Основной проблемой был тот факт, что их балансировщик нагрузки не справлялся со своей задачей ... поначалу у нас возникала масса проблем, связанных с задержками и повисшими соединениями. Переход на отдельный сервер с запущенным только nginx в режиме proxy балансировщика нагрузки позволила решить все проблемы.

Каким образом планируется масштабировать архитектуру вашего проекта?

Каких-то конкретных планов нет. На уровне приложения система не использует какие-либо общие ресурсы, так что все достаточно тривиально. На уровне баз данных на данный момент все еще используется один сервер в роли "master", но мы стараемся отложить неизбежный переход к сегментированной базе данных на как можно более длительный срок. На данный момент базы данных масштабируются вертикально, но со временем, надеюсь, мы сможем от этого избавиться.

Назовите самые интересные уникальные факты о вашем проекте?

Я могу назвать:

Ни один из двух разработчиков ранее не имел опыта в крупномасштабных разработках на основе Rails.
Наша траектория роста проекта достаточно редка в истории разработок с использованием Rails.
У нас практически не было возможностей для кэширования статических страниц - каждый запрос страницы приходилось обрабатывать Rails.

Чему вам удалось научиться? Каков залог вашего успеха? Чего бы вам хотелось сделать по-другому в прошлом, если бы была такая возможность? Что бы вы оставили как есть?

Отличные хостинг, оборудование и архитектура БД являются очень важными факторами. Мы привыкли пользоваться услугами хостинга Railsmachine, который честно говоря является отличным провайдером shared хостинга, но со временем они потеряли возможность выдерживать необходимую нагрузку. В итоге почти месяц мы были едва способны отвечать на запросы браузеров из-за проблем с оборудованием, хотя последующий переход на Softlayer занял всего два часа. Стоит заранее выбирать качественный хостинг, если планируется масштабирование проекта, смена хостинг-провайдера - не очень веселое занятие.

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

Определенно нам нужен был более качественный хостинг намного раньше.

Мы определенно не сменим наш framework - Rails был незаменим при быстрой разработке приложения, нам удалось доказать, что для масштабирования проекта на RoR достаточно двух парней, абсолютно не имеющих опыта в этом.

Кто входит в состав вашей команды?

У нас есть два разработчика, включая меня. Помимо этого недавно мы начали пользоваться услугами помощи с DBA, о которой уже упоминалось.

Сколько всего людей участвует в проекте?

В технической части - два разработчика и один администратор баз данных, работающий на контрактной основе.

Где они расположены с географической точки зрения?

Все участники проекта живут в районе SOMA, San Francisco.

Каковы обязанности каждого из участников проекта?

Оба разработчика проекта по совместительству являются и его создателями. Поначалу я (Siqi) был ответственным за дизайн и разработку пользовательского интерфейса, но так как у меня был некоторый опыт с развертыванием систем я взял на себя и разработку управления сетевыми операциями и развертывания. Мой коллега Alex был ответственным за большую часть Rails кода, вся логика приложения - его рук дело.

На данный момент я по большей части занимаюсь более техническими моментами, такими как оптимизация сетевых операций и работы и репликации MySQL. С трудом получается вернуться к работе над пользовательским интерфейсом - к тому, что мне по-настоящему нравится. Но это был опыт, который явно стоило получить, так что я стараюсь извлекать максимум выгоды из этого занятия.

У вас есть какая-то определенная философия менеджмента?

Да - найти самых умелых и сообразительных людей, сделать им наилучшее возможное предложение и убраться с их пути. Самые лучшие менеджеры должны уметь НЕ МЕШАТЬ работникам, так что я стараюсь максимально этому следовать при работе с другими участниками проекта. Но, к сожалению, мне удается это далеко не всегда.

Если ваша команда работает раздельно, как вам удается координировать свою работу?

Нам стоило бы задуматься об использования каких-либо эффективных средств общения. Мне кажется, что использование удаленной работа / outsourcing'а является по-настоящему сложной задачей - я предпочитаю обходиться без этого в разработке основы системы. Для системного администрирования или разработки архитектуры БД это было бы более оправданно.

Что вы используете для разработки?

Мы используем Rails с несколькими plug-in'ами, самыми важными являются cache-fu от Cris Wanstrath и magic multi connections от Dr Nic. В качестве текстового редактора я предпочитаю vim с плагином rails.vim.

Какие языки программирования используются?

Ruby on Rails

Сколько используется серверов?

На данный момент используется кластер из 12 серверов.

Как они используются?

4 сервера баз данных, 6 серверов приложений, 1 тестовый сервер и 1 сервер для балансировки нагрузки.

Кто их предоставляет?

Мы заказываем их у Softlayer - до подключения их к системе проходит порой менее четырех часов, что очень неплохо.

Какая операционная система используется?

CentOS 5 (64 бит)

Какой http сервер используется?

nginx

Какая СУБД используется?

MySQL 5.1

Вы используете обратную proxy?

Мы просто используем встроенный в nginx proxy балансировщик нагрузки.

Как вы развертываете вышу систему в датацентре?

Мы используем хостинг выделенных серверов, Softlayer.

Какова ваша стратегия хранения данных?

Мы используем резервное копирование NAS помимо внутренних SCSI RAID массивов.

Какой объем дискового пространства вам доступен?

На всех серверах в сумме около 5 TB.

Как вы наращиваете объем дискового пространства?

Спонтанно. Мы еще не выполнили каких-либо исследований в планировании дискового пространство, но это было явно зря не сделано.

Вы используйте какой-либо сервис хранения информации?

Нет.

Вы используете виртуализацию хранимых данных?

Нет.

Как организована работа с сессиями?

На данный момент она поручена СУБД, но передача их обслуживания напрямую memcached - достаточно несложная задача.

Как организована архитектура вашей БД?

На данный момент - "master/slave". Мы осуществляем переход к нескольким "slave" с proxy балансировщиком нагрузки для режима "только для чтения".

Как организована балансировка нагрузки?

На программном уровне средствами nginx.

Какой framework / AJAX библиотеку вы используете?

Rails.

Какие средства распределенного управления задачами вы используете?

Starling

Как вы управляете рекламой в проекте?

Мы участвуем в нескольких рекламных сетях. Мы оцениваем эффективность каждой рекламной сети с помощью eCPM на уровне приложения.

Имеете ли вы стандартную API на вашем сайте?

Нет.

Сколько человек в вашей команде?

2 разработчика.

Какими наборами способностей обладают участники вашей команды?

Я: дизайн пользовательского интерфейса, разработка, ограниченные знания в Rails, оптимизация MySQL, развертывание Rails.

Alex: разработка логики приложения, дизайн пользовательского интерфейса, программная инженерия в целом.

Какие средства разработки вы используете?

Alex работает в OS X, а я предпочитаю Ubuntu. Для контроля за версиями используется SVN. В качестве текстового редактора я использую VIM, а Alex - TextMate.

Как проходит процесс разработки?

На логическом уровне все упирается в тесты, мы проводим их достаточно экстенсивно. На уровне приложения все ограничивается быстрыми итерациями и не менее быстры тестированием.

Какова ваша стратегия кэширования объектов и контента?

Мы используем memcached без TTL и просто вручную очищаем кэш при необходимости.

Как происходит кэширование на клиентской стороне?

Никак.

Как вы проверяете глобальную доступность и моделируете производительность для конечных пользователей?

Мы используем Pingdom для внешнего мониторинга за сайтом - они отлично справляются.

Как вы проверяете работоспособность ваших серверов и сетей?

На данный момент мы полагаемся на внешний мониторинг и ping мониторинг от Softlayer. В перспективе мы рассматриваем FiveRuns как возможное решение для мониторинга серверов.

Как вы строите на графиках или диаграммах сетевую и серверную статистику, а также тенденции?

Мы не занимаемся этим.

Как вы тестируете систему?

Сначала мы разворачиваем ее на тестовом сервере и проводим несколько тестов, после чего разворачиваем систему уже на серверах приложений.

Как вы анализируете производительность?

Мы отслеживаем каждый SQL-запрос в процессе разработки, это позволяет нам убедиться, что не выполняются никакие ненужные запросы или создание экземпляра модели. Помимо этого мы не выполняем каких-либо тестов на производительность.

Как вы обеспечиваете безопасность?

Тщательно.

Как вы решаете какие возможности добавить или оставить?

Решения основываются на отзывах пользователей и критическом взгляде на них. Мы верим в простоту, так что нам приходится как следует все взвесить перед добавлением каких-либо существенных возможностей.

Как вы реализуете веб-аналитику?

Мы используем собственную систему оценок для оптимизации вирусного эффекта, но помимо этого пользуемся и услугами Google Analytics.

Используете ли вы A/B тестирование?

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

Как вы выполняете резервное копирование и восстановление?

Мы используем LVM для создания ежедневных и еженедельных инкрементальных резервных копий.

Как выполняются обновления оборудования и программного обеспечения?

На данный момент мы делаем это вручную, за исключением развертывания Rails приложения. Для обновления и перезапуска серверов приложений мы используем Capistrano.

Как вы выполняете глобальные изменения в структуре базы данных при обновлениях?

Обычно мы начинаем переход с второстепенных серверах баз данных, а затем просто переключаем основные.

Каковы ваши планы насчет защиты от сбоев и развития бизнеса?

Не самым лучшим образом...

Есть ли у вас отдельная операционная команда, работающая над сайтом?

Было бы неплохо, но нет :)

Используете ли вы CDN? Если да, то какую и для каких целей?

Нет.

Как выглядит модель ваших доходов?

CPM: больше просмотров страниц - больше денег. Помимо этого у нас бывают прямые поощрительные предложения через нашу виртуальную валюту.

Как вы продвигаете ваш продукт?

Это же социальная сеть. Мы просто используем вирусный эффект для поддержания роста проекта.

Используете ли вы какие-либо особенно интересные технологии или алгоритмы?

Я думаю Ruby запросто мог бы подойти под это определение, но на самом деле нет - мы не проводим научных исследований, мы просто стараемся быть полезными для посетителей.

Храните ли вы изображения в базе данных?

Нет, это бы была не самая лучшая идея.

Как много работы над организацией взаимодействия с пользователями приходится выполнять?

Я бы сказал, что никакой, если вам не приходилось раньше масштабировать что-либо, и достаточно много, если приходилось. Достаточно сложно сказать что именно станет проблемой до тех пор, пока на самом деле с ними не столкнешься. Как только ты пройдешь через это, у тебя будет достаточно знаний, чтобы осознанно проводить какую-либо работу в этом направлении.

Приходилось ли вам сталкиваться с какими-либо сюрпризами, положительными или отрицательными?

Было удивительно, насколько ненадежным может оказаться поставщик оборудования, и как может отличаться уровень технической поддержки одного хостинг-провайдера по сравнению с другим. Одной из основных вещей, которая вам понадобится при масштабировании системы - хостинг, способный поддерживать ваши потребности.

С другой стороны, было удивительно насколько далеко смогла наз завести архитектура с одним "master" и несколькими "slave" на самом обыкновенном оборудовании. Я думаю, что даже миллиард просмотров страниц в месяц достижим при таком подходе к базе данных.

Как ваша система эволюционирует для соответствия новым требованиям к масштабируемости?

По большому счету она этого не делает, мы просто исправляем узкие места в системе и смотрим что же будет дальше.

Кем вы восхищаетесь?

Brad Fitzpatrick за изобретение memcache, а также каждым, кому успешно удалось горизонтально масштабировать свой проект.

Каковы ваши планы по изменению архитектуры в будущем?

Скоро предется переходить к сегментированной по пользователям базе данных, так как скоро мы достигнем пределов базы данных по операциям записи и размерам.

Их мысли о вирусном эффекте Facebook

Facebook моделирует социальную сеть в цифровой форме максимально точно и полно, по крайней мере насколько это возможно.
Построение социальной сети более важно, чем возможности, предоставляемые пользователям.
Facebook позволяет быстро распространять новые приложения через социальную сеть.
Идея вашего приложения должна быть социальной, затягивающей и универсальной.
Социальный аспект является основой вирусного эффекта.
"Затягивание" пользователей позволяет зарабатывать на нем.
Универсальность дает необходимый потенциал.
Friends for Sale - социальный проект, так как предоставляет возможность торговать своей частью социального графа.
Он затягивает, так как в основе лежит в какой-то степени сумасшедшая идея, ненавязчивая, слегка флиртующая, и немного циничная.
Он универсальный, так как все люди в какой-то степени самовлюбленны, знают себе цену, и хотят флиртовать с "горячими" людьми.
Каждая часть приложения является потенциальной для вовлечения новых пользователей.
Каждый пользователь в среднем приводит 1.4 новых, что является залогом экспонентациального роста.
Для каждого нового пользователя отслеживается количество приглашений, нотификаций, записей на "стене", кликов в профиле и других факторов.
Для каждого канала поступления новых пользователей вычисляются проценты нажавших, успешно вовлеченных и выходов из проекта.

Подводим итоги

На Facebook требуется масштабирование с самого начала. Дорога до миллиона просмотров страниц в сутки заняла 4 недели.
Ruby on Rails может масштабироваться.
При правильном подходе к архитектуре может масштабироваться практически все что угодно, сосредоточтесь на этом.
Вам определенно нужна продуманная архитектура базы данных, качественный хостинг, а также правильно настроенное оборудование.
С использованием кэширования и современных серверов, может пройти достаточно длительный период времени до тех пор, пока понадобится использование баз данных с более сложной структурой, такой как сегментирование.
Социальная сеть - это реальность. Количество новых пользователей в хорошо реализованном Facebook приложении на самом деле ошеломляет.
Большая часть проблем с производительностью в итоге сводится к базе данных. Лишний раз обратите внимание на конфигурацию СУБД, запросы и использование индексов.
Люди до сих пор пользуются Vi!

Архитектура YouTube

Иван Блинков — Sat, 01 Mar 2008 16:07:00 +0300

Рост YouTube был феноменально быстр, количество просмотров видео превысило 100 миллионов в сутки при том, что только около пяти человек работало над масштабированием проекта. Как им удается управлять предоставлением всех этих видеороликов своим посетителям? Как они развивались с тех пор, как были приобретены Google?

Платформа

Apache
Python
Linux (SuSe)
MySQL
psyco, динамический компилятор Python → C
lighttpd для видео

Что внутри?

Статистика

Поддержка обработки более 100 миллионов видеороликов в сутки
Сервис был запущен в феврале 2005 года
В марте 2006 года в среднем производилось около 30 миллионов просмотров видео в день
К июлю 2006 года эта цифра достигла 100 миллионов просмотров в день
Над проектом работают: 2 системных администратора, 2 архитектора масштабируемости программного обеспечения, 2 разработчика новых возможностей, 2 инженера по сетям, 1 архитектор баз данных

Рецепт управления огромными темпами роста

while (true)
{
   identify_and_fix_bottlenecks();
   drink();
   sleep();
   notice_new_bottleneck();
}

Этот цикл проходит далеко не одну итерацию ежедневно.

Веб-серверы

NetScalar используется для балансировки нагрузки и кэширования статического контента.
Apache работает с включенным mod_fast_cgi
Запросы отправляются на обработку с помощью серверного приложения на Python.
Приложение взаимодействует с различными базами данных и другими источниками информации для формирования финальной HTML-страницы.
Масштабирование обычно происходит просто добавлением дополнительных компьютеров.
Код на Python обычно не является узким местом системы, он проводит большую часть времени заблокированным RPC.
Python предоставляет быстроту и гибкость в процессе разработки и развертывания. Этот факт является очень актуальным, если учесть кто является их конкурентами.
На формирование страницы обычно уходит не более 100 миллисекунд.
psyco, динамический компилятор Python → C, использует JIT подход к компилированию для оптимизации внутренних циклов
Для интенсивных вычислений, таких как шифрование, используются расширения, написанные на C.
Какая-то часть заранее сгенерированного HTML хранится в кэше.
Кэширование данных в СУБД на уровне строк.
Кэшируются полностью сформированные объекты Python.
Некие данные вычисляются и отправляется каждому серверу для кэширования в локальной оперативной памяти. Эта стратегия годится далеко не всегда, чаще всего более эффективен другой метод: самым быстрым кэшем является само серверное приложение, а отправка уже готовых данных остальным серверам для дальнейшей обработки обычно не занимает так много времени. Для организации такого подхода необходимы агенты, осуществляющие отслеживание изменений, предварительную обработку и отправку данных.

Управление видео

Издержки включают в себя затраты на пропускную способность каналов связи, приобретение нового оборудования и оплату огромных счетов за электроэнергию.
Каждый видеоролик расположен на мини-кластере, что означает управление работой с ним группой из нескольких компьютеров.
Использование кластеров влечет за собой: – увеличение производительности пропорционально количеству дисков, на которых расположен контент; – возможность поддержания функционирования всей системы даже в случае прекращения работоспособности части компьютеров; – возможность организации создания резервных копий online.
В роли HTTP-сервера для работы с видео используется lighttpd: – Он способен дать фору Apache в плане производительности предоставления статического контента; – Для работы с событиями ввода-вывода используется epoll; – Многопоточная конфигурация способна обрабатывать большее количество соединений одновременно;
Самая популярная часть контента размещается в CDN – CDN реплицирует весь контент в разных частях системы; – Компьютеры CDN в основном предоставляют данные напрямую из кэша в оперативной памяти, так как ассортимент популярного видео с течением времени меняется достаточно медленно.
Менее популярный контент, количество просмотров в день которого варьируется в диапазоне от одного до двадцати, обычно размещается на серверах YouTube, расположенных в датацентрах на colocation: – Не смотря на тот факт, что такое видео может быть просмотрено всего несколько раз за день, количество таких роликов велико, что приводит к случайным блокировкам данных на жестких дисках; – В такой ситуации кэширование практически бесполезно, инвестиции в кэширование контента с низкой вероятностью востребованности обычно является пустой тратой средств; – Более детальная настройка низкоуровневых компонентов системы, таких как, например, RAID-контроллеры, в этой ситуации может достаточно положительно повлиять на производительность; – Выбор оптимального размера оперативной памяти на каждой машине также очень важен: как недостаточное, так и излишнее ее количество не являются эффективными решениями.

Ключевые моменты

Чем проще - тем лучше;
Старайтесь минимизировать количество устройств (маршрутизаторов, коммутаторов и тому подобных) между контентом и пользователями: далеко не факт, что все они будут способны выдерживать интенсивную нагрузку;
Старайтесь использовать самое обыкновенное оборудование. Hi-end оборудование обычно влечет за собой рост издержек, связанных с сопутствующими процессами, например технической поддержкой, а также уменьшает вероятность нахождение решения той или иной проблемы с оборудованием в Сети;
Используйте самые простые распространенные утилиты. YouTube использует идущий в комплекте с Linux набор утилит для построения системы именно на их основе;
Не забывайте о случайных доступах к жестким дискам, эту, казалось бы, мелочь тоже стоит настроить.

Управление миниатюрами видео

На удивление сложно решаемая задача, особенно если необходима эффективность;
Для каждого видео хранится 4 миниатюры, что приводит к существенному преобладанию количества миниатюр над количеством видеороликов;
Миниатюры хранятся всего на нескольких компьютерах;
Некоторые проблемы наблюдаются в связи с работой с большим количеством маленьких объектов: – Проблемы на уровне операционной системы, связанные с большим количеством запросов на поиск данных, а также кэшем страниц и inode'ов файловой системы; – Ограничение на количество файлов в одной директории (особенно актуально для ext3), возможно частичное решение в виде перехода к более иерархической структуре хранения данных, а также переходе к ядру Linux версии 2.6, что может привести к более чем стократному росту производительности, но в любом случае хранение такого огромного количества файлов в локальной файловой системе - не самая лучшая идея; – Большое количество запросов в секунду, так как одна страница может содержать до 60 миниатюр различных видеороликов; – В условиях таких нагрузок Apache показывает плохую производительность; – Проводились эксперименты с использованием squid (обратной proxy) между Apache и посетителями. Какое-то время такой вариант казался работоспособным, но с ростом нагрузки производительность начала падать. С обработки 300 запросов в секунду она упала до 20; – Попытки использовать lighttpd также не завершились успехом: однопоточный режим не справлялся с задачей, а многопоточный требовал отдельного кэша для каждого потока, что сводило на нет его эффективность; – С таким количеством изображений добавление в систему нового компьютера могло занимать более 24 часов; – Перезагрузка занимала 6-10 часов, так как кэш должен был "разогреться" прежде чем перестать использовать данные с жестких дисков.
Решением всех описанных выше проблем стала распределенная система хранения данных BigTable от Google: – Она позволяет избежать проблем, связанных с большим количеством файлов, так как объединяет маленькие файлы вместе. – Она работает быстро и устойчива к сбоям, помимо этого она прекрасно приспособлена для работы по ненадежной сети. – Уменьшает задержки, так как использует распределенный многоуровневый кэш, который способен работать даже между удаленными датацентрами.

Базы данных

Раньше: – MySQL использовалась для хранения данных: пользователей, тэгов, описаний и так далее. – Данные хранились на монолитном RAID 10 массиве, состоящем из 10 жестких дисков; – Оборудование арендовалось, что негативно сказывалось на состоянии их кредитных карточек. В случае необходимости нового оборудования, на оформление заказа и доставку мог уходить далеко не один день. – Они прошли через весь путь эволюции: сначала был один сервер, затем добавилось несколько дополнительных серверов, обслуживающих операции чтения, после чего они решили разбить базу данных на части, и, наконец, они пришли к полноценной распределенной архитектуре. – Поначалу их система страдала от задержек, связанных с реплицированием. Основной сервер, обрабатывающий операции записи, являлся мощным сервером, работающим в многопоточном режиме, это было необходимо для своевременного выполнения большого объема работы. Второстепенные сервера, которые обрабатывали только операции чтения, асинхронно реплицировали данные в одном потоке, что влекло за собой возможность серьезного отставания некоторых из них. – Обновления были причиной частого отсутствия необходимой информации в кэше, что заставляло сервера читать данные с жестких дисков. Этот факт сильно замедлял процесс чтения и репликации. – Реплицирующая архитектура требует немалых вложений в оборудование, необходимого для поддержания постоянно растущих темпов записи информации. – Основным из кардинальных решений, принятых в архитектуре системы было отделение обеспечения процесса просмотра видео от основного кластера. Основной целью посетителей является просмотр видео, а второстепенные задачи можно возложить и на менее производительный кластер.
Сейчас: – Используются распределенные базы данных; – Сегментированная система (прим.: по аналогии с Flickr); – Распределенные чтение и запись; – Более эффективное расположение кэша, что ведет к уменьшению работы с жесткими дисками; – Такая архитектура привела к 30%-й экономии на оборудовании; – Задержки в реплицировании сведены к нулю; – Размеры базы данных могут расти практически неограниченно

Стратегия размещения в датацентрах

Поначалу использовались хостинг провайдеры, предоставляющие услуги colocation. Не самый экономичный подход, но тогда не было другого выхода.
Хостинг провайдеры не могут поспеть за темпами роста проекта. Не всегда получается получить контроль над необходимым оборудованием или сделать необходимые соглашения о предоставлению сетевых услуг.
Решением этой проблемы стало создание собственной базы для размещения оборудования. Появилась возможность настраивать абсолютно все и подписывать свои собственные контракты такого рода.
Было использовано 5 или 6 разных датацентров в дополнение к CDN.
Видео поступает из случайного датацентра, никаких специальных проверок не проводится. Если ролик становится достаточно популярным - он перемещается в CDN.
Основным фактором, влияющим на доступность того или иного ролика является пропускная способность канала связи.
Для изображений же более актуальны задержки, особенно если на одной страницы должно быть размещено под 60 изображений.
Репликация изображений производится средствами BigTable. В этом случае используются различные меры для определения ближайшего места, откуда можно получить необходимые данные.

Подводим итоги

Остановитесь на секунду. Креативные и рискованные трюки могут помочь справиться с задачей в краткосрочном периоде, но со временем понадобятся более продуманные решения.
Расставьте приоритеты. Определите какие части Вашего сервиса являются более важными и стройте систему обеспечения ресурсами и усилиями именно в соответствии с поставленными приоритетами.
Выбирайте свои битвы. Не бойтесь пользоваться аутсорсингом в некоторых ключевых сервисах. YouTube использует CDN для распределения своего наиболее популярного контента. Создание своей собственной подобной сети стоило бы им слишком много и потребовало бы слишком много времени. Возможно у Вас появятся подобные возможности в отношении Вашей системы.
Будьте проще! Простота позволяет изменять архитектуру более быстро, что позволяет своевременно реагировать на возникающие проблемы. Никто на самом деле не знает что такое простота, но если Вы не боитесь делать изменения, то это неплохой знак что вашей системе свойственна та самая простота.
Сегментирование. Сегментирование позволяет изолировать и ограничить дисковое пространство, процессорное время, оперативную память и ввод-вывод. Оно выполняется не только для повышения производительности операций записи.
Постоянная работа над поиском и устранением узких мест в системе: – на программном уровне это чаще всего бывает кэширование и работа с СУБД; – на уровне операционной системы - операции ввода-вывода; – на уровне оборудования - оперативная память и RAID массивы.
Залог Вашего успеха - командная работа. Хорошая команда разного рода специалистов должна понимать принцип системы вцелом и того, что лежит под ней. Каждый должен знать свое дело: настраивать принтеры, подключать к системе новые компьютеры, строить сети и так далее. С отличной командой Вам по силам все что угодно.

Источники информации

В отличии от остальных, этот перевод статьи от Todd Hoff'а уже был выполнен до меня (при желании можно найти в любой поисковой системе), но я все равно решил опубликовать свою версию просто для собственного развития и полноты коллекции, да и многим читателям, возможно, покажется интересным. Что ж, перейдем к источнику информации оригинала:

Google Video

Отношения online

Иван Блинков — Sat, 16 Feb 2008 13:07:00 +0300

Допустим, у Вас появилось желание оставить на своем интернет-ресурсе ссылку на сайт своего старого друга. Объяснить этот факт простому читателю достаточно просто: <a href="www.site.ru">Сайт моего друга</a>, но поймет ли такую надпись очередной раз инспектирующий Ваш сайт crawler какой-нибудь поисковой системы? Может быть Вы просто злостно торгуете ссылками со своего сайта? Как Вы могли уже догадаться, для решения этой достаточно узкоспециализированной задачи - выражение отношений с владельцем сайта, на который указывает ссылка - существует специальный микроформат под названием XFN, что расшифровывается как XHTML Friends Network. С его помощью любой человек, у которого есть сайт может продемонстрировать всем желающим в каких отношениях он находится с владельцем сайта, на который он ссылается.

Реализуется этот микроформат с помощью атрибута rel тэга <a>, возможные варианты значения (имеется возможность их комбинировать):

Категории значений	Значения XFN
дружба:	`friend`(кто-либо, кого Вы считаете другом), `acquaintance` (знакомый, просто пару раз здоровались или недолго общались), `contact` (кто-либо, с кем Вы знаете как связаться в случае необходимости)
физические:	`met` (кто-либо, с кем вы когда-то лично встречались)
профессиональные:	`co-worker` (коллега по работе),`colleague` (коллега по учебе или иной форме активности)
географические:	`co-resident` (живете на одной улице),`neighbor` (сосед)
семейные:	`child` (ребенок, в том числе и приемный),`parent` (родители, в том числе и приемные),`sibling` (все братья и сетры),`spouse` (муж/жена), `kin` (дальний родственник)
романтические:	`muse` (муза, источник вдохновения), `crush` (кто-либо, к кому у Вас страстное увлечение), `date` (кто-либо, с кем Вы встречаетесь), `sweetheart` (кто-либо, в кого Вы влюбились"}
личность:	`me` (ссылка на самого себя на другом сайте. Обязательно должна быть симметрична; отношение 'me' неявно подразумевается между поддиректорией и всем ее содержимым)

Как не трудно заметить, практически все возможные варианты отношений могут быть описаны одним из значений или их комбинацией. Наш пример из начала этого поста с использованием XFN выглядел бы:

<a href="www.site.ru" rel="friend met">
    Сайт моего друга
</a>

Помимо этого есть еще один маленький нюанс, необходимый для того, чтобы browser'ы и поисковые системы знали, что данная страница оффциально поддерживает этот микроформат, для этого необходимо указать следующий атрибут тэгу <head>:

<head profile="http://gmpg.org/xfn/11">

Этот пост был написан по мотивам официального сайта XFN, если Вас заинтересовал этот микроформат, возможно имеет смысл посетить и его: там можно найти FAQ, утилиты для автоматической генерации кода, а также всю остальную информацию по данному микроформату (на английском естественно).

Архитектура Flickr

Иван Блинков — Fri, 08 Feb 2008 22:41:00 +0300

Flickr является мировым лидером среди сайтов размещения фотографий. Перед Flickr стоит впечатляющая задача, они должны контролировать обширное море ежесекундно обновляющегося контента, непрерывно пополняющиеся легионы пользователей, постоянный поток новых предоставляемых пользователям возможностей, а делается все это при постоянной поддержке отличной производительности. Как же они это делают?

Источники информации

Как и предыдущий пост "Архитектура Google", этот тоже является переводом статьи от Todd'а Hoff'а. Возможно читателям Google был более интересен, но подход Flickr к масштабируемости тоже более чем заслуживает внимания. Далее привожу источники информации из оригинальной статьи:

Flickr и PHP (ранний документ)
Планирование нагрузок на LAMP
Федерация Flickr: Тур по архитектуре Flickr
Построение масштабируемых веб-сайтов от Call Handerson'а из Flickr
История войн баз данных #3: Tim O'Reilly о Flickr
Cal Henderson's Talks - много полезных презентаций

Платформа

PHP
MySQL
Сегментирование (прим.: разбиение системы на части, обслуживающие каждая свою группу пользователей; называть можно было по-разному, но давайте остановимся на этом варианте перевода слова "Shards")
Memcached для кэширования
Squid в качестве обратной-прокси для html и изображений
Linux (RedHat)
Smarty в роли шаблонизатора
Perl
PEAR для парсинга e-mail и XML
ImageMagick для обработки изображений
Java для узлового сервиса
Apache
SystemImager для развертывания систем
Ganglia для мониторинга распределенных систем
Subcon хранит важные системные конфигурационные файлы в SVN-репозитории для легкого развертывания на машины в кластере.
Cvsup для распространения и обновления коллекций файлов по сети

Статистика

Более четырех миллиардов запросов в день
Примерно 35 миллионов фотографий в кэше Squid
Около двух миллионов фотографий в оперативной памяти Squid
Всего приблизительно 470 миллионов изображений, каждое представлено в 4 или 5 размерах
38 тысяч запросов к memcached (12 миллионов объектов)
2 петабайта дискового пространства
Более 400000 фотографий добавляются ежедневно

Архитектура

Симпатичное изображение архитектуры Flickr можно увидеть на этом слайде. Краткое ее описание выглядит следующим образом:

Два ServerIron
Squid кэши
Системы хранения NetApp
Серверы PHP приложений
Менеджер хранения данных
Master-master сегменты
Центральная база данных, структурированная по принципу Dual Tree
Memcached кластер
Поисковая система

Хранение данных

Структура Dual Tree является индивидуальным набором модификаций для MySQL, позволяющим масштабировать систему путем добавления новых мастер-серверов без использования кольцевой архитектуры. Эта система позволяет экономить на масштабировании, так как варианты мастер-мастер требовали бы удвоенных вложений в оборудование.
Центральная база данных включает в себя таблицу пользователей, состоящую из основных ключей пользователей (несколько уникальных идентификационных номеров) и указатель на сегмент, на котором может быть найдена остальная информация о конкретном пользователе.
Использование выделенных серверов для статического контента
Все, за исключением фотографий, хранится в базе данных
Отсутствие состояний заключается в том, что в случае необходимости они имеют возможность передать пользователей от сервера к серверу, что стало намного проще для них после создания своего API
В основе масштабируемости лежит репликация, но этот факт помогает лишь при обработке операций чтения
Для поиска по определенной части базы данных создается отдельная копия этого фрагмента
Использования горизонтального масштабирования для того чтобы можно было проще добавлять новые машины в систему
Обработка изображений, полученных от пользователей по электронной почте, происходит с помощью PHP
Раньше система страдала от задержек связанных с организацией по принципу мастер-слуга. При слишком большой нагрузке они имели одну точку, которая теоретически могла дать сбой.
Им было необходимо иметь возможность проводить технические работы во время непрерывной работы сайта, не прекращая его функционирование.
Были проведены отличные работы по планированию распределения дискового пространства, более подробную информацию можно найти по ссылкам в разделе "Источники информации".
Для обеспечения возможности масштабирования в будущем, они пошли по федеративному пути развития:
- Сегменты системы: Мои данные хранятся на моем сегменте, но запись о Вашем комментарии хранится на Вашем сегменте.
- Глобальное кольцо: Принцип работы схож с DNS, Вам необходимо знать куда Вы хотите пойти и кто контролирует то место, куда Вы собираетесь пойти.
- Логика на PHP устанавливает соединение с сегментом и поддерживает целостность данных (10 строк кода с комментариями!)
Сегменты:
- Срез основной базы данных
- Активная репликация по принципу мастер-мастер: имеет несколько недостатков в MySQL 4.1. Автоматическое инкрементирование идентификационных номеров используется для поддержания системы в режиме одновременной активности обоих серверов в паре
- Привязывание новых учетных записей к сегментам системы происходит случайным образом
- Миграция пользователей проводится время от времени для того, чтобы избавиться от проблем, связанных с излишне активными пользователями. Необходима сбалансированность в этом процессе, особенно в случаях с большим количеством фотографий… 192 тысячи фотографий, 700 тысяч тэгов, может занять несколько минут. Миграция выполняется вручную.
Нажатие на Favorite:
- Получается информация об учетной записи владельца из кэша для того, чтобы узнать к какому сегменту он привязан (допустим на shard-5)
- Получается информация о моей учетной записи из кэша, более конкретно - мой сегмент (например shard-13)
- Начинается "распределенная транзакция" для определения ответов на вопросы: Кто добавил эту фотографию в избранное? Как изменился список избранных фотографий?
Подобные вопросы могут задаваться любому сегменту, информация на них абсолютно избыточна.
Для избавления от задержек, связанных с репликацией...
- при каждой загрузке страницы, пользователю предоставляется список серверов
- если сервер не в состоянии ответить на запрос, запрос переходит к следующему серверу в списке; если список кончился - выводится сообщение об ошибке. При этом не используются постоянные соединения, каждый раз создаются и разрываются новые соединения.
Запросы на чтение и запись от каждого пользователя ограничиваются рамками одного сегмента. Задержки репликации исчезают из поля зрения пользователей.
Каждый сервер в рамках одного сегмента в обычном состоянии нагружен ровно на половину. Выключите половину серверов в каждом сегменте и система продолжит функционировать без изменений. Это значит, что один сервер внутри сегмента может взять на себя всю нагрузку второго, в то время как второй сервер может по каким либо причинам быть отключен от системы, например для проведения технических работ. Обновление оборудования производится очень просто: отключается половина сегмента, она же обновляется, подключается обратно, процесс повторяется для оставшейся половины.
Периоды пиковой нагрузки также нарушают правило 50% нагрузки. В такие моменты система получает 6-7 тысяч запросов в секунду, в то время как на данный момент система может работать на пятидесятипроцентном уровне нагрузки только при четырех тысячах запросов в секунду.
В среднем при загрузке одной страницы выполняется 27-35 SQL-запросов. Списки избранных фотографий обрабатываются в реальном времени, ровно как и доступ через API к базе данных. Все требования к нагрузке в реальном времени выполняются без каких-либо недостатков.
Более 36 тысяч запросов в секунду может выполняться не выходя за рамки возможностей системы, даже при резком росте трафика.
Каждый сегмент содержит данные о более чем 400 тысячах пользователей.
Многие данные хранятся в двух местах одновременно. Например, комментарий является частью между комментатором и автором комментируемого контента. Где его хранить? Как насчет обоих мест? Транзакции используются для предотвращения рассинхронизации данных: открывается первая транзакция, выполняется запись, открывается вторая транзакция, выполняется запись, подтверждается первая транзакция если все нормально, после чего вторая подтверждается только в случае если первая прошла успешно.

Поиск

Используется два варианта поиска: поиск в рамках сегмента, поддерживающий до 35 тысяч запросов в секунду, а также проприетарный веб-поиск от Yahoo!
В 90% случаев используется система от Yahoo!, за исключением поиска по тэгу фотографий одного пользователя и массовых изменений тэгов.
Эту систему стоит рассматривать как аналог Lucene.

Оборудование

EMT64 под управлением RHEL 4 с 16 Gb оперативной памяти.
6 жестких дисков с 15000rpm, объединены в RAID-10.
Размер для пользовательских метаданных достигает 12 терабайт (это не включает фотографии, для них цифры существенно больше).
Используются 2U корпуса.

Резервное копирование данных

ibbackup выполняется регулярно посредством cron daemon'а, на каждом сегменте настроен на разное время.
Каждую ночь делается снимок со всего кластера баз данных.
Запись или удаление нескольких больших файлов с резервными копиями одновременно на реплицирующую систему хранения может сильно сократить производительность системы вцелом на последующие несколько часов из-за процесса репликации. Выполнение этого на активно работающей системе хранения фотографий было бы не самой лучшей идеей.
Содержание нескольких резервных копий всех Ваших данных требует существенных материальных затрат, но оно того стоит. Особенно это актуально для тех ситуаций, когда Вы понимаете, что что-то пошло не так только спустя несколько дней после того как это случилось, в таких случаях неплохо иметь, например, резервные копии 1, 3, 10 и 30-дневной давности.
Фотографии хранятся в системе хранения данных. После загрузки изображения система выдает различные его размеры, на чем ее работа заканчивается. Метаданные и ссылки на файловые системы, где расположены фотографии, хранятся в базе данных.
Агрегация данных проходит очень быстро, так как она ограничена пределами сегмента.
max_connections = 400 соединений на каждый сегмент, неплохой запас. Значение для кэша потоков установлено равным 45, так как не бывает ситуаций когда более 45 пользователей одновременно выполняют какие-либо действия с одним конкретным сегментом.

Тэги

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

Направления для развития

Ускорение работы с помощью создания организационного плана для непрерывной работы всей системы на уровне нескольких датацентров, таким образом чтобы все датацентры имели возможность получать запросы на общий уровень данных (как сами БД, так и memcache и прочее) все вместе одновременно. Если все части системы постоянно активны - время простоя оборудования будет сведено к минимуму.

Подводим итоги

Старайтесь думать о своем приложении как о чем-то большем, чем просто веб-приложении, тогда у Вас возможно появятся поддержка различных API, RSS и Atom ленты и многие другие возможности.
Отсутствие состояний системы позволяет более легко выполнять модернизации не моргнув и глазом.
Реструктуризация базы данных - не самое лучшее занятие.
Планирование нагрузок должно проводиться уже на ранних этапах развития проекта
Начинайте медленно. Не покупайте сразу много оборудования просто из-за того, что Вы рады/боитесь, что ваш сайт взорвется.
Измеряйте реально, планирование нагрузок должно базироваться на реальных вещах, а не абстрактных.
Внедряйте ведение логов и индивидуальные измерения для оценки реальных показателей на основе серверной статистики, статистика использования не менее важна чем серверная.
Кэширование и оперативная память может стать ответом на все вопросы.
Создавайте четкие уровни абстракции между работой базы данных, бизнес-логикой, логикой страниц, разметкой страниц и презентационным уровнем. Это позволяет ускорить циклы итеративной разработки.
Разделение приложения на уровни позволяет каждому заниматься своим делом: разработчики могут строить логику страниц, в то время как дизайнеры работают с удобством работы для пользователей.
Делайте релизы как можно чаще, пускай даже это будет происходить каждые полчаса.
Забудьте о всех небольших эффективных вещах, предварительная оптимизация является корнем всего зла в примерно 97% всех случаев.
Тестируйте в работе. Постройте архитектурные механизмы (флаги конфигурации, балансировку нагрузки, и так далее), которые позволят Вам разворачивать новое оборудование в (и из) работу.
Забудьте об искусственных тестах, они годятся только для получения общего представления о нагрузках, но не для планирования. Искуственные тесты дают искусственные результаты, для настоящих тестов все же стоит пользоваться реальным временем выполнения задач.
Найдите максимальное значения для всех показателей:
- Какой максимум чего-то, что может выполнять каждый сервер?
- Как близко параметр находится к максимуму и каковы тенденции?
- MySQL (дисковый ввод/вывод?)
- Squid (дисковый ввод/вывод? или процессорное время?)
- Memcached (процессорное время? или пропускная способность?)
Старайтесь учесть особенности использования Вашего приложения.
- Возможен ли резкий рост нагрузки, связанный с каким-либо событием? Например: какое-либо бедствие, или может быть новость?
- Flickr получает на 20-40% больше новых фотографий в первый рабочий день нового года, чем в любой пик в предыдущем году.
- По воскресеньям нагрузка в среднем на 40-50% выше, чем в любой другой день недели.
Учтите возможность экспоненциального роста. Больше пользователей означает больше контента, больше контента означает больше соединений, больше соединений означает более активное использование.
Планируйте возможные варианты управления работой системы в периоды пиковых нагрузок.

На пути к идеалу

Иван Блинков — Thu, 07 Feb 2008 15:39:00 +0300

...или 15 привычек, которые помогут ускорить PHP-приложение

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

Прочитав достаточно солидный объем разного рода документации по PHP, я часто натыкался на статьи и тексты, так или иначе связанные с производительностью PHP-скриптов. Порой в такого рода источниках информации удавалось найти достаточно интересные и неочевидные факты об этом языке программирования, которые не смотря на свою простоту могли дать вполне заметный прирост к производительности итогового приложения. Я почему-то очень серьезно стал относиться к производительности написанных мной скриптов, и довольно часто стал испытывать на практике спорные моменты в реализации, о которых узнавал из Сети или каких-либо других источников, с помощью самописных или opensource benchmark'ов, хотя порой и просто внедряя в реальные приложения. Как ни странно, в большинстве случаев практика подтверждала теорию, и я стал постоянно пользоваться этими простыми правилами, о которых я и хочу Вам рассказать.

Повышения значения индекса с помощью ++\$i;

Этот факт был наверное одним из самых удивительных для меня, когда я впервые о нем услышал, но действительно операция ++\$i; выполняется несколько быстрее, чем \$i++;. или другие вариации на ту же тему вроде \$i+=1;. Привычка использовать в качестве индекса цикла переменную под названием i, казалось бы стара как Мир, мне она досталась в наследство от C, а в месте с ней "в комплекте" шла привычка писать выражение i++ в заголовках циклов. Разница в скорости обработки этих выражений, насколько мне известно, обусловлена разным количеством элементарных машинных операций, которые необходимо выполнить процессору (в точных цифрах не уверен, пишу по памяти, но ++\$i; требует трех элементарных операций, а \$i++; – четырех). В справедливости этого факта не трудно убедиться, достаточно написать простенький скрипт, состоящий из цикла с достаточно большим количеством итераций, и замерить любым способом точное время его выполнения при использовании разных способов инкрементации индекса цикла.

Вывод статического контента без помощи PHP

Сейчас тот факт, что использование интерпретатора PHP для вывода статического контента сильно замедляет этот процесс, кажется мне очевидным, но поначалу я использовал echo там, где он был необходим, ничуть не чаще, чем там, где он лишь замедляет работу скрипта. От использования еще менее эффективного способа - print, меня избавила моя лень: писать каждый раз на одну букву больше дико не хотелось (в отличии от echo, print возвращает информацию об успешности выполнения своей работы, что в большинстве случаев просто-напросто не нужно). Проверить опять же не трудно - нужен лишь объемистый текстовый файл, который достаточно вывести в browser разными способами и засечь уходящее на это время.

Вывод статического контента из отдельного файла

Частенько при желании выполнить указанное в заголовке действие по привычке используют include, require или их _once версии, что является далеко не самой лучшей идеей с точки зрения производительности. Самым быстрыми быстрыми и экономичными поотношению к оперативной памяти являются функции readfile и fpassthru. В качестве доказательства этого факта приведу таблицу, демонстрирующую статистику выполнения этой операции различными методами и позаимствованную с одного англоязычного сайта:

Функция	Время (сек.)		Оперативная память (байт)
Функция	32Kb файл	1Mb файл	32Kb файл	1Mb файл
file\_get\_contents	0.00152	0.00564	52480	1067856
fpassthru	0.00117	0.00184	20016	20032
fgets	0.00195	0.07190	30760	30768
file	0.00157	0.06464	87344	2185624
require\_once	0.00225	0.08065	67992	2067696
readfile	0.00117	0.00191	19192	19208

Вывод переменных

Наверняка вам известно, что переменные можно выводить с помощью конструкции вроде echo "\$var text";, что является одним из самых удобных вариантов решения этой задачи благодаря минимальному количеству символов, которые необходимо набрать, но с точки зрения быстродействия этот вариант далек от идеала, так как влечет за собой достаточно серьезные преобразования в памяти сервера, эффект которых порой бывает заметен невооруженным глазом. Частично ущерб производительности можно сгладить заменой этой конструкции на echo \$var." text";, что приводит к несколькому усложнению внешнего вида кода и несколько поправляет ситуацию со скоростью выполнения. Но как известно знак . обозначает конкатенацию двух строк, что тоже требует некоторых вычислений и затрат памяти, но и от нее можно избавиться, заменив на запятую. Выражение echo \$var," text"; ничем по своему эффекту не отличается от предложенных ранее вариантов, за исключением максимального быстрого выполнения, обусловленного отсутствием дополнительных преобразований в процессе передачи просто последовательности из константы и переменной.

Избегайте выполнения лишних действий

Достаточно абстрактное утверждение, но тем не мение постоянное напоминание себе о нем может избавить Вас от совершения массы ошибок. Самой широкораспространенной является наверное вызов какой-либо функции (чаще всего count(); или strlen();) в проверке условия выхода из цикла. Когда-нибудь доводилось писать видеть в собственном или чужом коде выражение вида for(\$i = 0; \$i \< count(\$array); ++\$i) { ... }? А задумываться о последовательности выполнения действий при его обработке? Стоит только немного начать размышлять и ошибка становится очевидной: count(); выполняется при каждой итерации цикла, что приводит к подсчету количества элементов массива при каждой проверки условия выхода из цикла - почему бы не посчитать это значение заранее и сравнивать значения индекса с переменной, а не с результатом выполнения функции?

@

Использование этого оператора стоит избегать при каждой возможности. Казалось бы такое простое действие, как сокрытие вывода возможного сообщения об ошибке, влечет за собой достаточно трудоемкую последовательность действий: устанавливает значение параметра PHP-интерпретатора error_reporting = 0, выполняет указанное за этим оператором действие, возвращает значение error_reporting в исходное состояние.

Маленькие мелочи

Развивая тему предыдущего подраздела, хочется обратить внимания, что даже на еще более элементарных вещах можно сэкономить драгоценное процессорное время:

Вместо условия if(\$variableOne == \$variableTwo) { ... } можно написать if(\$variableOne === \$variableTwo) { ... }, что избавит от проверки на соответствие типов данных и приведения их друг к другу, в некоторых случаях эти действия эти случаях эти действия конечно же и бывают необходимы, но бывает это далеко не часто.
Глядя на выражения вроде if(\$boolean == true) { ... }, я чаще всего вспоминаю цитату из одного малоизвестного интернет-ресурса: if (b.ToString().length \< 5) { ... }. Хоть и не имет никакого отношения к PHP, но суть проблемы отражает очень ярко.
Самым очевидным способом проверить попадает ли длина строки в какой-либо диапазон является использование функции strlen(); и сравнение полученного результата с фиксированными значениями, но зачем выполнять лишний вызов функции, если можно воспользоваться услугами конструкцией языка PHP isset(); для определения наличия в строке определенных символов. if(isset(\$str{5})) { ... } приведет к абсолютно тем же результатам, что и if(strlen(\$str)>4){ ... }
Битовые операции выполняются намного быстрее относительно обычных арифметических действий. Об этом факте редко вспоминают, да и работать с ними умеет далеко не каждый, но порой они бывают очень актуальны, особенно при частой работе с числами кратными двойке.
Угадайте, что делает интерпретатор при виде надписи 1/2? Правильно: делит 1 на 2. Зачем лишний раз утруждать его, когда можно написать просто половину - 0.5.
При возвращении значения переменной из функции при помощи global выполняется на порядок больше действий, чем при классическом return.
Конечно же фраза \$array[text]; интерпритируется практически точно так же, как и \$array['text'];, но зачем выполнять лишнее преобразование из необъявленной константы в строку, проверять, что такой константы все же не существует, выводить сообщение типа E_NOTICE, если можно всего этого не делать?
По возможности не используйте require_once(); или include_once(); неоднократно по отношению к одному и тому же файлу. При отсутствии какого-либо эффекта, попусту тратится время на обработку повторного запроса.
Даже "безобидных" ошибок стоит избегать, лишняя проаерка потратит не так много процессорного времени, как генерирование достаточно длинного сообщения об ошибке и вывод его в stdout, stderr или лог-файл, а также не стоит забывать, что даже "безобидные" ошибки могут стать потенциальной угрозой безопасности приложения вцелом.

В заключении...

...хотелось бы упомянуть одну из первых статей по оптимизации PHP, которые мне доводилось читать, до сих пор храню ссылку на нее в bookmark'ах, именно она и выступала в роли одного из основных источников информации для этого текста. В качестве возможных вариантов продолжения чтения про PHP хотелось бы предложить Вам соответствующие раздел сайта, серию статей, тэг и RSS-ленту.

Месяц

Иван Блинков — Mon, 04 Feb 2008 12:02:00 +0300

Что ж, вот и прошел ровно месяц с того момента, как в мою голову пришла мысль о создании этого блога, срок конечно же очень и очень скромный, но уже можно провести своеобразную черту и подвести вое-какие итоги прошедшего месяца.

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

Говорить о том удалась идея или нет еще определенно рано, возраст у проекта еще маловат для такого рода громких слов. Но зато можно посмотреть в статистику, и увидеть что некоторые из 23 постов, которые я успел-таки написать за месяц каким-то загадочным образом умудрились попасть на главные страницы некоторых крупных новостных порталов, количество уникальных посетителей по разным данным очень сильно колеблется, но так или иначе оно уже исчисляется тысячами. Хостинг-провайдер на котором располагается блог, с радостью успел мне сообщить, что за январь с моего сайта был скачано почти два гигабайта информации, если учесть, что подавляющее большинство расположенного здесь контента является просто текстом, а количество изображений и JavaScript'ов минимально, то цифра выглядит более чем внушительно.

За месяц я успел получать от читателей совершенно разные отзывы, начиная от откровенно негативных, которые даже спам-фильтр не проходили из-за мата, заканчивая добрыми и теплыми словами, которые всегда приятно читать.

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

Архитектура Google

Иван Блинков — Thu, 31 Jan 2008 18:05:00 +0300

Эта статья датируется 2008 годом, новая версия: Архитектура Google 2011

Google - Король масштабируемости.

Каждый хоть раз слышал о Google благодаря их всеобъемлющему, "умному" и быстрому поисковому сервису, но ни для кого не секрет, что они не ограничиваются только им. Их платформа для построения масштабируемых приложений позволяет выпускать множество удивительно конкурентноспособных интернет-приложений, работающих на уровне всего Интернета вцелом. Они ставят перед собой цель постоянно строить все более и более производительную и масштабируемую архитектуру для поддержки своих продуктов. Как же им это удается?

Источники информации

Сразу хочу сказать, что эта запись является переводом с английского, автор оригинальной версии - Todd Hoff. Оригинал написан приблизительно в середине 2007 года, но по-моему до сих пор очень даже актуально.

Далее следует перечисление источников информации из оригинала:

Платформа

Linux
Большое разнообразие языков программирования: Python, Java, C++

Что внутри?

Статистика

На 2006 год система включала в себя 450000 недорогих серверов
За 2005 год было проиндексировано 8 миллиардов страниц. На данный момент… кто знает?
На момент написания оригинала Google включает в себя более 200 GFS кластеров. Один кластер может состоять из 1000 или даже 5000 компьютеров
Десятки и сотни тысяч компьютеров получают данные из GFS кластеров, которые насчитывают более 5 петабайт дискового пространства. Суммарные пропускная способность операций записи и чтения между дата центрами может достигать 40 гигабайт в секунду
BigTable позволяет хранить миллиарды ссылок (URL), сотни терабайт снимков со спутников, а также настройки миллионов пользователей

// Цифры не первой свежести конечно, но тоже неплохо.

Стек

Google визуализирует свою инфраструктуру в виде трехслойного стека:

Продукты: поиск, реклама, электронная почта, карты, видео, чат, блоги
Распределенная инфраструктура системы: GFS, MapReduce и BigTable
Вычислительные платформы: множество компьютеров во множестве датацентров
Легкое развертывание для компании при низком уровне издержек
Больше денег вкладывается в оборудование для исключения возможности потерь данных

Надежное хранение данных с помощью GFS

Надежное масштабируемое хранение данных крайне необходимо для любого приложения. GFS является основой их платформы хранения информации
GFS - большая распределенная файловая система, способная хранить и обрабатывать огромные объемы информации
Зачем строить что-либо самим вместо того, чтобы просто взять это с полки? Они контролируют абсолютно всю систему и именно эта платформа отличает их от всех остальных.

Она предоставляет:
- высокую надежность дата центров
- масштабируемость до тысяч сетевых узлов – высокую пропускную способность операций чтения и записи
- поддержку больших блоков данных, размер которых может измеряться в гигабайтах
- эффективное распределение операций между датацентрами для избежания возникновения "узких мест" в системе
В системе существуют мастер-сервера и сервера, собственно хранящие информацию:
- Мастер-сервера хранят метаданные для всех файлов. Сами данные хранятся блоками по 64 мегабайта на остальных серверах. Клиенты могут выполнять операции с метаданными на мастер-серверах, чтобы узнать на каком именно сервере расположены необходимые данные.
- Для обеспечения надежности один и тот же блок данных хранится в трех экземплярах на разных серверах, что обеспечивает избыточность на случай сбоев в работе какого-либо сервера.
- Новые приложения могут пользоваться как существующими кластерами, так и новыми, созданными специально для них.
- Ключ успеха заключается в том, чтобы быть уверенными в том, что у людей есть достаточно вариантов выбора для реализации их приложений. GFS может быть настроена для удовлетворения нужд любого конкретного приложения.

Работаем с данными при помощи MapReduce

Теперь, когда у нас есть отличная система хранения, что же делать с такими объемами данных? Допустим, у нас есть много терабайт данных, равномерно распределенных между 1000 компьютерами. Коммерческие базы данных не могут эффективно масштабироваться до такого уровня, именно в такой ситуации в дело вступает технология MapReduce.
MapReduce является программной моделью и соответствующей реализацией обработки и генерации больших наборов данных. Пользователи могут задавать функцию, обрабатывающую пары ключ/значение для генерации промежуточных аналогичных пар, и сокращающую функцию, которая объединяет все промежуточные значения, соответствующие одному и тому же ключу. Многие реальные задачи могут быть выражены с помощью этой модели. Программы, написанные в таком функциональном стиле автоматически распараллеливаются и адаптируются для выполнения на обширных кластерах. Система берет на себя детали разбиения входных данных на части, составления расписания выполнения программ на различных компьютерах, управления ошибками, и организации необходимой коммуникации между компьютерами. Это позволяет программистам, не обладающим опытом работы с параллельными и распределенными системами, легко использовать все ресурсы больших распределенных систем.
Зачем использовать MapReduce? – Отличный способ распределения задач между множеством компьютеров – Обработка сбоев в работе – Работа с различными типами смежных приложений, таких как поиск или реклама. Возможно предварительное вычисление и обработка данных, подсчет количества слов, сортировка терабайт данных и так далее – Вычисления автоматически приближаются к источнику ввода-вывода
MapReduce использует три типа серверов:
- Master: назначают задания остальным типам серверов, а также следят за процессом их выполнения
- Map: принимают входные данные от пользователей и обрабатывают их, результаты записываются в промежуточные файлы
- Reduce: принимают промежуточные файлы от Map-серверов и сокращают их указанным выше способом
Например, мы хотим посчитать количество слов на всех страницах. Для этого нам необходимо передать все страницы, хранимые в GFS, на обработку в MapReduce. Этот процесс будет происходить на тысячах машин одновременно с полной координацией действий, в соответствии с автоматически составленным расписанием выполняемых работ, обработкой потенциальных ошибок, и передачей данных выполняемыми автоматически.
- Последовательность выполняемых действий выглядела бы следующим образом: GFS → Map → перемешивание → Reduce → запись результатов обратно в GFS
- Технология MapReduce состоит из двух компонентов: соответственно map и reduce. Map отображает один набор данных в другой, создавая тем самым пары ключ/значение, которпыми в нашем случае являются слова и их количества.
- В процессе перемешивания происходит агрегирование типов ключей.
- Reduction в нашем случае просто суммирует все результаты и возвращает финальный результат.
В процессе индексирования Google подвергает поток данных обработке около 20 разных механизмов сокращения. Сначала идет работа над всеми записями и агрегированными ключами, после чего результат передается следующему механизму и второй механизм уже работает с результатами работы первого, и так далее.
Программы могут быть очень маленькими, всего лишь от 20 до 50 строк кода.
Единственной проблемой могут быть "отстающие компьютеры". Если один компьютер работает существенно медленнее, чем все остальные, это будет задерживать работу всей системы в целом.
Транспортировка данных между серверами происходит в сжатом виде. Идея заключается в том, что ограничивающим фактором является пропускная способность канала и ввода-вывода, что делает резонным потратить часть процессорного времени на компрессию и декомпрессию данных.

Хранение структурированных данных в BigTable

BigTable является крупномасштабной, устойчивой к потенциальным ошибкам, самоуправляемой системой, которая может включать в себя терабайты памяти и петабайты данных, а также управлять миллионами операций чтения и записи в секунду.
BigTable представляет собой распределенный механизм хэширования, построенный поверх GFS, а вовсе не реляционную базу данных и, как следствие, не поддерживает SQL-запросы и операции типа Join.
Она предоставляет механизм просмотра данных для получения доступа к структурированным данным по имеющемуся ключу. GFS хранит данные не поддающиеся пониманию, хотя многим приложениям необходимы структурированные данные.
Коммерческие базы данных попросту не могут масштабироваться до такого уровня и, соответственно, не могут работать с тысячами машин одновременно.
С помощью контролирования своих низкоуровневых систем хранения данных, Google получает больше возможностей по управлению и модификации их системой. Например, если им понадобится функция, упрощающая координацию работы между датацентрами, они просто могут написать ее и внедрить в систему.
Подключение и отключение компьютеров к функционирующей системе никак не мешает ей просто работать.
Каждый блок данных хранится в ячейке, доступ к которой может быть предоставлен как по ключу строки или столбца, так и по временной метке.
Каждая строка может храниться в одной или нескольких таблицах. Таблицы реализуются в виде последовательности блоков по 64 килобайта, организованных в формате данных под названием SSTable.
В BigTable тоже используется три типа серверов:
- Master: распределяют таблицы по Tablet-серверам, а также следят за расположением таблиц и перераспределяют задания в случае необходимости.
- Tablet: обрабатывают запросы чтения/записи для таблиц. Они разделяют таблицы, когда те превышают лимит размера (обычно 100-200 мегабайт). Когда такой сервер прекращает функционирование по каким-либо причинам, 100 других серверов берут на себя по одной таблице и система продолжает работать как-будто ничего не произошло.
- Lock: формируют распределенный сервис ограничения одновременного доступа. Операции открытия таблицы для записи, анализа Master-сервером или проверки доступа должны быть взаимоисключающими.
Локальная группировка может быть использована для физического хранения связанных данных вместе, чтобы обеспечить лучшую локализацию ссылок на данные.
Таблицы по возможности кэшируются в оперативной памяти серверов.

Оборудование

Как эффективно организовать большую группу компьютеров с точки зрения издержек и производительности?
Используется самое обыкновенное ультра-дешевое оборудование и поверх него строится программное обеспечение, способное спокойно пережить смерть любой части оборудования.
Тысячекратный рост вычислительной мощности может быть достигнут с издержками в 33 раза меньшими, если воспользоваться толерантной к сбоям инфраструктурой, по сравнению с инфраструктурой, построенной на высоконадежных компонентах. Надежность строится поверх ненадежных компонентов.
Linux, домашнее размещение серверов, материнские платы предназначенные для персональных компьютеров, дешевые средства хранения данных.
Цена за каждый ватт энергии в расчете на производительность не становится меньше, что ведет к большим проблемам связанным с энергообеспечением и охлаждением.
Использование совместного размещения в своих и арендуемых датацентрах.

Разное

Быстрый выпуск изменений более предпочтителен, чем ожидание.
Библиотеки - превалирующий метод построения программ.
Некоторые приложения предоставляются в виде сервисов.
Инфраструктура управляет определением версий приложений таким образом, что они могут выпускать новые продукты, не боясь сломать работу какого-либо компонента системы.

Пути развития

Поддержка географически распределенных кластеров.
Создание единого глобального пространства имен для всех данных. На данный момент данные распределены по кластерам.
Более автоматизированные передача и обработка данных
Решение вопросов, связанных с поддержанием работоспособности сервисов даже в тех случаях, когда целый кластер отключается от системы в связи с техническими работами или каким-либо сбоем в работе.

Подводим итоги

Инфраструктура может быть конкурентным преимуществом. Это определенно так для Google. Они могут выпускать новые интернет сервисы быстрее, с меньшими издержками, на таком уровне, что мало кто сможет составить им конкуренцию. Подход многих компаний сильно отличается от подхода Google, эти компании рассматривают инфраструктуру как статью расходов, они обычно используют совсем другие технологии и совсем не задумываются о планировании и организации своей системы. Google позиционирует себя как компанию по построению систем, что является очень современным подходом к разработке программного обеспечения.
Охватывание нескольких дата центров до сих пор является нерешенной проблемой. Большинство сайтов базируется в одном или двух дата центрах. Полное распределение сайта между несколькими датацентрами является хитрой задачей.
Взгляните на Hadoop, если у Вас нет времени на собственноручное построение всей архитектуры с нуля. Hadoop является opensource воплощением в жизнь многих идей здесь представленных.
Часто недооцениваемым преимуществом платформенного подхода является тот факт, что даже неопытные разработчики могут быстро и качественно реализовывать трудоемкие приложения на базе платформы. Но если бы каждый проект требовал одинаково распределенной архитектуры, то это создало бы много проблем, так как люди, которые понимают как это делается, являются достаточно большой редкостью.
Совместная деятельность не всегда является таким уж плохим занятием. Если все части системы работают взаимосвязанно, то улучшение в одной из них сразу и абсолютно прозрачно отразится положительным образом и на остальных компонентах системы. В противном случае такой эффект наблюдаться не будет.
Построение самоуправляемых систем позволяет более легко перераспределять ресурсы между серверами, расширять систему, отключать некоторые компьютеры и элегантно проводить обновления.
Производить длительные операции стоит параллельно.
Всему, что было сделано Google, предшествовало искусство, а не только крупномасштабное развертывание системы.
Учитывайте возможность компрессии данных, она является очень неплохим решением, если остается лишнее процессорное время, но присутствует нехватка пропускной способности.

Микроформаты

Иван Блинков — Sun, 27 Jan 2008 19:31:00 +0300

Не смотря на тот факт, что эта технология еще только начинает получать широкое распространение и применение на просторах Сети, слов о ней уже написано немало, не вижу ни одной причины почему бы мне тоже не написать несколько слов о микроформатах.

Основной идеей микроформатов является попытка дополнить смыслом существующие элементы стандартов разметки - XHTML и HTML, такого рода смысл нынче модно назвать словом семантика, что так или иначе влияет как на людей, пользующихся услугами Сети, так и на программы, обслуживающие ее функционирование.

Что представляют собой микроформаты?

Строго говоря, микроформаты являются набором форматов данных, основывающихся на существующих широкораспространенных стандартах представления данных (в частности XHTML), каждый из них предназначен для решения конкретной узкоспециализированной задачи, то есть для обеспечения конкретной семантикой конкретной части стандарта.

Как не трудно догадаться, измение существующих и добавление новых тэгов к стандарту XHTML в микроформатах недопустимо, ведь иначе документ перестанет соответствовать исходному стандарту. Именно по-этому для реализации микроформатов используются атрибуты тэгов XHTML, в которых допускаются некоторые вольности - rel и class.

Что же может дать осмысленность разметки?

В перспективе вся эта затея направлена на повышение качества сервисов, предоставляемых в Сети. На данный момент большая часть сервисов, основанных на анализе данных расположенных в Сети, способна лишь на частичное использование разметки документа для уточнения смысла той или иной информации. Показать это лучше всего на примере: тэги <em> и <strong> говорят о том, что содержащаяся внутри них информация имеет некий смысловой акцент, но в то же время многие другие тэги не несут за собой никакой дополнительной смысловой информации, помимо содержащегося внутри них текста. Одним из таких тэгов является <a>, который говорит о наличии ссылки на некоторую интернет-страницу, как-то связанную с текстом между открывающим и закрывающим тэгами, а также расположенную по URL, указанному в атрибуте href, можно конечно к этому прибавить атрибут title, но так или иначе на этом информация о ресурсе, на который ссылается автор документа, заканчивается. Один из микроформатов, позволяющих расширить возможности простых ссылок, называется XFN и предоставляет авторам документов возможность описать свое отношение к другим авторам, на работы которых они ссылаются, выглядит это примерно следующим образом:

<a href="http://www.my-friend.ru" rel="friend">
    Сайт моего друга
</a>

Теперь понять, что сайт, на который происходит ссылка, является сайтом друга автора текущего документа, может не только читатель, но и программа, занимающаяся индексированием страниц Сети для какого-либо сервиса, например этот микроформат полезен для повышения качества работы социальных сетей. Это была лишь небольшая часть возможностей микроформата XFN, подробнее останавливаться на нем не буду - ведь каждый из них явно заслуживает отдельной записи.

Классификация

Наверняка к Вам в голову приходила мысль: а почему необходимо пользоваться именно вот этими микроформатами? Если в XHTML допускаются любые значения тэгов rel и class, почему я не могу придумать свои микроформаты и пользоваться ими? Ответ прост: микроформаты призваны повысить качество Сети вцелом, а не какого-то конкретного сайта отдельно. Только часть микроформатов получила широкое распространение, и именно ими приходится пользоваться всем остальным сайтам под влиянием сетевого эффекта (т.е. того факта, что ценность технологии прямо пропорциональна обширности ее применения, в нашем случае в рамках Сети), просто чтобы быть совместимыми с остальной частью Интернета.

Но не смотря на это - количество и разнообразие распространенных микроформатов велико, и как-либо классифицировать их достаточно сложно. Самым простым и точным вариантом можно назвать разделение по структуре формата:

элементарные - применимые только к одному конкретному типу тэгов. В эту группу попадают упомянутый выше XFN, а также множество других, например rel-tag, rel-nofollow*, и так далее;
композитные (или составные) - имеют более сложную структуру, и для своей реализации требуют модификации нескольких тэгов одного элемента. Микроформаты из этой категории предназначены для описания более сложной структуры, например hCard, используемый для описания людей или организаций (можно посмотреть на пример его использования на моей странице "О себе").

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

Применение на практике

Вариантов их применения на сегодняшний день не так уж и много. Как я уже упоминал, эта технология еще находится лишь на пути к получению повсеместной распространенности на просторах Сети, но уже сейчас они проявили себя достаточно, чтобы оказывать влияние на многие аспекты сети Интернет:

Многие поисковые системы активно используют при составлении своего индекса микроформат rel-nofollow, об этом мне уже доводилось упоминать в одной из предыдущих записей;
Plug-in для Firefox под названием Operator - позволяет просматривать используемые на текущей странице микроформаты, а также предлагает небольшой ассортимент действий, с ними связанных. Например, hCard предлагается экспортировать в адресную книгу, а для rel-tag - осуществить поиск по скромному списку интернет-сервисов. Лично я уже достаточно его себе установил и всегда держу включенным, не для того, чтобы реально им пользоваться, а просто чтобы быть в курсе, что тот или иной ресурс вдруг начал поддерживать эту замечательную технологию;
Появляется все больше и больше CMS, поддерживающих различные микроформаты "из коробки" или с помощью plug-in'ов, что ведет к все более активному расширению списка сайтов, следующих этим стандартам представления данных. WordPress, ~~на которой работает этот блог~~, тоже относится к категории CMS, поддерживающих микроформаты, в чем вы можете убедиться, установив упомянутый в предыдущем пункте Operator. Сам по себе этот факт какой-либо полезности не несет, но является лишним стимулом для разработчиков программного обеспечения и интернет-ресурсов, поддерживающих микроформаты.

Этот список можно было бы продолжать еще достаточно долго, так что позволю себе остановиться, ограничившись лишь перечислением наиболее актуальных с моей точки зрения аспектов применения микроформатов.

Подводим итоги

По сути являясь своеобразной "надстройкой" над XHTML, микроформаты создаются по принципу "чем проще - тем лучше", но в то же время благодаря своей узкой специализации и простоте, каждый из них способен быть составной частью модульной структуры форматов данных, способной поднять Сеть на качественно новый уровень развития.

Шаблонизация

Иван Блинков — Sat, 26 Jan 2008 15:25:00 +0300

Наверняка Вы часто замечали, что в пределах одного сайта все (или покрайней мере большинство) страниц имеют много общего: структуру, расположение элементов, дизайн и так далее. Основным различием обычно является лишь содержание. Естественно, что делается это не спроста: именно общие компоненты сайта создают в голове посетителей тот самый образ, который производит общее подсознательное впечатление о сайте, а также позволяет посетителям отличать сайт А от сайта Б.

Продолжая разговор, начатый еще в одной из предыдущих статей, рассмотрим организацию интерфейса между двумя другими составляющими практически любого интернет-проекта: скриптов (все так же на примере PHP) и страницами, отправляемыми посетителям посредством http-сервера.

С точки зрения веб-разработчика было бы как минимум не логично мешать в кучу постоянные части страниц с динамическими. Для этого существует множество причин, в том числе, например, экономия вычислительной мощности сервера на отсутствии необходимости каждый раз заново генерировать статичные элементы или неминуемое сокращение объемов кода, который необходимо написать, в случае если статический и динамический контент разделены. Отделенную подобным образом статическую часть страниц (слегка модифицированную с целью обозначить правила, по которым будет проводиться "заполнение" ее динамическим контентом) принято называть словом "шаблон".

Наверняка у Вас уже возникло два вполне логичных вопроса:

Как можно разделить таким образом контент?
Как потом восстановить страницу в исходном виде?

Вариантов ответа на каждый из них можно придумать множество: начиная с банальных вариаций на тему применения echo, заканчивая применением достаточно серьезных готовых решений вроде широкораспространенного Smarty или существенно более эффективного Blitz. Каждый из них имеет свои сильные и слабые стороны, но в целом любой из них можно оценить по двум критериям: производительности и удобстве организации кода.

Какие-либо цифры оценки производительности приводить не буду, так как, во-первых, в Сети можно найти много benchmark'ов, посвященных этой теме, а, во-вторых, просто-напросто вовсе не о цифрах я хотел с Вами поговорить. Как известно самым производительным по крайней мере с теоретической точки зрения является метод под названием php mess, заключается он в следующем: вся страница размещается в рамках одного файла, при этом статическая часть документа пишется просто "как есть" в соответствии с необходимым стандартом, а изменяемые части организуются размещенным в необходимых местах PHP-кодом, окруженным стандартной конструкцией <?php ?>. Но огромнейший недостаток очевиден - огромное количество информации расположенной в одном файле, при отсутствии какого-либо более четкого разделения PHP-кода и остального содержимого, чем указанная выше конструкция, приводит к постоянной путанице в коде, а также существенным затратам времени программиста при попытках исправить ту или иную часть документа.

На противоположной стороне нашей шкалы удобство-производительность я бы расположил уже упомянутое выше решение под названием Smarty. Представляет оно собой целую систему, реализованную также на PHP, и предоставляющую огромное количество возможностей по решению нашей задачи. Шаблоны хранятся в отдельных файлах, для определения мест расположения динамического контента используется специальный синтаксис, который прост как три копейки, так как разрабатывался с расчетом не на программистов, а по принципу "чем проще, тем лучше". Именно этот факт сделал Smarty одним из самых (если не самым) распространенных движков шаблонизации (или как их принято правильно называть "Template Engine"). Но, к сожалению, за удобство приходится платить, в этом случае производительностью: вся система сама по себе громоздка и состоит из множества файлов, между которыми все данные так или иначе передаются, а так как написано она на PHP (который является далеко не самым производительным языком программирования, в основном в силу своей интерпритируемости и некоторых других особенностей), конкуренции в плане производительности многим другим вариантам решения нашей задачи Smarty составить не в состоянии.

Одним из лучших "компромиссных" вариантов, которые доступны на данный момент, могу назвать также упомянутый выше Blitz. Реализован он в виде модуля PHP, написанного на языке C, что является залогом его отличной производительности. При этом общая его концепция близка к Smarty: шаблоны также хранятся в отдельных файлах и подчинены незамысловатому синтаксису (который вообще можно понять и запомнить буквально за 15-20 минут, прочитав статью, ссылку на которую я уже приводил выше), а в PHP-скриптах после установки становится доступен специальный класс для управления модулем. Но основное достоинство этого решения является одновременно и его основным недостатком - редкий хостинг имеет этот модуль в списке предустановленных (видимо в силу своей не очень обширной известности, обусловленной ), а доступ к http-серверу и PHP-интерпретатору, который необходим для установки PHP-модулей, предоставляется чаще всего только на дорогих тарифах виртуального хостинга или на различных вариантах VPS или арендуемых серверов.

Помимо этого некоторые энтузиасты берутся на написание "собственных" Template Engine, базирующихся на различных вариантов использования PHP-функций вроде preg_replace. Если честно такие попытки редко заканчиваются успехом: в лучшем случае удается добиться удобства использования самим разработчиком, но чаще всего в ущерб производительности. Заниматься подобными экспериментами я Вам не советую, вместо этого я предлагаю написать "обертку" к приглянувшемуся распространенному Template Engine, что позволит не только сделать его использование более удобным конкретно для Вас, но и позволит заменить его на другой с минимальными затратами сил и времени (например в случае, если модуль Blitz недоступен).

Разрабатываем "обертку"

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

Если Ваш выбор всетаки пал на написание "оболочки", не смотря на принесение в жертву несущественной части производительности, то стоит для начала определиться: а что же мы будем "заворачивать"? В качестве примера я, пожалуй, буду использовать Blitz, как самый оптимальный вариант (по крайней мере с моей точки зрения). Начать стоит как обычно с пустой заготовки для класса.

Далее следует решить какие все же модификации мы будем производить для собственного удобства над стандартным решением. Попробую привести несколько примеров в отношении Blitz, для начала хочу обратить внимание, что при внимательном прочтении все той же статьи от разработчика этого шаблонизатора, можно обнаружить, что модуль показывает более высокие показатели производительности при однократном вызове метода set. Достичь это можно выполнением этого метода с указанием в качестве одного из входных параметров "многоуровнего" массива, составленного специальным образом (надеюсь Вы все же к этому моменту уже успели прочитать неоднократно упоминавшуюся статью, и представляете принцип работы модуля). Написание механизма составления такого массива позволит как сократить время разработки, так и сэкономит драгоценные миллисекунды, вычитаемые из свободного времени посетителей сайта в процессе генерации страницы.

В любом случае понадобится переменная для его хранения:

<?php
class TemplateEngine
{
  {
    array=array();
    //можно сразу указать указать путь к папке с шаблонами
    $this->engine=new Blitz('./template/'.$template.'.tpl');
  }
}
?>

А также метод, переопределяющий стандартный set на метод, добавляющий новые значения к нашему массиву (хотя можно и любое другое понравившееся название использовать):

<?php
function set($caption,$value)
{
  $this->array[$caption]=$value;
}
?>

После чего оригинальный set можно использовать уже непосредственно перед parse, с указанием уже собранного массива в качестве параметра. За компанию позволю произвести себе еще одну модификацию: в подавляющем большинстве случаев parse используется в совокупности с echo, чтобы не указывать каждый раз это слово - можно включить его прямо в наш класс:

<?php
function parse()
{
  if(count($this->array))$this->engine->set($this->array);
  echo $this->engine->parse();
}
?>

Еще одним возможным вариантом модификации может стать обработка всех (или какой-то части, если есть необходимость) динамических данных с помощью какой-либо функции, например это актуально для htmlspecialchars:

<?php
function set($caption,$value)
{
  $this->array[$caption]=$this->html($value);
}
function rawset($caption,$value)
{
  $this->array[$caption]=$value;
}
private function html($array)
{
  if(is_array($array))
  {
    foreach($array as $caption => $value)
    $value=$this->html($value);
    return $array;
  }
  else return htmlspecialchars($array,ENT_QUOTES);
}
?>

Как нетрудно заметить, в методе используется рекурсия, так как структура передаваемых параметром массивов неизвестна.

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

Путеводитель для роботов

Иван Блинков — Fri, 18 Jan 2008 01:13:00 +0300

Ни для кого не секрет, что одним их основных факторов, влияющих на расположение страниц интернет-ресурса на просторах поисковых систем, является уникальность контента (или другими словами - содержания). Конечно же простейшим способом избежать дублирующегося контента является просто собственноручная его генерация (или в крайнем случае с помощью наемных работников или посетителей Вашего сайта). Но, к сожалению, это позволяет избежать лишь повторов между разными сайтами. Помимо этого свою роль играют и повторы в рамках одного сайта. Наверняка Вы замечали, что многие CMS размещают один и тот же текст на разных страницах сайта: например на обычной странице, в RSS-ленте и каком-нибудь архиве.

Именно для решения этой маленькой проблемы и была создана технология под названием Robots Exclusion Protocol. С ее помощью можно минимизировать возможность повторов содержимого, проиндексированного поисковыми системами в рамках одного сайта, а также исключить из индекса неинформативные страницы.

Надеюсь, что Вы представляете себе в чем заключается принцип работы поисковых систем, но в любом случае не вижу причин для того чтобы не рассказать вкратце об этом. Помимо собственно сайта, где пользователи вводят ключевую фразу для поиска, любая поисковая система имеет еще две части: базу данных (другими словами - индекс сайтов) и специальной программы (которую чаще всего называют пауком или по-английски - crawler или spider, но иногда используется более общий термин - робот). Эта программа запущена на серверах поисковых систем во множестве экземпляров и основной целью их работы является пополнение и обновления индекса поисковой системы. Сам же сайт лишь делает выборку из индекса в соответствии с запросом и сортирует результат.

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

Обсуждаемая нами технология дает возможность веб-мастеру предоставить crawler'ам, образно говоря, путеводитель по его сайту. Методов для этого имеется несколько:

Любой crawler прежде чем перейти на новый домен проверяет существование файла по адресу http://www.некий-домен.ru/robots.txt. В таком файле веб-мастер может разместить директивы для потенциальных компьютеризированных посетителей в соответствии с соответствующим стандартом. Если поисковый робот обнаруживает этот файл, то прочитав его он корректирует свой маршрут обхода всего интернет-ресурса в соответствии с указанными директивами.
Внутри заголовка любой HTML-страницы или любого другого документа, передаваемого по http протоколу (с помощью заголовков самого протокола), можно разместить специальный meta-tag для роботов, который также должен соответствовать стандарту, опубликованному в 1996 году.
Основной частью путеводителя чаще всего является карта сайта в формате XML. С ее помощью программа может быстро определить весь ассортимент страниц, которые ей было бы неплохо проиндексировать.
Самым последним был воплощен в жизнь метод, основанный на микроформатах. Реализуется он с помощью параметра rel="nofollow", указанного внутри тэга <a>, который обозначает ссылку, не предназначенную для перехода по ней пауком.

Карты сайтов и директивы robots.txt предназначены для определения маршрута путешествия crawler'а, в то время как микроформаты и meta-тэги - для влияния на сам процесс индексации.

У каждого из описанных выше методов есть своя узкая специализация:

robots.txt предоставляет базовый набор директив для роботов, которым они следуют даже в случае конфликтов с другими использованными методами.
Карта сайта влияет на последовательность и набор страниц, посещенных пауком, с помощью указания приоритетов страниц или времени последней модификации.
Мета-тэги распространяют свое действие на весь документ и влияет на индексирование страниц (если они одновременно присутствуют как в заголовке (X)HTML документа, так и в заголовках X-Robots-Tags HTTP-протокола, то приоритет считается выше у заголовков протокола).
Микроформаты позволяют в случае необходимости переопределять параметры любого конкретного тэга документа, не смотря на указания в мета-тэгах.

С синтаксисом robots.txt лучше всего ознакомиться прямо в соответствующей спецификации, ссылку на которую я уже приводил (хотя возможно в будущем я всетаки соберусь написать запись и по этому поводу). Не знаю занимается ли кто-нибудь генерацией карт сайта вручную, но для общего развития будет полезно изучить и ее формат, неплохим примером может послужить XML-карта этого блога.

Защита интернет-ресурсов в картинках

Иван Блинков — Sun, 13 Jan 2008 22:30:00 +0300

Этой статьей мне хотелось бы открыть мою первую серию статей "Джентельменский набор PHP программиста". Как и во всей остальной серии здесь пойдет речь о программировании на PHP для интернет-проектов, но в каждой статье я буду выбирать один узкий аспект и на протяжении всей статьи буду стараться показать возможные варианты его реализации и применения.

Сегодня таким аспектом станет защита интернет-ресурса от возможного возникновения нежелательного контента со стороны пользователей с помощью технологии captcha (точнее о "графическом" варианте ее реализации), о которой уже неоднократно шла речь.

Начать имеет смысл с небольшого напоминания о принципе работы этой технологии: перед потенциальным посетителем ставится некое препятствие, которое ему необходимо преодолеть для продолжения работы с интернет-ресурсом. Существует множество вариантов такого рода препятствий. Как уже упоминалось, сегодня мы будем реализовывать только один наиболее распространенный тип - "графический". В простейшем случае он представляет собой просьбу переписать с изображения некий набор символов. В процессе генерирования изображения, символы сильно искажаются с целью предотвращения возможности их распознавания любой программой с помощью технологии OCR.

Подготовка

Прежде чем начать писать код стоит более детально осознать какая же цель перед нами стоит: нам необходимо написать скрипт, генерирующий искаженное изображение некоторого набора символов и незаметно для пользователя передающее этот набор какому-либо другому скрипту, который нас пока мало интересует, но ясно лишь, что собственно проверкой будет заниматься именно он на основе данных полученных от пользователя и нашего скрипта. Способов исказить текст существует огромное количество, в ходе написания статьи постараюсь упомянуть несколько самых эффективных и широкоиспользуемых из них.

В первую очередь стоит подготовить некий каркас кода, который мы будем впоследствии заполнять. Он будет состоять из двух частей:

Описание класса, генерирующего изображение
Файл, который будет вызываться browser'ом. В нем будет подключено описание нашего класса, выбор настроек данного конкретного изображения и выполнено создание объекта класса, в соответствии с выбранными настройками.

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

Итак, создание объекта будем производить максимально простым способом, параметрами укажем белый и черный цвета. Заготовка для самого класса будет выглядеть примерно следующим образом (предположим, что он хранится в файле captcha.class.php):

<?php
class Captcha
{
   private $string; // генерируемый текст
   private $bgcol;  // основной цвет фона
   private $fgcol;  // основной цвет текста
   private $height; // высота изображения
   private $width;  // ширина изображения
   function __construct($bgcol,$fgcol)  // конструктор, вызывается при создании экземпляра класса
   {
   }
}
?>

Задаем параметры

Первым делом при создании объекта необходимо задать остальные параметры, размеры изображения можно указать прямо в конструкторе, а для генерации текста лучше написать отдельную функцию:

<?php
private function generateImage()  // генерация изображения
{
  $this->width=250;
  $this->height=80;
  $this->fgcol=$fgcol;
  $this->bgcol=$bgcol;
  $this->generateSymbols();
 }
 private function generateSymbols()   // генерация четырех цифр
 {
    $this->string=$this->leadingZero(rand()%10000,4);
 }
 private function leadingZero($num,$length) // дополнения числа num лидирующими нулями
 {                        // до длины length
  $str=strrev($num);
  for($i=strlen($str);$i<$length;++$i)$str.="0";
  return strrev($str);
 }
}
?>

Этих данных нам должно хватить для написания функции, генерирующей изображение.

Генерируем изображение

Если забыть, что текст необходимо искажать, то функция, генерирующая изображение выглядела бы просто как:

<?php
private function generateImage()  // генерация изображения
{
   $im=@imagecreatetruecolor($this->width,$this->height);
   $bcol=imagecolorallocate($im,$this->bgcol[0],$this->bgcol[1],$this->bgcol[2]);
   $fcol=imagecolorallocate($im,$this->fgcol[0],$this->fgcol[1],$this->fgcol[2]);
   imagefill($im,0,0,$bcol);
   imagettftext($im,40,10,20,25,$fcol,"./font/font_name.ttf",$this->string));
   header('Content-Type: image/png');
   imagepng($im);
   imagedestroy($im);
}
?>

В данном методе используются функции модуля PHP под названием GD, основывающегося на одноименной библиотеке, убедитесь, что на Вашем хостинге этот модуль установлен.

Реально же ей пользоваться не стоит - такое изображение с легкостью поддается OCR. Полученный текст необходимо тем или иным образом исказить. Для вывода изображения используется формат PNG, но никто не мешает воспользоваться JPEG или GIF, для этого достаточно заменить везде png на название соответствующего формата.

Искажаем текст

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

использование нестандартных шрифтов - функция imagettftext позволяет использовать произвольный шрифт в формате Truetype, чем и необходимо воспользоваться. В Сети можно найти огромное количество бесплатных шрифтов в этом формате. По возможности стоит выбирать шрифты, максимально не похожие на любой стандартный, но при этом легко читающиеся.
использование нескольких шрифтов - сделав подборку подходящих шрифтов, можно не останавливаться на каком-то одном, а сделать выбор текущего шрифта случайным из списка.
случайный выбор цветов - усложняет работу OCR и в большинстве случаев не сильно мешает восприятию человеком.
случайное расположение символов - еще один способ усложнить работу программам, пытающимся прочитать текст.
неравномерный фон - изобразив на фоне какой-либо абстрактный набор любых фигур, можно заставить программу-посетителя подумать что какая-то часть из них является символом. Например, пересечение двух прямых линий часто распознается как буква T или L. Неплохим вариантом является написание на фоне других символов другим цветом, сильно отличающимся от основного и близким к цвету фона.

Для начала этого вполне хватит, перейдем к реализации, в комментариях постараюсь указывать все особенности:

<?php
private function generateImage() // генерация изображения
{
   $im=@imagecreatetruecolor($this->width,$this->height);  // создаем пустое изображение
   $mcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%55); // выбираем случайным образом
   $kcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%20); // несколько цветов
   $lcol=imagecolorallocate($im,$this->bgcol[0]-rand()%20,$this->bgcol[1]-rand()%20,$this->bgcol[2]-rand()%20);
   $bcol=imagecolorallocate($im,$this->bgcol[0],$this->bgcol[1],$this->bgcol[2]);
   $fcol=imagecolorallocate($im,$this->fgcol[0],$this->fgcol[1],$this->fgcol[2]);
   imagefill($im,0,0,$bcol);  // заполняем изображение фоном
   $array=array(6,7,6,6,20,20,25,26,31,32,37,39,41); // список названий подходящих шрифтов
   $n=$array[rand()%count($array)];  // наугад выбираем из них один
   $m=rand()%50+1;
   $k=rand()%50+1;
   for($i=0;$i<$m;++$i)
   imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$lcol); // создаем на фоне несколько линий
   for($i=0;$i<$k;++$i)
   imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$lcol); // и еще несколько
   /*
   Генерируем текст: две строки на фон, а также интересующие нас символы по одному.
   */
   imagettftext($im,rand()%20+40,rand()%100-50,rand()%$this->height*0.8,rand()%50+25,$kcol,"./font/".$k.".ttf",$this->randomString(rand()%15));
   imagettftext($im,rand()%40+35,rand()%70-35,rand()%$this->height*0.8,rand()%25+25,$mcol,"./font/".$m.".ttf",$this->randomString(5+rand()%4));
   for($i=0;$istring);++$i)
   imagettftext($im,rand()%10+33,rand()%70-35,15+$i*$this->width/5*1.1+rand()%5,rand()%7+$this->height*0.73,$fcol,"./font/".$n.".ttf",$this->string[$i]);
   for($i=0;$i<$m/10;++$i)
   imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$mcol); // еще линии
   for($i=0;$i<$k/4;++$i)
   imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$mcol);  // и еще немного
   for($i=0;$i<$k/6;++$i)
   imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$fcol);  // и еще чуть-чуть
   header('Content-Type: image/png');
   imagepng($im);
   imagedestroy($im);
}
private function randomString($length)  // генерируем случайный набор символов заданной длины
{
  $list="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVXYZ!@#$%^&**()-=_+.,<>/\|;:";
  for($i=0,$str="";$i<$length;++$i)$str.=substr($list,mt_rand(0,strlen($list)-1),1);
  return $str;
}
?>

Стоит заметить, что конкретные цифры необходимо подбирать индивидуально, в примере они указаны абсолютно произвольно. Использование конкретно этих же цифр приведет к далеко не самым лучшим результатам.

Сборка

Не стоит забывать, что помимо генерации самого изображения, необходимо передать написанный текст другому скрипту, который будет сверять данные. Удобнее всего это делать через глобальный массив $_SESSION.

Собрав все написанное выше, и учтя передачу текста, можно получить следующий класс:

<?php
class Captcha
{
   private $string; // генерируемый текст
   private $bgcol;  // основной цвет фона
   private $fgcol;  // основной цвет текста
   private $height; // высота изображения
   private $width;  // ширина изображения
   function __construct($bgcol,$fgcol)  // конструктор, вызывается при создании экземпляра класса
   {
      $this->width=250;
      $this->height=80;
      $this->fgcol=$fgcol;
      $this->bgcol=$bgcol;
      $this->generateSymbols();
      $this->generateImage();
   }
   private function generateImage() // генерация изображения
   {
      $im=@imagecreatetruecolor($this->width,$this->height);  // создаем пустое изображение
      $mcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%55); // выбираем случайным образом
      $kcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%20); // несколько цветов
      $lcol=imagecolorallocate($im,$this->bgcol[0]-rand()%20,$this->bgcol[1]-rand()%20,$this->bgcol[2]-rand()%20);
      $bcol=imagecolorallocate($im,$this->bgcol[0],$this->bgcol[1],$this->bgcol[2]);
      $fcol=imagecolorallocate($im,$this->fgcol[0],$this->fgcol[1],$this->fgcol[2]);
      imagefill($im,0,0,$bcol);  // заполняем изображение фоном
      $array=array(6,7,6,6,20,20,25,26,31,32,37,39,41); // список названий подходящих шрифтов
      $n=$array[rand()%count($array)];  // наугад выбираем из них один
      $m=rand()%50+1;
      $k=rand()%50+1;
      for($i=0;$i<$m;++$i)
      imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$lcol); // создаем на фоне несколько линий
      for($i=0;$i<$k;++$i)
      imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$lcol); // и еще несколько
      /*
      Генерируем текст: две строки на фон, а также интересующие нас символы по одному.
      */
      imagettftext($im,rand()%20+40,rand()%100-50,rand()%$this->height*0.8,rand()%50+25,$kcol,"./font/".$k.".ttf",$this->randomString(rand()%15));
      imagettftext($im,rand()%40+35,rand()%70-35,rand()%$this->height*0.8,rand()%25+25,$mcol,"./font/".$m.".ttf",$this->randomString(5+rand()%4));
      for($i=0;$istring);++$i)
      imagettftext($im,rand()%10+33,rand()%70-35,15+$i*$this->width/5*1.1+rand()%5,rand()%7+$this->height*0.73,$fcol,"./font/".$n.".ttf",$this->string[$i]);
      for($i=0;$i<$m/10;++$i)
      imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$mcol); // еще линии
      for($i=0;$i<$k/4;++$i)
      imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$mcol);  // и еще немного
      for($i=0;$i<$k/6;++$i)
      imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$fcol);  // и еще чуть-чуть
      header('Content-Type: image/png');
      imagepng($im);
      imagedestroy($im);
   }
   private function generateSymbols()   // генерация четырех цифр
   {
      $this->string=$this->leadingZero(rand()%10000,4);
   }
   private function leadingZero($num,$length) // дополнения числа num лидирующими нулями
   {                        // до длины length
      $str=strrev($num);
      for($i=strlen($str);$i<$length;++$i)$str.="0";
      return strrev($str);
   }
   private function randomString($length)  // генерируем случайный набор символов заданной длины
   {
      $list="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVXYZ!@#$%^&**()-=_+.,<>/\|;:";
      for($i=0,$str="";$i<$length;++$i)$str.=substr($list,mt_rand(0,strlen($list)-1),1);
      return $str;
   }
}
?>

Слегка доработав его и приведя в более подходящий вид, можно добиться генерации изображений, выглядящих например вот так:

Специально не выкладываю уже доведенный до ума класс, чтобы у читателей не возникало желания просто взять и воспользоваться им, это приведет лишь к очередной серии captcha-клонов.

Откуда возникает спам и как с ним бороться

Иван Блинков — Thu, 03 Jan 2008 20:25:00 +0300

На сегодняшний день далеко не каждый пользователь Сети является человеком, возможно это покажется странным для не интересующегося ИТ читателя, но существует множество программ, способных передвигаться по сайтам, следуя по гипер-ссылкам, как внутри одного сайта, так и переходя с одного сайта на другой (в целом такой тип программ называется spider или crawler). Такие программы могут иметь совершенно разное предназначение, самый распространенный пример: поисковые системы используют crawler'ов для пополнения своих индексов, но, к сожалению, далеко не все программы этого класса написаны для благих целей.

Good vs Evil

Большая часть "хороших" spider'ов используется лишь для сбора информации о сайте и следуют пожеланиям владельцев сайтов, оставленных ими в специальном файле под названием robots.txt, либо внутри HTML-разметки с помощью специально предназначенных для этого тэгов (этот механизм выходит за рамки данного повествования, так что позволю себе его пропустить, оставив как тему для отдельного разговора).

Но даже сбор информации во время автоматизированного путешествия программы по сайтам можно использовать в корыстных целях - на многих сайтах люди размещают свою контактную информацию для тех или иных целей, и некоторые сайты эту информацию "публикуют". Spider, настроенный на сбор контактной информации (в основном адресов электронной почты и номеров ICQ и прочих служб обмена сообщениями) может в очень сжатые сроки насобирать длинный список адресов, пригодный, например, для рассылки нежелательной рекламы, в простонародье называемой спам. Избежать попадания своей контактной информации в такие списки относительно просто - достаточно лишь следить за тем, чтобы она либо не публиковалась, либо была защищена любым из простейших способов защиты от такого рода программ, начиная от банального требования регистрации для просмотра контактных данных пользователей, заканчивая выводом адресов через изображения или шифрование посредством JavaScript.

Среди прочих функций, которые может выполнять такого рода программа, одной из наиболее часто используемых является возможность заполнения такой неотъемлемой составляющей практически любого сайта, как формы. Имея возможность заполнения существенно большего количества форм в единицу времени, чем человек, такие программы служат основным источником спама в гостевых книгах, форумах и блогах. Еще одним из возможных применений автоматического заполнения форм является регистрация на множестве интернет-ресурсов с целью получения какой-либо выгоды, например регистрация сайтов в каталогах. Помимо этого crawler перемещается по сайту с относительно высокой скоростью, что резко увеличивает нагрузку на сервер, особенно при недостаточно оптимизированном движке сайта и/или недостатке ресурсов сервера, выделяемых на выполнение скриптов сайта.

Защита форм от автоматического заполнения

Наверняка многие из вас раньше слышали термин CAPTCHA, но боялись спросить: что же он значит? Как не трудно догадаться этот термин является аббревиатурой :). Расшифровывается она как "Completely Automated Public Turing test to tell Computers and Humans Apart". Для меня до сих пор остается загадкой по какому принципу выбирались слова для составления этой аббревиатуры, наверное тупо случайным образом :). Смысл этой фразы в переводе на русский можно передать как "полностью автоматический способ отличить человека от компьютера". Конечно же имеется ввиду не внешние различия, а особенности их поведения на просторах сети Интернет. В роли "компьютера" в данном случае как раз выступают программы, о которых шла речь в самом начале. Эта технология позволяет владельцам сайтов, желающих исключить (по крайней мере чисто теоретически, на практике же - минимизировать) посещение своего ресурса "плохими" "компьютерами", крайне затруднить их использование.

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

Современные компьютеры не должны иметь возможности точно ее пройти.
Она должна быть "по зубам" большинству людей.
Не должна полагаться на тот факт, что потенциальный "злоумышленник" просто не знаком с принципом работы данной проверки.

Более подробно о возможностях этой технологии можно узнать, прочитав запись о нескольких вариантах ее реализации.