Перфокарты, лунная программа «Аполлон» и эпоха big data: рассказываем о важном из истории хранения данных

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

Как развивались базы данных, как они эволюционировали в облаке и почему их появлению способствовали ткацкое дело, запуск космического корабля и бум интернета и мультимедиа в 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 и бизнесе.

Другие истории, которые активно читают наши подписчики:

• Неловко спросить: отвечаем на 5 простых вопросов об облаках для бизнеса
• От «носимых эффекторов» до «перспективного такси»: как в лаборатории СССР разработали умные вещи
  
• Зачем предсказывать урожай или как нейросеть научилась считать яблоки