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

Данный пост является переводом англоязычной статьи, автор оригинала: Todd Hoff.

Статистика

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

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

Источники данных

• Baidu Aladdin Technology Guashudila
• Rachel Liao, лекция директора по архитектуре Baidu
• Baidu Chief Architect: алгоритмы на службе разработчиков Baidu
• Aladdin Plans

Если кто-то достаточно любопытен, чтобы нажать на приведенные ссылки — они все на китайском, так что статья написана на основе перевода Google Translate со всеми вытекающими последствиями. Даже за название «Aladdin» не ручаюсь, его тоже он придумал

О компании Baidu

Baidu.com является лидером китайского рынка интернет-поиска, объем которого достаточно значителен. На данный момент Китай насчитывает около 340-360 миллионов интернет-пользователей, что превышает общую численность населения США. Не трудно представить с каким трафиком приходится сталкиваться крупнейшей китайской поисковой системе.

Чтобы не быть голословным, еще немного цифр о Baidu:

• 100 миллионов поисковых запросов в день
• Более миллиарда проиндексированных страниц
• 300-400 миллионов проиндексированных сайтов

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

Как крупнейшей китайской поисковой системе, Baidu приходится быть чем-то большим, чем просто инструментом для поиска, это позволяет удовлетворять потребности потенциальных клиентов наиболее гармоничным и целесообразным образом. Помимо неустанной погони за технологическими инновациями, Baidu предпочитает придерживаться политики «потребности клиентов важнее всего».

Aladdin

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

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

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

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

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

Возможности платформы

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

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

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

После обязательной процедуры подачи и рассмотрения заявки пользователям платформы Aladdin предоставляются следующие возможности:

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

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

Взгляд с другой стороны

Да, вся платформа Aladdin по своей задумке очень искуственна: практически все делается вручную, но по сути это лишь процесс интеграции, а не работа с самим контентом. Для большинства других поисковых систем такой подход неприемлем: где найти столько людей, чтобы управлять огромными массивами данных вручную? Наоборот все поисковые системы стремятся по максимуму все автоматизировать и борятся с искуственным вмешательством в поисковый индекс (т.н. SEO), но... если вспомнить, что Baidu работает в Китае — вся затея начинает обретать здравый смысл. Как сама компания Baidu, так и большинство их потенциальных партнеров, клиентов и пользователей находится в примерно одинаковой ситуации: большое количество дешевой рабочей силы, относительно низкий уровень образования и профессиональной подготовки, а также прочие национальные особенности. В их ситуации не выгодно идти по пути Google и делать основной акцент на построении полностью автоматизированных систем анализа контента, добавления дополнительного материала к поисковым результатам и самим делать различные дополнительные приложения и сервисы. Намного выгоднее пойти по собственному пути, более адаптированному к ситуации в Китае, большое количество трудолюбивых людей позволяет строить сервисы коллективно, с привлечением партнеров, клиентов и заинтересованных лиц. Да, во многом вручную, за счет интеграции совершенно различных систем и сервисов, но зато более качественно и продуманно. В этом-то и заключается вся магия Китая.

Stack Overflow является любимым многими программистами сайтом, где можно задать профессиональный вопрос и получить ответы от коллег. Этот проект был написан двумя никому не известными парнями, о которых никто никогда раньше не слышал. Хорошо, не совсем так. Stack Overflow был создан топовыми программистами и звездами блогосферы: Jeff Atwood и Joel Spolsky. В этом отношении Stack Overflow похож на ресторан, владельцами которого являются знаменитости. По оценкам Joel'а около 1/3 программистов всего мира использовали этот интернет-ресурс, так что должно быть он представляет собой что-то достаточно полезное и интересное.

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

Если Вы стремитесь к масштабу Google, у Вас нет другого выхода, как двигаться в направлении не-SQL. Но Stack Overflow — это не Google, ровно как и подавляющее большинство других сайтов. Когда Вы задумываетесь о возможных вариантов дизайна Вашего проекта, попробуйте учесть и историю Stack Overflow, она тоже имеет право на жизнь. В этот век многоядерных машин с большим объемом оперативной памяти и невероятными темпами развития методов параллельного программирования, вертикальное масштабирование все еще является жизнеспособной стратегией и не должна сразу же отбрасываться в сторону просто так как это теперь больше не модно. Возможно в один прекрасный день мы получим лучшее из обоих миров, но на сегодняшний момент перед нами лежит большой болезненный выбор стратегии масштабирования, от которого определенно зависит судьба Вашего проекта.

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

Перевод статьи, автор оригинала — Todd Hoff. Возможно будет еще один пост с менее формальной информацией на ту же тему.

Статистика

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

• Легкодоступность: данные доступны посредством повсеместно используемого протокола HTTP.
• Распреденность: узлы могут работать и существовать на любых доступных серверах.
• Эластичность: имеется возможность динамического добавления и удаления узлов кластера на лету, без малейшего простоя системы и каких-либо изменений в конфигурации.
• Масштабируемость на уровне данных: документы разбиваются на группы и распределяются между доступными узлами с автоматической прозрачной балансировкой, в том числе и при добавлении и исключении узлов в кластере.
• Масштабируемость на вычислительном уровне: запросы и обновление данных распределяются по узлам, которые физически хранят используемые данные, тем самым минимизируется трафик и распределяется вычислительная нагрузка.
• Консистентность: система обеспечивает по-документную консистентность данных, таким образом гарантируя тот факт, что пользователь всегда получает самую свежую версию документа, обеспечивая изоляцию для параллельных модификаций документов.
• Отсутствие схемы: предоставляет JSON интерфейс, основанный на коллекциях; пользователям предоставляется возможность просто создать свою коллекцию и положить туда что угодно.
• Простота в работе: установка полностью работоспособного кластера заключается в вводе всего нескольких команд и не требует какого-либо редактирование XML-конфигов.
• Богатый функционал: поддерживаются push-down предикаты, запросы по диапазонам и серверные функции обновления.

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

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

