andreycha24 авг 2010 в 12:25

Точка сбора NoSQL

1 мин

NoSQL *

+52

Комментарии 45

NikitaG 24 авг 2010 в 13:14

я ежедневно работаю с MongoDb и Redis(через редиску)
Было бы интересно читать материалы на эту тему.

andreycha 24 авг 2010 в 13:21

Я думаю, с ежедневной работой вы и сами можете поделиться опытом :).

NikitaG 24 авг 2010 в 13:23

ну если кто то начнет дискуссию я мог бы=))

Masterkey 24 авг 2010 в 15:13

начинаю!

кто пробовал Django + MongoDB?

NikitaG 24 авг 2010 в 15:14

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

SMiX 24 авг 2010 в 17:05

Я пробовал RoR + MongoDB, когда она еще падала. Теперь сидим на CouchDb и ничего нам пока* больше не нужно.

kurokikaze 24 авг 2010 в 17:32

А map-reduce вы используете?

SMiX 24 авг 2010 в 17:35

Активно изучаем :)
А пока обходимся обычными view-функциями с одним map.

Homakov 25 авг 2010 в 10:07

какую orm юзали?

SMiX 25 авг 2010 в 10:25

CouchRest

VolCh 24 авг 2010 в 17:13

Пробовал с хранилищем гугловским (используется один форк Django-nonrel). Главный минус (для меня) — не работает join и many-to-many. То есть для большинства приложений тупо заменить БД не получится

SMiX 24 авг 2010 в 17:21

Что вы имеете в виду под «не работает»?

VolCh 24 авг 2010 в 17:45

ManyToManyFields не поддерживается, как именно это выражается, если честно, не помню: пока отказался от джанго после нескольких экспериментов — фреймворк выбрать для GAE можно, сменить хранилище нельзя

MagaSoft 24 авг 2010 в 19:55

я пробовал и очень успешно.
для front-end'а, скажем так, вполне достаточно pymongo
для «админки», а точнее удобной работы по добавлению/обновлению и т.д. рекомендую mongokit

Masterkey 24 авг 2010 в 20:13

а как со стабильностью?
как с основными плюшками админки с монгокитом?
где почитать саксесс стори?

MagaSoft 24 авг 2010 в 20:30

>а как со стабильностью?
со стабильностью проблем не было, да и нагрузок не было т.к. в локалке компании (CRM-система) и пользуется не много народу.
под «админкой» я имею ввиду часть сайта где требуется работа по изменению данных, в этом случае удобно работать с записями как с моделями, со своей схемой, для валидации, с интерфейсами, что и дает mongokit.
>как с основными плюшками админки с монгокитом?
непосредственно модулем админки джанги я мало пользовался, а для nosql он вроде до сих пор не портирован, хотя я видел проскакивали новости по переводу джанги на nosql.
>где почитать саксесс стори?
давно специально не искал, но на момент моей работы с этой связкой (месяца 4 назад) с документацией было очень плохо, не говоря уже про статьи, кроме оф. документации к pymongo и mongokit ничем не пользовался, там достаточно просто.

Masterkey 25 авг 2010 в 07:18

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

xtender 24 авг 2010 в 13:33

Я б перенес, но боюсь, что Cache не подходит под этот блог :)

andreycha 24 авг 2010 в 13:34

Ну с т.з. нереляционности вполне подходит :). Или я ошибаюсь?

xtender 24 авг 2010 в 13:36

Cache — ООБД, но с поддержкой SQL :)

НЛО прилетело и опубликовало эту надпись здесь

xtender 24 авг 2010 в 13:40

Да я уже все равно перенес :)

НЛО прилетело и опубликовало эту надпись здесь

Setti 24 авг 2010 в 13:37

— Так у нас проблемы с производительностью, надо добавить кэширование, вертикальное партиционирование и NoSQL DB для логинов.
— Парни — я тут посмотрел EXPLAIN — у Вас fullscan запрос на 4,000 строк, я попробовал создать индекс — все ускорилось в 26 раз.

via

micle 24 авг 2010 в 14:16

Шуточный бот, выдающий комментарии по ключевым словам?

НЛО прилетело и опубликовало эту надпись здесь

SHSE 24 авг 2010 в 14:33

Автор забыл упомянуть в тегах RavenDB.

kurokikaze 24 авг 2010 в 17:46

Если все упоминать, тегов не хватит наверное :)

andreycha 24 авг 2010 в 18:00

О, отличная схемка, спасибо.

kurokikaze 24 авг 2010 в 18:06

Я её себе перерисовал на A4 и отмечаю те которые уже попробовал :) Ну и пометки оставляю типа «требует Java», «работает с Thrift» и т.д.

dude_sam 24 авг 2010 в 14:43

Только сегодня с нашим админом sql 2000 обсуждали тему nosql.
Очень хотелось бы почитать статьи…
Сами занимается автоматизацией и учетом ж/д перевозок на очень большом предприятии.

KReal 24 авг 2010 в 15:07

Ну вроде бы в вашем случае реляционные базы данны самое оно. Зачем же там NoSQL?

dude_sam 24 авг 2010 в 16:09

Просто интересно! :)

dude_sam 24 авг 2010 в 16:10

Просто интересно! :)

VolCh 24 авг 2010 в 14:54

Хотелось бы увидеть сравнение (ключевые отличия друг от друга) «MongoDB, CouchDB, Cassandra, Redis, Cache — все, что угодно» между собой. Сейчас вот начал изучать MongoDB, но выбрал её среди других NoSQL, лишь потому что, как говорится, «на слуху» название.

Deepwalker 24 авг 2010 в 16:37

Это все весьма разные штуки. Как-то можно сравнить между собой mongo и couch, cassandra и riak, всякие базы графов. А по сути важен вопрос — какой тип данных предполагается? Ведь вполне может оказаться, что вам mysql прям очень в тему ;-)
Для прототипирования я бы взял mongo — самое простое и функциональное в то же время. Для важных данных я бы монго не выбрал. Так что если вам что-то серьезное хранить — это не ваш выбор.

VolCh 24 авг 2010 в 18:01

Ну я особо не в теме, только начал изучать нереляционные СУБД (читай — NoSQL), противопоставление mongo и couch как-то встречается, я и подумал что все они одного поля ягоды :)

MySQL точно не в тему, предполагается большое количество объектов с заранее неописанной структурой, общее у них только id, name, description, author и т. п. То есть в случае SQL сразу надо создавать таблицу атрибутов объектов, определять их тип, и, если он не элементарный (ссылка на другие объекты или их списки), производить рекурсивные запросы, да ещё и в цикле в случае списков. Реализовывать это чисто на SQL мне кажется неразумным даже пытаться (если вообще это возможно), устраивать спагетти из SQL и «главного» ЯП не хочется, не говоря о том, что быстродействие всего этого внушает серьёзные опасения.

Но данные как бы важные, юзерам не понравится, если их усилия по заполнению анкеты или написанию поста в блог пропадут :)

andreycha 24 авг 2010 в 18:11

MySQL точно не в тему, предполагается большое количество объектов с заранее неописанной структурой, общее у них только id, name, description, author и т. п.

Да, это имхо сразу исключает использование РБД: либо замучаетесь с обновлением структуры базы, либо придется создавать кучу избыточных колонок.

Судя по комменту, ссылка на который приведена ниже, стоит попробовать CouchDB.

SMiX 24 авг 2010 в 17:10

Вот здесь был очень хороший комментарий.
Мы выбрали CouchDb за то что она работает по протоколу Json (простота интеграции с базой, не требующая обязательного использования доп. библиотек)