Операции, выполняемые мастером

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

В отличие от большинства файловых систем GFS не хранит состав файлов в директории. GFS логически представляет пространство имен, как таблицу, которая отображает каждый путь в метаданные. Такая таблица может эффективно храниться в памяти в виде бора (словаря этих самых путей). Каждая вершина в этом дереве (соответствует либо абсолютному пути к файлу, либо к директории) имеет соответствующие данные для блокировки чтения и записи(read write lock). Каждое операция мастера требует установления некоторых блокировок. В этом месте в системе используются блокировки чтения-записи. Обычно, если операция работает с /d1/d2/.../dn/leaf, то она устанавливает блокировки на чтение на /d1, /d1/d2,..., d1/d2/.../dn и блокировку, либо на чтение, либо на запись на d1/d2/.../dn/leaf. При этом leaf может быть как директорией, так и файлом.

Покажем на примере, как механизм блокировок может предотвратить создание файла /home/user/foo во время резервного копирования /home/user в /save/user. Операция резервного копирования устанавливает блокировки на чтение на /home и /save, а так же блокировки на запись на /home/user и /save/user. Операция создания файла требует блокировки на чтение /home и /home/user, а также блокировки на запись на /home/user/foo. Таким образом, вторая операция не начнет выполняться, пока не закончит выполнение первая, так как есть конфликтующая блокировка на /home/user. При создании файла не требуется блокировка на запись родительской директории, достаточно блокировки на чтение, которая предотвращает удаление этой директории.
Кластеры GFS, являются сильно распределенными и многоуровневыми.

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

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

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

1. Желательно поместить новую реплику на чанк-сервер с наименьшей средней загруженностью дисков. Это будет со временем выравнивать загруженность дисков на различных серверах.

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

3. Как сказано выше, желательно распределить чанки среди разных стоек.

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

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

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

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

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

Мастер помимо регулярного сканирования пространства имен файлов делает аналогичное сканирование пространства имен чанков. Мастер определяет чанки, которые отсоединены от файла, удаляет их из метаданных и во время регулярных связей с чанк-серверами передает им сигнал о возможности удаления всех реплик, содержащих заданный чанк.

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

Устойчивость к сбоям и диагностика ошибок

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

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

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

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

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

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

6.12. Berkeley DB – движок для СУБД

