Insight IT

Twitter Storm

Иван Блинков — Sat, 31 Mar 2012 00:08:00 +0400

Storm является распределенной системой для выполнения вычислений в реальном времени. Она родилась в рамках проекта Backtype, который специализировался на аналитике твитов и который в июле 2011 был приобретен Twitter. Так же как Apache Hadoop предоставляет набор базовых абстракций, инструментов и механизмов для пакетной обработки данных, Twitter Storm делает это для задачи обработки данных в режиме реального времени. Хотите узнать в чем их отличие?

Отличие

Не смотря на то, что Storm изначально появился на свет в процессе неудачных попыток приспособить Hadoop к задаче обработки данных в реальном времени, сравнивать их некорректно. Никакой хак или патч не сможет заставить Hadoop работать по-настоящему в режиме реального времени, так как в его основе лежит фундаментально другая концепция и набор принципов, которые актуальны лишь в контексте задачи пакетной обработки данных. Storm можно представить как "Hadoop для вычислений в реальном времени", но по факту между ними нет практически ничего общего, кроме изначально-распределенной природы, слегка похожей архитектуры, работы внутри JVM и публичной доступности. Для понимания задачи, которая стоит перед Storm, лучше взглянуть на то, как она обычно решается.

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

Особенности

Итак, основные особенности Storm, вытекающие из требований к подобным системам:

Три основных варианта использования, но ими он не ограничивается:
- Обработка потоков сообщений (stream processing) в реальном времени, с возможностью внесения изменений во внешние базы данных;
- Постоянные вычисления (continuous computation) на основе источников данных с публикацией результатов произвольным клиентам в реальном времени;
- Распределенные удаленные вызовы (distributed RPC) с выполнением комплексных вычислений параллельно во время запроса.
Масштабируемость: Storm может обрабатывать огромное количество сообщений в секунду. Для масштабирование необходимо лишь добавить сервера в кластер и увеличить параллельность в настройках топологии. В одном из первых приложений для Storm обрабатывался 1 миллион сообщений в секунду на кластере из 10 серверов, при этом выполнялось несколько сотен запросов в секунду к внешней базе данных.
Гарантия отсутствия потерь данных: в отличии от других систем обработки сообщений в реальном времени (например S4 от Yahoo!) это свойство изначально является частью архитектуры Storm. Для этого используется механизм подтверждения (acknowledgement) успешной обработки каждого конкретного сообщения.
Стабильность: в то время как Hadoop позволительны простои по несколько часов, так как он априори не является системой реального времени, одной из основных целей Storm является стабильная бесперебойная работа кластера, с максимально безболезненным его управлением.
Защита от сбоев: если что-то пошло не так во время выполнения вычисления, Storm переназначит задачи и попробует снова. В его задачи входит обеспечение бесконечной работы вычислений (или до момента запланированной или ручной остановки).
Независимость от языка программирования: в то время как большая часть системы написана на Clojure и работает в JVM, сами компоненты системы могут быть реализованы на любом языке, что удобно для проектов, использующих в основном другие технологии.

У Вас уже могло сложиться общее представление, о том что собой представляет Twitter Storm и насколько он актуален лично для Вас или Вашего проекта. Если интерес все еще не погас, предлагаю перейти к концепции, предлагаемой Storm для разработки приложений под эту платформу.

Концепция

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

