VI.Детали

30. База данных — это деталь

 

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

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

Реляционные базы данных

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

Но какой бы блестящей, полезной и близкой к математике ни выглядела технология, она не перестает быть просто технологией. А значит, она — деталь.

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

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

Почему системы баз данных настолько распространены?

Почему среди программных систем и корпоративных программных продуктов доминирующее положение заняли системы баз данных? Чем объясняется превосходство Oracle, MySQL и SQL Server? Если говорить одним словом — диски.

Пять десятилетий вращающийся магнитный диск был основой хранения данных. Несколько поколений программистов не знали иных форм хранения данных. Технология производства дисковых накопителей прошла долгий путь от огромных пакетов массивных пластин по 48 дюймов в диаметре, весивших тысячи килограммов и способных хранить 20 мегабайт, до тонких дисков по 3 дюйма в диаметре, весящих несколько граммов и способных хранить терабайт данных и даже больше. Это была сумасшедшая гонка. И на протяжении всей этой гонки программисты страдали от одного фатального свойства дисков: они работают слишком медленно.

Данные хранятся на диске на круговых дорожках. Дорожки делятся на секторы, хранящие определенное круглое число байтов, обычно 4 Кбайт. На каждой пластине может иметься несколько сотен дорожек, а в одном дисковом накопителе — десяток или около того пластин. Чтобы прочитать конкретный байт, устройство должно поместить головку на конкретную дорожку, дождаться, пока диск повернется так, что требуемый сектор окажется под головкой, прочитать все 4 Кбайт из сектора в ОЗУ, и затем вам останется только прочитать требуемый байт из ОЗУ. Но все это требует времени — миллисекунд времени.

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

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

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

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

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

Сохранятся ли диски?

Прежде занимающие доминирующие позиции, ныне диски превратились в вымирающий вид. В скором времени их ожидает судьба накопителей на магнитной ленте, гибких дисков и приводов компакт-дисков. Им на смену придет ОЗУ.

Спросите себя: когда диски исчезнут и все данные будут храниться в ОЗУ, как вы будете организовывать их? Вы предпочтете организовать их в таблицы и обращаться к ним, используя запросы на языке SQL? Или организовать их в файлы и обращаться к ним через систему каталогов?

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

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

Детали

Такое положение дел объясняет, почему я говорю, что база данных — это деталь. Это лишь механизм перемещения данных взад-вперед между поверхностью диска и ОЗУ. База данных в действительности — не более чем большой мешок с битами, в котором мы храним свои данные. Но мы редко используем данные именно в такой форме.

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

А производительность?

Является ли производительность архитектурной проблемой? Конечно! Но в отношении хранения данных эту проблему можно полностью инкапсулировать и отделить от бизнес-правил. Да, нам нужно, чтобы данные быстро перемещались из хранилища и в хранилище, но это низкоуровневая проблема. Ее можно решить с помощью низкоуровневых механизмов доступа к данным. И она не имеет ничего общего с архитектурой системы.

История

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

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

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

Для меня это было бессмысленно. Почему я должен превращать связные списки и деревья в кучу записей и таблиц, доступных через SQL? Почему я должен вводить накладные расходы и тратить деньги на приобретение массивной СУРБД, если простых файлов более чем достаточно? Поэтому я вступил в сражение с ним, пустив в ход зубы и когти.

В этой компании работал один инженер-электронщик, который направо и налево расхваливал СУРБД. Он имел свое, техническое обоснование необходимости СУРБД в нашей системе. За моей спиной он встретился с руководством компании, нарисовал изображение дома на шесте и спросил у руководства: «Хотели бы вы жить в доме на шесте?» Его посыл был прост: он считал, что СУРБД, хранящая таблицы в файлах, надежнее простых файлов, которые мы использовали.

Я боролся с ним. Я боролся с маркетологом. Я придерживался своих технических принципов перед лицом невероятного невежества. Я боролся, боролся и боролся.

В конце концов электронщик пошел на повышение и стал руководителем отдела программного обеспечения. Они втиснули СУРБД в эту несчастную систему. И в результате они оказались абсолютно правы, а я ошибался.

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

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

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

Что я должен был сделать в описанной ситуации? Я должен был прикрутить СУРБД к системе и дать ей узкий и безопасный канал доступа к данным, сохранив в ядре системы простые файлы. А что я сделал? Я ушел и стал консультантом.

Заключение

Организационная структура и модель данных являются архитектурно значимыми, а технологии и системы, перемещающие данные на вращающуюся магнитную поверхность, — нет. Системы реляционных баз данных, которые заставляют организовывать данные в таблицы и обращаться к ним посредством SQL, имеют гораздо больше общего с последними, чем с первыми. Данные — значимы, а база данных — это деталь.