Статистика

• Общее
  • Ежедневная аудитория Google составляет около 1 миллиарда человек
    • По данным Alexa больше половины каждый день Google пользуются более половины аудитории интернета
    • По данным IWS аудитория интернета составляет 2.1 миллиарда человек
  • Используется более 900 тысяч серверов
    • Планируется расширение до 10 миллионов серверов в обозримом будущем
  • 12 основных датацентров в США, присутствие в большом количестве точек по всему миру (более 38)
  • Около 32 тысяч сотрудников в 76 офисах по всему миру
• Поиск
  • За последние 14 лет среднее время обработки одного поискового запроса уменьшилось с 3 секунд до менее 100 миллисекунд, то есть в 30 раз
  • Более 40 миллиардов страниц в индексе, если приравнять каждую к листу А4 они бы покрыли территорию США в 5 слоев
  • Более 1 квинтиллиона уникальных URL (10 в 18 степени); если распечатать их в одну строку, её длина составит 51 миллион километров, треть расстояния от Земли до Солнца
  • В интернете встречается примерно 100 квинтиллионов слов, чтобы набрать их на клавиатуре одному человеку потребовалось бы примерно 5 миллионов лет
  • Проиндексировано более 1.5 миллиардов изображений, чтобы их сохранить потребовалось бы 112 миллионов дискет, которые можно сложить в стопку высотой 391 километр
• Gmail
  • Активных пользователей более 170 миллионов
  • Второй по популярности почтовый сервис в США, третий в мире (по данным comScore)
  • При текущем темпе роста аудтории GMail и конкурентов, он станет лидером рынка через 2-3 года
• Google+
  • Более 40 миллионов пользователей на октябрь 2011, при запуске в июне 2011
  • 25 миллионов пользователей за первый месяц
  • 70:30 примерное соотношение мужчин и женщин
  • Себестоимость разработки больше полумиллиарда долларов
• YouTube
  • Загружается более 13 миллионов часов видео в год
  • Каждую минуту загружается 48 часов видео, что соответствует почти 8 годам контента или 52 тысячам полнометражных фильмов в день
  • Более 700 миллиардов просмотров видео в год
  • Месячная аудитория составляет 800 миллионов уникальных посетителей
  • Несколько тысяч полнометражных фильмов в YouTube Movies
  • Более 10% всех видео в формате HD
  • 13% просмотров (400 миллионов в день) происходит с мобильных устройств
  • До сих пор работает в убыток, лишь 14% просмотров видео приносят выручку с рекламы
• Финансы
  • Выручка порядка 36 миллиардов долларов в год
  • Прибыль после налогов порядка 10 миллиардов долларов в год
  • Капитализация порядка 55 миллиардов долларов

Архитектура

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

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

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

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

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

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

• Точное измерение потребления электроэнергии всеми компонентами позволяет определить возможности по его уменьшению;
• В датацентрах Google тепло, что позволяет экономить на охлаждении;
• При проектировании датацентра уделяется внимание даже незначительным деталям, позволяющим сэкономить даже немного — при таком масштабе это окупается;
• Google умеет охлаждать датацентры практически без кондиционеров, с использованием воды и её испарения (см. как это реализовано в Финляндии).

В Google активно пропагандируют максимальное использование возобновляемой энергии. Для этогоe заключаются долгосрочные соглашения с её поставщиками (на 20 и более лет), что позволяет отрасли активно развиваться и наращивать мощности. Проекты по генерации возобновляемой энергии, спонсируемые Google, имеют суммарную мощность более 1.7 гигаватт, что существенно больше, чем используется для работы Google. Этой мощности хватило бы для обеспечения электричеством 350 тысяч домов.

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

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

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

• Резервное питание, интегрированное в блок питания сервера, обеспеченное стандартными 12V батарейками;
• «Серверный сендвич», где материнские платы с двух сторон окружают водяную систему теплоотвода в центре стойки;
• Датацентр из контейнеров.

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

Платформа

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

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

