ODS а-ля MongoDB

ODS (Object Data Storage)
Все ниже написанное, есть мое видение ситуации и решения отдельно взятых проблем.

Около двух лет назад, один знакомый ( breathless.ru ) «толкнул» меня в сторону объектного хранения данных. Сопротивлялся я не очень долго, так-как быстро увидел плюса для себя. Основополагающим принципом стало, хранение массива (объекта) в БД, в таком виде, который позволял получать доступ к любому элементу данных.

Тут конечно, сразу вспоминаются, старые добрые таблицы с множеством столбцов, которые выполняют туже-самую роль. Однако, данный метод позволял не тратить время (иногда очень драгоценное) на проектирование структуры таблицы.
Для примера приведу соответствие хранения с использованием обычных и «3D-таблиц»
id	name	email			age
-------------------------------------------------
1	alex	alex@email.com	18
2	oleg	oleg@email.com	22


I	K		V
--------------------------------------------
1	name	alex
1	email	alex@email.com
1	age	18
2	name	oleg
2	email	oleg@email.com
2	age	22

Как видно, данные хранимые в двух разных таблицах идентичны по структуре данных, но их представления хранения, различны.

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

За основу была взята следующая архитектура (Id,Key,Value).
Для удобства работы с такой структурой хранения данных, я начал разрабатывать класс, который помогал бы мне, быстро и удобно работать. От первых набросков логики на бумаге, до первого «стабильного релиза», прошло не более 2-ух месяцев. Проблем было много: от «хитрого» запроса, который сам собирал все поля объекта, до проблем с обновлением и удалением отдельных полей (при чем последняя до сих пор не решена окончательно). Однако это не помешало использовать класс в работе.

Как и везде, есть плюсы и минусы.
Минусы:
  • не возможность использования JOIN-запросов
  • ограниченная структура (только один уровень)
Плюсы
  • гибкость структуры хранимых данных
  • удобство проектирования структуры (а по сути отсутствие необходимости проектирования)

И все же, при чем тут MongoDB?
А при том, что позже (где-то через пол года) я узнал о существовании такого замечательного продукта, который в разы превосходит ODS. Конечно я установил MongoDB, и проверил его весь, вдоль и поперек.
Таблица сравнений:
Сравнение ODS и MongoDB

Конечно, я буду продолжать разрабатывать ODS и стремиться к воссозданию функционала MongoDB:
  • хранение сложных структур
  • более гибкая выборка данных
  • использование Memcache (на данный момент используется кеширование запросов и результатов на уровне класса)

Почему я использую ODS, а не перешел на MongoDB или подобные ей?
Все же это класс PHP, он не требует установки дополнительного программного обеспечения (что не всегда допустимо у хостеров), ODS работает используя SQL — MySQL, FireBird, MSSQL, PostgreSQL, ORACLE и другие БД (поддерживающие стандарт SQL:1999).

Так что, если кому-то стало интересно:
Собственно сама таблица (класс сам умеет создавать таблицы)
CREATE TABLE `data` (
  `I` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `K` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `V` longtext COLLATE utf8_unicode_ci NOT NULL,
  KEY `I` (`I`),
  KEY `K` (`K`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
и класс ODS (2.2.5)
ODS_2.2.5.php.txt

Для работы с классом, необходимо указать DSN
user:pass@host/dbname/charset/pref
$ODS = new ODS("root:12345@localhost/test/utf8/ods_");

13 комментариев

avatar
  • akhmetov
  • 0
Одно из решений хранения данных каталога разношерстной продукции.

Хранение сложных структур — имеется в виду вложенные объекты? В MongoDB удобно сделаны выборки из них.
www.mongodb.org/display/DOCS/Dot+Notation+%28Reaching+into+Objects%29
avatar
Да, именно вложенные объекты или просто сложные (многоуровневые) массивы.
Отсюда и решение продолжать развитие.
avatar
  • MpaK
  • 0
Чистой воды EAV en.wikipedia.org/wiki/Entity-attribute-value_model

Только в этой модели мне не нравится, что ключи varchar, ну и в целом таблицы и индексы вообще не рационально будут использоваться.
avatar
По поводу EAV — соглашусь.
По поводу ключей-varchar — исходил из возможности использовать для ключей любые значения (даже кириллица допускается).
Индексы — да, сам не понимаю зачем… но проводил небольшие тесты, и вроде как ключи делают свою работу.
Не рациональное использование самих таблиц — это как посмотреть. С одной стороны — не рациональное использование, с другой — гибкая архитектура.
avatar
  • MpaK
  • 0
Я просто не представляю как будет «пухнуть» база с такими ключами и индексы. Да использовать ключи написанные на кириллице в ORM это как-то ужасным кажется :)

Гибкая архитектура за счет скорости, как-то мне кажется не самый удачный инструмент MySQL для таких вещей, как раз тот же самый MongoDB хорошо бы применить.
avatar
Да, из-за данных таблица будет «пухнуть» как на дрожжах, а вот ключи (при правильно использовании) будут «пухнуть» не больше, чем при обычной архитектуре.
Да и вроде как, БД и сделаны для того что бы хранить большой объем данных.

По поводу кириллицы — это просто был тест, на извращения. :)

ODS разрабатывается и используется для тех случаев, когда нужен MongoDB, но установить его не хостинге (VDS или сервере) нет возможности.
По своей сути (плохая, но все же) альтернатива MongoDB на основе MySQL.
avatar
  • daken
  • 0
интересно, но есть минус в том, что нельзя расставить индексы для определенных полей объекта
avatar
Индексы ставятся для столбцов (I,K)
где:
I — идентификатор объекта
K — поле объекта
так что, по сути все поля объекта индексируются.
Советую сделать небольшой тест:
Создать две таблицы (одну с индексами, другую — без), заполнить их данными (объектами), по 1000 (10000) объектов, где каждый объект по 10 полей, и сравнить скорость выборки, для каждой таблицы.
Разница есть, и даже ощутимая.
avatar
  • daken
  • 0
я не это имел ввиду. допустим у нас есть объект книга и у него есть свойство назвние. нельзя задать индекс по полю название для ускорения поиска
avatar
Я понял.
Твой случай:
I    K      V
1    author Кизяков
1    book   Кулинария
1    year   2005

Когда ты будешь делать запрос:
WHERE `book` = 'Кулинария'
учитывать — запрос сделан в формате SQL, в ODS запросы формируются массивом
array('book'=>'Кулинария')
значение `book` — будет индексировано, а значение 'Кулинария' — нет.
Довольно легко решается постановкой столбца V в индекс (FULLTEXT), но тогда мы получим очень большой индекс по полю V, что может плохо сказаться на производительности.
Ко всему прочему, используется InnoDB, он «у меня», не дружит с FULLTEXT

Согласен — это можно считать еще одним минусом
avatar
  • glilya
  • 0
все клево, кроме того иннодб фулсерч не держит. А кстати а почему не орм?
avatar
  • glilya
  • 0
*кроме того что
avatar
  • timach
  • 0
чичас вдски дешевые есть, зачем так извращаца
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.