Поток (Stream): неограниченный поток сообщений, представленных в виде кортежей (произвольных именованный список значений). При этом все кортежи в одном потоке должны иметь одинаковую схему: элемент на каждой позиции должен иметь один и тот же тип данных и значение.
Струя воды из крана (Spout): источник потоков, который берет их из какой-то внешней системы.
Cтруя состояния (state spout): предоставляет распределенный доступ к некому общему состоянию, которое кэшируется в памяти на исполнителях и синхронно обновляется при внешних изменениях. Таким образом возможно избежать обращений к внешней базе данных при обработке каждого сообщения. В случае с Twitter этим общим состоянием является сам социальный граф.
Молния (Bolt): обрабатывает входящие потоки и создает исходящие потоки, производя какую-либо обработку данных (по сути здесь реализуется основная бизнес-логика). Помимо этого никто не запрещает использовать при обработке какие угодно внешние сервисы вроде СУБД.
Топология (Topology): произвольная связанная сеть из "молний" и "струй". При создании топологии можно указать:
- уровень параллелизма для каждого компонента, что создаст необходимое количество его потоков исполнения в кластере.
- группировку потоков, то есть как именно сообщения будут распределяться между созданными потоками исполнения каждого компонента, есть четыре основных варианта - случайно (shuffle), каждый получит по копии (all), хэш по определенным полям сообщения (fields), один поток получает все сообщения (global).

Таким образом, для создания приложения для обработки данных в реальном времени с использованием Storm, необходимо:

Определить схему(ы) потока(ов) сообщений.
Реализовать источник(и) сообщений, основанные на парсинге каких-то внешних данных (для Backtype это был Twitter firehose, поток всех твитов) или реакции на события (допустим действия пользователей в виде HTTP-запросов).
Реализовать обработчик(и) сообщений, которые преобразуют входящие сообщения и либо создают новые потоки сообщений, либо как-то влияют на внешний мир, например изменяя что-то в базе данных (они используют Cassandra для этого).
Объединить реализованные компоненты в топологию и запустить её на кластере.
При необходимости оптимизировать систему, включив общее состояние в топологию.

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

Архитектура

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

В остальном все достаточно просто:

Мастер-сервер (Nimbus) отвечает за распространение кода, распределение задач и мониторинг сбоев.
На каждом сервере в кластере запускается процесс-надсмотрщик (Supervisor), который запускает локально потоки исполнения, отвечающие за выполнение назначенных ему компонентов топологий.
Передача сообщений между компонентами топологий осуществляется напрямую, посредством ZeroMQ.
Топологии являются Thrift-структурами, а мастер-сервер - Thrift-сервисом, что позволяет осуществлять регистрацию топологий и другие операции программно из любого языка программирования.

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

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

Планы на будущее

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

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

На самом деле подход, лежащий в основе Storm, не является чем-то кардинально-новым. Помимо упоминавшегося выше S4 можно найти еще несколько альтернатив, пускай и менее близких по идеологии. Подробнее про эту тему можно узнать погуглив complex event processing или real-time stream processing.
Storm выделяет из их числа простота, гибкость, масштабируемость и отказоустойчивость в одном флаконе. Обеспечивает это в первую очередь простая и понятная архитектура, основанная на (уже) проверенном временем и многими проектами распределенном координаторе в виде Zookeeper.
Хоть за проектом и стоит крупный интернет-проект в лице Twitter, он достаточно молод и нужно быть морально готовым к возможным сбоям и неудачным моментам. Плюс не забывайте, что существенная часть написана на Clojure - для, пожалуй, большинства разработчиков изучение исходников проекта будет капитальным "выносом мозга". Мое первое знакомство с Lisp (Clojure - его диалект, работающий в JVM) надолго засело в памяти из-за обилия скобочек за каждым углом :)
В любом случае из доступных opensource реализаций систем для распределенных вычислений в реальном времени Storm на мой взгляд является наиболее перспективным для применения в интернет-проектах.
Если Вашему проекту нужна лишь одна-две топологии и особо большого кластера не планируется, то подобную схему достаточно не сложно реализовать и просто посредством Zookeeper + ZeroMQ или альтернативных технологий. Это избавит проект от возможных заморочек с Clojure и другими "особенностями" Storm, ценой вероятно существенно большей собственной кодовой базы, которую придется самостоятельно тестировать и поддерживать. Какой путь ближе - команда каждого проекта решает для себя сама.
Помимо различных вариаций веб-аналитики заманчивыми применениями подобной системы в Интернете может стать:
- построение индекса для поисковых систем, на сколько я знаю от MapReduce здесь отказался только Google;
- поведенческий таргетинг для рекламы - собираем действия пользователей и делаем на их основе выводы в реальном времени;
- ведение рейтингов чего-либо в реальном времени - в зависимости от специфики проекта можно определять и показывать лучшие, самые просматриваемые или самые комментируемые статьи/фото/видео/музыку/товары/комментарии/что-нибудь-еще;
- предлагаем свои варианты в комментариях.