• Google File System: распределенная файловая система, состоящая из сервера с метаданными и теоретически неограниченного количества серверов, хранящих произвольные данные в блоках фиксированного размера.
• BigTable: распределенная база данных, использующая для доступа к данным две произвольных байтовых строки-ключа (обозначающие строку и столбец) и дату/время (обеспечивающие версионность).
• MapReduce: механизм распределенной обработки больших объемов данных, оперирующий парами ключ-значение для получения требуемой информации.

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

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

Google Colossus

Новая архитектура GFS была спроектирована для минимизации задержек при доступе к данным (что критично для приложений вроде GMail и YouTube), не в ущерб основным свойствам старой версии: отказоустойчивости и прозрачной масштабируемости.

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

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

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

По прогнозам Google текущий вариант реализации распределенной файловой системы «уйдет на пенсию» в 2014 году из-за популяризации твердотельных накопителей и существенного скачка в области вычислительных технологий (процессоров).

Google Percolator

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

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

Новая система получила довольно своеобразное название Percolator, попытки узнать что оно значит приводит к различным устройствам по фильтрации дыма, кофеваркам и непойми чему еще. Но наиболее адекватное объяснение мне пришло в голову, когда я прочитал его по слогам: per col — по колонкам.

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

Веб-документы или любые другие данные изменяются/добавляются в систему посредством модифицированного API BigTable, а дальнейшие изменения  в остальной базе осуществляются посредством механизма »обозревателей». Если говорить в терминах реляционных СУБД, то обозреватели — что-то среднее между триггерами и хранимыми процедурами. Обозреватели представляют собой подключаемый к базе данных код (на C++), который исполняется в случае возникновении изменений в определенных колонках BigTable (откуда, видимо, и пошло название). Все используемые системой метаданные также хранятся в специальных колонках BigTable. При использовании Percolator все изменения происходят в транзакциях, удовлетворяющих принципу ACID, каждая из которых затрагивает именно те сервера в кластере, на которых необходимо внести изменения. Механизм транзакций на основе BigTable разрабатывался в рамках отдельного проекта под названием Google Megastore.

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

В качестве бонуса в этой схеме удалось избежать еще двух недостатков MapReduce:

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

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

Тем не менее, при выбранной архитектуре Google удалось достичь практически линейного масштабирования при увеличении вычислительных мощностей на много порядков (см. график, основан на тесте TPC-E). Дополнительные накладные расходы, связанные с распределенной природой решения, в некоторых случаях до 30 раз превосходят аналогичный показатель традиционных СУБД, но у данной системы есть солидный простор для оптимизации в этом направлении, чем Google активно и занимается.

Google Spanner

Spanner представляет собой единую систему автоматического управления ресурсами всего парка серверов Google.

Основные особенности:

• Единое пространство имен:
  • Иерархия каталогов
  • Независимость от физического расположения данных
• Поддержка слабой и сильной целостности данных между датацентрами
• Автоматизация:
  • Перемещение и добавление реплик данных
  • Выполнение вычислений с учетом ограничений и способов использования
  • Выделение ресурсов на всех доступных серверах
• Зоны полу-автономного управления
• Восстановление целостности после потерь соединения между датацентрами
• Возможность указания пользователями высокоуровневых требований, например:
  • 99% задержек при доступе к этим данным должны быть до 50 мс
  • Расположи эти данные на как минимум 2 жестких дисках в Европе, 2 в США и 1 в Азии
• Интеграция не только с серверами, но и с сетевым оборудованием, а также системами охлаждения в датацентрах

Проектировалась из расчета на:

• 1-10 миллионов серверов
• ~10 триллионов директорий
• ~1000 петабайт данных
• 100-1000 датацентров по всему миру
• ~1 миллиард клиентских машин

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

Прочие компоненты платформы

Платформа Google в конечном итоге сводится к набору сетевых сервисов и библиотек для доступа к ним из различных языков программирования (в основном используются C/C++, Java, Python и Perl). Каждый продукт, разрабатываемый Google, в большинстве случаев использует эти библиотеки для осуществления доступа к данным, выполнения комплексных вычислений и других задач, вместо стандартных механизмов, предоставляемых операционной системой, языком программирования или opensource библиотеками.

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

