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

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

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

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

Date: 2014-06-21 11:41 pm (UTC)
From: [identity profile] plumqqz.livejournal.com
sqlite возьмите. Или Apache Derby, если жаба. Хотя это скорее для ищущих легких путей.

Date: 2014-06-22 12:49 am (UTC)
From: [identity profile] kika.livejournal.com
Дерби это совсем за гранью, это еще и явскую машину с собой таскать.
Скулайт вполне годится, но вокруг него все равно придется огород городить. Хочется готовенького.

Date: 2014-06-22 12:56 am (UTC)
From: [identity profile] plumqqz.livejournal.com
А что, разложить джсон по трем таблицам - это уже сложно? (Да, собственно, даже по одной). Если сложно - то тогда ой, конечно.

Date: 2014-06-22 01:04 am (UTC)
From: [identity profile] kika.livejournal.com
Не то чтоб сложно конечно. Но если пейсать какую-то миддлварь, которая это будет делать, то обычным JSON.parse не обойдешься, надо делать то и это. А хочется просто, грубо говоря POST "{name: "xxx", surname: "yyy"}, а потом GET /name=xxx

Date: 2014-06-22 12:04 am (UTC)
From: [identity profile] ircicq.livejournal.com
Проще 1-м индексом вида key_value обойтись.

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

Date: 2014-06-22 12:37 am (UTC)
From: [identity profile] kika.livejournal.com
А как тогда найти всех Вась?

Date: 2014-06-22 12:53 am (UTC)
From: [identity profile] 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)
Edited Date: 2014-06-22 12:56 am (UTC)

Date: 2014-06-22 01:02 am (UTC)
From: [identity profile] kika.livejournal.com
А, когда коммент в ЖЖ, то понятно :-) В емейле он склеился в name_Vasya surname_Pupkin. Я решил что это одна строка и удивился.

Date: 2014-06-22 08:01 am (UTC)
From: [identity profile] 109.livejournal.com
facepalm
(deleted comment)

Date: 2014-06-22 12:35 am (UTC)
From: [identity profile] kika.livejournal.com
Как все сделать самому я и сам понимаю. Обычно если надо все делать самому то при нынешнем уровне развития индустрии это означает что я что-то не то придумал. При чем тут жена и твои фантазии я не понял.

Date: 2014-06-22 12:45 am (UTC)
From: [identity profile] evolver.livejournal.com
Про готовые решения я не в курсе. Ну а про ролевую игру я шутил, извини.

Date: 2014-06-22 12:49 am (UTC)
From: [identity profile] juan-gandhi.livejournal.com
Я на эту тему крепко сейчас думаю; предлагаю держать в простой реляционной базе, а ключи сплющивать.

Date: 2014-06-22 01:04 am (UTC)
From: [identity profile] 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/), давно не обновлял конечно, но исходники открыты.

Date: 2014-06-22 01:10 am (UTC)
From: [identity profile] kika.livejournal.com
Прикольно, всегда было интересно на чем AD базируется, но лень было гуглить. К сожалению, жениться на винде я не хочу.

Date: 2014-06-22 01:22 am (UTC)
From: [identity profile] soonts.livejournal.com
Дело ваше конечно.
Но по моим данным, в мире не-винды ничего сопоставимого по функциональности и производительности вы не найдёте, и за разумное время сами не запилите.

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

Date: 2014-06-22 01:23 am (UTC)
From: [identity profile] kika.livejournal.com
Да я сам по себе ничего против винды не имею, если ее администрировать не надо (вот уж что кошмар девопса-то), но к сожалению подавляющее большинство целевых платформ - это скорее линукс чем что бы то ни было еще.

Date: 2014-06-22 03:44 am (UTC)
romikchef: (штора)
From: [personal profile] 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' } );
найдёт всех родившихся в этот день (и у кого есть это свойство в коллекции).
Добавить день рождения существующему Васе - тоже не проблема.

Из коробки же по умолчанию всё держит в памяти - то есть, для производительности индексы тоже не очень-то и нужны, при десятках тысяч-то.
Edited Date: 2014-06-22 04:08 am (UTC)

Date: 2014-06-22 05:16 am (UTC)
From: [identity profile] kika.livejournal.com
О, кстати, как же я мог про Монгу-то забыть. Спасибо! Я с ней никогда не общался тесно, а гугление общих слов почему-то не вывело.

Date: 2014-06-22 07:46 am (UTC)
From: [identity profile] freedom_of_sea.livejournal.com
так ведь в Монго одна колонка всего как в Berkley

Date: 2014-06-22 09:09 am (UTC)
romikchef: (штора)
From: [personal profile] romikchef
В этой колонке-то деревья растут.

Date: 2014-06-22 08:30 am (UTC)
From: [identity profile] ircicq.livejournal.com
Предпочтительнее LevelDB
У MongoDB лицензионные ограничения AGPL

Date: 2014-06-22 09:22 am (UTC)
romikchef: (штора)
From: [personal profile] romikchef
Пользователям это ведь без разницы.
Если ты начал патчить - то да, должен патчи тоже делать бесплатными.
Но просто юзать в коммерческих проектах - без проблем же.

Date: 2014-06-22 10:22 am (UTC)
From: [identity profile] ircicq.livejournal.com
Насколько я понял, если MongoDB в виде Embedded DBMS, то приложение тоже должно быть AGPL.

Date: 2014-06-22 05:31 pm (UTC)
From: [identity profile] p1r4nh4.livejournal.com
Монга же вроде не может быть эмбеддед, она всегда запускается отдельным процессом, а потому и никаких вопросов к лицензии приложения нет.

Date: 2014-06-22 09:35 am (UTC)
romikchef: (штора)
From: [personal profile] romikchef
Отлично ложится, кстати, на приведенную выше модель.
POST дергает update c upsert, чтобы база сама решала, update или insert
А GET кодируется в JSON и отправляется прямиком в .find().
Ну, или честный REST организовать, там даже что-то под основные языки уже есть.

Date: 2014-06-22 07:09 pm (UTC)

Profile

kika: (Default)
kika

January 2017

S M T W T F S
1234567
89 1011121314
151617181920 21
22232425262728
293031    

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 27th, 2017 10:45 pm
Powered by Dreamwidth Studios