Удачи в построении приложений для вычислений в реальном времени и до встречи на страницах Insight IT!

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

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

Иван Блинков — Thu, 10 Apr 2008 00:24:00 +0400

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

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

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

Основным источником информации послужила презентация Brad Fitzpatrick в Токио.

Платформа

Linux (Debian Sarge)
Perl
Apache
MySQL 4.0/4.1 в основном с InnoDB
Perlbal, веб-сервер и балансировщик нагрузки
memcached для распределенного кэширования
MogileFS, распределенная файловая система
Gearman
TheShwartz
djabberd

Статистика

на данный момент 15320315 учетных записей; (10.04.08)
из них активно используется 551589;
наиболее активно сервис используется в США и Российской федерации, а 2/3 пользователей - девушки и женщины;
более 15 миллионов новых записей в блогах за месяц;
более 50 миллионов просмотров страниц в день, при пиковой нагрузке - несколько тысяч в секунду (сильно устаревшие цифры, 2004 год);
связь с внешним миром осуществляется через два BIG-IP (активный + в режиме ожидания) с автоматическим восстановлением работоспособности в случае сбоя в работе одного из них, защитой от DDoS, L7 набором правил, включая TCL;
более сотни серверов, насчет конфигурации известен только тот факт, что практически на каждом сервере установлены огромные объемы оперативной памяти (более 12 GB) для эффективного кэширования.

История

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

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

Применительно к LiveJournal эту схему лучше всего демонстрирует один из слайдов презентации, указанной в источниках информации:

При работе такой системы не используется auto_increment в MySQL, а также используется составной primary key из номера пользователя и номера записи. Таким образом пространство имен объектов разбито на группы, соответствующие конкретному пользователю.

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

Программное обеспечение

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

memcached

Залогом быстрой загрузки любой страницы крупного интернет-проекта является кэширование. Но как всегда возникает вопрос: а на каком уровне обработки данных его стоит выполнять? Для динамических страниц недопустимо кэширование на уровне готовых страниц. Можно кэшировать на уровне mod_perl, но по сути это пустая трата оперативной памяти, так как создастся отдельный кэш для каждого потока Apache, и количество промахов мимо кэша будет огромно. Кэширование запросов MySQL или HEAP таблицы также не дали бы требуемого результата ввиду чрезвычайной распределенности базы данных.

Выходом из сложившейся ситуации стало написание собственной распределенной системы кэширования объектов, получившей название memcached. Она позволяет:

использовать для кэширования свободную оперативную память практически любого компьютера, задействованного в системе;
кэшировать объекты практически любого языка программирования в сериализованном виде: Perl, PHP, Java, C++ и так далее;
использовать для передачи кэшируемых данных простой протокол, не требующий избыточности данных;
избегать даже теоретической возможности полного сбоя работы кэшируещей системы в связи с полной равнозначностью серверов;
достигать превосходной производительности при формировании HTML-кода страниц;
в разы снизить нагрузку на базы данных в проекте любого масштаба.

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

Perlbal

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

быстрый;
небольшой размер;
"сообразительный";
обработка "мертвых" узлов;
может выступать как в роли reverse proxy, так и балансировщика нагрузки;
базовый функционал классического веб-сервера;
реализация внутреннего перенаправления данных;
поддержка некоторых менее существенных трюков, реализованных обычно в виде plug-in'ов.

Perlbal не так активно используется вне LiveJournal, по сравнению с memcached, но для решения конкретной задачи он подошел как нельзя лучше.

MogileFS

