Есть ли ORM (OKM) для хранилищ ключей?

Question

Object-Relational-Mappers были созданы, чтобы помочь приложениям (которые думают в терминах объектов) обрабатывать хранимые данные более удобным для приложения способом, как и любой другой класс / объект.

Однако я никогда не видел OKM (Object-Key / Value-Mapper) для систем хранения NoSQL "Key / Value". Это кажется странным, потому что потребность должна быть намного больше, учитывая тот факт, что большее количество ценностных отношений должно быть жестко запрограммировано в приложении, чем обычный объект одной строки таблицы SQL.

four requests:
user:id
user:id:name
user:id:email
user:id:created

vs one request:
user = [id => ..., name => ..., email => ...]

Кроме того, вы должны отслеживать "списки" (оставлять комментарии has_many), поскольку у вас нет has_many для таблиц или внешних ключей.

INSERT INTO user_groups (user_id, group_id) VALUES (23, 54)

vs

usergroups:user_id = {54,108,32,..}
groupsuser:group_id = {23,12,645,..}

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

Есть ли? Есть ли причины, по которым их нет?

Answer 1

Ruby's DataMapper - это ORM, и он будет рад взаимодействовать с хранилищем значений ключей с помощью адаптера.

Redis и MongoDB есть адаптеры, которые уже существуют.CouchDB имеет адаптер - он не поддерживается, но в какой-то момент он работал довольно хорошо.Я не думаю, что кто-то что-то сделал с Кассандрой, но нет никаких причин, по которым это невозможно. Сомнительная структура для Google App Engine использует очень похожий подход к Data Mapper, чтобы сделать хранилище данных доступным для приложений.

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

Answer 2

Одна из целей разработки SQL состоит в том, что любые данные могут храниться / запрашиваться в любой реляционной базе данных. Между платформами есть некоторые различия, но в целом правильный способ обработки конкретной структуры данных хорошо известен и легко автоматизируется, но требующий довольно подробного кода. Это не относится к NoSQL - обычно вы будете напрямую хранить данные, используемые в вашем приложении, а не пытаться отобразить их в реляционную структуру, и без объединений или других различий между объектами и реляциями код отображения тривиален.

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

MGET user: id: имя пользователя: id: email ... (multiget - получить любое количество ключей за один вызов)

GET user: id: * (ключевые символы подстановки)

HGETALL пользователь: id (redis hash - получает все подразделы пользователя)

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

Работа со списками не очень хороша, если в вашей платформе нет встроенной поддержки - собственная поддержка списков / наборов - одна из причин, по которой мне нравится использовать redis - но помимо потенциально необходимых блокировок это не хуже, чем получение списка из sql.

Стоит также отметить, что вам могут не понадобиться все отношения, которые вы бы определили в sql - например, если у вас есть группа, содержащая миллион пользователей, возможность получить список всех пользователей в группе совершенно бесполезна, поэтому Вы никогда не создадите список groupsuser вообще, и вместо того, чтобы отдельный список групп пользователей имел user: id: groups как многозначное свойство. Если вам просто нужно проверить членство, вы можете установить ключи как группы пользователей: userid: groupid и получить постоянный поиск по времени.

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

Answer 3

UNIVERSE db, который является потомком Pick, позволяет вам хранить список пар ключ-значение для данного ключа. Однако это очень старая технология, и мир давно убежал от этих баз данных.

Вы можете реализовать это в базе данных SQL с таблицей из трех столбцов

  CREATE TABLE ATTRS ( KEYVAL VARCHAR(32),
                       ATTRNAME VARCHAR(32),
                       ATTRVAR  VARCHAR(1024)
                     )

Хотя большинство администраторов баз данных поразит вас очень толстым изданием Codd и Date в твердом переплете, если вы предложите это, на самом деле это очень распространенный шаблон в упакованных приложениях, позволяющий вам добавлять специфические атрибуты сайта в систему.

Чтобы перефразировать комментарии Ричарда Столлмана на LISP. «Любая разумно работающая система хранения данных в конечном итоге будет реализовывать собственную версию СУБД».

Answer 4

ORM не очень хорошо отображают безсхемную природу хранилищ ключей и значений. При этом, если вы используете Riak и Ruby, вы можете взглянуть на Ripple . Есть ряд других драйверов для Riak, которые могут соответствовать вашему языку.

Если вы ищете MongoDB (больше хранилища документов, чем хранилище k / v), есть несколько драйверов .