Кстати про Terracotta, на основе которой работает данный продукт, тоже давно пора было уже написать, в ближайшее время займусь

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

Данная статья является переводом статьи MySpace Architecture, автором которой является Todd Hoff. Когда-то давно один из читателей этого блога просил меня осветить и эту тему, тогда я так и не решился из-за отсутствия моего личного интереса, но сейчас снова случайно наткнулся на эту статью и подумал: а почему бы и нет?

• Презентация: за сценой MySpace.com
• Внутри MySpace.com

Платформа

• ASP .NET 2.0
• Windows
• IIS
• MSSQL Server

Что внутри?

• 300 миллионов пользователей.
• Отдает 100Gbps в Интернет. 10Gbps из них является HTML контентом.
• 4,500+ веб серверов со связкой: Windows 2003 / IIS 6.0 / ASP .NET.
• 1,200+ кэширующих серверов, работающих на 64-bit Windows 2003. На каждом 16GB объектов находятся в кэше в оперативной памяти.
• 500+ серверов баз данных, работающих на 64-bit Windows и SQL Server 2005.
• MySpace обрабатывает 1.5 миллиарда просмотров страниц в день, а также 2.3 миллионов одновременно работающих пользователей в течении дня.
• Вехи по количеству пользователей:
  — 500 тысяч пользователей: простая архитектура перестает справляться
  — 1 миллион пользователей: вертикальное партиционирование временно спасает от основных болезненных вопросов с масштабированием
  — 3 миллиона пользователей: горизонтальное масштабирование побеждает над вертикальным
  — 9 миллионов пользователей: сайт мигрирует на ASP.NET, создается виртуализированная система хранения данных (SAN)
  — 26 миллионов пользователей: MySpace переходит на 64-битную технологию.
• 500 тысяч учетных записей было многовато для двух веб-серверов и одного сервера баз данных.
• На 1-2 миллионах учетных записей:
  — Они использовали архитектуру базы данных, построенную на концепции вертикального партиционирования, с отдельными базами данных для разных частей сайта, которые использовались для выполнения различных функций, таких как экран авторизации, профили пользователей и блоги.
  — Схема с вертикальным партиционированием помогала разделить нагрузку как для операций чтения, так и для операций записи, а если пользователям в друг оказывалась нужна новая функциональная возможность — достаточно было просто добавить еще один сервер баз данных для её обслуживания.
  — MySpace переходит от использования систем хранения, подключенных к серверам баз данных напрямую, к сетям хранения данных (SAN), при таком подходе целый массив систем хранения объединяется вместе специализированной сетью с высокой пропускной способностью, и сервера баз данных также получают доступ к хранилищам через эту сеть. Переход к SAN оказал положительное влияние как на производительность, так и на доступность и надежность системы.
• На 3 миллионах учетных записей:
  — Решение с вертикальным партиционированием не протянуло долго, так как им приходилось реплицировать какую-то часть информации (например информацию об учетных записях) по всем вертикальным частям базы данных. С таким большим количеством операций репликации данных один узел даже при незначительном сбое мог существенно замедлить обновление информации во всей системе.
  — Индивидуальные приложения вроде блогов на под-секциях сайта достаточно быстро стали слишком большими для нормальной работы с единственным сервером базы данных
  — Произведена реорганизация всех ключевых данных для более логичной организации в единственную базу данных
  — Пользователи были разбиты на группы по миллиону в каждой и каждая такая группа была перемещена на отдельный SQL Server
• 9–17 миллионов учетных записей:
  — Переход на ASP .NET, который требовал меньше ресурсов по сравнению с их предыдущим вариантом архитектуры. 150 серверов, использовавших новый код могли обработать нагрузку, для которой раньше требовалось 246 серверов.
  — Снова пришлось столкнуться с узким местом в системе хранения данных. Реализация SAN решило какую-то часть старых проблем с производительностью, но на тот момент потребности сайта начали переодически превосходить возможности SAN по пропускной способности операций ввода-вывода — той скорости, с которой она может читать и писать данные на дисковые массивы.
  — Столкнулись с лимитом производительности при размещении миллиона учетных записей на одном сервере, ресурсы некоторых серверов начали исчерпываться.
  — Переход к виртуальному хранилищу, где весь SAN рассматривается как одно большое общее место для хранения данных, без необходимости назначать конкретные диски для хранения данных определенной части приложения. MySpace на данный момент работает со стандартизированным обородуванием от достаточно нового вендора SAN — 3PARdata
• Был добавлен кэширующий уровень — прослойка из специализированных серверов, расположенных между веб-серверами и серверами данных, чья единственная задача была захватывать копии часто запрашиваемых объектов с данными в памяти и отдавать их веб-серверам для минимизации количества поиска данных в СУБД.
• 26 миллионов учетных записей:
  — Переход на 64-битные сервера с SQL Server на правах решения проблемы с недостатком оперативной памяти. С тех пор их стандартеый сервер баз данных оснащен 64 GB RAM.
• Горизонтальная федерация баз данных. Базы данных партиционируются в зависимости от своего назначения. У них есть базы данных с профилями, электронными сообщениями и так далее. Каждая партиция основана на диапазоне пользоваталей. По миллиону в каждой базе данных. Таким образом, у них есть Profile1, Profile2 и все остальные базы данных вплоть до Profile300, если считать, что у них на данный момент зарегистрировано 300 миллионов учетных записей.
• Кэш ASP не используется, так как он не обеспечивает достаточного процента попаданий на веб серверах. Кэш, организованный как промежуточный слой, имеет существенно более высокое значение данного показателя.
• Изоляция сбоев. Внутри веб-сервера запросы сегментируются по базам данным. Разрешено использование только 7 потоков для работы с каждуой базой данных. Таким образом, если база данных по каким-то причинам начинает работать медленно, только эти потоки замедлятся, в то время как остальные потоки будут успешно продолжать обрабатывать поток трафика.

Работа сайта