Идея распределенных файловых систем далеко не нова, достаточно вспомнить лишь GFS или любой ее opensource аналог. Сам факт создания такой системы был очень легок, изначальная версия была написана за одни выходные, но при доведении ее до требуемого уровня качества пришлось попотеть. Решение о ее создании было развитием идеи распределения операций записи. Общая принцип хранения файлов прост: каждый файл в ФС относится к определенному классу файлов, который определяет все правила работы с файлом, в основном механизм его реплицирования, об остальном заботится сама система.

Как и все файловые системы этого класса, MogileFS работает на уровне пользовательских приложений и использует достаточно тривиальные протокол передачи данных и общую архитектуру: клиенты, управляющие серверы, абстрактные базы данных, сервера для хранения самих данных - в этом плане ничего нового придумано не было. Доступ к файлам осуществляется с помощью HTTP-запросов PUT/GET либо через виртуальный NFS-раздел. Единственной особенностью можно назвать уклон в построение собой абстрактной прослойки между приложением и собственно кластером базы данных (в случае LiveJournal - сегмента), используемой в роли альтернативы более тривиальной master/slave схемы.

Gearman

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

В рамках LiveJournal Gearman применяется в основном для:

обработка изображений средствами Image::Magick вне perl-приложений;
создание pool'а DBI соединений (DBD::Gofer + Gearman);
уменьшением нагрузки, создаваемой отдельными компонентами системы;
улучшения субъективного впечатления пользователей о быстродействии сервиса, благодаря выполнению части работ параллельно в фоновом режиме;
выполнение блокирующего ресурсы кода отдельно от обработчиков различных событий.

TheShwartz

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

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

Основными сферами применения TheShwartz в LJ являются:

отправка электронной почты (SMTP клиент);
LJ Notifications: каждое событие может вызывать за собой цепочку из тысяч уведомлений по электронной почте, SMS, XMPP и так далее;
отправка RPC сообщений внешним сервисам;
внедрение Atom потоков;

djabberd

Как всегда следуя принципу "чем проще - тем лучше", разработки LJ написали этот крошечный daemon, лежащий в основе их Jabber/LJTalk. Он способен спокойно работать с более чем 300 тысячами соединений, используя очень скромное количество оперативной памяти для поддержания каждого соединения.

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

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

Если перед Вами появилась нетривиальная задача - не бойтесь написать программное обеспечение для ее решения самостоятельно! Пускай, возможно, это потребует некторых дополнительных усилий, но масса преимуществ, связанных с полным соответствием требованиям конкретного проекта, превосходит все издержки дополнительной разработки.
Невозможно масштабировать проект просто постоянно добавляя новые сервера, рано или поздно все же прийдется задуматься об его архитектуре;
Распределение нагрузок и параллельное операций порой заслуживают того, чтобы разработчики обратили на них внимание;
"Мы ненавидим изобретать колесо! Но тем не менее, если колесо не существует или оно квадратное, то мы не боимся изобретать круглое колесо." (с)

Hypertable

Иван Блинков — Sat, 05 Apr 2008 20:27:00 +0400

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

Принцип работы Hypertable прост до безобразия:

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

Master Server

– как и во многих других подобных системах мастер-сервер выполняет обязанности скорее административного характера: он управляет работой Range серверов, работает с метаданными (которые хранятся просто в отдельной таблице, наравне с остальными).

Range Server

– их задача стоит в собственно в хранении диапазонов строк из различных таблиц. Каждый сервер может хранить несколько несмежных диапазонов строк, если диапазон превышает по объему определенный лимит (по-умолчанию - 200 MB), то он разбивается на пополам и одна половина обычно перемещяется на другой сервер. Если же на одном из серверов подходит к концу дисковое пространство, то под руководством мастер-сервера часть диапазонов с него перераспределяется на менее загруженные Range серверы.
Еще одним компонентом системы является Hyperspace, этот сервер предоставляет указатель на основную таблицу с метаданными, а также пространство имен. Помимо этого этот сервис выступает в роли lock-механизма для клиентов системы.

