среда, 26 августа 2009 г.

FluidDB: вступление

Одна из важнейших задач, в условиях сегодняшнего количества и структурированности данных — возможность рационально хранить и обрабатывать их. Для этого человечество последние пять десятилетий усердно работает, придумывая разнообразные СУБД, отличающиеся способом хранения данных, организации доступа и обработки, интерфейсом взаимодействия и вообще, часто — специализацией под конкретные тип, структуру данных. Начиная с первых навигационных СУБД, соответствующих хранению данных на ленточных носителях, которые позже развились в табличные и реляционные структуры, и не заканчивая набирающими обороты сегодня т.н. key-value хранилищами, на протяжении всей эволюции хранилищ можно проследить некоторые направления её развития: сначала структуры и алгоритмы были сильно скованы возможностями железа, и разработчикам СУБД нередко приходилось идти на компромиссы между скоростью работы и гибкостью использования продукта. С ростом вычислительной мощи компьютерных систем, с усовершенствованием устройств хранения данных мы получили возможность неимоверно усложнять реализацию СУБД, например внедряя триггеры, хранимые процедуры, используя объектно-ориентированные реляционные СУБД, что, со временем, привело нас к ситуации, которую мы имеем. В чём-то она схожа с трендами в языках программирования. Как выразился Tim Berners-Lee о принципе наименьших возможностей (Principle of Least Power):

Computer Science in the 1960s to 80s spent a lot of effort making languages which were as powerful as possible. Nowadays we have to appreciate the reasons for picking not the most powerful solution but the least powerful. The reason for this is that the less powerful the language, the more you can do with the data stored in that language. If you write it in a simple declarative from, anyone can write a program to analyze it in many ways. … If, for example, a web page with weather data has RDF describing that data, a user can retrieve it as a table, perhaps average it, plot it, deduce things from it in combination with other information. At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analyzed at all. … This the only way to find out what a Java applet means is to set it running in front of a person.

То есть на сегодняшний день для абсолютного большинства решений как в ЯП, так и в системах хранения данных, гибкость достигается за счёт простоты. Тут можно вспомнить о ставших особо популярными в последние годы скриптовых языках, распространении json, как формата передачи данных, популяризации key-value store.

Сегодня я хочу рассказать об одном инновационном подходе к хранению данных, который раннее нигде не встречал — FluidDB, разработки отличных ребят из Fluidinfo.

FluidDB — централизованное он-лайн хранилище данных, предназначенное для обмена, аггрегации и дополнения данных пользователями. Свобода работы с информацией в таком духе — фундаментальное отличие данной системы от традиционных СУБД.

Основные постулаты хранения данных в FluidDB можно свести к следующим:

  1. Объекты, хранящиеся в базе не имеют владельца. Любой пользователь может создавать объекты в общей базе данных.
    Тоесть при создании нового объекта, никакой связи с создающим пользователем не остаётся. Все пользователи имеют равные права, относительно объектов в базе данных.

  2. Основная информационная нагрузка хранится в т.н. тегах, привязываемых пользователями к объектам.
    Теги являются типизированными контейнерами данных, используемыми для хранения информации, связанной с соответствующими объектами. Например, пользователь vasiliy может создать объект, соответствующий книге “isbn13:9780596514983”, привязать к нему тег vasiliy/rating со значением 7. Другой пользователь, johndoe, в свою очередь может привязать к этому объекту свои теги johndoe/rating=9.5, johndoe/comment="blown up my mind" и т. д. В результате мы имеем объект с набором метаданных, из которых, например, можно легко получить среднюю оценку книги, а далее — всех пользователей, оценивших данную книгу, оставивших комментарий и т.д.

  3. Работа с тегами контролируется развитой системой контроля доступа
    Доступ к тегам же, в отличии от объектов, жёстко контролируется гибкой системой управления правами так, что пользователь может ограничивать возможность чтения, редактировния, добавления “своих” тегов к объектам другими пользователями.

  4. FluidDB предоставляет специализированный язык запросов для поиска по базе
    С помощью этого языка можно делать выборки, например has sally/opinion and (tim/rating > 5 or mike/rating > 7) для выбора объектов, содержащих тег sally/opinion, а также заданные значения тегов tim/rating или mike/rating.

Чтобы лучше понять, что представляет из себя FluidDB можно посмотреть отличный пост Kaleidoscope: 10 takes on FluidDB, несколько пунктов из которого — ниже в вольном переводе:

  • БД с душой вики: аналогия с вики в некотором смысле уместна: любой может вносить данные (см. ниже), приложения могут сотрудничать, данные, расшаренные в общем хранилище представляют бóльшую ценность, и, можно сказать, в FluidDB есть объекты для любой сущности, точно как в вики есть страницы на любую тему — многие, ожидающие, что их кто-то создаст.
    Но с другой стороны, аналогия не уместна: FluidDB имеет жёсткую систему контроля доступа, которая защищает данные от изменения, или вообще просмотра другими пользователями, присутствует язык запросов к БД и данные в хранилище типизированы. Таким образом FluidDB пропитан духом вики, но как только вы присматриваетесь повнимательнее, то почти всё существенно отличается.
    Продолжая тему википедии: долгое время мир энциклопедий был жёстко подконтрольный и совсем немного людей имело допуск к внесению информации — энциклопедия была источником “только для чтения”. Хотя википедия являлась фактически противоположностью, и многие были настроены скептически, за несколько лет она разрослась и затмила даже огромную Encyclopædia Britannica. Может быть, FluidDB станет для приложений и традиционных СУБД тем, чем википедия стала для людей и традиционных энциклопедий. Вы не ограничены неподатливыми таблицами или схемой данных, любой может вносить изменения, содержимое может развиваться, улучшаться, отсутствует сквозной вертикальный контроль.

  • Платформа для меш-апов: когда разработчик создаёт меш-ап, комбинируя информацию из разных источников, для создания новых данных, где эти новые данные должны храниться? Традиционный, на сегодняшний день, ответ — положить данных в СУБД, за новым API, отдокументировать его, поднять сервер и поддерживать его. На самом деле, это всё приводит к повтору всей этой итерации программистом, создающим следующий меш-ап. в FluidDB Вы можете хранить новые данные вместе со старыми, т.к. объекты не имеют владельцев. И, что более важно, потому, что в этом случае данные сразу же доступны для создания новых меш-апов, комбинируясь с данными, хранящимися в этом же объекте.

  • Система коммуникации: можно рассматривать FluidDB объекты, как контейнеры для обмена информацией приложениями, работающими сообща. Информацией могут быть сообщения, задания, результаты и др. Nicholas Radcliffe, работающий не первый год над FluidDB, недавно нашёл неожиданную точку зрения на БД — это Twitter для данных.
    Вы можете запросто использовать FluidDB объект, как урну для голосования, с некоторыми приятными свойствами (напр. отменять, или изменять свой голос, подтверждать, что кто-то проголосовал, без возможности просматривать их голос). Так же Вы можете делать более сложные вещи.

Таким образом я попытался дать общее представление о том, что же такое FluidDB, что отличает данную разработку от традиционных СУБД, что позволяет делать ставки на то, что эта технология начнёт новый виток в развитии систем хранения данных.

Заключение

В следующем посте я собираюсь описать примеры непосредственной работы с FluidDB, а так же рассмотреть несколько библиотек, которые могут пригодиться при этом.

Комментариев нет:

Отправить комментарий