• Коллектор данных о производительности. Централизованная система сбора информации о производительности через UDP. Такой подход более надежен, чем стандартный механизм Windows, а также позволяет любому клиенту подключиться и увидеть статистику.
• Веб-система по просмотру дампов стеков процессов. Можно просто сделать клик правой кнопкой мыши на проблемном сервере и увидеть дамп стека процесов, управляемых .NET. И это после привычки каждой раз удаленно подключаться к серверу, влючать дебаггер и через полчаса получать свой ответ о том что же все таки происходит. Медленно, немасштабируемо и утомительно. Эта же система позволяет увидеть не просто стек процесса, но и предоставляет большое количество информации о контектсе, в котором он работает. Обнаружение проблем намного проще при таком подходе, например можно легко увидеть, что база не отвечает, так как 90 ее потоков заблокировано.
• Веб-система создания дампа heap-памяти. Создает дамп всей выделенной памяти. Очень удобно и полезно для разработчиков. Сэкономьте часы на выполнение этой работы вручную.
• Профайлер. Прослеживает запрос от начала до конца и выводит подробный отчет. В нем можно увидеть URL, методы, статус, а также все, что поможет идентифицировать медленный запрос и его причины. Обнаруживает проблемы с блокировкой потоков, непредвиденными исключениями, другими словами все, что может оказаться интересным. В то же время остается очень легковесным решением. Работает на одной машине из каждой VIP (группа из 100 серверов) в production-среде. Опрашивает 1 поток каждые 10 секунд. Постоянно следит за системой в фоновом режиме.
• Powershell. Новая программная оболочка от Microsoft, которая работает в процессе и передаем объекты между командами вместо работы с текстовыми данными. MySpace разрабатывает множество так называемых commandlets'ов для поддержки различных операций.
• Разработана собственная технология асинхронной коммуникации для того, чтобы обойти проблемы с сетевыми проблемами Windows и работать с серверами как с группой. Например, она позволяет доставить файл .cs, скомпилировать его, запустить, и доставить результат обратно.
• Развертывание. Обновление кодовой базы происходит с помощью упомянутой выше собственной технологии. Ранее происходило до 5 таких обновлений в день, сейчас же они происходят лишь раз в неделю.

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

• С помощью стека Microsoft тоже можно делать большие веб-сайты.
• Стоит использовать кэширование с самого начала.
• Кэш является более подходящим местом для хранения временных данных, не требующих персистентности, например информации о пользовательских сессиях.
• Встроенные в операционные систему возможности, например по обнаружению DDoS-атака, могут приводить к необъяснимым сбоям.
• Храните свои данные в географически удаленных датацентрах для минимизации проблем, связанных со сбоями в электросети.
• Рассматривайте возможности использования виртуализированных систем хранения данных или кластерных файловых систем с самого начала. Это позволит существенно параллелизировать операции ввода-вывода, а также увеличивать дисковое пространство без необходимости какой-либо реорганизации.
• Разрабатывайте утилиты для работы с production окружением. Невозможно смоделировать все ситуации в тестовой среде. Масштабируемость и все различные варианты использования API не могут быть симулированы в процессе тестирования качества программного обеспечения. Обычные пользователи и хакеры обязательно найдут такие способы использования вашего продукта, о которых вы даже никогда и не подумаете в процессе тестирования, хотя конечно большая часть все же обнаружима в процессе QA тестирования.
• Когда это возможно — лучше просто использовать дополнительное оборудование для решения проблем. Это намного проще, чем изменять поведение программного обеспечения для того чтобы решать задачи как-то по-другому. Примером может служить добавление нового сервера на каждый миллион пользователей. Возможно было бы более эффективным изменить подход к самой работе с СУБД, но на практике все же проще и дешевле добавлять все новые и новые сервера. По крайней мере на данный момент.

Хотя да, достаточно давно уже Google выпустили в свет платформу Google App Engine. Описание этого продукта меня заинтересовало еще до открытия публичного доступа к системе и я даже записался на полу-закрытое тестирование. Вскоре пришло подтверждение, что мол «мы рады сообщить, что Ваша учетная запись активирована и теперь у Вас есть возможность попробовать наш новый продукт, для этого нажмите ссылку такую-то». Но пришло оно как-то не очень удачно, когда ни лишнего свободного времени не было, да и идеи подходящей для создания чего-нибудь эдакого на новой платформе тоже на горизонте не наблюдалось. В общем зашел на их сайт, посмотрел админку, поставил демо-приложение, поигрался чуток и забросил. Но с тех пор руки так и не прекращали чесаться от желания попробовать GAE на каком-нибудь более приближенном к реальности приложении, что мне совсем недавно и довелось сделать. Спешу поделиться впечатлениями.

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

Если взглянуть издалека, то GAE представляет собой условно-бесплатный хостинг для веб-приложений, для разработчиков предоставляется все необходимое: начиная от минимально-необходимого SDK со встроенным веб-сервером, локально эмулирующим саму платформу, заканчивая неплохой документацией по самой системе и доступным из нее API от Google. Почему условно-бесплатный? Бесплатно приложениям выделяется лишь ограниченное количество вычислительных ресурсов, при превышении которых по выбору владельца приложения либо взимается вполне скромная плата, либо всем пользователям начинают показывать «извиняйте, заходите завтра» (в прямом смысле, счетчики потребления ресурсов сбрасываются ежедневно).

Но финансовый вопрос далеко не самый интересный, давайте взглянем на техническую сторону медали. Написанное с использованием SDK приложение загружается в production-окружение, которое физически размещается на тех самых известных кластерах Google, о которых у меня даже есть пост (конечно же под GAE используется только очень небольшая часть их вычислительных можностей). Причем все заботы о распределенной работе приложения на большом количестве машин платформа берет на себя: разработчику не нужно думать ни о балансировке нагрузки, ни о партиционировании данных, ни о других аспектах. Сразу же после окончания процессов загрузки и развертывания приложение готово становится готово к работе и доступно по домену третьего уровня на *.appspot.com, либо можно подключить свой отдельный домен.

