Рейтинг@Mail.ru
[Войти] [Зарегистрироваться]

Наши друзья и партнеры

UnixForum
купить дешевый 
компьютер родом из Dhgate.com




Lines Club

Ищем достойных соперников.

Библиотека сайта или "Мой Linux Documentation Project"

База с "археологическим" принципом хранения данных

Оригинал: An Archaeology-Inspired Database
Автор: Yoav Rubin
Дата публикации: 20 October 2015
Перевод: Н.Ромоданов
Дата перевода: июль 2016 г.

Глава 7 из предварительной версии книги "500 Lines or Less", которая входит в серию "Архитектура приложений с открытым исходным кодом", том 4.

Creative Commons

Перевод сделан в соответствие с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.

Сегодня мы представляем седьмую главу предварительной публикации нашего нового сборника «500 строк или меньше». Глава написана Йоавом Рубиным (Yoav Rubin).

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

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

Приятного чтения!

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

Это предварительная публикация главы из сборника «500 строк или меньше», четвертой книги из серии книг Архитектура приложений с открытым исходным кодом. Пожалуйста, сообщайте в нашем треккере GitHub о любых проблемах, которые вы обнаружите при чтении этой главы. Следите в блоге AOSA или в Твиттере за объявлениями о предварительных публикациях новых глав и окончательной публикацией.

Йоав Рубин является старшим инженером-программистом в Microsoft, ранее был научным сотрудником и мастером изобретатель в IBM Research. Сейчас его работа связана с вопросами безопасности данных в облачном хранилище, а в прошлом он занимался разработкой облачного хранилища и среды разработки на основе веб-технологий. Йоав имеет степень магистра по медицине в области неврологии, а также степень бакалавра наук в области инженерии информационных систем. Его можно найти в Twitter-е по ссылке @yoavrubin, а иногда и в блогах в http://yoavrubin.blogspot.com.

Введение

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

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

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

Например, в большинстве современных баз данных обновления осуществляются посредством переписывания данных на место старых данных вместо того, чтобы добавить новые данные и сохранить старые данные. Этот механизм, который Рич Хикки (Rich Hickey) назвал "позиционно-ориентированным программированием", экономит пространство, но делает невозможным получить всю историю конкретной записи. Это дизайнерское решение отражает точку зрения ученых о том, что "история" является менее важной, чем стоимость хранения данных.

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

(Отказ от ответственности:. Мое понимание взглядов типичного археолога основано на посещении нескольких музеев, чтении нескольких статей Википедии, и просмотра всей серии участием Индиана Джонса).

Создаем базу с «археологическим» принципом хранения данных

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

  • Все данные найдены и каталогизированы в определенном месте.
  • Если копать глубже, то можно обнаружить предметы из более ранних времен.
  • Артефакты, найденные в том же слое, принадлежать одному и тому же периоду.
  • На состоянии каждого артефакта отражается влияние разных периодов.

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

На рис.1 визуально представлена аналогичная ситуация:

  • Вся круг представляет собой место раскопок.
  • Каждое кольцо представляет собой слой (они пронумерованы от 0 до 4).
  • Каждый сектор помечен как артефакт (от "А" и до "E").
  • Каждый артефакт имеет «символьный» атрибут (где пусто, то это означает, что ничего не изменилось).
  • Толстые стрелки обозначают изменение символа при перемещении между слоями
  • Пунктирные стрелки являются произвольными взаимосвязями между артефактами (например, от "E" до "А").

Рис.1: Место раскопок

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

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

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

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

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

Продолжение статьи смотрите здесь


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

Комментарии отсутствуют