Кто-нибудь сталкивался с nosql-базами?

← →
Kerk © (2010-06-18 12:55) [0]

Типа redis. Подскажите, чего толковое почитать. Что-то никак не получается у меня эту концепцию key-value на реальную задачу натянуть.

← →
Демо © (2010-06-18 13:03) [1]

Вот подобный вопрос был - http://delphimaster.net/view/15-1272032376/
Может подтолкнёт в нужном направлении.

← →
Kerk © (2010-06-18 13:14) [2]

Это совсем не подобный вопрос

← →
tesseract © (2010-06-18 14:03) [3]

> на реальную задачу натянуть.

Вазелином смажь. Проблема-то в чем ? Вариаций BerkleyDB вообще-то море.

← →
Kerk © (2010-06-18 14:04) [4]

> tesseract © (18.06.10 14:03) [3]
> Проблема-то в чем ?

Я непонятно сформулировал вопрос?

← →
tesseract © (2010-06-18 14:17) [5]

> Что-то никак не получается у меня эту концепцию key-value
> на реальную задачу натянуть.

Не понятно зачем натягивать. Тут по архитектуре немножко : http://pybsddb.sourceforge.net/reftoc.html.

← →
Kerk © (2010-06-18 22:40) [6]

> tesseract © (18.06.10 14:17) [5]
> Не понятно зачем натягивать.

Объясню подробнее. У меня тут есть задача, которая, как мне кажется, подходит для решения ее с помощью key->value. Часто вижу упоминания таких БД и для самообразования решил попробовать.

Расскажу в терминах обычной БД. Ситуация очень простая. Есть одна таблица Table. Поля: ID, field1, field2, field3. Нужно выполнять запросы типа:
select ID from Table where field1 = X and field2 = Y and field3 = ZВроде бы идеально подходит под key->value в виде
field1:field2:field3 как key и ID как value

НО! Во-первых, запрос может вернуть несколько подходящих строк. А во-вторых, запрос может быть и вида:
select ID from Table where field1 = X and field3 = Z
Т.е. одно и более полей в условии может быть пропущено.

Ну так вопрос, базы типа redis применимы к моей задаче? И если да, то как?

← →
Kerk © (2010-06-18 22:43) [7]

> Во-первых, запрос может вернуть несколько подходящих строк.

Причем, это-то решается списками или множествами, которые можно хранить по данному ключу, но вот что делать с пропускаемыми параметрами, я так и не придумал пока.

← →
turbouser © (2010-06-18 23:05) [8]

> Kerk © (18.06.10 12:55)

в тут нет?
http://code.google.com/p/redis/

← →
xayam © (2010-06-19 10:37) [9]

> Kerk © (18.06.10 22:43) [7]
> > Во-первых, запрос может вернуть несколько подходящих строк.
> Причем, это-то решается списками или множествами, которые
> можно хранить по данному ключу, но вот что делать с пропускаемыми
> параметрами, я так и не придумал пока.

по логике должно вернуть в списке ключи, где этот третий параметр имеет любое значение. Только видимо несколько индексов нужно сделать для каждого варианта пропуска параметра. Не?

← →
xayam © (2010-06-19 11:00) [10]

Или у них вообще нет понятия индекса? не в теме я :)

← →
tesseract © (2010-06-19 23:57) [11]

> Или у них вообще нет понятия индекса?

Тут всё извращенно. Если помнишь иерархические БД или пытался работать с interbase через API то поймешь чего ромик хочет.

А вообще я бы реализовал через sqlite, не думаю что redis будет иметь преимущество по скорости.

← →
Sha © (2010-06-19 23:59) [12]

Если сцепить значения нескольких полей,
то по ним будет можно искать, как по связке and.

Просто мысль :)

← →
Kerk © (2010-06-20 00:15) [13]

> tesseract © (19.06.10 23:57) [11]
> А вообще я бы реализовал через sqlite, не думаю что redis
> будет иметь преимущество по скорости.

Дык мне самому удобнее сделать через что-то типа MySQL, но хочется попробовать новое.
Я хочу понять, пременим ли сабж с моей задачей, если да, то как, если нет, то я забью.
Просто я не представляю реальную задачу с БД, которая еще проще.

> Sha © (19.06.10 23:59) [12]

Так я же и говорил про составной ключ здесь:
> field1:field2:field3 как key и ID как value

Но ведь выборка может быть не по всем трем полям, а по двум, или даже по одному. Не заводить же мне все возможные комбинации ключей? Или это действительно общепринятое решение? Причем, в реальности у меня не 3 поля, а 10. Комбинаций между ними дофига.

1. не все комбинации нужны
2. если требуется только поиск без сортировки, значения можно сжать хешем,
а потом сцепить - будет не так длинно.
3. можно искать двумя-тремя последовательными запросами,
и самому пересекать списки

> Просто я не представляю реальную задачу с БД, которая еще проще.

Игровой сервер:
по имени чара получить всю или часть инфы о нем.

> Sha © (20.06.10 00:29) [15]
>
> 1. не все комбинации нужны

Да, но это ж в любом случае не практично. А что, если мне понадобится поле добавить в таблицу? Придется все ключи пересчитывать. С остальными пунктами согласен. Но из-за п.1 пока получается, что такая задача разумно решается только в рамках sql-базы... как-то так.

> Kerk © (20.06.10 17:41) [17]

> А что, если мне понадобится поле добавить в таблицу?

а все просто: это ЧАСТНЫЙ СЛУЧАЙ sql-баз. эффективно, допустим, когда ключ - время, остальное - сто полей положения звезд. При таком раскладе задача " при какой фазе луны зведзы больше глючат" sql-базами эффективно не решается, поэтому живы и будут жить решения, где sql нету, зато все просто реализовано, а значит, быстро пишется и быстро читается.

> Petr V. Abramov © (20.06.10 22:38) [18]

Это я знаю, просто ожидал, что оно применимо немножко шире.
В общем, вопрос закрыт наверно. Если только кто-то что-нибудь сенсационное не напишет :)

Кто-нибудь сталкивался с nosql-базами? Найти похожие ветки