Технические ограничения тоже имеют быть: для разработки под GAE можно использовать лишь небольшой набор языков программирования, в частности Python 2.5, а также Java и все остальные языки, компилируемые или интерпретируемые под JVM (JRuby, Scala, Rhino, etc.). Все приложения исполняются в песочнице, ограничивающей доступ к окружающему миру, то есть определенные подмножества языков становятся недоступны, например: доступ к файловым системам, встроенные средства обработки изображений, доступ к сторонним ресурсам по HTTP, отправка почты. Про реляционные базы данных, memcached и библиотеки, использующие нативный, платформозависимый код, также стоит забыть. Но не все так плохо, как кажется: для реализации всех «отобранных» у разработчиков функциональных компонент Google предоставляет собственные сервисы-заменители, доступные через хорошо документированный API или вовсе замаскированные под стандартные методы языка. В качестве дополнительных бонусов предоставляются и возможности по интеграции с другими продуктами Google, скажем можно легко сделать авторизацию пользователей в приложении по учетным записям от GMail или нотификацию пользователей по Jabber через GTalk.

Отдельного внимания заслуживает используемая в данной платформе система хранения данных, основанная на BigTable, о которой более подробно можно почитать в уже упомянутом посте об архитектуре Google. Если в двух словах, то она представляет собой распределенное нереляционное хранилище данных, автоматически обеспечивающее репликацию и кеширование данных, а также практически гарантирующее постоянную доступность данных вне зависимости от сбоев низлежащего оборудования. Для доступа к нему разработчикам предоставляется специальный API и язык доступа к данным GQL, слегка напоминающий упрощенный диалект SQL (лишь отдаленно). Продукт в обращении достаточно своеобразен, как оказалось самый простой способ привыкнуть к работе с ним — выкинуть из головы все знания о традиционных СУБД и взглянуть на процесс хранения данных с чистого листа. Разномастные JOIN'ы и прочие изыски лишь мешают думать в терминах подобных систем.

Закончив тему с рекламой GAE, позвольте перейти к моим личным впечатлениям. Попробовал я данную платформу на вполне конкретном примере (в конце поста дам ссылочку на частично-готовый результат, если кому интересно), надо же в конце-концов на что-то с пользой убивать внезапно появившееся свободное время. ОтJava и прочей компании языков, основанных на JVM, я невероятно устал на теперь уже «прошлой» работе, так что взор мой упал на Python и давно находящийся у меня на слуху (в основном благодаря Ивану Сагалаеву) фреймворк Django. Ни с тем, ни с другим я ранее почти не был знаком на практике, разве что когда-то пытался помогать своим очень хорошим подругам с прохождением Python в университете (пользуясь случаем, передаю привет Полине, Кате и Юле, очень по вам скучаю ). Стоит упомянуть, что существует несколько сборок Django, адаптированных под GAE, наиболее продуманным и готовым к эксплуатации мне показался проект под названием app engine patch, которым я и воспользовался для экспериментов.

