Пока все идет хорошо (и данные, например, не начинают «мистическим образом» пропадать), никто особенно не склонен задумываться о внутренних механизмах работы хранилищ данных. База данных представляется неким черным ящиком, доступ к которому осуществляется через хорошо знакомый и отлаженный API – но все меняется, если возникают проблемы, причем необязательно отрицательного толка.
Бывает и так, что дела компании резко идут в гору, создается «наплыв» клиентов (а вместе с ними и данных), и привычные структуры попросту его не выдерживают. Вот тогда-то и наступает момент, когда приходится вспомнить, что база данных – это не просто магическая шкатулка, которая «принимает» и «отпускает» данные по первому требованию. И, соответственно, характеристики ввода и вывода информации – далеко не единственное, на что стоило бы обратить внимание, сравнивая и выбирая для себя наиболее подходящую технологию.
Почему это важно?
К примеру, задайте себе вопрос: что подразумевается под словом «операция базы данных»? Имеется ли в виду транзакция? Или, может быть, индексирование? Стоп, может, все-таки извлечение? И если так, то откуда вообще извлекаются ваши данные? С жесткого диска – или при помощи телепортационного луча откуда-то из звездной системы Альфа Центавра?
Кроме шуток, неопределенности и неоднозначности, касающиеся теоретических и практических аспектов баз данных, есть не только в экзаменационных ответах студентов-троечников. На практике такие пробелы чреваты невозможностью принять взвешенное решение и, в конечном счете, потерей данных.
Как этого избежать? Необязательно «учить матчасть» – достаточно просто раз и навсегда разобраться в понятиях.
Характеристики баз данных: модель данных
Итак, что же такое база данных? В принципе, любая структура, хранящая данные для их последующего извлечения, может быть отнесена к этой категории. Существует множество самых разных классификаций, но сегодня мы остановимся на, пожалуй, главной из пяти категорий, по которым отличаются все существующие базы данных, – модели данных (кроме нее, БД различаются по типу интерфейса прикладного программирования (API), транзакций, персистенции и, наконец, индексации – о них мы поговорим в следующих статьях).
Традиционно, эта категория моделей данных подразумевает три вида: реляционная модель, модель «ключ-значение» и иерархическая модель данных.
1. Реляционная модель – настоящая «классика», пик популярности которой пришелся на 90-е, хотя она и сейчас не сдает своих позиций. Во многом благодаря таким своим преимуществам, как способность занимать довольно мало места, доступность в смысле понимания ее структуры и механизмов, удобный язык запросов SQL и поддержка множества вариантов использования. Впрочем, почти каждый, кто сталкивался с этой моделью данных на практике – и особенно в случае больших данных – укажет на ее существенные недостатки: относительно низкая скорость работы при высоких затратах на прикладное программирование, а также заметная «сложносочиненность», со всеми вытекающими из этого потенциальными «косяками».
2. Модель «ключ-значение» предполагает наличие записей, в которых ключ (обычно, набор байтов) связан напрямую со значением (обычно другой набор байтов). Используется такая технология тогда, когда «исходный материал» не требует сложного реляционного подхода. База данных, построенная на модели «ключ-значение» будет работать быстро во многом за счет возможности сжатия записей (они одинаковы по размеру и имеют повторяющиеся данные) – и понять структуру такой базы будет гораздо проще. Однако отсутствие схемы, невозможность проверки данных на непротиворечивость и куда более сложная логика внедрения выглядят во многих случаях существенными недостатками.
3. Иерархическая модель стала популярной относительно недавно. Главное преимущество такой структуры – в эргономике: данные хранятся и извлекаются из БД точно в том виде, в котором они хранятся в объектах приложения. То есть в общем случае, все данные, касающиеся одного реального объекта, хранятся в одной записи со множеством разных ключей и значений, причем последние в свою очередь могут быть ассоциированы с другими ключами и значениями. Для хранения данных в этом случае понадобится больше места, чем в случае реляционной модели (хотя в последнее время это становится все менее и менее критичным), зато построение запросов существенно облегчается – ведь этот процесс сводится к извлечению единственной записи из единственной таблицы.
Кроме того, иерархическая модель является самой гибкой и надежной из существующих. Что до дегтя в этой бочке меда, то кроме возможных проблем с местом, такая модель не предусматривает схемы, поэтому данные могут приобретать достаточно хаотичную структуру, делая проверку данных на непротиворечивость невозможной.
Этим материалом мы начинаем серию статей, посвященных теоретическим и практическим особенностям баз данных. В следующих статьях речь пойдет о четырех оставшихся характеристиках баз данных – API, транзакциях, персистенции и индексации.
Автор: Лиза Филиппова
В основу статьи легли материалы ACM.
Спасибо!
Очень познавательная статья.
Жду следующих серий.
Супер!