Pull to refresh

Comments 23

Как раз искал статью про аспэху, и любую базу кроме мускула! Спасибо!
К сожалению отсутствует, но на текущих выходных появится ;)
Надеюсь, как результат на хабре появиться статья. Будет здорово, есть в ней будет освящена работа с оперативной памятью, я слышал, что в 32 битной версии есть ограничение в 2 гига) а вся db отображается в память, поэтому интересно узнать правда это или нет. А так же интересно посмотреть на расход памяти, когда db забита под завязку.
Да, на 32 битах база не более 2 Гб, т.к. используются memory-mapped files.
Ещё добавлю, что замечен всплеск интереса к аналогичной базе на .NET под названием RavenDB: www.codeproject.com/KB/cs/RavenDBIntro.aspx
Как в MongoDB обстоят дела с optimistic locking и referential integrity?
Есть ли возможность индексировать или как-то по-другому ускорять тормозящие запросы?
Насчет поддержки locking механизмов можно прочитать тут, referential integrity не поддерживается.
Короче, чтобы другим не копаться, в двух словах:

1) оптимистический локинг на 1 запись, т.е. бизнес-транзакционности нет (обновить запись дебета одновременно записью кредита — нельзя).
2) оптимистический локинг на вложенные записи, т.е. при обновлении мастер-записи можно обновить деталь-записи. Можно ли обновить какие-то определенные деталь-записи не загружая их все в память — не сказано.

Большая просьба к Вам. Если будете пользоваться новой БД, напишите, пожалуйста, сравнения по скорости выполнения с любой другой. А если замерите (ясное дело, качественно-примерно) количество занимаемой памяти — вообще будет шикарно и моей прищнательности не будет конца в рамках разумного. )
Может мне кто-нибудь назвать пример задачи, для которой использование NoSQL БД будет предпочтительней/оправдонней, чем реляционной?
Например, задачи, где часто меняется структура данных, где присутствует неполнота данных. Поддержка схемы БД в актуальном состоянии в таком случае может дорого обходиться.
маленький офтоп
Мы используем активно используем MongoDb в наших проектах — и да, чуть что, системный инженер утерая горькие слезы пырится в лог запросов монги ибо хрен его знает когда эта неведомая херота начнет свопится на диск.=) Это все понятно но вот недавно эта ваша монго вместе со свей этой теткой как там ее Кристина Чудроу(тетка которая у них подписывается под всеми презентациями и корпоративными херями типо саппорта) отожгла ваще неподецки.
Короче цимес вот в чем ни стого ни с сего в верхнем левом углу появляется надпись «writing more»
Сломав голову сменив два дебагера мы понимаем что это бля тупо в модуле для php прямо набыдлокожено
github.com/mongodb/mongo-php-driver/commit/05209bc7a65696203da0fee6d5c2270d7bf303e7
Да да php_printf(«writing more\n»); прямо в модуле
Причем челы из монги пока не нашлась именно та самая строчка в исходниках грили что типо они ваще не при делах
в итоге когда ткнули носом Кристина родила фразу которая стала у нас в компании нарицательной
Sorry, debugging output.
jira.mongodb.org/browse/PHP-91
Немного оффтопик.
А почему бы вместо
var category = session.Queryable
    .Where(c => c.Id == Id)
    .FirstOrDefault();


не писать
var category = session.Queryable
    .FirstOrDefault(c => c.Id == Id);

?
UFO just landed and posted this here
есть вопрос, я так понял вся суть этой штуки в том что в любой момент времени я могу дополнить класс category дополнительными полями и оно все будет нормально работать, то есть мне не нужно будет заморачиваться что там и как будет в базе?

и еще один вопрос к знатокам есть ли возможность тащить с апликухой (не веб) standalone базу, чтобы без инсталяторов и всякой другой разности?
мне не нужно будет заморачиваться что там и как будет в базе?

Именно так.
Прежде чем бросаться изучать очередную не отлаженную технологию, сначала почитайте про ORM. То, что обычно бизнес-сущности напрямую соответствуют таблицам в базе, еще не значит, что так должно быть всегда.
ну то все понятно, меня вот к примеру больше интересует вариант: при необходимости склепать по быстрому маленькую апликуху которая будет с собой таскать несколько табличек и чем меньше мне для этого надо будет изворачиваться — тем счастливее я буду.

до этого делал на winform'ах и xml — не могу сказать что очень доволен, сейчас пытаюсь въехать в wpf — так там сам черт ногу сломит :(

а так конечно да, не вопрос, если делать какой ни буть энтерпрайз то надо все по науке и ни шага в сторону…
Немного раскрою мысль:
если вы ищите в mongodb хранилище где нет сложностей со схемой данных — вам оно не нужно. Лучше используйте старые проверенные технологии.
Сейчас ключевые козыри MonoDB в масштабируемости, а не в удобстве.
Если надо тащить standalone — можно брать SQL Server CE, FireBird или SQLite.
Насколько я понимаю, одна из проблем при работе с ДОБД (=документно-ориентированных баз) — отсутствие поиска по каким-либо полям, кроме ключа. Эта проблема решается построением индекса. Иногда вручную, иногда при первом запросе (а как с этим у MongoDB?).

Другая проблема: данные в ДОБД денормализованы, поэтому чтобы изменить, например, название категории продукта, нужно найти все продукты и поменять это название в них.
Sign up to leave a comment.

Articles