• GWT для реализации пользовательских интерфейсов на Java;
• Closure — набор инструментов для работы с JavaScript;
• Protocol Buffers — не зависящий от языка программирования и платформы формат бинарной сериализации структурированных данных, используется при взаимодействии большинства компонентов системы внутри Google;
• Snappy — быстрая компрессия данных, используется при хранении данных в GFS.

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

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

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

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

Поправки и уточнения приветствуются

• Official Google Data Centers Site
• Challenges in Building Large-Scale Information Retrieval Systems (Jeff Dean, WCDMA ’09)
• Designs, Lessons and Advice from Building Large Distributed Systems (Jeff Dean, Ladis ’09)
• Google Percolator official paper
• Google Megastore official paper
• Google Percolator
• Google Caffeine Explained
• Google Spanner
• Google Software Infrastructure Dubbed Obsolete by ex-Employee
• Google Moves Off the Google File System
• Google Internet Stats
• Google Statistics
• Google Plus — Killer Facts and Statistics
• YouTube statistics
• Alexa on Google
• Internet World Stats
• Google Inc. financials
• Hotmail still on top worldwide; Gmail gets bigger
• Google Server Count
• Google Envisions 10 Million Servers
• Google Data Center FAQ

Бонус: типичный первый год кластера в Google

• ~1/2 перегрева (большинство серверов выключаются в течении 5 минут, 1-2 дня на восстановление)
• ~1 отказ распределителя питания (~500-1000 резко пропадают, ~6 часов на восстановление)
• ~1 передвижение стойки (много передвижений, 500-100 машин, 6 часов)
• ~1 перепрокладка сети (последовательной отключение ~5% серверов на протяжении 2 дней)
• ~20 отказов стоек (40-80 машин мгновенно исчезают, 1-6 часов на восстановление)
• ~5 стоек становится нестабильными (40-80 машин сталкиваются с 50% потерей пакетов)
• ~8 запланированных технических работ с сетью (при четырех могут случаться случайные получасовые потери соединения)
• ~12 перезагрузок маршрутизаторов (потеря DNS и внешних виртуальных IP на несколько минут)
• ~3 сбоя маршрутизаторов (восстановление в течении часа)
• Десятки небольших 30-секундных пропаданий DNS
• ~1000 сбоев конкретных серверов (~3 в день)
• Много тысяч сбоев жестких дисков, проблем с памятью, ошибок конфигурации и т.п.

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

Оригинал

Не забываем подписываться на RSS

Это было большим достижением, ведь всего несколько компаний во всем мире способны на реализацию по-настоящему меж-датацентровой системы хранения данных. Помимо SimpleDB, как много других публично-доступных сервисов баз данных могут хранить информацию в нескольких датацентрах одновременно? Теперь эта возможность доступна каждому. Но всему есть цена: так как Megastore использует втрое больше ресурсов, чем обычное Master-Slave хранилище в GAE, стоимость так же увеличивается в три раза. Помимо этого стоит учитывать, что с ростом надежности и издержек, понижается производительность. Именно из-за этого, новая система хранения является альтернативой обычному хранилищу GAE для критичных задач, а не полной заменой.

Основные особенности Megastore