Django, как известно, является вполне традиционным веб-фрейморком, пропагандирующим свою вариацию на тему MVC (именуемую MVT — Model-View-Template, но по сути абсолютно то же самое), а также целый ряд философских верований (вроде DRY, Don't repeat yourself), которым даже отведена отдельная страница на официальном сайте. Адаптированная под GAE версия фреймворка отличается от стандартной по большому счету лишь замененной частью Model, в которую очень неплохо вписался предоставляемый API к уже упоминавшемуся хранилищу данных. По всем остальным компонентам системы официальная документация по Django практически полностью актуальна и сильно помогла понять всю картину разработки веб-приложений с использованием данных технологий.

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

Предложение Google по использованию платформы GAE выглядит очень заманчиво, не смотря на все ограничения под нее можно как портировать существующие приложения, так и легко создавать новые. Бесплатное использование до превышения квот также не может не радовать (кстати квоты там рассчитаны на мировой рынок, превысить большинство из них в рамках рунета — надо постараться, мне кажется). Но закончить данное повествование мне всетаки хотелось парой недокументированных или вкратце официально упоминавшихся «ложек дегтя». Первая неприятная особенность: процессы, обрабатывающие пользовательские запросы приложений, умирают после очень небольшого времени простоя (таймаут судя по всему секунд 20-30). По истечении таймаута система освобождает использующиеся приложением ресурсы и когда после перерыва приходит очередной пользователь система вынуждена заново инициализироваться (чуть ли не заново компилировать байткод, хотя не уверен), что занимает около 5 секунд, а то и больше, во время которых пользователю ничего не остается кроме как терпеливо ждать. Сделали данный механизм видимо в связи с тем фактом, что подавляющее большинство развернутых приложений были сделаны просто чтобы побаловаться и были сразу же заброшены, что делает неэффективным постоянное держание в готовом состоянии даже одного процесса для каждого приложения. Таким образом использование GAE для тяжелых веб-приложений с небольшой целевой аудиторией не очень эффективно.  Минус второй: существуют некоторые жесткие ограничения, которые не разрешают увеличивать даже за деньги (по крайней мере расценок не видно). В их число входят максимальное время обработки одного запроса (30 секунд, правда не ясно распространяется ли это на выполнение задач в Task Queue и местном аналоге Cron'а), 30 активных процессов, обрабатывающих запросы приложения (что влечет за собой достаточно жесткое ограничение на количество запросов в секунду в районе нескольких сотен), максимальный размер HTTP запроса/ответа в 10 мегабайт и некоторые другие. В итоге «тяжелые» вычисления на GAE не погоняешь (хотя есть варианты с применением AJAX и, соответственно, большого количества запросов к GAE), от Digg-эффекта или DDOS'а есть шанс не уберечься, хостинг файлов не соорудить, но... разве это ограничения? Есть масса более интересных типов веб-приложений, способных прекрасно существовать в такой среде. Да и в крайнем случае всегда можно связаться с представителями Google с просьбой в виде исключение для Вашего приложения, судя по их заявлениям все ограничения носят искусственный характер и служат лишь для защиты от потребления неоправданно большого количества вычислительных ресурсов плохо спроектированных приложениями.

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

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

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

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

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

Данный текст является переводом статьи How Ravelry Scales to 10 Million Requests Using Rails, автор оригинала — Todd Hoff.

Статистика

• 10 миллионов запросов ежедневно обрабатывается Rails (AJAX + RSS + API)

• 3.6 миллиона просмотров страниц ежедневно

• 430,000 зарегистрированных пользователей. 70,000 активно пользуются сайтом ежедневно. 900 новых пользователей регистрируется ежедневно.

• 2.3 миллиона проектов по вязанию, 50000 новых сообщений на форуме ежедневно, всего 19 миллионов сообщений на форуме, 13 миллионов сообщений, 8 миллионов фотографий (большая часть размещена на Flickr).

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

• Монетизация: рекламодатели + магазин соответствующей продукции + продажа узоров

Platform

• Ruby on Rails (1.8.6, Ruby GC патчи)

• Percona сборка MySQL

• Gentoo Linux

• Servers: Silicon Mechanics (не арендуемые, в их собственности)

• Хостинг: Colocation от Hosted Solutions

• Интернет-канал: Cogent (очень дешево)

• Capistrano для развертывания.

• Nginx существенно более быстрый и менее требовательный к оперативной памяти по сравнению с Apache.

• Xen для виртуализации

• HAproxy для балансировки нагрузки.

• Munin для мониторинга.

• Tokyo Cabinet/Tyrant для кеширования больших объектов

• Nagios для предупреждений

• HopToad для уведомлений об исключительных ситуациях.

• NewRelic для тонкой настройки

• Syslog-ng для агрегации логов

• S3 для хранения данных

• Cloudfront в роли CDN

• Sphinx для текстового поиска

• Memcached для кеширования маленьких объектов

Архитектура

• 7 серверов (Gentoo Linux). Средствами виртуализации (Xen) создано 13 виртуальных серверов.
  * Для обработки пользовательских запросов используются Nginx и Haproxy. Запросы проходят следущую цепочку: nginx -> haproxy -> apache + mod_passenger.
  * Один небольшой сервер для резервного копирования данных.
  * Один небольшой вспомогательный сервер для некритичных процессов и тестирования новых версий.
  * 2 сервера с 32 GB оперативной памяти для master+slave баз данных, а также поисковой системы Sphinx.
  * 3 сервера приложений, состоящих из 6 Apache Passenger и запущенных экземпляров Ruby, каждый ограничен 20-ю потоками. Суммарно 6 четырехядерных процессоров и 40 GB оперативной памяти. Часть оперативной памяти большую часть времени простаивает.

• 5 терабайт данных располагается в Amazon S3. Cloudfront используется как CDN.

• Tokyo Cabinet/Tyrant используется вместо memcached в некоторых местах для кеширования более крупных объектов, в частности уже размеченного текста в HTML.

• HAproxy и Capistrano используются для вывода новых версий сайта без негативного влияния на производительность и работу пользователей.

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

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

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

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

• Успех не обязательно должен быть связан с масштабностью проекта, намного большее значение имеет стабильная и качественная реализация [Jeff Putz].

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

• Продолжайте получать удовольствие. Casey перешел на Ruby on Rails так как ему хотелось снова заняться программированием с энтузиазмом. Этот факт стал одним из основных факторов, которые помогли сделать проект успешным.

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

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

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

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

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

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

Предистория

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

Само же тестирование меня несколько позабавило. Не знаю кто его составлял, но суть его была примерно в следующем: за полтора часа предлагплось ответить на 10 вопросов, семь из которых формулировалось примерно как "какой результат будет получен после выполнения программы <код на перле>". Основной прикол был в том, что этот код написан на Perl там сказано не было, если честно с первого вопроса я его даже не признал, приняв за какой-то псевдо-код. На втором вопросе до меня дошла-таки истина, благодаря не столь отдаленному во времени посещению YAPC::Russia 2008 «May Perl» и, в частности, проходившему там мастер-классу Ивана Сережкина. Дальнейшее тестированме проходило с открытым vim'ом и /bin/perl под рукой, лишь один или два вопроса пришлось неторопливо погуглить...

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

День первый

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

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

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

После непродолжительного перерыва на кофе слово перешло еще одному представителю компании Яндекс — Филиппу Дельгядо. На этот раз речь пошла о веб-проектах средних размеров, которым необходимо справляться с серьезной нагрузкой (наравне с прочими нефункциональными требованиями) но с несколько другой точки зрения, программиста. Выступление также носило обзорный характер и содержало в себе повествования о достаточно большом количестве граблей, на которые могут натыкаться те или иные проекты. На самом деле по затрагиваемым темам мне в свое время довелось прочитать достаточно много материалов, пару раз споткнуться на практике и даже написать пару постов, так что лично я рассматривал этот доклад как закрепление знакомых тем. Разве что затронутый вопрос горизонтального масштабирования хранения данных меня несколько смутил: не знаю, может быть я несколько не в теме или еще что, но суть была примерно такова, что под partitioning'ом рассматривались только псевдо-универсальные решения, входящие в комплект некоторых СУБД, в то время как sharding'ом было предложено понимать все остальные, «самопальные», решения, специфичные для конкретного проекта. Я же почему-то всегда рассматривал такой подход как нечто концептуально-общее, так как конкретика реализации не важна, а важна сама идея данного подхода, и считаю эти два слова достаточно близкими синонимами (ровно как и многочисленные их русские аналоги), хотя может быть я и не прав...

Следующее выступление было, пожалуй, лучшим из увиденных мной в первый день. В программке оно значилось как: «Как писать высокопроизводительные веб-сервера», Антон Самохвалов (Яндекс). Были рассмотрен ряд возможных подходов к написанию веб-серверов: начиная банальными неработоспособными однопоточными вариантами и заканчивая противопоставлению вполне рабочих вариантов: threads, FSM и co-routine. Докладчик оказался убежденным сторонником подхода с использованием co-routine или на худой конец thread'ов, а также использующего схожую идеологию веб-сервера от ASF. Презентация сыграла лишь роль детонатора для последующей бурной дискуссии с участием многих слушателей, а также ведущего этой секции — Игоря Сысоева, по совместительству разработчика известного в «узких» кругах проекта nginx. Ничего удивительного, что обсуждение плавно перетекло в Holy War: Threads vs FSM, но в отличии от знаменитых войн анонимусов на linux.org.ru, шоу выдалось захватывающим и информационно-полезным. Основными аргументами были даже не цифры о производительности, полученные ребятами из Яндекса в полу-синтетических тестах (Антон активно упоминал тот факт, что на примере базового поиска Яндекса использованние thread'ы давало примерно 10% прирост производительности по сравнению с FSM), а скорее споры о maintenability кода и его простоте, а также теоретических пределах использования этих подходов в разных условиях (речь даже дошла до гипотетических ситуаций с использованием более чем четырехядерных процессоров). Довелось выслушать мнения профессионалов по обе стороны «баррикад» и самостоятельно сделать все требуемые выводы, самый банальный и немаловажный из которых заключается просто в том факте, что оба подхода имеют право на жизнь в реальных проектах и какой из них использовать очень во многом зависит от личных предпочтений разработчиков и специфики проекта.

Далее по расписанию был запланировал обеденный перерыв, на котором я решил заглянуть в аудиторию параллельного потока (где весь день рассказывали о различных системах хранения данных). В это время там как раз проходил доклад Павла Уварова из Рамблер о их собственной разработке для хранения и передачи данных под названием HCS (читается почему-то как «хикс»). Самое начало доклада я, к сожалению, пропустил, но почти с первых же увиденных мной слайдов проект меня заинтересовал. Суть данной технологии примерно характеризуется ее названием: Hierarchically Compressed Stream. С одной стороны это формат хранения иерархически структурированных данных, с другой же — данные в нем представляют обычный файл, который легко обернуть в произвольный протокол передачи потоковых данных (т.е. например просто раздавать через любой HTTP-сервер). По представленным в презентации benchmark'ам запись и линейный доступ к данным в этом формате происходит в разы, а то и порядки быстрее по сравнению с РСУБД, а для ускорения случайного доступа, на сколько я понял, имеется возможность построения индекса по верхнему уровню иерархии. Помимо всего прочего, Павел обрадовал аудиторию, что данная технология в ближайшем времени будет опубликована в opensource, обязательно надо будет попробовать ее в деле как только появится возможность.

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

После этого доклада можно было стать свидетелем повествования работников mail.ru сначала об их собственной разработке под названием Imagine Framework, которая тоже вполне соответствует своему названию: ее можно разве что представить — ни одного примера кода, закрыт для использования только в рамках mail.ru, много слов ни о чем и общий стиль изложения в духе «вот какую клевую штуку мы придумали, но никому не дадим и не покажем». В общем я даже, если честно, не понял для какого он языка программирования предназначен и чем он лучше (или хотябы просто отличается) от opensource аналогов (упоминались собственные системы кэширования, мониторинга и бинарный протокол). В итоге я до конца так и не дослушал и ушел снова в соседний поток слушать про хранение слабосвязанных данных.

Илья Космодемьянцев из SUP Fabrik вел рассказ о том, как могут развиваться события, если тот или иной проект сталкивается с хранением данных, плохо вписывающихся в модель РСУБД. Разработчикам приходят мысли о создании собственного специфического формата хранения данных, о том с какими проблемами могут столкнуться в процессе. Возможные варианты решения проблем также рассматривались, например в виде написания не формата хранения данных, а собственного хранилища для, например, MySQL — это может помочь избежать части проблем. Помимо этого выдвигалось очень спорное предложение о создании некого «UseCase API», которое могло бы позволить инкапсулировать для бэкэнда все особенности хранения данных в случае их нетрадиционности. Хотя на практике подобные методики применяются достаточно давно, особенно в объектно-ориентированных языках программирования в виде data-access objects.

После еще одного кофе-брейка оставалось лишь два заключительных доклада первого дня, из которых я решил посетить нечто под названием «Масштабный Jaabber-кластер, IM и не только» от Андрея Федоровского из РБК. Начало доклада было достаточно примитивным — что такое Jabber и с чем его едят, всем это и без того было известно, так что было достаточно скучно. Даже обзор доступных расширений не открыл ничего нового — все те же давно знакомые вещи, разве что некий интерес вызвал процесс отправки бинарных данных (т.е. произвольных файлов): было заявлено что отправка файла временно обрывает поток XML-данных и отправляет вместо него бинарный поток, но не заставил себя ждать очевидный вопрос: а как же тогда происходит общение в этот момент. Вокруг этого образовалась небольшая дискуссия, но к консенсусу прийти так и не удалось. Далее пошел рассказ собственно о том как на сегодняшний день можно построить Jabber-кластер — подробностей повествованию явно не хватало, но суть была примерно такова: единственным более-менее сносным Jabber-сервером является ejabberd, написанный на до сих пор экзотическом языке Erlang (что впоследствии подтвердили сотрудники Яндекс: в своем проекте Я.Онлайн они используют тоже его). По-умолчанию он использует нативное для Erlang хранилище данных под названием Mnesia, но в том проекте РБК, на основе которого и строился весь доклад (правда я так и не понял как он называется), почему-то побоялись его использовать (видимо из-за нежелания разбираться в том как оно функционирует) и использовали имеющуюся возможность интеграции с более традиционной СУБД — PostgreSQL. В дискуссии после доклада речь шла скорее о самом ejabberd, Erlang'е, острой нехватке программистов на нем и тому подобных вещах, чем о самом докладе.

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

День второй

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

Предисловие

Сообщение о публикации двух презентаций c JavaOne 2008 о LinkedIn и их обобщении от Overn Hurvitz пронеслось по русскоязычным новостным ресурсам уже достаточно давно, но время черкнуть пару строк обо всем этом нашлось у меня только сейчас.

Статистика

• 22 миллиона пользователей;
• 4+ миллиона уникальных посетителей в день;
• 40 миллионов просмотров страниц в день;
• 2 миллиона поисковых запросов в день;
• ежедневно отправляются 250 тысяч приглашений;
• 1 миллион ответов в день;
• 2 миллиона электронных сообщений ежедневно.

Платформа

• Solaris (как x86, так и SPARC)
• Tomcat и Jetty
• Oracle и MySQL
• Никакого ORM
• ActiveMQ для JMS
• Lucene в качестве основы для поиска
• Spring в роли «клея»

Серверная архитектура

2003—2005

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

2006

• Добавлена репликация для уменьшения нагрузки на основную базу данных. Реплики предоставляют данные в режиме «только для чтения», а репликация ведется в асинхронном режиме с помощью дополнительного компонента под названием Databus, с его появлением обновление данных стало выглядеть следующим образом:

  – сначала какие-либо изменения происходят в веб-приложении;

  – веб-приложение обновляет основную базу данных;

  – она, в свою очередь, отправляет обновления на Databus;

  – далее уже Databus обновляет: реплики, Облако и поисковый индекс.

• Поиск был вынесен на отдельный сервер.

2008

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

Облако

• «Облаком» в LinkedIn называют сервер, который кэширует весь граф социальной сети в памяти;
• его размеры: 22 миллиона вершин и 120 миллионов ребер;
• занимает 12GB оперативной памяти;
• одновременно держится в памяти в 40 экземплярах;
• построение Облака из данных, в дисковой системе, занимает 8 часов;
• обновления происходят в режиме реального времени с помощью Databus;
• во время остановки данные записываются на диск;
• кэш реализован с помощью C++, а доступ предоставляется по JNI;
• они выбрали именно C++ так как требовалось использовать минимум оперативной памяти, а также, задержки, связанные с Garbage Collection, были неприемлемыми.
• размещение всех данных в памяти является ограничением, но, как удалось выяснить в LinkedIn, разбиение графов на части — не самая тривиальная задача.

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

Помимо этого используется кэширование профилей пользователей средствами EHcache. Одновременно в памяти хранится до 2 миллионов профилей (из 22 миллионов). Изначально планировалось использовать алгоритм LFU, но оказалось, что иногда EHcache зависал секунд на 30 во время перерасчета LFU, таким образом было принято решение о использовании вместо него алгоритма LRU.

Архитектура коммуникации

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

Сервис постоянных сообщений

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

• вся система работает асинхронно и активно использует JMS;
• клиенты отправляют сообщения так же через JMS;
• далее сообщения перенаправляются с помощью сервиса маршрутизации в соответствующий почтовый ящик или напрямую в обработку электронной почты;
• доставка сообщений происходит как с помощью Pull (клиенты запрашивают свои сообщения), так и с использованием Push (т.е. отправки сообщений);
• помимо этого используется Spring с их собственными закрытыми расширениями, использующими HTTP-RPC.

Приемы, способствующие масштабируемости

• Функциональное сегментирование: отправленные, полученные, архивные сообщения. (т.е. вертикальное сегментирование)
• Классовое сегментирование: пользовательские, гостевые, корпоративные почтовые ящики.
• Сегментирование по диапазонам: по идентификаторам пользователей или по лексикографическим диапазонам самих сообщений. (т.е. горизонтальное сегментирование)
• Асинхронное выполнение операций.

Сервис сетевых обновлений

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

Изначальная архитектура (до 2007 года)

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

В 2008 году вся эта система поэтапно эволюционировала собственно в сам сервис сетевых обновлений:

Первая итерация

• клиент отправляет единственный запрос сервису сетевых обновлений;
• этот сервис в свою очередь параллельно отправляет всем остальным сервисам соответствующие запросы.
• результаты аггрегируются и все вместе возвращаются клиенту;
• весь процесс основывается на Pull.

Вторая итерация

• стал использоваться метод Push: каждый раз, когда происходит какое-либо событие, они помещаются в пользовательский «почтовый ящик», в момент запроса пользователя ему возвращается просто содержимое, уже ожидающее своего звездного часа в специально том самом «ящике»;
• такой подход сильно ускоряет процесс чтения, так как на тот момент данные уже готовы;
• с другой стороны, какая-то часть данных может так никогда и не понадобиться, что приводит к бесполезным передвижениям данных и лишнему используемому дисковому пространству;
• небольшая часть обработки данных все же производится уже в момент запроса пользователя (например, объединение нескольких обновлений от определенного пользователя в одно);
• обновления хранятся в CLOB'ах: по одному CLOB'у на каждый тип обновления для каждого пользователя (то есть в сумму около 15 CLOB'ов на каждого пользователя);
• сначала использовался размер CLOB'ов равный 8 KB, что было явно больше требуемого и приводило к существенному количеству неиспользуемого дискового пространства.
• вместо CLOB'ов можно было бы использовать дополнительные таблици по одной на каждый тип обновлений, но в этом случае пришлось бы постоянно удалять из них устаревшие записи, что было бы чрезвычайно неэффективно.
• в дополнение к этому использовался JMX для мониторинга и изменения конфигурации в реальном времени, что оказалось очень удобным и полезным.

Третья итерация

• Цель: повысить производительность путем сокращения количества обновлений CLOB'ов, так как они требуют много вычислительных ресурсов.
• Был добавлен буфер: колонки в таблицах типа varchar (4000), в которых данные помещались изначально. При полном заполнении ячейки данные перемещаются в CLOB; это позволило на порядок сократить количество их обновлений.
• Уменьшен размер самих сообщений об обновлениях.

И напоследок пару советов от LinkedIn

• нельзя бесконечно долго ограничиваться одной базой данных: используйте много баз данных как с вертикальным, так и с горизонтальным сегментированием данных;
• забудьте о ссылочной целостности и кросс-серверных JOIN'ах;
• забудьте о 100% целостности данных;
• при большом масштабе издержки могут стать проблемой: оборудование, базы данных, лицензии, системы хранения данных, электроэнергия и так далее;
• как только вы станете достаточно крупны и популярны, спаммеры и прочие злые люди не заставят себя долго ждать;
• не забывайте про кэширование!!!
• используйте асинхронные потоки данных;
• аналитика и построение отчетов может стать непростой задачей, постарайтесь задуматься о них заранее в процессе планирования системы;
• имейте всегда ввиду, что Ваша система может упасть в любой момент;
• не стоит недооценивать траекторию своего роста.

P.S.

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

Кстати если Вы еще не успели подписаться на RSS — сейчас самое время!

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

A Bigtable is a sparse, distributed, persistent multidimensional sorted map.

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

map

За этим термином нет четкого устоявшегося обозначения в русском языке (да и в английском тоже все далеко не так однозначно), математики обычно называют это отображением одного множества в другое, в то время как если Вы знакомы с программированием, то Вам наверняка больше знакомы будут более знакомы такие обозначения, как ассоциативный массив (PHP), словарь (Python), хэш (Ruby) или объект (JavaScript).

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

{
  "qqqq" : "some",
  "abc" : "sample",
  "zz" : "JSON",
  "123" : "map",
  "mnbvcxz" : "looks like this"
}

persistent

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

distributed

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

• Как HBase, так и BigTable сами по себе могут функционировать на большом количестве серверов, которые можно разделить на две большие категории: master и slave. Slave сервера собственно выполняют всю работу с данными, а master — лишь только координируют их действия и управляют процессом в целом. Этот факт обеспечивают высокую степень устойчивости к сбоям (в HBase правда количество master-серверов ограничено одним, что представляет собой единственную точку, сбой в которой приведет к отказу всей системы, но это лишь временная проблема, которую наверняка устранят в следующих версиях), а также существенно облегчает масштабируемость всей системы так как добавление дополнительных серверов (а значит и увеличение производительности и вместительности системы) достаточно тривиально, безболезненно и не мешает общему ее функционированию.
• Помимо этого каждая из этих систем обычно использует для хранения данных кластерную файловую систему (HBase — HDFS, а BigTable — GFS), которые тоже по своей природе являются распределенными и функционируют по схожему принципу, обеспечивая дополнительную сохранность данных, реплицируя их в нескольких экземплярах на нескольких серверах (обычно трех).

sorted

HBase и BigTable не строят никакие индексы для ускорения процесса извлечения данных, единственное используемое в них правило заключается в следующем: каждый slave-сервер в системе отвечает за определенный диапазон ключей (от и до определенных его значений), и держит все записи в строгом лексикографическом порядке по ключам (заметьте: сортировку значений никто не гарантирует!). Продолжая пример с JSON это выглядело бы примерно вот так:

{
  "123" : "map",
  "abc" : "sample",
  "mnbvcxz" : "looks like this",
  "qqqq" : "some",
  "zz" : "JSON"
}

Этим фактом можно активно пользоваться при планировании использовании системы, например если в качестве ключей планируется использовать доменные именные имена, то имеет смысл использовать их в «развернутом» виде, например: «com.example.www» вместо «www.example.com». Это почти наверняка обеспечит попадание всех поддоменов одного и того же домена на один slave-сервер, а также группировку доменов по зонам.

multidimensional

До сих пор ключ интерпретировался нами как нечто единое и неделимое, но на самом деле в данной ситуации это далеко не так. На самом деле пространство имен HBase и BigTable имеет несколько пространств, по аналогии с трехмерным материальным пространством, где есть ширина, высота и глубина. Если мы попытаемся представить это с помощью JSON, то это будет выглядеть как набор вложенных простых map'ов:

{
  "table-1":
  {
     "column-family-1":
     {
        "column-1":
        {
           "row-1":
           {
              "timestamp-1": "value-1",
              "timestamp-2": "value-2",
              "timestamp-3": "value-3"
           },
           "row-2":
           {
              "timestamp-1": "value-4",
              "timestamp-2": "value-5",
              "timestamp-3": "value-6"
           }
        },
        "column-2":
        {
           "row-1":
           {
              "timestamp-1": "value-1",
              "timestamp-3": "value-3"
           },
           "row-2":
           {
              "timestamp-1": "value-4",
              "timestamp-2": "value-5",
              "timestamp-3": "value-6"
           }
        }
     "column-family-2":
     {
        "column-1":
        {
           // ...
        },
        "":
        {
           "row-1": "some-value"
        }
        // ...
     }
     }
  }
}

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

• таблицы;
• наборы столбцов;
• столбцы;
• строки;
• время;

Таким образом, каждое значение в хранилище данных однозначно соответствует ключу, состоящему из пяти компонентов, например в примере значению «value-5» соответствует ключ, состоящий из:

• table-1;
• column-family-1;
• column-1;
• row-2;
• timestamp-2;

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

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

sparse

Развивая мысль предыдущего абзаца, можно понять, что наличие значения столбца в каждой строке вовсе не обязательно, оно запросто может и отсутствовать вовсе. Таким образом каждая строка может содержать произвольное количество значений для столбцов в рамках одной column family, ровно как может и не содержать их вовсе. Несуществующие данные не хранятся в виде какого-либо NULL-значения, они просто отсутствуют. Запрос на несуществующие данные просто вернет пустой результат. Если же взглянуть с другой стороны, то тот же самый факт можно представить и как возможность наличия пробелов в списке ключей строк.

И напоследок...

хочется сказать, что все это лишь дело терминологии, ровно то же самое можно подразумевать и под краткой фразой «нереляционная база данных», не смотря на то, что она существенно менее точна и полноценна. В данном контексте самое главное лишь чтобы люди просто понимали друг друга. Надеюсь после прочтения этого поста в вашем сознании сложилась четкая картина этого продукта и предоставляемых им возможностей, которая Вам пригодится как для «общего развития», так и для потенциального практического применения этого продукта. Если остались неясные моменты — смело оставляйте комментарии. Традиционная подписка на RSS — приветствуется