?

Log in

No account? Create an account
Key-Value store - Cyril Pertsev
June 21st, 2014
04:02 pm

[Link]

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

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

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

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

Tags:

(26 comments | Leave a comment)

Comments
 
[User Picture]
From:plumqqz
Date:June 21st, 2014 11:41 pm (UTC)
(Link)
sqlite возьмите. Или Apache Derby, если жаба. Хотя это скорее для ищущих легких путей.
[User Picture]
From:kika
Date:June 22nd, 2014 12:49 am (UTC)
(Link)
Дерби это совсем за гранью, это еще и явскую машину с собой таскать.
Скулайт вполне годится, но вокруг него все равно придется огород городить. Хочется готовенького.
[User Picture]
From:plumqqz
Date:June 22nd, 2014 12:56 am (UTC)
(Link)
А что, разложить джсон по трем таблицам - это уже сложно? (Да, собственно, даже по одной). Если сложно - то тогда ой, конечно.
[User Picture]
From:kika
Date:June 22nd, 2014 01:04 am (UTC)
(Link)
Не то чтоб сложно конечно. Но если пейсать какую-то миддлварь, которая это будет делать, то обычным JSON.parse не обойдешься, надо делать то и это. А хочется просто, грубо говоря POST "{name: "xxx", surname: "yyy"}, а потом GET /name=xxx
From:ircicq
Date:June 22nd, 2014 12:04 am (UTC)
(Link)
Проще 1-м индексом вида key_value обойтись.

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

[User Picture]
From:kika
Date:June 22nd, 2014 12:37 am (UTC)
(Link)
А как тогда найти всех Вась?
From:ircicq
Date:June 22nd, 2014 12:53 am (UTC)
(Link)
SELECT object FROM index_table JOIN objects ON objects.id=objectid WHERE key = 'name_Vasya'

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

Edited at 2014-06-22 12:56 am (UTC)
[User Picture]
From:kika
Date:June 22nd, 2014 01:02 am (UTC)
(Link)
А, когда коммент в ЖЖ, то понятно :-) В емейле он склеился в name_Vasya surname_Pupkin. Я решил что это одна строка и удивился.
[User Picture]
From:109
Date:June 22nd, 2014 08:01 am (UTC)
(Link)
facepalm
(Deleted comment)
[User Picture]
From:kika
Date:June 22nd, 2014 12:35 am (UTC)
(Link)
Как все сделать самому я и сам понимаю. Обычно если надо все делать самому то при нынешнем уровне развития индустрии это означает что я что-то не то придумал. При чем тут жена и твои фантазии я не понял.
[User Picture]
From:evolver
Date:June 22nd, 2014 12:45 am (UTC)
(Link)
Про готовые решения я не в курсе. Ну а про ролевую игру я шутил, извини.
From:ex_juan_gan
Date:June 22nd, 2014 12:49 am (UTC)
(Link)
Я на эту тему крепко сейчас думаю; предлагаю держать в простой реляционной базе, а ключи сплющивать.
[User Picture]
From:soonts
Date:June 22nd, 2014 01:04 am (UTC)
(Link)
В коропке с любой вендой начиная с 2000 есть ESENT — это такой NoSQL, который придумали и сделали ещё до того, как NoSQL стало круто.
На нём работают например Active Directory, DNS server, Exchange, Windows Search, и ещё куча разного софта и компонент винды.

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

BTW, я когда-то запилил над ним ORM для .NET, давно не обновлял конечно, но исходники открыты.
[User Picture]
From:kika
Date:June 22nd, 2014 01:10 am (UTC)
(Link)
Прикольно, всегда было интересно на чем AD базируется, но лень было гуглить. К сожалению, жениться на винде я не хочу.
[User Picture]
From:soonts
Date:June 22nd, 2014 01:22 am (UTC)
(Link)
Дело ваше конечно.
Но по моим данным, в мире не-винды ничего сопоставимого по функциональности и производительности вы не найдёте, и за разумное время сами не запилите.

Там производительность сотни тыщ запросов в секунду, масштабируемость на много ядер, много памяти и много терабайт базы (при этом оно и вниз масштабируется, т.е. без нагрузки почти ничего не отжирает), устойчивость к сбоям, транзакционность, и другие достоинства.
[User Picture]
From:kika
Date:June 22nd, 2014 01:23 am (UTC)
(Link)
Да я сам по себе ничего против винды не имею, если ее администрировать не надо (вот уж что кошмар девопса-то), но к сожалению подавляющее большинство целевых платформ - это скорее линукс чем что бы то ни было еще.
[User Picture]
From:romikchef
Date:June 22nd, 2014 03:44 am (UTC)
(Link)
На первый взгляд выглядит, как 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' } );
найдёт всех родившихся в этот день (и у кого есть это свойство в коллекции).
Добавить день рождения существующему Васе - тоже не проблема.

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

Edited at 2014-06-22 04:08 am (UTC)
[User Picture]
From:kika
Date:June 22nd, 2014 05:16 am (UTC)
(Link)
О, кстати, как же я мог про Монгу-то забыть. Спасибо! Я с ней никогда не общался тесно, а гугление общих слов почему-то не вывело.
[User Picture]
From:freedom_of_sea
Date:June 22nd, 2014 07:46 am (UTC)
(Link)
так ведь в Монго одна колонка всего как в Berkley
[User Picture]
From:romikchef
Date:June 22nd, 2014 09:09 am (UTC)
(Link)
В этой колонке-то деревья растут.
From:ircicq
Date:June 22nd, 2014 08:30 am (UTC)
(Link)
Предпочтительнее LevelDB
У MongoDB лицензионные ограничения AGPL
[User Picture]
From:romikchef
Date:June 22nd, 2014 09:22 am (UTC)
(Link)
Пользователям это ведь без разницы.
Если ты начал патчить - то да, должен патчи тоже делать бесплатными.
Но просто юзать в коммерческих проектах - без проблем же.

From:ircicq
Date:June 22nd, 2014 10:22 am (UTC)
(Link)
Насколько я понял, если MongoDB в виде Embedded DBMS, то приложение тоже должно быть AGPL.
[User Picture]
From:p1r4nh4
Date:June 22nd, 2014 05:31 pm (UTC)
(Link)
Монга же вроде не может быть эмбеддед, она всегда запускается отдельным процессом, а потому и никаких вопросов к лицензии приложения нет.
[User Picture]
From:romikchef
Date:June 22nd, 2014 09:35 am (UTC)
(Link)
Отлично ложится, кстати, на приведенную выше модель.
POST дергает update c upsert, чтобы база сама решала, update или insert
А GET кодируется в JSON и отправляется прямиком в .find().
Ну, или честный REST организовать, там даже что-то под основные языки уже есть.
[User Picture]
From:b00ter
Date:June 22nd, 2014 07:09 pm (UTC)
(Link)
My Website Powered by LiveJournal.com