• Megastore совмещает масштабируемость NoSQL систем хранения данных с удобством традиционных СУБД. Оно использовалось для внутренних проектов Google на протяжении нескольких лет. Более 100 приложений, 3 миллиардов транзакций на запись и 20 миллиардов на чтение, более петабайта данных распределены по множеству датацентров по всему миру.
• Megastore — хранилище, разработанное для удовлетворения требований современных интерактивных онлайн сервисов. Используется синхронная репликация для достижения высокого уровня доступности и консистентности. Вкратце, оно предоставляет полную ACID семантику для удаленных реплик с достаточно низкой задержкой, чтобы использоваться в интерактивных приложениях. Хранилище партиционируется и каждая часть реплицируется отдельно, позволяя достичь полного соответствия ACID внутри партиции, но консистентность между ними гарантируется лишь ограниченно. Предоставляются некоторый функционал традиционных СУБД, такой как вторичные индексы, но только те из них, которые масштабируются без сильного негативного влияния на задержки и которые укладываются в семантику используемой схемы партиционирования.
• Paxos используется для управлением синхронной репликацией между датацентрами. Это позволяет достичь очень высокого уровня надежности ценой повышения времени выполнения операций записи. Обычно Paxos используется только для координации, но в Megastore он также используются и для управления записью данных.
• Поддерживается три уровня консистентности при чтении: текущий, снимок и неконсистентный.
• Группы сущностей являются единицей консистентности и транзакционности. Они рассматриваются как маленькие независимые базы данных. Сами же данные внутри каждого датацентра хранятся в масштабируемом NoSQL хранилище.
• Megastore, как и обычное хранилище в GAE, не поддерживает транзакции с использованием нескольких групп сущностей, это существенно повысило бы время их выполнения.
• Группы сущностей — основной механизм группировки данных для быстрого осуществления операций. Их размер и композиция должны быть сбалансированы. В каждом приложении должен найтись способ естественным образом очертить границы групп сущностей. При оптимальном выборе групп сущностей ресурсоемкие кросс-групповые операции будут сведены к минимуму. По сути этот процесс чем-то напоминает нормализацию в реляционных СУБД.
• Запросы с высокими требованиями по консистентности должны быть ограничены одной группой сущностей. Кросс-групповые запросу могут вернуть устаревшие результаты. Это является серьезным отличием в поведении от обычного хранилища GAE, где по-умолчанию используется высокий уровень консистентности для всех запросов, так как операции записи и чтения по-умолчанию происходят с мастера.
• В обычном хранилище GAE иногда отключается в связи с запланированными техническими работами, а также вовремя непредвиденных проблем с инфраструктурой. Megastore в большинстве случаев не страдает этими проблемами.
• Резервирование данных и избыточность достигаются посредством синхронной репликации, снимков и инкрементального лога транзакций.
• API для доступа к данным остался прежним.
• Операции записи могут достигать секунды для каждой группы сущностей, так что для приложений с высокой нагрузкой на запись оно подходит не так хорошо.
• Только новые приложения могут воспользоваться опцией Megastore, существующие приложения необходимо пересоздать, чтобы использовать эту возможность. Впоследствии изменить тип хранилища невозможно.
• Одно приложение не может использовать одновременно обычное хранилище и Megastore. Напрашивается использование одного приложения с Google Megastore для критически важных данных, а другое приложение с обычным хранилищем для всего остального, но такая схема противоречит правилам использования сервиса.
• Автоматической миграции данных между Master/Slave хранилищем и Megastore не существует, разработчики приложения должны сами позаботиться об этом. Google предоставляют лишь набор инструментов и примеров кода, чтобы облегчить процесс миграции.
• В приложениях, использующих Megastore, еще большее  значение приобретает эффективное кэширование данных.

Материалы по теме

• Google Megastore — 3 Billion Writes And 20 Billion Read Transactions Daily
• Megastore: Providing Scalable, Highly Available Storage for Interactive Services
• May 25th Datastore Outage Post-mortem
• Paxos Made Live – An Engineering Perspective
• Choosing a Datastore
• Using the High Replication Datastore
• Bigtable: A Distributed Storage System for Structured Data
• How Google Serves Data From Multiple Datacenters
• Consensus Protocols: Paxos
• Performance comparison

P.S.: По традиции хочу напомнить, что читать Insight IT удобнее всего через RSS-reader.

В четырех отдельных интервью, сотрудники 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 хочет быть ответственным за организацию мировых данным, шаг за шагом, на протяжении всего пути.

В этой секции я провел большую часть своего времени на конференции, причин было несколько: начиная от низкой плотности населения и заканчивая нормальным доступом в Интернет, хотя доклады тоже были достаточно интересные . В данной секции освещались три основные темы: Google Wave, Google App Engine, Google Web Toolkit. Оказывается GWT у них принято называть как-то вроде «гуит», очень забавно звучало, особенно когда через слово повторяют. Давайте обо всем по порядку…

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

