ФАЙЛ-СЕРВЕРНАЯ  NOSQL  СУБД

Шахматов  Александр  Александрович

студент  4  курса,  факультета  информатики,  математики  и  физики  ШГПИ,  г.  Шадринск

E-mail:  xardas1307@gmail.com

Слинкин  Дмитрий  Анатольевич

научный  руководитель,  канд.  пед.  наук,  доцент  ШГПИ,  г.  Шадринск

По  мнению  аналитического  агентства  Gartner,  манипуляции  с  большими  объемами  данных  при  помощи  внешних  нетрадиционных  NoSQL-хранилищ  входят  в  «Топ-10  стратегических  технологических  трендов  2013  года»  [3].  Однако,  NoSQL  базы  могут  быть  более  эффективны  и  на  малых  объемах  данных,  которые  предполагают  некоторую  иерархичность.  Так  называемые,  «schemaless  key-value  storage»  позволяет  быстро  начать  работу  над  данными  и  не  требуют  детальной  проработки  и  длительной  проектировки,  как  реляционные  базы  данных  (РБД).

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

1.Полная  изоляция  данных  и  возможность  напрямую  редактировать  их  без  наличия  СУБД.

2.Наличие  доступого  API  для  большинства  известных  языков  программирования.

3.Возможность  AJAX-запросов  к  СУБД.

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

Одним  из  самых  подходящих  под  заданные  критерии  была  СУБД  от  Apache  —  документо-ориентированная  CouchDB,  которая  обладает  огромным  потенциалом,  но,  к  сожалению,  не  подходящая  по  причине  не  слишком  удобной  (хотя  и  несомненно  лучшей,  чем  у  аналогов)  работы  с  бинарными  данными  и  невозможности  напрямую  редактировать  данные  без  веб-интерфейса  (хотя,  опять  же,  редактировать  данные  можно  и  с  помощью  CURL  по  HTTP,  однако  данное  решение  слишком  громоздко  и  неудобно).

Таким  образом,  было  принято  решение  разработать  свою  СУБД,  которая  бы  в  полной  мере  отвечала  заданным  критериям,  а  именно:

1.  Имела  бы  полноценный  REST-интерфейс.

2.  Данные  хранились  бы  напрямую  в  файлах.

Если  с  первым  всё  очевидно  (соответствие  второму  и  третьему  пункту  требований),  то  со  вторым  пунктом  имелись  некоторые  сложности.  Необходимо  было  решить,  как  именно  будут  храниться  данные,  по  какому  принципу  и  т.  д.  Решение  было  навеяно  структурой  JSON  документов  в  CouchDB  и  MongoDB.

Согласно  RFC-2627  [2],  JavaScript  Object  Notation  (JSON)  —  легковесный,  основанный  на  текстовой  информации,  независящий  от  языка  программирования  изменяемый  формат  для  сериализации  структурированных  данных.  С  помощью  JSON  можно  представить  в  удобном  для  человека  и  автоматизированной  обработки  формате  иерархическую  структуру  любой  сложности  в  формате  ключ-значение  (key-value).  Многие  REST-сервисы  предоставляют  API  для  работы  со  своими  ресурсами  при  помощи  JSON  или  XML.  JSON  имеет  преимущество  перед  XML  в  более  легком  восприятии  его  человеком,  а  также  встроенными  платформонезависимыми  типами  данных.  Собственно,  по  этой  причине  он  и  был  выбран.

Однако  для  упрощенного  доступа  к  данным  и  пакетной  их  обработке  напрямую  стандартными  средствами  GNU/Linux  было  предложено  использовать  следующую  структуру:  все  пары  ключ-значение  преобразуются  по  правилу  «ключ  —  название  файла,  значение  —  его  содержимое»,  вложенные  пары,  у  которых  значение  является  ключом  для  следующей  пары  —  преобразуются  в  папки.  Таким  образом,  можно  быстро  превратить  JSON-структуру  в  файловую  и  наоборот,  древовидную  структуру  файлов  и  папок  представить  в  виде  JSON-документа.

В  соответствии  с  идеологией  REST  [1],  для  обращения  к  БД  используются  4  HTTP-запроса:  GET,  POST,  PUT,  DELETE.  GET  для  получения,  POST  для  обновления,  PUT  для  добавления  и  DELETE  для  удаления  (стандартные  CRUD-операции  (Create  Read  Update  Delete))  данных.

При  обращении  по  определенному  URL  методом  GET,  имеющего  вид  имя_протокола:  //имя.сервера:  порт/db/*,  часть  URL,  которая  соответствует  символу  «*»  в  схеме  разбивается  на  имена  директорий  (например,  https://shgpi.edu.ru:5678/db/xyz/123/  разбивается  на  на  две  папки:  xyz  и  вложенная  в  неё  папка  123).  При  этом  в  JSON-ответ,  формируемый  сервером,  попадает  полное  дерево  каталогов  и  файлов  начиная  от  той  папки,  которую  мы  указали  в  URL,  при  условии  её  существования.  Иначе  будет  выдана  ошибка  с  кодом  404  и  ответом  {“ok”:  false,  “error”:  “Not  found”}.