В качестве основы для этой системы может использоваться как входящая в состав Hadoop файловая система HDFS, так и KosmosFS, о которой я недавно рассказывал. Это позволяет Hypertable выступать в роли конкурента для HBase в рамках проекта Hadoop.

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

Для доступа к данным каждая из систем использует язык HQL, только в одном случае аббревиатура расшифровывается как HBase Query Language, а в другом - Hypertable Query Language (как эгоистично :) ). По сути и то и другое является сильно упрощенным диалектом SQL, что позволяет сократить знакомство с синтаксисом HQL до пары минут при достаточном знании классического SQL. Хотелось бы отметить, что вся простота в сравнении с классическим SQL и реляционными СУБД вполне обоснована: обе системы хранения данных предназначены для использования в совокупности с MapReduce программами, что делает их просто хранилищем данных, а не средством их обработки.

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

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

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

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

Gentoo Linux + Sony Vaio = ♥

Иван Блинков — Tue, 22 Jan 2008 01:06:00 +0300

Gentoo is all about choices

Абсолютно не важно, держите ли Вы в руках блестящую болванку с надписью "Прощай, предустановленная Vista!" или только подумываете о том, чтобы избавить свой ноутбук от тяжести этой ноши. Прочитав это повествование, Вы сможете представить себе процесс установки альтернативной операционной системы на ноутбук на примере Gentoo Linux и Sony Vaio. Я постараюсь освятить все особенности этого процесса, а также по возможности дать советы по избежанию потенциальных проблем. Не надейтесь найти здесь пересказ Gentoo Handook, ее стоит прочитать в любом случае, если Вы на самом деле задумали установить эту очень серьезную операционную систему.

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

Как я уже успел намекнуть во вступлении, начинается все с болванки на которую записан тот самый волшебный образ. Никто не мешает выбрать любой из доступных вариантов, но предположим, что выбор пал на Gentoo Linux LiveCD 2007.0. Загрузка ноутбука с этого диска проходит плавно и непринужденно, ровно как и сама работа с уже загруженным LiveCD как в консоли, так и в используемом там рабочем окружении - Gnome. Следуя инструкциям из настольной книги начать установку операционной системы очень нетрудно, но если честно у меня прочитав пару раз этот немаленьких размеров текст возникла мысль попытаться сэкономить некоторое количество времени, воспользовавшись услугами двух предложенных автоматических инсталляторов - с графическим и консольным пользовательским интерфейсом - не повторяйте этой ошибки, так как качество реализации обоих вариантов на данный момент оставляет желать лучшего, заставить успешно установить систему один из них может занять ничуть не меньше времени, чем ручная установка. Лично мне приручить ни один из автоматических инсталлятора так и не удалось, но как ни странно тоже не пришлось жалеть об этом факте - как оказалось ручная установка очень качественно позволяет разобраться в структуре операционной системы вцелом, ровно как и в принципе работы отдельных ее компонентов.

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

Ядро

Как известно, для Gentoo доступно несколько вариантов ядер, в процессе установки мой выбор пал на suspend2-sources, но со временем полностью перебрался на gentoo-sources, так как я понял, что сами suspend-to-ram и suspend-to-hdd мне абсолютно не нужны, но suspend2 слегка отстают от gentoo по версиям. Тем более, насколько я знаю, в современных версиях основной ветки ядра suspend тоже поддерживается на достойном уровне (но так как мне он не нужен - пробовать на собственном опыте не доводилось).

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