Google App Engine по прежнему для меня был достаточно актуален, так как я все еще вожусь с ним на досуге. По нему было два доклада: один вел Fred Sauer, про базовые принципе работы платформы, и второй был более детальным, Brett Slatkin рассказывал о практическом применении новых функциональных возможностей, особенно много внимания было уделено разным вариантам применения Task Queue. Оба докладчика очень хорошо и наглядно рассказывали, но доклад Fred’а был слишком прост и был нацелен на тех, кто еще совсем не знаком с платформой.

Про GWT официально тоже было два доклада, но один из них в итоге все равно полностью свелся к обсуждению Wave, так как это всем было существенно более интересно. Второй же доклад был из серии 201, то есть для тех кто уже работает с технологией, но докладчика тоже унесло непонятно куда — вместо GWT он рассказывал о создании систем со слабой связанностью компонентов и Dependency Injection в Java; в итоге целый час мусолил на примерах с кодом то, что можно было бы рассказать за 5 минут.

Общая организация

Не смотря на бесплатное участие в конференции, организаторы не поскупились на техническое обеспечение мероприятия. Мероприятие проходило в кинотеатре Октябрь на Новом Арбате, в 5 потоков; как следствие: большие хорошие проекторы, качественный звук и удобные кресла. Большинство выступлений проходило на английском, всем желающим выдавали наушники и специальные девайсы для синхронного перевода (сам не взял, но многие пользовались). Помимо этого всех бесплатно кормили завтраком и обедом (вполне прилично) + фуршет-afterparty чуть ли не до ночи. Традиционный пакетик с безделушками почему-то выдавали в конце мероприятия, в обмен на заполненную анкету с отзывом о мероприятии; как верно подметил один человек в официальной волне мероприятия: если кому-то и правда лень было заполнять анкету — заполняли наугад и толку от этого ноль, зато те кто любят записывать информацию с конференции в халявный блокнотик не смогли этого сделать.

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

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

Пару слов в заключении

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

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

P.S.: Продам инвайты в Google Wave (шутко)

Хотя да, достаточно давно уже 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 ходят в основном негативные мнения, мол тормозит, большое время отклика, сплошные таймауты и ошибки. На практике пока не удалось столкнуться с чем-то подобным, но реально работающего приложения с активной пользовательской базой у меня пока нет для того, чтобы делать какие-то относительно объективные выводы. Может быть со временем что-нибудь изменится и более тонкие нюансы станут выползать на поверхность — время покажет. Как раз будет повод написать еще один пост на эту же тему

Зато через какое-то время наткнувшись на очередную заметку про все ту же довольно избитую тему, я заметил ма-а-аленькую неприметную ссылку на «инструкцию по компиляции Google Chrome из исходников в Linux». В очередной раз пожав плечами с мыслью «а нам не привыкать, все равно Gentoo пользуюсь» отправился вводить заветное заклинание в свежесозданную консольку.

Заклинание это выглядит примерно следующим образом:

#!/bin/bash
CHROME=/usr/local/src
mkdir $CHROME/chrome
cd $CHROME/chrome
export LANG=C
$CHROME/depot_tools/gclient config http://src.chromium.org/svn/trunk/src
$CHROME/depot_tools/gclient sync
cd $CHROME/src/chrome
../third_party/scons/scons.py Hammer

Для успешного каста требуются следующие ингридиенты:

• subversion >= 1.4
• pkg-config >= 0.20
• python >= 2.4
• perl >= 5.x
• gcc/g++ >= 4.2
• bison >= 2.3
• flex >= 2.5.34
• gperf >= 3.0.3
• libnss3-dev >= 3.12

Начался процесс вполне оптимистично — строчки, генерируемые svn co побежали по экрану вполне весело, но когда этот процесс затянулся на более чем час – стало очевидно, что даже Google оказалось не по зубам выдержать такой наплыв желающх «заценить» новую игрушку и обеспечить достаточную пропускную способность на сервере с SVN. Правда и масштабы проекта мягко говоря впечатляют — директория с исходным кодом перед инициализацией компиляции оказалось очень даже весомой: 2.6 GB. В общем в итоге я не придумал ничего лучше, чем по старой традиции оставить браузер компилироваться на ночь и с чистой совестью уползти спать.

