`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Время других DBMS

Статья опубликована в №16-17 (683) от 19 мая

+77
голосов

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

Уже развернутые и эксплуатируемые масштабные веб-сервисы и дата-центры больших проектов cloud computing дали возможность быстро определить уникальные, но общие для двух этих классов ИТ-проектов особенности. Если говорить о специфике используемых в таких системах данных, то эти особенности будут вполне очевидны – данных становится не просто много, а Исключительно Много, к ним требуется быстрый доступ, при этом в сложных критериях поиска нет особой нужды, частота исполнения процедур чтения крайне высока и несоизмеримо выше интенсивности обращений к процедурам записи, удаления данных же, в свою очередь, – вообще редкость. Ярким примером проявления таких особенностей работы с информацией можно считать источники данных для сетей доставки контента (CDN). Речь идет о таких гигантах, как, например, Facebook. И здесь очень важно также не забывать специфику скорости роста проектов в области тех же социальных сетей – если уж проект «выживает» и начинает завоевывать популярность, то рост ее становится лавинообразным. Что при невозможности тотального изменения инфраструктуры может заставить прибегать к самым неожиданным приемам, включая довольно жесткий хакинг. Именно так поступили создатели сервиса Facebook, масштабы которого впечатляют – он объединяет в одну из самых больших инсталляций СУБД MySQL более чем на десяти тысячах серверов шесть тысяч логических баз данных. Вся эта махина хранит порядка семи миллиардов оригиналов загруженных пользователями фотографий и еще почти 25 миллиардов автоматически сгенерированных их копий разного размера, при этом фотоколлекцию Facebook пользователи сервиса просматривают со скоростью 475 тысяч изображений в секунду (а пополняют, для сравнения, всего 165 раз в секунду, общее число записей в весь «фотоальбом» Facebook оценивается на уровне ста миллионов в неделю). Такие масштабы выявили массу нюансов в архитектурах реализующих сервис подсистем. Так, например, эволюция Facebook выявила, что 15 операций дискового ввода-вывода, необходимых немодифицированному системному ПО файлового кэша (в первую очередь операционной системе) для выполнения полного цикла чтения и «выдачи» удаленному потребителю одной фотографии – это катастрофически много. Для радикального уменьшения этого показателя пришлось прибегнуть к классическому хакерскому методу (под ним понимается затрата усилий на модификации чего-то для использования его совсем не так, как задумывали разработчики) – изменению ядра ОС Linux «под задачу» (не углубляясь в детали – уровень абстракции имен, которыми оперирует сетевая файловая система NFS, был принудительно «обрушен» до одного из самых базовых примитивов файловых систем UNIX-совместимых ОС – inode).

Трудно представить себе дистанцию, отделяющую макропоказатели всего сервиса Facebook от элементарного «винтика» реализации файловых систем ОС Linux, но, как оказалась, скорости роста социальных сетей вынуждают проходить такие дистанции за весьма короткий период времени. Что означает – к формированию архитектур современных ИТ-систем следует относиться крайне щепетильно. Понятно, что невозможно найти единственное гарантированно наилучшее решение (его попросту не существует), но и игнорировать архитектурную оптимизацию на начальных уровнях проектирования, следуя принципу «что чаще всего используют все, то и лучше», уже, похоже, нельзя. Системы управления базами данных – как раз тот ключевой элемент архитектуры масштабных ИТ-сервисов, который во многом предопределяет и самые высокоуровневые потребительские и технические характеристики будущей системы, и ее «приспособленность к эволюции» (термин хоть и неофициальный, но вполне понятный – приспособленные к эволюционному развитию системы в период жизненного цикла дешевле и эффективнее изменять эволюционным путем, чем революционным). Рост нагрузок на вычислительные системы, приводящий к появлению программных решений типа Hadoop (инфраструктура поддержки кластерной обработки данных), уже проверенных «обкаткой» в проектах сверхвысокого масштаба (всем известный сервис Last.fm, например, широко использует Hadoop), буквально вынуждает искать и адекватные решения задач хранения и организации доступа к структурированным данным. Впрочем, сегодня у проектирующих ИТ-сервисы выбор есть – чувствительное к потребностям сообщество разработчиков не оставило такую важную подсистему без внимания. И несмотря на то, что вся эта преамбула дает более чем достаточно информации (даже с учетом допустимой для короткой статьи степень детализации) для того, чтобы понять, почему именно сейчас приобретают популярность нереляционные базы данных, сформулируем причины этого интереса более конкретно. Во-первых, во многих случаях узкоспециализированных сервисов (а именно о них сейчас идет речь) развитые реляционные базы просто избыточны. И это «просто» на самом деле означает ненужный в данном конкретном применении расход производительности. Который, в свою очередь, уже измеряется в потерях доходов – или из-за снижения привлекательности «тормозящего» сервиса, или из-за повышения расходов на рост быстродействия (а это не только разовые траты на закупку оборудования, но и постоянное увеличение стоимости администрирования и обслуживания, например). Во-вторых, реляционная модель данных может просто не соответствовать требованиям решаемых задач. Безусловно, и в рамках реляционной модели можно строить «эмуляции» специфических структур данных, например графов, но никто не отменяет требований реальности, в первую очередь – миллисекундного времени реакции (вспомним интенсивность просмотров фотографий в Facebook). Любая же эмуляция – это расход ресурсов, недопустимый в задачах реального времени (а мы как раз говорим о них – современный пользователь ИТ-сервиса не хочет ждать, когда система осчастливит его реакцией на запрос). Есть еще множество доводов – от технологических, экономических и лицензионных до сугубо эмоциональных, но они, как показывает практика, второстепенны.

Наш краткий обзор мы начнем с системы, о которой дольше рассказывать, что она из себя не представляет, чем дать краткую характеристику ее функциональности. Но мы все же начнем ее описание от обратного. Во-первых, хоть она и никоим образом не реляционная СУБД, но удовлетворяет критериям ACID (атомарности, непротиворечивости, изоляции и гарантированной завершенности или долговечности транзакций). Во-вторых, она и не объектно-ориентированная СУБД. В-третьих, она «прозрачна» – не вводит в смысловое поле использующей ее надсистемы никаких новых абстракций, влекущих необходимость в модификациях. В-четвертых, ее разработка поддерживается, и она сама, несмотря на молодость, реально используется одним из известнейших масштабных сервисов. Сочетание, согласитесь, очень удачное. Речь идет о проекте Voldemort, результатом деятельности участников которого является одноименная по сути... хэш-таблица. Только «несколько» отличающаяся от тех базовых примитивных конструкций, которые знакомы каждому программисту. Для начала следует указать, что Voldemort – распределенная хэш-таблица. Это означает, что обеспечение фундаментальной функциональности любой хэш-таблицы – нахождение по некоторому ключевому значению методом вычисления специальной функции индекса соответствующей этому ключу записи и собственно записи – может быть «размазано» по множеству соединенных в сеть вычислителей. В свою очередь это «размазывание» функциональности, изначально заложенное в «конструкцию» распределенных хэш-таблиц, означает их принципиальную пригодность к масштабированию. Иными словами, систему хранения данных на основе распределенной хэш-таблицы мож-но наращивать в соответствии с потребностями практически чуть ли без ограничений одним из самых дешевых способов – добавлением новых вычислительных узлов сети. Кроме того, Voldemort – персистентная хэш-таблица. Это тоже немаловажный нюанс – записи в ней хранятся не только дольше использующих их вычислительных процессов, но и остаются в сохранности при отключении питания всех вычислителей сети. Ну и наконец, Voldermort – устойчивая к сбоям система. В отличие от более маститых аналогов и хорошо известных реляционных СУБД Voldemort обладает рядом очень «аппетитных» особенностей. К ним, кроме очевидных, требуемых классом этой системы (автоматические репликация и секционирование, например), следует отнести удачную архитектурную реализацию – полностью децентрализованная система из совершенно независимых отдельных вычислителей не просто реализует единые механизм кэширования в быстродействующей оперативной памяти и подсистему хранения данных, в ней это сделано так, что для отладки и моделирования сервисов с ее использованием совершенно нет нужды в развертывании тестового кластера и можно обойтись всего одной машиной. Кроме того, механизмы репликации базы данных в Voldemort допускают поддержку множества копий «дубликатов» для операций чтения и записи (так называемое горизонтальное масштабирование репликации), а процедура секционирования (разбиения большой базы на меньшие фрагменты) выполняется прозрачно. Все это свидетельствует в пользу того, что Voldemort является очень интересной и перспективной разработкой, развитие которой не стоит упускать из вида. Система распространяется с открытыми исходными текстами на основании либеральной лицензии Apache 2.0, а поддержкой процесса ее разработки и «обкаткой» в условиях, «приближенных к боевым», занимаются специалисты известного масштабного сервиса LinkedIn.

В качестве второго примера совсем уж нереляционной крайности автор выбрал СУБД Neo4j (neo4j.org). Как и Voldemort, эта система реализована на Java и распространяется с открытыми на основе лицензии GNU AGPL исходными текстами. Так же, как и Voldemort, Neo4j не является реляционной СУБД, соответствует критериям ACID и способна работать в распределенных вычислительных системах. Собственно говоря, на этом сходство и заканчивается. Во всем остальном две системы – чуть ли неполная противоположность друг другу. Проекты отличаются даже организационно. Так, Neo4j трудно назвать молодым – система прошла многолетнюю разработку и доводку традиционными коммерческими методами и используется более пяти лет в реальных сервисах, в том числе и загруженных, работающих в режиме 24/7. Ну а если говорить об используемых абстракциях (которых в Voldemort как бы и не было, кроме традиционных «ключа» и «записи»), то здесь начинается настоящая бездна. Neo4j – система, ориентированная на хранение так называемых «не совсем структурированных» данных, возможно – динамически изменяемых, которые лучше всего описываются топологической конструкцией – графом. Поэтому здесь нет ни привычных в «бухгалтерском» мире реляционных СУБД таблиц, строк и столбцов, ни простых пар «ключ-запись». Фундаментальные понятия Neo4j – узлы, отношения и свойства. При этом свойства могут быть присущи как узлам, так и отношениям. Более того, Neo4j допускает хранение в одной базе, например узлов с разными наборами свойств (в мире реляционных СУБД нечто подобное также возможно, но реализуется очень «неуклюже»). Ну и наконец, Neo4j предлагает разработчику совершенно иной механизм «навигации» в графе данных. Именно навигации – в теории баз данных граф-ориентированные СУБД также называются «навигационными». Соответственно, запросы к такой базе данных радикально отличаются от реляционных – они обязательно включают стартовый узел графа и содержат некоторое условие или множество условий, так, что их можно описать, например, следующей неформальной конструкцией: «найти множество всех узлов с заданными свойствами, соединенных путями с заданными свойствами со стартовым узлом». В Neo4j эти механизмы навигации доступны посредством несложного и внятного API (эта СУБД относится к классу «встраиваемых» и не располагает собственным специальным языком запросов) и реализованы с учетом потенциальных размеров баз данных, которые в реальных проектах описывают сети с несколькими сотнями миллионов узлов.

К числу очень интересных разработок в области нереляционных СУБД можно отнести сравнительно молодую Persevere (docs.persvr.org) – систему одновременно куда более функциональную, чем «просто» распределенная хэш-таблица, соответствующая критериям ACID, и потенциально более широко применимую, чем Neo4j. Persevere объединяет в себе и СУБД (если быть более точным – персистентное хранилище объектов), и сервер приложений, и, что главное, предоставляет доступ к их ресурсам посредством стандартных протоколов. Эту систему можно использовать как аналог распределенной хэш-таблицы, но допускающей цепочки сложных запросов, в которых результат предыдущего запроса используется в качестве базы данных для следующего. Естественно, более простые системы (такие как Voldemort) этой возможности лишены.

В отдельную категорию нереляционных СУБД, ориентированных на обслуживание большого числа простых запросов в сильнозагруженных системах, можно выделить уже целое множество разработок на популярном функциональном языке Erlang. В первую очередь следует упомянуть CouchDB. Несмотря на ее «документную ориентацию», фактически под «документом» в ней понимается та же пара «ключ-запись», что и, например, в Voldemort (разве что с некоторыми ограничениями). Как и Persevere, CouchDB не является встраиваемой СУБД и предполагает обмен данными с внешними подсистемами на основе формата JSON. Менее популярными, но во многих смыслах не менее интересными являются разработанные на Erlang нереляционные СУБД Scalaris, Dynomite, Ringo. Из этой тройки Scalaris – одна из самых интересных систем, в проект которой заложены уникальные свойства. Так, в отличие от большинства распределенных хэш-таблиц (Scalaris относится к этому классу СУБД) в ней реализовано упорядоченное хранение ключей, что позволяет выполнять невозможные в других системах запросы. Несмотря на усложнения, Scalaris – очень быстродействующая система, демонстрирующая, как и Voldemort, производительность порядка 10–20 тыс. транзакций при исполнении на одном вычислительном узле.

Естественно, объемы малой статьи не позволяют просто упомянуть даже названия всех существующих нереляционных СУБД. Поэтому автором были выбраны разработки, которые одновременно как бы «не у всех на слуху», представляют заслуженный интерес своими особенностями и доступны всем желающим. Похоже, что время этих систем действительно пришло, и пусть даже не глубокое их знание, а просто осведомленность об их существовании для многих окажется далеко не лишней.

+77
голосов

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT