Key-Value store

[kika]

Я что-то не втыкаю, прошу помощи зала. Я хочу хранить JSON объекты в какой-нибудь простой базе, при этом не хочу руками заводить индексы. Хочу чтобы база сама парсила объекты и если в нем есть какой-то ключ, то по этому ключу заводила бы сама индекс. То есть я скажем пишу туда { name: "Vasya", surname: "Pupkin" }, и она заводит два индекса, добавляю в какие-то объекты birthday: "02/20/1969" - она создает третий индекс. Объектов - ну максимум десятки тысяч, то есть в принципе все можно держать в голове. Хочется без тяжелого рантайма, инсталляций с триллионом prerequisites и прочего девопс-кошмара.

В принципе это наверное можно соорудить вокруг Редиски. Наверняка почти любая RDBMS с этим справится тоже. Но хочется избежать "сооружения" и не хочется таскать за собой постгресс с кучей зависимостей или мускль со своими капризами.

Можно это соорудить вокруг Дивана (Кауча), если написать внешний кауч-процесс, который будет следить за новыми объектами и добавлять индекс при необходимости. Наверное я так и сделаю, если не найду ничего лучше, Кауч хотя бы заметно проще большинства RDBMS по части зависимостей, но все равно надо лепить горбатого вокруг. Зато хорошая репликация достанется бесплатно.

Или я извращенец и никому это не надо?

Comments

[plumqqz.livejournal.com]

sqlite возьмите. Или Apache Derby, если жаба. Хотя это скорее для ищущих легких путей.

[kika.livejournal.com]

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

[plumqqz.livejournal.com]

А что, разложить джсон по трем таблицам - это уже сложно? (Да, собственно, даже по одной). Если сложно - то тогда ой, конечно.

[kika.livejournal.com]

Не то чтоб сложно конечно. Но если пейсать какую-то миддлварь, которая это будет делать, то обычным JSON.parse не обойдешься, надо делать то и это. А хочется просто, грубо говоря POST "{name: "xxx", surname: "yyy"}, а потом GET /name=xxx

[ircicq.livejournal.com]

Проще 1-м индексом вида key_value обойтись.

name: "Vasya", surname: "Pupkin"
превратится в 2 записи в индексе:
name_Vasya
surname_Pupkin

[kika.livejournal.com]

А как тогда найти всех Вась?

[ircicq.livejournal.com]

SELECT object FROM index_table JOIN objects ON objects.id=objectid WHERE key = 'name_Vasya'

Если у нас 2 связанные таблицы: objects(id, object) и index_table(key, objectid)

[kika.livejournal.com]

А, когда коммент в ЖЖ, то понятно :-) В емейле он склеился в name_Vasya surname_Pupkin. Я решил что это одна строка и удивился.

[109.livejournal.com]

facepalm

[kika.livejournal.com]

Как все сделать самому я и сам понимаю. Обычно если надо все делать самому то при нынешнем уровне развития индустрии это означает что я что-то не то придумал. При чем тут жена и твои фантазии я не понял.

[evolver.livejournal.com]

Про готовые решения я не в курсе. Ну а про ролевую игру я шутил, извини.

[juan-gandhi.livejournal.com]

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

[soonts.livejournal.com]

В коропке с любой вендой начиная с 2000 есть ESENT (http://en.wikipedia.org/wiki/Extensible_Storage_Engine) — это такой NoSQL, который придумали и сделали ещё до того, как NoSQL стало круто.
На нём работают например Active Directory, DNS server, Exchange, Windows Search, и ещё куча разного софта и компонент винды.

У записи может быть до 64k колонок, с кучей самых разных индексов по ним.

BTW, я когда-то запилил над ним ORM для .NET (https://esentserialize.codeplex.com/), давно не обновлял конечно, но исходники открыты.

[kika.livejournal.com]

Прикольно, всегда было интересно на чем AD базируется, но лень было гуглить. К сожалению, жениться на винде я не хочу.

[soonts.livejournal.com]

Дело ваше конечно.
Но по моим данным, в мире не-винды ничего сопоставимого по функциональности и производительности вы не найдёте, и за разумное время сами не запилите.

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

[kika.livejournal.com]

Да я сам по себе ничего против винды не имею, если ее администрировать не надо (вот уж что кошмар девопса-то), но к сожалению подавляющее большинство целевых платформ - это скорее линукс чем что бы то ни было еще.

[romikchef]

На первый взгляд выглядит, как MongoDB.

Только оно не key-value, а хранит именно что JSON объекты:
db.people.insert({ name: 'Vasya', surname: 'Poupkine'})
- это ванильный синтаксис.
формат "строки" - полностью свободный. Придет объект вида
{ name: 'Vasya', surname: 'Poupkine', birthday: '02/20/1969' }
- сохранится тоже
Соответственно, все поля доступны для запроса, и для поиска индексы специально строить не нужно:
db.people.find( { birthday: '02/20/1969' } );
найдёт всех родившихся в этот день (и у кого есть это свойство в коллекции).
Добавить день рождения существующему Васе - тоже не проблема.

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

[kika.livejournal.com]

О, кстати, как же я мог про Монгу-то забыть. Спасибо! Я с ней никогда не общался тесно, а гугление общих слов почему-то не вывело.

[freedom_of_sea.livejournal.com]

так ведь в Монго одна колонка всего как в Berkley

[romikchef]

В этой колонке-то деревья растут.

[ircicq.livejournal.com]

Предпочтительнее LevelDB
У MongoDB лицензионные ограничения AGPL

[romikchef]

Пользователям это ведь без разницы.
Если ты начал патчить - то да, должен патчи тоже делать бесплатными.
Но просто юзать в коммерческих проектах - без проблем же.

[ircicq.livejournal.com]

Насколько я понял, если MongoDB в виде Embedded DBMS, то приложение тоже должно быть AGPL.

[p1r4nh4.livejournal.com]

Монга же вроде не может быть эмбеддед, она всегда запускается отдельным процессом, а потому и никаких вопросов к лицензии приложения нет.

[romikchef]

Отлично ложится, кстати, на приведенную выше модель.
POST дергает update c upsert, чтобы база сама решала, update или insert
А GET кодируется в JSON и отправляется прямиком в .find().
Ну, или честный REST организовать, там даже что-то под основные языки уже есть.

[b00ter.livejournal.com]

JFYI http://vedis.symisc.net/