В итоге оказалось, что в результате получается не вовсе браузер, а лишь некоторые непонятно зачем нужные бинарники: надо было внимательно читать инструкцию, особенно обведенный в красную рамку блок — студенческая привычка при чтении чего-либо подсознательно отфильтровывать всю на первый взгляд второстепенную информацию, попадающую в категорию «слишком много букв», дала о себе знать В общем там об этом все заранее предупреждали — я просто не заметил, ну да ладно: в wine-то оно точно заведется, все тот же Google с легкостью помог обнаружить соответствующий мануал, для моего Gentoo он свелся к следующему:

#!/bin/bash
emerge --sync; emerge -av wine cabextract
cd /usr/bin
sudo wget www.kegel.com/wine/winetricks
sudo chmod +x winetricks
winetricks riched20 riched30 flash allfonts
cd ~
wget gpdl.google.com/chrome/install/149.27/chrome_installer.exe
wine chrome_installer.exe
rm chrome_installer.exe

Запуск с ходу из инсталлятора ничем хорошим не закончилcя, но вот такая команда вполне нормально запустила-таки браузер

wine ~/.wine/drive_c/windows/profiles/m11/Local Settings/Application Data/Google/Chrome/Application/chrome.exe--new-http --in-process-plugins

(если кто соберется копипастить — не забываем подменять m11 на свое имя пользователя)

Первое впечатление — ужасный V**ta-like дизайн, вернее не то чтобы он совсем ужасный — минималистичность очень даже полезное свойство для дизайна браузера, но в мое KDE 3.5.9 темно-фиолетовой раскраски он не вписывается ну совсем никак. Ну да ладно — пока он стоит «просто побаловаться», то можно и потерпеть. Далее я решил пройтись по основным «фишечкам», заинтересовавшим меня в комиксах — все реализовано вполне «как обещали», очень много концептуально правильных решений, которых в старом-добром FF определенно не хватает (перечислять наверное смысла нет — все и так уже, наверное, в курсе что там есть «вкусненького»). Но и многих абсолютно жизненно-важных вещей я там не обнаружил — начиная с блокировки рекламы и заканчивая все тем же стандартно-фиксированным дизайном и отсутствием центрального репозитория плагинов. Кое-какие неприятности можно свалить на все еще не окончательную доведенность до ума wine (проблемы с SSL/TSL, скажем), но на них я смело закрывал глаза — пока не будет полноценной Linux-версии о регулярном использовании данного продукта речи быть просто не может. Скорость работы новинки также произвела впечатление — на его фоне даже FF чисто субъективно показался медлительным (не смотря на все огрехи wine, как оно будет выглядить в native-версии — предсказать сложно).

Меню настроек оказалось вполне стандартным — ничего лишнего, лишь самые необходимые вещи, даже ребенок разберется. Хотя сложно на самом деле сказать плюс это или минус: если вдруг взбредет в голову потюнить что-либо более специфическое, могут возникнуть проблемы, хотя впринципе возможно там всетаки предусмотренно какое-то более расширенное меню настроек, по аналогии с about:config в FF, а я его просто не нашел.

Вдоволь наигравшись, я смело закрыл окошко браузера, с твердой уверенностью, что когда-нибудь потом обязательно заморочусь и с установкой и (возможно) эксплуатацией полноценной native Linux версии, когда граждане из Google соизволят-таки довести ее до работоспособного состояния — к тому времени глядишь и ситуацию с плагинами и темами исправят. Вот такая вот бестолковая история, спасибо, что дочитали до конца

P.S.: А вот тут есть RSS, если вдруг кто еще не в курсе.

Вам когда-нибудь доводилось задумываться какое количество сообщений приходится обрабатывать такого рода сервисам? Допустим есть абстрактный IM-сервис, которым пользуется миллион пользователей, в среднем каждый из них отправляет сто текстовых сообщений. Сколько всего сообщений обработал и доставил сервис? Сто миллионов? Наивно!

