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

Маленькая поисковая фирма Zvents выпустила под свободной лицензией уникальную разработку — систему управления базами данных, которая легко распараллеливается на сотни машин. В роли серверов может использоваться стандартное дешёвое железо, оно в случае необходимости заменяется «на лету» без потери данных. Новая программа Hypertable теоретически рассчитана работать на кластере из 1000 узлов, хотя текущая альфа-версия 0.9 испытывалась только на десяти. Но тесты прошло отлично, а интерес к разработке уже проявила компания Yahoo. Дело в том, что в настоящее время в Hypertable используется файловая система Hadoop, ведущий разработчик которой работает как раз в Yahoo.

Руководители компании Zvents говорят, что они были вынуждены открыть свою программу в виде open source, потому что у них маленькая софтверная фирма и совершенно нет денег на инфраструктуру. Подобные СУБД коммерческого масштаба нужно испытывать на громадных кластерах.

Программа Hypertable создана по образцу известной базы данных Bigtable, которая используется в Google. Эта распределённая система, когда она была представлена на суд научной общественности в 2006 году, произвела настоящий фурор как одно из лучших изобретений в компьютерной области. Правда, там в качестве файловой системы используется запатентованная Google File System.

Cтало известно, что Google планирует на следующей неделе открыть для разработчиков свою СУБД BigTable. Данное событие, безусловно, можно расценивать как вызов Amazon Web Services (AWS) и начало захватывающей конкуренции с Amazon SimpleDB.

BigTable — масштабируемая система базы данных, базирующаяся на Google File System (GFS). Спроектированная для хранения и управления огромным массивом структурированных данных с учетом внутреннего использования в Google. Система содержит сотни терайбайт информации на тысячах серверов Google. Разработка BigTable была начата в 2004 года, а активное использование уже в феврале 2005 года. Приложения, в которых Google используют BigTable — Google Search, Google Earth, Google Maps, Google Finance, Google Print, Orkut, YouTube, Blogger и т.д.

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

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

С другой стороны, в большинстве случаев, когда речь идет о десктопных (или веб-) приложениях, где не нужно ворочать миллионами примитивных записей,  а приложение работает с относительно высокоуровневыми, сложными объектами, суть «дизайна и проектирования баз данных» заключается в повторении двух действий:

freetonik & Nomad

— Ubuntu Mobile on eeePC
— Microsoft объявила ультиматум Yahoo!
— Домены от Microsoft
— «Писать без опечаток — совершенно не модно»
— BigTable от Google
— «Механический турок» для обмана венчурных инвесторов
— Первый КПК будущего от Lenovo
— Американские ИТ-компании начали массовые увольнения

RSS-подписка

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

Маленький скандальчик случился на конференции Structure 09, которая посвящена облачным вычислениям. Всё началось с выступления Наджама Ахмада (Najam Ahmad), главного менеджера по глобальным сетевым сервисам Microsoft. Он подробно рассказал, как Microsoft пытается увеличить производительность множества своих сервисов. Мол, проблема в огромном их количестве, так что невозможно подобрать настройки так, чтобы все эти сервисы одинаково эффективно работали на одной платформе. Приходится фрагментировать инфраструктуру, ставить разные серверы с разными настройками для отдельных приложений, таких как Messenger или Virtual Earth, и оптимизировать их по отдельности. Он подробно рассказал, как тщательно они сейчас оптимизируют Virtual Earth.

Сразу после этого слово взял Виджай Гилл (Vijay Gill), старший инженер по архитектуре из Google, и, как говорится, пропесочил конкурента по полной программе.

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

Google выпустил библиотеку Snappy под лицензией Apache 2.0. Эта библиотека для компрессии/декомпрессии нацелена не на максимальную степень сжатия или совместимость с другими библиотеками, а на максимальную скорость работы. Например, по сравнению с самым быстрым режимом zlib, Snappy примерно на порядок быстрее для большинства входящих данных, но архивы получаются на 20–100% больше по размеру. На одном ядре Core i7 в 64-битном режиме Snappy скорость компрессии больше как минимум на 250 МБ/с, а декомпрессии — минимум на 500 МБ/с.

Snappy широко используется в Google, в разных системах от BigTable и MapReduce до внутренних RPC-систем (в некоторых презентациях она упоминалась под названием Zippy).

Дополнительную информацию см. в файле readme. Бенчмарки по сравнению с другими библиотеками (zlib, LZO, LZF, FastLZ и QuickLZ) поставляются в комплекте с исходниками.

Компания Google открыла исходные коды LevelDB — это созданный в Google быстрый движок (библиотека) для работы с хранилищем пар ключ-значение.

Библиотеку LevelDB на C++ можно использовать для разных целей. Например, веб-браузер может обрабатывать с помощью LevelDB кэш недавно посещённых страниц. Операционная система — список установленных пакетов и зависимостей между ними, а любое приложение может использовать LevelDB для хранения пользовательских настроек.

Агентство национальной безопасности США предоставило на рассмотрение фонда Apache Software Foundation свой проект Accumulo. Это распределённая СУБД, созданная на основе дизайна Google BigTable с использованием кода Hadoop, Zookeeper и Thrift. Дизайн BigTable обнародован в 2006 году, работа над Accumulo началась в 2008-м, причём он изначально задумывался как свободный проект с использованием открытых библиотек.

Главным улучшением Accumulo по сравнению с BigTable является продвинутая система разграничения прав доступа на уровне отдельных ячеек (cell-level access labels). Различные пользователи могут получать доступ только к определённым полям базы данных, которым присвоен соответствующий уровень доступа (labels).

В октябре 2011 года в Москве проходила ежегодная конференция разработчиков высоконагруженных проектов HighLoad++.
Решил поделиться с читателями основными тезисами с конференции. Поскольку вся информация открыта и доступна на странице конференции, решил что собрать все тезисы вместе будет не такой уж и плохой затеей. Сразу отмечу, что в отчёте не содержится детальной информации о каждом докладе — затронуты лишь ключевые моменты.
Итак, о чём говорилось на HighLoad++ 2011.

Часть 1.

Моделируем 4 вида NoSQL-баз с помощью GlobalsDB

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

Джефф Дин считается кем-то вроде Чака Норриса. Отличие только в том, что он вовсе не герой боевиков, а инженер-программист компании Google.

Шутки о нём впервые появились на 1 апреля шесть лет назад. Один из коллег Дина по имени Кентон Варда открыл страничку, куда каждый мог добавлять факты о Джеффе Дине. Идею с энтузиазмом подхватили другие разработчики — и вскоре наполнили страничку множеством таких «фактов».

В последнее время набирают популярность различные NoSQL базы данных. Эта статья начиналась как изучение особенностей графитовой графовой базы данных Neo4j. Но, в процессе подбора информации, мне захотелось систематизировать информацию о NoSQL решениях и о графовых базах данных, в частности.
В ходе этого небольшого исследования, были выбраны для подробного рассмотрения СУБД, успешно применяющиеся в области Web. И, поскольку в тегах присутствует «PHP», я выбирал СУБД, которые уже можно использовать с этим языком.

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

Так что давай покончим с этим.

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