ORM на базе Key-Value Storage

Мне одному кажется, что продукт разрабатывается верх-ногами?! Как можно было умудриться выбрать встраиваемую бд для большого проекта? Почему бы не ограничиться sqlalchemy и memcached?

>Однако я подумал, если все так хвалят KVS, может есть смысл сделать небольшой ORM на базе KVS?

Мапить хеши в... хеши?

Или в специальные объекты с удобными няшными методами, и затормозить этот самый KVS чтоб было как у нормальных пацанов?

Как пример основы хотелось бы привести именно Tokyo Cabinet с сервером Tyrant. Забавно то, что сам Tyrant создан как БД, хранящаяся на hdd, однако поддерживается репликация, балансировка и остальные фичи масштабирования. Собственно, что вы думаете?

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

Попробуй сначала поработать с memcached, прежде чем огород городить, оне ведь тоже KVS.

Кстати, сам термин ORM не имеет смысла в контексте KVS. Мне кажется, что ты ищешь какой-то святой грааль.

Ау! SQLAlchemy и испольщуется. Просто пока работаю с sqlite как с драйвером ЧЕРЕЗ SQLAlchemy. Ну и да, Tokyo Cabinet как KVS.

Или в специальные объекты с удобными няшными методами, и затормозить этот самый KVS чтоб было как у нормальных пацанов?

Сорт оф.
Пока я вижу таблицы как ключи вида table_column_rowid c соответствующими значениями. При этом схема хранится в table.
Проверки на типы etc - задача ORM. А типы можно брать на базе того же пайтона.

Кстати, сам термин ORM не имеет смысла в контексте KVS. Мне кажется, что ты ищешь какой-то святой грааль.

Да. Просто ORM никто не пытался построить на KVS, возможно. А не имеет смысла ибо там нет такого понятия как объект. Всё что есть - пары. С этим согласен, но почему бы не ввести это понятие?

Это все скорее всего приведет к построению костылей и будет в итоге работать медленней чем реляционные бд.

Я вижу применение kvs конкретно для вебдева в: 1) session store, 2) маршаллинге для построения быстрого кеша ( тот же tokyo cabinet например можно будет использовать как замена memcached с возможностью записи на диск ), 3) построение DBMS для данных, которые плохо ложатся в реляционную модель ( документные бд, все эти попытки от амазонов, апачей и т.д. )

Приблизительно то что ты хочешь - здесь http://github.com/ranedk/kvds/ , но мне python-fu и dbarchitecture-fu не хватает, чтобы по поводу его что-нибудь внятное сказать. Отпишись, если будет какая-нибудь история успеха, мало ли что.

Спасибо. Была идея сравнить производительность mysql с tokyo cabinet, но понятно что в бенче на скорость чтения/записи данных ключ-значения скорее всего победит TC, а для проверки всех особенностей, необходимых при работе с таблицами, нужо писать ORM => сравнить можно только сделав.
А есть ли смысл...

А kvds глянул. Это, простите, большой пи*дец. Используется PyTyrand + самопальный «kvds_server», который является джангоприложением(если я не напутал) и цепляется через веб-сервер.
При сохранении модели формируется сериализированный json-док и отсылается на «kvds_server», который отсылает всё на pytyrand. Оверхед пипец какой.
В общем, ужас.
Как будет свободное время, попробую сделать независимый ORM на базе KVS. И, судя по всему, он будет «кроссплатформенным», т.е. ринцип то один и юзать можно будет хоть memcached.

>Да. Просто ORM никто не пытался построить на KVS, возможно.

Пытался, и даже успешно =) есть багтрекер который работает на берклидб.

Я написал только по информации из ответов в данной теме.
А BDB это не ORM. Как гласит википедия,
[quote]
Berkeley DB предполагает работу с парами ключ-значение, где ключ и значение могут иметь фиксированную или переменную длину, а функция сравнения ключей может быть написана и назначена прикладным программистом. Программа, которая использует БД, сама решает, как данные сохраняются в записи; БД не налагает ограничений на данные, хранимые в записях.
[/quote]
После НГ начну думать над этой темой серьёзно.

Конечно не ОРМ, я имел ввиду что ОРМ в качестве стораджа там использует BerkleyDB, тоесть как раз ORM над БД из ключ-значение.

Тогда всё интереснее. Нужно будет исследовать проекты на BDB. Спасибо за информацию. Хорошо бы ещё ссылку на тот трекер, а лучше на его код.

Сорцы у него закрыты =( Просто я участвовал в разработке.

> Да. Просто ORM никто не пытался построить на KVS, возможно. А не имеет смысла ибо там нет такого понятия как объект. Всё что есть - пары. С этим согласен, но почему бы не ввести это понятие?

Нет. Просто модель kvs построена не на отношениях (relation), а парах ключ-значение (kv). Придумай для своей задумки новое название, а термин ORM — object-RELATION-mapping — оставь в покое. ;)

А вот я очень разочарован этим модненьким noSQL движением. Всякие redis и так далее не подойдут. Не для этого они сделаны. Не смотрел сильно на кабинет, но он тоже вроде не канает.

Единственными подающими надежды так называемыми базами данными являются mongodb и couchdb. Буду говорить про последнюю.

Обычно даже при большой степени денормализации (документы) нужно создавать связи между ними. Выдернуть это все потом минимизировав кол-во запросов - геморрой. Не знаю как в mongo, но в CouchDB недавно сделали небольшую поддержку соединений.

Что не хватает:

1. Нет нормальных транзакций, под нормальными транзакциями я подразумеваю то что все изменения будут отвергнуты если есть конфликты. Так как это не так, простые задачи превращаются в такое количество геморроя, что сводит на нет всю прелесть. Пример - уменьшить кол-во товаров после того как кастомер сделает заказ. Разрабы предлагают совершенно идиотское и дикое решение с «inventory tickets», но это просто игнорирование проблемы и только вызывает раздражжение. Я понимаю что при их подходе с репликацией и тд это невозможно, но можно же хотябы сделать это в рамках опции для single-writer вариантов.

2. Нет проверки на уникальность полей в документе. Раз нет такой проверки, значит создание тупого приложения с регистрацией юзеров где нужен уникальный имейл и логин превращается в кошмар. Разрабы отсылают к созданию таких полей в виде ID документа, но это также вызывает раздражжение, так как невозможно создать комплексные «уникальные ключи».

3. Используется map/reduce. Но без map/reduce chaining это очень ограниченая штука. Предлагают выдачу одной вьюхи пихать в другую базу и потом делать уже по ней запрос. Это не жесть ли? Но вроде сейчас какие-то почесывания в мейл-листе есть по этому поводу.

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

> Я понимаю что при их подходе с репликацией и тд это невозможно, но можно же хотябы сделать это в рамках опции для single-writer вариантов.

Да и решается же это в РСУБД каким-то образом.

> А вот я очень разочарован этим модненьким noSQL движением. Всякие redis и так далее не подойдут. Не для этого они сделаны. Не смотрел сильно на кабинет, но он тоже вроде не канает.

мир не делится на sql и nosql: разные задачи требуют разных моделей представления данных. для документов удобны http://en.wikipedia.org/wiki/XML_database . мы используем http://modis.ispras.ru/sedna/ .

Это не отменяет того что нужно контроллировать целостность данных и проводить их валидацию.

Обзор NoSQL систем http://habrahabr.ru/blogs/hi/77909/ Сейчас это модно

Это не отменяет того что нужно контроллировать целостность данных и проводить их валидацию

При рил-тайм общении чатик нужно вести в оперативке, а потом сбрасывать лог в базу. А не сбрасывать каждое сообщение моментально в базу