Введение

Сервисы мгновенного обмена на самом деле подвергаются существенно большей нагрузке, чем это может показаться на первый взгляд. Давайте взглянем на расшифровку аббревиатуры XMPP: eXtensible Messaging and Presence Protocol. Обмен сообщениями — лишь одна из его функций, наиболее важная же его часть остается «за сценой» — отображение присутствия пользователей online.

Давайте посмотрим на наш абстрактный пример с точки зрения присутствия: пускай им пользуется все тот же миллион пользователей, когда один из них включил компьютер и появился online — он должен уведомить весь свой список контактов об этом событии, а также узнать кто из них находится online. Если этот список велик, то такое элементарное событие может обернуться для сервиса далеко не одной сотней обработанных и доставленных сообщений. Помимо простого изменения статуса online/offline подобную цепочку сообщений может генерировать и любое другое изменение статуса: связанное с отсутствием пользователя около компьютера или с изменением небольшого текстового сообщения, которое обычно отображается в контакт листе рядом с ником пользователя и призвано отображать текущее его состояние, занятие или чего там только не пишут (эта функция не всегда предоставляется IM-сервисами, но наверняка многим знакома по ICQ, если не по Jabber). Все эти сообщения как раз и стоят за «presence» в аббревиатуре XMPP, суммарный траффик, ими генерируемый, может в несколько раз превышать траффик от собственно самих текстовых сообщений.

Если учесть факты, описанные в предыдущем абзаце, не трудно догадаться, что зависимость суммарного количества presence-сообщений от количества пользователей IM-сервиса далеко не линейна. Их количество за какой-то период времени можно очень приблизительно посчитать как произведение трех параметров: количества пользователей online, средней длины списка контактов среди них и количества изменений статуса каждым пользователем. А каждый дополнительный пользователь в системе так или иначе увеличивает как минимум два из этих трех параметров.

Введение несколько затянулась, а проблема масштабируемости XMPP-сервисов я думаю теперь стала очевидна, так что сейчас очень подходящий момент, чтобы вернуться к основной теме разговора — сервису Google Talk и том, как команда его разработчиков решает эту проблему.

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

Наверное уже стало заметно, что это не очередной перевод, а лично мной написанный текстик. Так что сразу выдам видео, являющееся основным источником информации, и продолжу.

Архитектура

Со стороны Google (о котором я, кстати говоря, уже писал) было бы глупо строить сервис мгновенного обмена сообщениями в стороне от остальных коммуникационных сервисов, предоставляемых этой компанией. Еще до своего публичного старта Google Talk был интегрирован в почтовый сервис GMail и социальную сеть Orkut: эти сервисы просто запрашивали у Google Talk присутствие online пользователей из своего списка контактов при возникновении соответствующих событий, но при этом не отображали результаты в своих страницах. Таким образом разработчики получили возможность оценить предстоящие нагрузки и готовность сервиса к публичному запуску намного более точно, чем они могли бы это сделать средствами синтетических тестов.

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

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

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

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

Но не стоит забывать и о клиентской части программного обеспечения: какая-нибудь глупая ошибка в коде клиента сервиса запросто может устроить DDoS атаку на сервис, что и случилось с одной из ранних версий клиента Google Talk. Помимо этого необходимо поддерживать совместимость разных версий клиентских приложений.

Заключение

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

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

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

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

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

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

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

• Video: Построение больших систем в Google
• Google Lab: Файловая система Google (GFS)
• Google Lab: MapReduce: упрощенная обработка данных на больших кластерах
• Google Lab: BigTable.
• Video: BigTable: система распределенного хранения данных.
• Как работает Google от David Carr в Baseline Magazine.
• Google Lab: интерпретирование данных. Параллельный анализ с помощью Sawzall.
• Записи с конференции по масштабированию от Dare Obasonjo.

Платформа

• 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, предшествовало искусство, а не только крупномасштабное развертывание системы.
• Учитывайте возможность компрессии данных, она является очень неплохим решением, если остается лишнее процессорное время, но присутствует нехватка пропускной способности.