Berkeley DB (BDB) – высокопроизводительная встраиваемая база данных, реализованная в виде библиотеки (содержание данного пункта является полной копией работы http://bourabai.kz/dbt/dbms/berkeleydb.htm). BDB является нереляционной базой данных, то есть она хранит пары ключ / значение как массивы байтов и поддерживает множество значений для одного ключа. BDB может обслуживать тысячи процессов или потоков, одновременно манипулирующих базами данных размером в 256 терабайт, на разнообразном оборудовании под различными операционными системами, включая большинство UNIX-подобных систем и Windows, а также на операционных системах реального времени. Образно говоря, Berkeley BD – СУБД-невидимка, которой пользуются миллионы людей, не подозревая о ее существовании, так как она представляет собой “движок” - ядро СУБД, над которым программисты – разработчики создают свои СУБД, ОС и другие приложения, оперирующие большими массивами данных.

Первая версия Berkeley DB была разработана в Университете Беркли во время разработки BSD версии 4.3 (июнь 1986 года). Netscape попросила авторов Berkeley DB улучшить и расширить библиотеку – в то время версию 1.85, – чтобы она удовлетворяла их требованиям к использованию в сервере LDAP и в браузере Netscape. Этот запрос привёл к созданию Sleepycat Software (купленной корпорацией Oracle в феврале 2006 года). Berkeley DB распространяется под лицензией Sleepycat Public License (англ.), которая была одобрена OSI и FSF. Программа поставляется с полным исходным кодом, средствами сборки, инструментами тестирования и документацией. Качество кода и практичность вместе со свободной лицензией привело к использованию Berkeley DB во многих свободных и открытых программах. В рамках техники двойного лицензирования Oracle также распространяет проприетарную лицензию на использование библиотеки в закрытых проектах.

История СУБД-невидимки

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

В 1991 г., когда в Университете Беркли велись работы над проектом свободного от лицензионных ограничений клона ОС UNIX, перед разработчиками встала задача реализовать аналог одной из многочисленных библиотек – dbm. В те времена широко распространенная и востребованная dbm реализовывала относительно несложные механизмы однопользовательского хранилища данных. Востребованность же библиотеки объяснялась просто – она освобождала программистов от повторного решения в какой-то мере тривиальных задач накопления и хранения данных. Один из будущих авторов знаменитой книги “Дизайн и реализация ОС 4.4BSD” (“The Design and Implementation of the 4.4BSD Operating System” и исходные тексты BSD UNIX стали учебной партой для нескольких поколений программных архитекторов и системных программистов), ведущий архитектор 4.4BSD Кейт Бостик (Keith Bostic), предложил разработать свободный от лицензионного кода AT&T аналог dbm участникам проекта Марго Зельцер и Михаэлю Олсону. C этого момента началась история замечательного во всех отношениях программного продукта – Berkeley DB.

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

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

В-третьих, респектабельность семейного бизнеса Бостика, Зельцер и “примкнувшего к ним” Олсона получила убедительное доказательство после приобретения его гигантом мира баз данных Oracle (сумма и условия сделки, происшедшей в феврале этого года, не афишировались). И наконец.

В четвертых – Berkeley DB не повторила участи многих “прикупленных по случаю” программных проектов. Продукт развивается, и в последней, вышедшей недавно версии, предлагает пользователям совершенно новую функциональность.

Современные СУБД, использующие языки запросов (например, SQL), во многом похожи на систему, образованную компилятором с языка высокого уровня и аппаратными средствами целевой для этого компилятора машины. В данной системе высокоуровневый язык транслируется в некоторый промежуточный код, преобразуемый в бинарный код целевой машины. И наконец, бинарный код выполняется аппаратными средствами. В принципе, современные СУБД на уровне макроархитектуры отличаются от этой модели разве что спецификой промежуточного кода и системой команд аппаратных средств (к слову, “машины баз данных” в аппаратном смысле – не такая уж и редкость). Berkeley DB в подобной макроархитектуре занимает уровни от промежуточного кода (иначе говоря – среднеуровневого) до аппаратных средств. Естественно, Berkeley DB скрывает от программиста нюансы и сложности аппаратного уровня, предоставляя в распоряжение несоизмеримо более высокоуровневые возможности. Важно только не забывать, что все познается в сравнении, и макроассемблер сам является низкоуровневым средством по сравнению с современным объектно-ориентированным языком.

Berkeley DB позволяет использующему библиотеку программисту удобно оперировать базами данных и записями в них. В трактовании некоторых терминов Berkeley DB отличается от высокоуровневых СУБД, в большинстве же случаев терминология аналогична. Так, запись Berkeley DB, являющаяся парой, образованной ключом-идентификатором записи и данными записи, в некотором смысле идентична записи в двухколоночной таблице в терминах реляционных БД. Но так как и данные, и даже ключ в Berkeley DB могут сами быть наборами данных (например, структурами языка C), то вполне допустимы аналогии и с многоколоночными таблицами. Понятие базы данных в Berkeley DB, напротив, радикально отличается от так же звучащего термина высокоуровневых аналогов – здесь это множество записей с одинаковыми типами ключа и данных, формируемое на основании выбранного программистом механизма доступа (в высокоуровневых СУБД, в свою очередь, последний обычно полностью скрыт).

В Berkeley DB существуют и уникальные конструкции, и, естественно, уникальные термины для их обозначения. Так, окружение (environment) Berkeley DB – это конструкция, позволяющая оперировать множеством БД с записями разных типов (здесь и далее под типом записи понимается пара типов ключа и данных) как единым целым. К специфическим понятиям Berkeley DB следует также отнести вторичные БД, позволяющие устранить важное и очевидное ограничение Berkeley DB, суть которого в неявной форме была только что указана. Речь, естественно, идет о единственности понятия ключа в записи Berkeley DB. А как быть, если данные записи представляют собой наборы данных, и программисту нужен, например, быстрый поиск в базе не только по ключам, но и по значениям определенных полей в этих наборах данных? Без вторичных баз для решения подобной задачи было бы необходимо последовательно просматривать записи базы до выполнения условия поиска, что крайне неэффективно. Вторичные же базы данных хранят индексы полей наборов данных записей и позволяют использовать механизмы быстрого поиска.

Следует заметить, что создание вторичной БД инициируется программистом, а ведение поддерживается Berkeley DB в полностью автоматическом режиме (вторичная БД недоступна по записи). Впрочем, упомянутый как неэффективный механизм последовательного просмотра (иначе говоря – доступа) к записям базы данных часто бывает необходим. В Berkeley DB он реализован с помощью курсоров (cursor), для которых существует более распространенное название итераторов.

Методы доступа Berkeley DB – это механизмы, позволяющие эффективно решать задачи поиска записи по ключу, добавления и удаления записей. В зависимости от характера (типа) ключей можно выделить два класса методов доступа. Так, для ключей, характеризующих содержимое записи, применяются методы доступа с помощью сбалансированных деревьев (BTree) и хэш-функций (Hash). Для тех баз данных, в которых ключи характеризуют уникальный логический номер записи, используются методы доступа на основе очереди (Queue) и “номера записи” (Recno).

Упомянутый ранее язык Berkeley DB (аналогичный по уровню макроассемблеру) – это, естественно, раз мы ведем речь о библиотеке, – интерфейс прикладного программирования (API). Следует отметить, что, несмотря на язык разработки (ANSI C), Berkeley DB – красиво написанная объектно-ориентированная программа, и об этом надо знать для того, чтобы изучать ее отлично документированный API. Ключевая структура данных в Berkeley DB – дескриптор базы (C-структура __db, декларацию которой можно найти в файле db.in, находящемся в подкаталоге dbinc дистрибутива Berkeley DB), содержит указатели на функции API – методы, и поэтому во многом аналогична классу, например, в С++. Поэтому в документации Berkeley DB принят следующий шаблон описания многих функций:

DB->имя_функции()

Эта запись означает, что подобные функции допустимо использовать только после создания базы данных (результатом которого является в том числе и формирование структуры дескриптора, для него в документации принято имя типа DB) и только посредством вызова функции разыменованием указателя на нее в созданном дескрипторе:

#include <db.h>typedef struct __db DB;/* резервируем место под указатель на дескриптор базы */DB db0_handle;/* создаем базу и дескриптор базы, инициируем указатель на него */db_create(*db0_handle...);/* удаляем базу, вызывая метод DB->close разыменованием указателя в дескрипторе */db0_handle->close(db0_handle...);

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

Во-первых, начиная с последней версии, выпущенной уже под эгидой Oracle, Berkeley DB приобрела одно совершенно уникальное свойство, позволяющее устранить существенный недостаток “встраиваемых” программ.

Давайте представим себе следующую ситуацию – вы разработали некий программный продукт с использованием библиотеки Berkeley DB и передали его на эксплуатацию заказчику. Но вот появились исходные коды новой версии библиотеки, устраняющие, например, только обнаруженную ошибку (даже очень хорошие программы не идеальны). Что вы должны сделать, чтобы обезопасить своего заказчика от потенциальных рисков, связанных с этой ошибкой? Естественно, пересобрать свою программу с новой версией libdb и переинсталлировать ее у заказчика. А если специфика его работы не допускает остановки исполнения вашей задачи? Именно для таких случаев Berkley DB предлагает механизм модернизации бинарного кода библиотеки без остановки сервиса базы данных.

Во-вторых, реализованный в Berkeley DB механизм транзакций (одновременных множественных операций с базами данных) полностью соответствует перечню свойств ACID (Atomicity, Consistency, Isolation, Durability). Это означает, что транзакции Berkeley DB действительно атомарны (т. е. неделимы и гарантированно приводят или к требуемым изменениям, или вообще не изменяют состояния базы данных), непротиворечивы (не приводят к запрещенным состояниям базы данных), изолированы (какое-либо взаимодействие одновременных транзакций, инициированных разными пользователями, невозможно) и наконец, надежны (сбои в работе системы после завершения транзакции не приводят к потере ее результатов).

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

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

В-пятых, Berkeley DB – разработка, не страдающая манией гигантизма. Динамически загружаемая библиотека, собранная в ОС Windows XP, занимает немногим больше 500 KB.

В общем, эта программа заслуживает того, чтобы вы ее изучили и использовали. Тем более что распространяется Berkeley DB на основании двух лицензий одновременно, и принципы лицензирования ни в чем не противоречат ни требованиям сторонников открытого ПО, ни придерживающимся традиционных принципов собственности разработчиков. Михаэль Олсон, будучи президентом и CEO компании Sleepycat, так охарактеризовал принцип двойного лицензирования – если вы пришли к нам из мира открытых исходных текстов, вы пришли в мир открытых исходных текстов, если же вы – собственник закрытого ПО, мы ничем не отличаемся для вас от всех остальных ваших поставщиков.

Архитектура Berkeley DB

Berkeley DB примечательна своей простой архитектурой в сравнении с другими системами баз данных, такими как, например Microsoft SQL Server и Oracle Database. Например, в ней отсутствует сетевой доступ — программы используют базу данных через вызовы внутрипроцессного API. Она поддерживает SQL в качестве одного из интерфейсов, начиная с версии 5.0, хотя и не поддерживает столбцы в таблицах в традиционном понимании на уровне внутренней архитектуры. Berkeley DB предполагает работу с парами ключ-значение, где ключ и значение могут иметь фиксированную или переменную длину, а функция сравнения ключей может быть написана и назначена прикладным программистом.

Программа, которая использует БД, сама решает, как данные сохраняются в записи; БД не налагает ограничений на данные, хранимые в записях. Запись и её ключ оба могут иметь размер до четырёх гигабайт.

Berkeley DB поддерживает необходимые возможности баз данных, такие как ACID-транзакции, детальные блокировки, интерфейс распределённых транзакций XA, горячее резервное копирование и репликацию. Berkeley DB может использоваться как средство для построения хранимых индексов, так и в качестве хранилища данных.

Oracle предлагает BDB в трёх вариантах:

1. Berkeley DB — собственно библиотека на языке “C”;

2. Berkeley DB Java — библиотека, переписанная на Java (поддержка Google Android, Apache Maven);

3. Berkeley DB XML — библиотека на Си, реализующая XML-СУБД на основе Berkeley DB со средствами работы с XML (Xerces, XPath, XQuery, XQilla).

Berkeley DB входит в состав большинства дистрибутивов Linux. Существуют интерфейсные средства для работы с Berkeley DB на Perl, Python и других языках.

Программы, в которых используется Berkeley DB

Berkeley DB является хранилищем данных для серверов LDAP, СУБД и множества других проприентарных и свободных программ. Ниже приведён список программ, в которых для хранения данных используется Berkeley DB:

1. Bogofilter — свободный спам-фильтр который хранит свои списки ключевых слов в Berkeley DB;

2. Caravel CMS — свободный web-движок изначально разработанный для использования в более чем 2000 организаций Меннонитской церкви;

3. Citadel — свободная платформа совместной работы, в которой все данные, включая базу сообщений, хранятся в Berkeley DB;

4. Fedora Directory Server — сервер каталогов уровня предприятия c открытым исходным кодом. Изначально именно под нужды FDS (тогда сервер назывался Netscape Directory Server) была адаптирована академическая версия BerkeleyDB;

5. Jabberd2 — сервер сети Jabber;

6. KDevelop — интегрированная среда разработки для Linux и других Unix-подобных операционных систем;

7. KLibido — свободный клиент новостных групп USENET, ориентированный на скачивание бинарных файлов;

8. MemcacheDB — Распределённое постоянное хранилище данных, реализующее интерфейс Memcached;

9. Movable Type — проприетарная система публикации блогов, разработанная калифорнийской компанией Six Apart;

10. MySQL — поддержка таблиц BDB включена в дистрибутив исходного кода MySQL начиная с версии 3.23.34 и в бинарную версию MySQL-Max. BerkeleyDB обеспечивает транзакционный обработчик таблиц для MySQL. Использование BerkeleyDB повышает для таблиц шансы уцелеть после сбоев, а также предоставляет возможность осуществлять операции COMMIT и ROLLBACK для транзакций. Дистрибутив исходного кода MySQL поставляется с дистрибутивом BDB, содержащим несколько небольших исправлений, которые позволяют устранить определённые проблемы при работе с MySQL. Начиная с версии 5.1 таблицы BDB более не поддерживаются;

11. OpenLDAP — свободная реализация “Облегчённого протокола доступа к каталогам” (LDAP);

12. Redland — прикладной каркас для RDF. Может использовать BDB для постоянного хранения данных (троек);

13. RPM — Менеджер пакетов RedHat;

14. Subversion — Система управления версиями, разработанная чтобы заменить CVS;

15. Sun Grid Engine — Свободная система управления распределёнными ресурсами. Самый популярный планировщик пакетных очередей задач для вычислительных ферм;

16. Spamassassin — Антиспамовое приложение;

17. Wialon — система спутникового мониторинга транспорта, работающая через Web-интерфейс.

6.13 СУБД – движок SQLite

SQLite — компактная встраиваемая реляционная база данных (содержание данного пункта является полной копией работы http://bourabai.kz/dbt/dbms/sqlite.htm). Исходный код библиотеки передан в общественное достояние. В 2005 году проект получил награду Google-O’Reilly Open Source Awards.

Слово “встраиваемый” означает, что SQLite не использует парадигму клиент-сервер, то есть движок SQLite не является отдельно работающим процессом, с которым взаимодействует программа, а предоставляет библиотеку, с которой программа компонуется и движок становится составной частью программы. Таким образом, в качестве протокола обмена используются вызовы функций (API) библиотеки SQLite. Такой подход уменьшает накладные расходы, время отклика и упрощает программу. SQLite хранит всю базу данных (включая определения, таблицы, индексы и данные) в единственном стандартном файле на том компьютере, на котором исполняется программа. Простота реализации достигается за счёт того, что перед началом исполнения транзакции записи весь файл, хранящий базу данных, блокируется; ACID-функции достигаются в том числе за счёт создания файла журнала.

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

В комплекте поставки идёт также функциональная клиентская часть в виде исполняемого файла sqlite3, с помощью которого демонстрируется реализация функций основной библиотеки. Клиентская часть работает из командной строки, позволяет обращаться к файлу БД на основе типовых функций ОС.

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

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

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

Описание	Значение	Константа в исходнике
Максимальная длина строки или BLOB-поля	1 000 000 000	SQLITE_MAX_LENGTH
Максимальное количество колонок	2 000	SQLITE_MAX_COLUMN
Максимальная длина SQL-выражения	1 000 000	SQLITE_MAX_SQL_LENGTH
Максимальное количество таблиц в выражениях с JOIN
Максимальная глубина дерева выражений	1 000	SQLITE_MAX_EXPR_DEPTH
Максимальное количество аргументов функции		SQLITE_MAX_FUNCTION_ARG
Максимальное количество термов в объединённом выражении с SELECT		SQLITE_MAX_COMPOUND_SELECT
Максимальная длина шаблона как аргумента операторов LIKE или GLOB	50 000	SQLITE_MAX_LIKE_PATTERN_LENGTH
Максимальное количество символов-заменителей в одном SQL-выражении		SQLITE_MAX_VARIABLE_NUMBER
Максимальная глубина рекурсии триггеров	1 000	SQLITE_MAX_TRIGGER_DEPTH
Максимальное количество присоединённых баз		SQLITE_MAX_ATTACHED
Максимальный размер страницы базы данных	32 768	SQLITE_MAX_PAGE_SIZE
Максимальное количество страниц в файле базы данных	1 073 741 823	SQLITE_MAX_PAGE_COUNT

На текущий момент только значение SQLITE_MAX_PAGE_SIZE не может быть больше заданного по умолчанию. Таким образом, не изменяя SQLITE_MAX_PAGE_COUNT, можно сказать, что максимальный размер файла базы данных составляет примерно 32ТБ (35.184.372.056.064 байт).Некоторые ограничения можно менять в сторону уменьшения во время исполнения программы при помощи задания категории и соответствующего значения функции sqlite3_limit():

int sqlite3_limit(sqlite3*, int id, int newVal)

Категория	Описание
SQLITE_LIMIT_LENGTH	Максимальная длина любой строки или BLOB-поля или ряда
SQLITE_LIMIT_SQL_LENGTH	Максимальная длина SQL-выражения
SQLITE_LIMIT_COLUMN	Максимальное количество колонок в определении таблицы или результате выборки, или индексе, или выражениях с операторами ORDER BY или GROUP BY
SQLITE_LIMIT_EXPR_DEPTH	Максимальная глубина разобранного дерева любого выражения
SQLITE_LIMIT_COMPOUND_SELECT	Максимальное количество термов в объединённом выражении с SELECT
SQLITE_LIMIT_VDBE_OP	Максимальное количество инструкций программы виртуальной машины выполняемого SQL-выражения
SQLITE_LIMIT_FUNCTION_ARG	Максимально количество аргументов функции
SQLITE_LIMIT_ATTACHED	Максимальное количество присоединённых баз
SQLITE_LIMIT_LIKE_PATTERN_LENGTH	Максимальная длина шаблона как аргумента операторов LIKE или GLOB
SQLITE_LIMIT_VARIABLE_NUMBER	Максимальное количество переменных в SQL-выражении, которые можно связать
SQLITE_LIMIT_TRIGGER_DEPTH	Максимальная глубина рекурсии триггеров

Это может быть полезным, если SQLite используется в веб-приложениях, так как уменьшенные пределы могут предотвратить DoS-атаки со стороны недоверяемых внешних клиентов.

Сама библиотека SQLite написана на C; существует большое количество привязок к другим языкам программирования, в том числе C++, Java, C#, VB.NET, Python, Perl, PHP, Tcl (средства для работы с Tcl включены в комплект поставки SQLite), Ruby, Haskell, Scheme, Smalltalk, Lua и Parser, а также ко многим другим. Полный список существующих средств размещён на странице проекта.

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

В частности, SQLite используют:

1. Adobe Integrated Runtime — среда для запуска приложений (частично);

2. Gears;

3. Фреймворк Qt;

4. Платформа XUL на движке Gecko 1.9, XULRunner 1.9 и, потенциально, все приложения, основанные на этой платформе, в том числе Mozilla Firefox (начиная с версии 3.0) и Mozilla Thunderbird (начиная с версии 3.0). В качестве примеров XUL-приложений можно привести Songbird и SQLite Manager.

5. Skype [5];

6. Некоторые модели GPS-навигаторов Garmin

7. Android API

Многие программы поддерживают SQLite в качестве формата хранения данных (особенно в Mac OS и iPhone OS, Android), в том числе:1С:Предприятие 7.7 (с помощью внешнего компонента); Adobe Photoshop Lightroom; FlylinkDC++; AIMP; Banshee; Eserv; F-Spot; FAR Manager (начиная с версии 3.0); Gajim; Google Chrome; Miranda IM (с помощью плагина драйвера базы данных); Money IQ; Mozilla Firefox; Opera (начиная с версии 10.50); qutIM; Safari; XnView; Garena.

Краткое описание СУБД SQLite при использовании PHP (содержание следующих пунктов является полной копией статьи Ожегова Дениса, Alexanderа Fedoroffа –

http://www.opennet.ru/base/dev/sqlite_guide.txt.html).

SQLite - это встраиваемая библиотека в которой реализовано многое из стандарта SQL 92. Её притязанием на известность является как собственно сам движок базы, так и её интерфейс (точнее его движок) в пределах одной библиотеки, а также возможность хранить все данные в одном файле. По функциональности SQLite где-то между MySQL и PostgreSQL. Однако, на практике, SQLite не редко оказывается в 2-3 раза (и даже больше) быстрее. Такое возможно благодаря высокоупорядоченной внутренней архитектуре и устранению необходимости в соединениях типа <<сервер-клиент>> и <<клиент-сервер>>.

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

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

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

Факт, что база данных - это единственный файл, делает её легко переносимой. SQLite к тому же, устраняет необходимость в запуске дополнительных служебных процессов (daemons), которые могли бы <<отъедать>> значительное количество памяти и других ресурсов, даже в случае умеренного использования базы данных.

Дата добавления: 2014-12-10