Просто скопировать ядро с LiveCD. Этот вариант является самым простым в плане реализации, систему с его помощью запустить вполне реально - пробовал, но в плане производительности ему до идеала о-о-очень далеко.
Собрать ядро с помощью genkernel и стандартной его конфигурации. Прочитав man genkernel это занятие тоже становится простым и привычным. Именно этот вариант я и выбрал в первый раз, слегка подредактировав конфигурационный файл с помощью ––menuconfig в тех местах, где был точно уверен что это не повлияет на функциональность и положительно повлияет на производительность. Естественно этот вариант тоже годится только на первое время.
Ручная сборка классическим способом - make, с использованием конфигурационного файла, взятого с LiveCD. Чисто теоретически возможно, но не могу порекомендовать этот способ, при его реализации возникает существенно больше проблем, до конца решить которые мне так и не удалось в процессе установки, а в последующем как-то не возникало желания возвращаться к ручной сборке ядра, так как привык к genkernel - просто и удобно.
Метод "проб и ошибок". Если есть желание и возможность потратить существенное количество времени на подбор оптимальной конфигурации ядра прямо в процессе установки - почему бы этим и не заняться?

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

Сеть

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

Как известно, у большинства ноутбуков дорога в Сеть может пролегать по трем маршрутам:

Сетевая карта - Ethernet
Беспроводная сеть - WiFi
Старый-добрый модем

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

Ethernet

Воткнув заветный штекер RJ45 в соответствующий разъем, я с удивлением обнаружил с помощью команды ifconfig, что на этом мои телодвижения по получению доступа в Интернет благополучно закончились. Все драйвера оказались на месте, DHCP-клиент без моего вмешательства получил IP-адрес, все необходимые настройки по-умолчанию были выбраны верно - вобщем в этом плане все отлично.

Конечно далеко не у всех локальная сеть организована таким же образом, как и у меня, возможно придется поизучать man ifconfig'а или повозиться с VPN-соединением.

WiFi

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

Попробовав несколько вариантов, мне удалось-таки установить беспроводное соединение с помощью драйвера под названием ipw3945 и сопутствующего ему daemon'а ipw3945d. Подробно весь процесс описывать не буду, я думаю при необходимости подробную инструкцию найти особого труда не составит.

Я еще не упоминал, что в качестве рабочего окружения предпочитаю использовать KDE, как-то с самого начала к нему привык, как внешне так и внутренне он меня более чем устраивает. Не сочтите предыдущее предложение за отступ от темы, я всеголишь хотел как-то объяснить переход к разговору об утилите, предоставляющей GUI к работе с беспроводными соединениями, - KWifiManager. Утилитка достаточно своеобразная, манера ее поведения поначалу сильно удивляла, но со временем привыкаешь. Особенно странно она производит выбор беспроводной сети, к которой подключаться. Не смотря на установленную в настройках мою домашнюю сеть, как сеть по-умолчанию, она все равно частенько пытается залезть к соседям или еще куда. И что самое интересное - вернуть ее на путь истинный ее же средствами мне обычно так и не удается. Из-за этого пришлось написать bash-скрипт, который помогает укратить эту утилиту. Включать в текст записи его особо желания нету, если кто хочет его заполучить: оставьте соответствующий комментарий - выложу.

Альтернатива консоли

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

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

Одно время конечно возникали некоторые трудности, например в одной из версий X-сервера была неприятная недоработка с LED'ами на клавиатуре - не было видно нажат ли Caps Lock, или при одной конкретной комбинации программного обеспечения и ядра системы по странному стечению обстоятельств частоиспользуемая клавиша F2 приводила к сворачиванию X-сервера и возвращению в консоль, что тоже доставляло массу неудобств. На данный же момент все проблемы такого рода решены руками огромного opensource-сообщества и все снова замечательно работает точно также как и полгода назад сразу после установки системы.

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

Видео

Используемый по-умолчанию видеодрайвер vesa оставляет желать лучшего, этот факт заметен сразу же после первой загрузки рабочего окружения, а значит ничего не остается кроме как искать ему замену. Искать долго не придется - отличный видеодрайвер для присутствующей в внутри этого ноутбука Nvidia GeForce 7600 легко доступен через Portage, называется он, как ни странно, nvidia-drivers.

Впечатления он оставляет только положительные: легко настраивается, достаточно производительный, поддерживает множество технологий, в том числе пресловутый Composite Extension в Xorg, который необходим для работы большинства (если не всех) трехмерных приложений.

Аудио

С ним все еще проще - достаточно лишь не забыть включить ALSA и Intel HD Audio в конфигурации ядра.

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

Bluetooth

Синий зуб прекрасно чувствует себя под руководством встроенного в ядра драйвера BlueZ, с работой в качестве GUI для работы с этим устройством также неплохо справляются KDE'шные утилиты KBluetooth и компания.

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

Разные мелочи

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

Очень удивил меня тот факт, что для приведения к жизни различных нестандартных кнопок вроде регулировки громкости, S1, S2 и Fn необходима достаточно серьезная "работа напильником": модули ядра вроде sonypi способны оживить их лишь частично, для полного их функционирования возможно придется изрядно покопаться в конфигурационных файлах, а также написать/найти некоторое количество bash-скриптов. Надеюсь в будущем найду в себе силы довести это дело до конца, правда особого дискомфорта от ненастроенных кнопок я не испытываю - не успел к ним привыкнуть, да и реализованного на уровне оборудования mute sound мне вполне хватает.

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

Встроенная камера заслуживает отдельного разговора. С одной стороны драйвера под нее есть и легко доступны, весь необходимый набор модулей для ядра - v4l, gspcav1, установить абсолютно не проблема. Найдя неплохую статейку в вики я достаточно быстро разобрался с их установкой, но после этого возник вопрос: а зачем оно собственно говоря надо? Как оказалось, камера является абсолютно бесполезным для меня device'ом, и я даже не придумал никакого адекватного способа проверить ее работоспособность. Так эти драйвера и находятся установленными в системе непонятно зачем.

Порт IEEE 1394 aka FireWire опробовать в действии не удалось, так как я не являюсь обладателем устройств, его использующих, но я не вижу каких-либо причин для того, чтобы он не работал: если мне не изменяет память, то он фигурировал в настройках ядра наравне с USB, который замечательно работает.

Cardreader'ов в комплекте было два - один встроенный для MemoryStick, и внешний в 34мм-слот для SD/MMC. Насчет первого не могу ничего сказать, так как карточек таких у меня не нашлось, а второй отлично определился без каких-либо дополнительных действий с моей стороны.

Про DVD-привод, miniJack и прочие стандартные вещи наверное и упоминать смысла нет - с ними все в порядке.

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

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

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

Закончить хотелось бы той же цитатой из Gentoo Handbook, которую я использовал в эпиграфе к этой статье: "Gentoo is all about choices."

Unix way

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

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

Наиболее точно охарактеризовать то, о чем пойдет речь можно лишь процитировав одного из основателей традиций Unix и разработчика технологии под названием "Unix pipes" - Douglas'а Mcllroy'а:

"This is the Unix philosophy: - Write programs that do one thing and do it well. - Write programs to work together. - Write programs to handle text streams, because that is a universal interface."

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

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

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

Закончив лирическое отступление, хочется взглянуть на нашу философию с точки зрения программиста.

Взгляд с точки зрения программиста

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

Как же это выглядит?

Одна задача - одна программа

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

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

Unix pipes

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

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

Взгляд с точки зрения пользователя

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

У каждой элементарной программы, соответствующей этой идеологии, должен быть входной и выходной стандартные текстовые потоки - stdin и stdout соответственно. Механизм unix pipes позволяет перенаправлять эти потоки любой программы произвольным образом с помощью трех простых операторов: |, > и <. Первый из них - | перенаправляет stdout команды слева от него в stdin команды справа, а > и < предназначены для перенаправление потоков в/из файлы по схожему принципу.

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

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

Начнем с примера, позволяющего прочитать постранично любой файл:

cat readme.txt | less

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

cat readme.txt | grep unix > readme.txt

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

cat readme.txt | grep unix > meread.txt

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

cat readme.txt | grep unix >> readme.txt

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

cat readme.txt > /dev/dsp

в ответ от компьютера Вы услышите некоторый звук, издаваемый из колонок или наушников.

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

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

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