По  аналогии  создаются  запросы  и  другими  методами.  Например,  при  обращении  к  серверу  методом  PUT  по  URL  https:  //shgpi.edu.ru:5678/db/xyz/123/  будет  осуществлена  проверка  существования  указанной  директории,  если  таковая  существует,  будет  выдана  ошибка  с  кодом  409  и  ответом  {"ok"  =>  false,  "error"  =>  "Item  already  exist"},  иначе  директорая  будет  создана,  и  в  неё  будет  записано  содержимое  данных  запроса,  которые  обязательно  должны  представлять  собой  консистентный  JSON-документ,  иначе  будет  выдана  ошибка  с  кодом  400  и  ответом  {"ok"  =>  false,  "error"  =>  "Not  valid  JSON"}.  В  случае  успеха  генерируется  стандартный  ответ  с  кодом  200  и  текстом  {"ok"  =>  true}.  При  обращении  методом  POST  поведение  сервера  схоже,  за  исключением  того,  что  начальная  директория  проверяется  не  на  отсутствие,  а  на  наличие.  При  обращении  же  методом  DELETE  проверяется  на  наличие  исходной  директории  и  если  присутствуют  данные  в  запросе,  которые  представляют  собой  валидный  массив  JSON,  то  удаляются  только  присутствующие  в  массиве  элементы,  при  отсутствии  данных  запроса  удаляется  только  директория,  к  которой  происходит  обращение.

В  указанной  схеме  имеется  некоторое  отличие  от  классического  использования  REST-архитектуры:  для  обновления  данных  используется  POST  вместо  PUT,  и  наоборот  для  создания  нового  ресурса  используется  PUT  вместо  POST.  Данная  рассогласованность  возникла  из-за  желания  максимизировать  совместимость  данной  СУБД  с  HTTP-интерфейсом  CouchDB.

На  данный  момент  кроме  обычных  GET-запросов  поддерживаются  запросы  с  параметрами.  Параметр  GET  type=conference  означает,  что  в  результирующую  выборку  должны  попасть  только  элементы  дерева,  у  которых  свойство  type  равняется  conference,  включая  все  его  ветви.  В  дальнейшем  планируется  расширение  возможностей  выборки  по  различным  категориям,  включая  регулярные  выражения,  а  также  создание  пользовательских  представлений  для  данных.

Поддерживается  также  кэширование  ответов  сервера  на  GET-запросы,  основанное  на  механизме  с  использованием  HTTP-заголовка  Last-Modified.

Для  предотвращения  выполнения  операций  создания,  изменения  и  удаление  от  неавторизованного  пользователя  был  внедрен  механизм  разделения  ресурсов  на  основе  Basic  HTTP  Authentication,  для  защиты  которого  было  использовано  SSL-шифрование.

Сам  прототип  СУБД  был  написан  на  ЯП  Ruby  под  ОС  Альт  Линукс  6,  с  использованием  следующих  гемов:  thin  (легковесный  веб-сервер),  sinatra  (веб-фреймворк  для  упрощенного  роутинга  и  пр.)  и  rack  (обработка  HTTP-запросов),  json/ext  из  stdlib  (для  обеспечения  быстрой  обработки  данных  в  формате  JSON),  rb-inotify  (для  отслеживания  изменений  файловой  системы,  в  целях  оптимального  кэширования  ответов).  Исходный  код  и  вся  сопутствующая  документация  доступны  по  ссылке:  https://github.com/X2rdas/easedb  .

Данная  СУБД  была  использована  в  проекте  «Система  автоматизированного  проведения  конференций»,  которая  успешно  внедряется  в  ФГБОУ  ВПО  «Шадринский  государственный  педагогический  институт»  в  рамках  студенческого  форума  «Актуальные  проблемы  теории  и  методики  информатики,  математики  и  физики».  Планируется  дальнейшее  развитие  СУБД,  а  также  добавление  веб-интерфейса,  который  бы  позволял  редактировать  данные  в  БД  без  непосредственного  входа  на  сервер  и  различные  другие  механизмы.

Список  литературы:

1. Crockford  D.  RFC  4627.  The  application/json  Media  Type  for  JavaScript  Object  Notation  (JSON)  //  The  Internet  Engineering  Task  Force.  —  2006.  [Электронный  ресурс]  —  Режим  доступа.  —  URL:  http://tools.ietf.org/html/rfc4627  (дата  обращения  2.03.2013)
2. Fielding  R.T.  Architectural  Styles  and  the  Design  of  Network-based  Software  Architectures.  Chapter  5.  Representational  State  Transfer  (REST):  Ph.  D  /  Roy  T.  Fielding.  —  University  of  California,  Irvine.  —  2000.  [Электронный  ресурс]  —  Режим  доступа.  —  URL:  http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm  (дата  обращения  01.03.2013)
3. Savitz  E.  Gartner:  Top  10  Strategic  Technology  Trends  For  2013  //  Forbes.  —  10/23/2012.  [Электронный  ресурс]  —  Режим  доступа.  —  URL:  http://www.forbes.com/sites/ericsavitz/2012/10/23/gartner-top-10-strategic-technology-trends-for-2013/  (дата  обращения  01.03.2013)