Без систем управления базами данных сложно представить эффективное использование информации, объемы которой стремительно растут с каждым годом. Современное состояние СУБД – результат развития рынка хранения данных за несколько десятков лет и даже веков.
Как развивались базы данных, как они эволюционировали в облаке и почему их появлению способствовали ткацкое дело, запуск космического корабля и бум интернета и мультимедиа в 90-х.
Идея автоматизации обработки информации
Первые успешные попытки автоматизации процесса обработки и хранения информации связаны с появлением перфокарт. Еще в 1725 году текстильщик Базиль Бушон разработал систему управления ткацким станком с помощью бумажной ленты с отверстиями. На основе этого изобретения в 1804 году Жозеф Жаккар создал ткацкую машину, управляемую «карточной цепочкой»: большие твердые пластины с несколькими рядами отверстий проходили через считывающее устройство, его щупы попадали в отверстия и поднимали необходимые нити для создания жаккардового узора.
Перфокарты использовались также для раскроя ткани и в механических пианино, завоевавших большую популярность в начале XX века. В 1890 году инженер Герман Холлерит создал табулятор – электрическое устройство, которое считывало информацию с перфокарт и выводило на бумажную ленту. Холлерит первым стал использовать перфокарты для хранения данных, а не инструкций.
Изначально перфокарта содержала 24 колонки и 12 строк и представляла собой картонный прямоугольник размером с доллар, для перфорации которого использовался пробойник кондуктора поезда. Перфокарта могла хранить, например, простую информацию из опросников, так табулятор нашел применение при переписи населения США, сократив время обработки данных с 8 лет до 1 года. На волне успеха табулятора Холлерит основал собственную компанию, которая в 1911 году вошла в состав Computing Tabulating Recording. CTR сосредоточилась на выпуске больших табуляторов и в 1924 году компания была переименована в International Business Machines.
IBM продолжили совершенствовать перфокарты, так в 1928 году они создали новую карту из 80 колонок и 12 строк, с прямоугольными пробивками, которая надолго стала наиболее популярной на рынке. Хранение данных на перфокартах и перфолентах оказалось настолько удачным решением, что применялось несколько десятков лет, не только в табуляторах, но и в инновационном изобретении 1940-х – вычислительных машинах.
Компьютеры с хранимыми программами и магнитные ленты
В 1944 году специалистами IBM был создан первый программируемый компьютер Марк I, в начале 50-х был разработан ламповый компьютер, а к концу десятилетия появились первые компьютеры на транзисторах. Вычислительные машины с хранимыми программами становились надежнее и быстрее, но продолжали массово использовать перфокарты для хранения и данных, и программ. Бизнес нуждался в сохранении постоянно увеличивающихся объемов информации – большие компании имели целые этажи для хранения перфокарт. При этом скорость чтения и записи была низкой, через считыватели нельзя было пропустить больше тысячи перфокарт в минуту. Для выполнения некоторых операций с данными нужно было использовать отдельные машины: сортировщики, перфораторы и табуляторы.
Исправить ситуацию помогли появившиеся в начале 50-х магнитные ленты. Они могли хранить данные 10 000 перфокарт, а отдельная запись на ленте уже рассматривалась как файл. Новые компьютеры с их емкими магнитными лентами для длительного хранения информации, пакетами ПО для расчета заработной платы, ведения инвентарных ведомостей, управления банковской деятельностью, постепенно вытеснили с рынка перфорационные комплексы.
Но технология магнитных лент имела один существенный недостаток. Лента физически не позволяла оперативно работать с данными, например. при ведении операций на фондовой бирже или при резервировании билетов, доступ был исключительно последовательным. Кроме того, для каждой системы приходилось заново разрабатывать файловую структуру, а при необходимости её изменить, приходилось вносить изменения и в ПО. Децентрализованное хранение данных приводило к дублированию файлов, а со временем к потере актуальности части данных. По сути такие файловые модели представляли собой замену ручных картотек, со всеми их недостатками. Эти проблемы привели к возникновению двух параллельно развивавшихся типов БД: иерархических и сетевых.
Космическая программа и появление СУБД
Иерархические базы появились во многом благодаря лунной программе NASA. В 1960-х компания Rockwell заключила с правительством США контракт на разработку командного отсека корабля Аполлон. Компании нужно было автоматизировать контроль данных и создать управление списком деталей в крупнейшем в мире инженерном проекте. Для учета около 2 миллионов компонентов космического корабля Rockwell создали систему управления файлами, работающую с магнитной лентой. Один её файл занимал 18 катушек ленты, более половины данных представляли собой избыточное повторение порядковых номеров деталей и частей, которые следовали за ней при сборке. Время доступа к данным было очень велико, а файл чаще всего был неактуальным из-за пакетной обработки данных, при которой данные сначала накапливаются в течение некоторого времени, а затем обрабатываются с помощью заданной последовательности программ.
В иерархических БД информация распределяется по «древовидному» принципу – каждый элемент, подобно ветвям дерева, имеет только один родительский элемент, но может иметь множество элементов потомков. На первом уровне иерархии всегда находится только один элемент, который называется корнем дерева. Связи между элементами одного уровня отсутствуют, поэтому данные в иерархической модели неравноправны – одни элементы жестко подчинены другим.
Для решения этих проблем Rockwell начали разработку метода прямого доступа к файлам, который должен быть простым в использовании, хорошо представлять иерархическую структуру файлов, слабо зависеть от аппаратной архитектуры. Этот метод назвали GUAM (Generalized Update Access Method), он стал первым примером реализации иерархической структуры. GUAM использовался в автоматизированной системе проектирования с дисковой памятью DOES, которая работала на платформе IBM 7010 с использованием дисковой системы 1301. Параллельно в компании разработали программу подготовки инженерной документации EDICT, для дистанционного отслеживания чертежей и инженерных спецификаций. В результате появился новый тип избыточности: половина данных в записи DOES совпадала с записью EDICT, но чтобы получить всю информацию нужно было запросить данные двух систем.
В этот момент IBM заявили о создании новой архитектуры мейнфреймов System/360. Чтобы воспользоваться всеми возможностями новых машин, специалисты Rockwell решили привлечь сотрудников IBM к разработке иерархической системы. Результатом их работы стала система под названием IMS. При реализации в пользу иерархической модели сыграли необходимость автоматизации обработки деталей и материалов, обладающих собственной иерархией, и то, что GUAM, ставший предшественником разработанного в рамках IMS специализированного языка запросов DL/I, тоже основывался на иерархической модели. В итоге специалисты получили оперативный доступ к данным и сэкономили место на диске, что было критично для проекта Аполлон.
К IMS изначально предъявлялись высокие требования, при этом Rockwell и IBM смотрели на систему по-разному. Для IBM одной из основных целей было создание коммерческого продукта. Для Rockwell важным было подготовить систему к эксплуатации до полёта на Луну. Rockwell заморозили работу над архитектурой IMS и занялись тестированием и внедрением системы, разработав множество приложений, внедрив автоматический откат прерванных транзакций, новый метод восстановления данных, контроль качества кода. В результате IMS стала не только инновационным продуктом, но и одним из самых надежных ПО на рынке.
Не только иерархические базы
Не только IBM и Rockwell занимались разработкой баз данных с оперативными транзакциями, крупный бизнес тоже нуждался в новых подходах. В 1963 году инженер General Electric Чарльз Бахман разработал СУБД IDS, основанную на сетевой модели данных. В отличие от иерархической модели в сетевой у потомка может быть любое количество предков.
Иерархическая и сетевая модели были конкурентами до середины 70-х годов, но на их фоне появилась совершенно новая, реляционная модель данных. Впервые она была предложена Эдгаром Коддом в цикле фундаментальных статей, опубликованных в 1969 — 1970 годах.
Реляционная база состоит из отношений, которые представлены в виде именованных таблиц. Каждый столбец имеет уникальное название и содержит элементы данных с простой структурой, которые несут одинаковую смысловую нагрузку (например столбец «Фамилия»). Все строки в пределах одной таблицы различны, а значит существует по крайней мере одна комбинация столбцов, которая позволяет однозначно определить нужную строку. В отличие от иерархической и сетевой моделей, в отношениях строки и столбцы отличаются только своим содержимым, а не порядком следования.
Для работы с данными в реляционных базах был разработан унифицированный структурированный язык запросов SQL. Появление новой модели данных вызвало множество споров, но время доказало ее эффективность – до сих пор большинство популярных СУБД всё еще используют реляционный подход.
Появление новых типов данных и баз
С ростом и изменением характера данных, необходимостью работать со сложными объектами, такими как карты, или мультимедиа, менялись и СУБД. В 80-х появились объектно-ориентированные базы, а к 90-м – мультимедийные.
В конце 2000-х годов в научной среде возникло понятие «Большие данные». Появилась необходимость в средствах массово-параллельной обработки и структурированных, и неструктурированных данных, а с последними реляционная модель справлялась не очень хорошо. Появилось понятие NoSQL – «не только SQL». Изначально название «NoSQL» принадлежало базе данных с открытым исходным кодом, которую создал Карло Строцци. В этой базе для доступа к данным вместо SQL использовались стандартные консольные команды, а сами данные хранились в виде текстовых файлов. В NoSQL базах в пользу высокой доступности данных пожертвовали их постоянной консистентностью: после изменения данных все запросы будут возвращать одинаковую информацию не сразу, а через некоторое время. Состояние самой базы изменяется в течение этого времени. Гарантируется завершение каждого запроса (успешное или безуспешное).
Полярность реляционного и NoSQL подхода, имеющих свои плюсы и минусы, привела к появлению комбинированных типов БД: NewSQL, имеющих реляционную структуру с использованием масштабируемых конструкций, и многомодельных баз, которые объединяют несколько видов баз в одной.
Облачные базы данных
В последние годы изменились не только типы хранимых данных, требования к производительности СУБД или модели данных, но и требования по горизонтальному масштабированию. Появление облачных платформ привело к массовой миграции в них БД. Первые облачные базы реализовали крупные облачные платформы, например, в 2009 году Amazon представили свою облачную реляционную базу данных RDS, а сейчас все крупные БД имеют облачную реализацию.
По оценкам Gartner, к 2022 году 75% всех баз данных будут развернуты или перенесены в облака. Сейчас существуют две основные модели развертывания баз. Первая – образ виртуальной машины, где можно самостоятельно запускать БД. Вторая – база данных как сервис, где пользователю предоставляется ограниченный набор БД, но не нужно заниматься установкой и обслуживанием, например, облачные базы данных Amazon Web Services или сервисы платформы данных Yandex.Cloud.
Несмотря на массовую миграцию БД в облака, базы всё еще используют разработанные ранее модели данных, связывают клиента с одним ЦОД и имеют свои преимущества и недостатки. С одной стороны, большие объемы данных вызывают так называемый «эффект притяжения», когда данные притягивают к себе сервисы и приложения, и в результате качество сервисов растет. С другой, когда объемы данных достигают петабайтов, возникает проблема их транспортировки. С таким количеством данных не могут справиться сети передачи, поэтому их приходится записывать на физические носители и перевозить с помощью транспорта. Впервые с этой проблемой столкнулись в Google, когда создавали «зеркала» на разных континентах, в итоге данные пришлось возить морскими контейнерами, сейчас и Google, и Amazon предлагают своим клиентам услуги по физической перевозке данных. Эта услуга может стать популярной, учитывая, что объем всех данных в «цифровой вселенной» удваивается в среднем каждые два года, и по оценкам международной исследовательской и консалтинговой компании IDC, к 2025 году составит 175 зеттабайт.
Подписывайтесь на блог Yandex.Cloud, чтобы узнавать еще больше новостей и историй об IT и бизнесе.
Другие истории, которые активно читают наши подписчики:
