Комментарии 75
Чёрт, а ведь красиво же ;)
Типичная записка к курсовому, по тексту одно, в выводе другое :) Дело в том, что эти примеры иллюстрируют использование MongoDB, но ничего из перечисленного вами.
Да, я вот тоже как- то ощутил радикальных отличий. Отсюда вопрос к знатокам — в каких случаех лучше использовать Mongo, а в каких проще оставить мускул и т.д.?
Вообще в описание Mongo только Ваш вопрос и надо обсуждать.
Смысл в том, что используется «документ» как конечный элемент базы.
Самый простой пример — Вы делаете новостной портал.
Есть там новости, потом добавляются статьи, потом добавляются интервью и т.д.
С mongoDB и подобными не надо плодить новых сущностей — все записи лежат в одной коллекции(таблице) и могут отличаться набором полей — у интервью есть участники, у статьи есть автор, у новости есть новостное агентство
Реальный плюс для разработки такого сайта — шаблон будет тоже один — просто показываете те поля, что есть. В реляционной базе тоже можно так сделать, если сразу предусмотреть абсолютно все колонки таблицы или в таблице хранить XML документ(как в CMS DJEM)
Смысл в том, что используется «документ» как конечный элемент базы.
Самый простой пример — Вы делаете новостной портал.
Есть там новости, потом добавляются статьи, потом добавляются интервью и т.д.
С mongoDB и подобными не надо плодить новых сущностей — все записи лежат в одной коллекции(таблице) и могут отличаться набором полей — у интервью есть участники, у статьи есть автор, у новости есть новостное агентство
Реальный плюс для разработки такого сайта — шаблон будет тоже один — просто показываете те поля, что есть. В реляционной базе тоже можно так сделать, если сразу предусмотреть абсолютно все колонки таблицы или в таблице хранить XML документ(как в CMS DJEM)
Я конечно рад любым статьям на эту тему, т.к. они повышают популярность решения. Однако, статья крайне неудачная. Такое ощущение что просто взяли куски мануала скопировали и добавили пару скринов. Для тех кто читал (или собирается читать) мануал от нее пользы 0.
Прочитайте, пожалуйста, название статьи… Там как раз написано, то о чем вы пишите.
НЛО прилетело и опубликовало эту надпись здесь
Постараюсь найти данные и выложить
Нашел презентацию, если вам интересно то смотреть тут
Плюс еще перевели гуглотранслейтом :-))
покажите кусок текста, где переведено гуглом
Да ну вот хотя бы :-)
> скажем, например, если вы пытаетесь интегрировать MongoDB into в существующее приложение (framework-based application).
> скажем, например, если вы пытаетесь интегрировать MongoDB into в существующее приложение (framework-based application).
Если Вы внимательно посмотрите, то в начале статьи я специально некоторые вещи добавлял на английском, так как русских аналогов нет (например тот же «шардинг»).
Более того framework-based application не переводится как существующее приложение, так как более подходящего аналога я в русском не нашел. И потом в конце статьи ссылка на оригинал, заправьте его в гугл и посмотрите, что он даст, хотя бы тот же кусок с framework-based application.
Более того framework-based application не переводится как существующее приложение, так как более подходящего аналога я в русском не нашел. И потом в конце статьи ссылка на оригинал, заправьте его в гугл и посмотрите, что он даст, хотя бы тот же кусок с framework-based application.
звучит очень красиво, но крайне интересны sucess story, когда в готовом проекте изменили базу данных с mysql на mongodb и производительность при этом не упала.
Что-то мне подсказывает что за все надо платить. В последнем примере, например, поиск красных и синих игрушек будет совсем не тривиальной задачей (регулярками, да?) с перелопачиванием всей базы.
Интересно, а что там с индексами и кешированием?
Что-то мне подсказывает что за все надо платить. В последнем примере, например, поиск красных и синих игрушек будет совсем не тривиальной задачей (регулярками, да?) с перелопачиванием всей базы.
Интересно, а что там с индексами и кешированием?
Нет, не регулярками, а оптимальным поиском по индексу поля. MongoDB поддерживает массивы в свойствах. Поиск будет такой же как будто там скалярное значение лежит.
mongodb — это хранилище документов. В бытность мою студентом, когда только появились xml-технологии, обсуждалась идея хранения в БД информации в виде xml. Однако вопрос поиска внутри xml-дерева достаточно сложный.
Что-то мне кажется, что пока это решение не для больших объемов информации
Что-то мне кажется, что пока это решение не для больших объемов информации
Извините а кем она обсуждалась? В курилке студентами? Никто в здравом уме не будет XML-формат использовать для базы данных, но не потому что якобы там будут проблемы с поиском (никаких проблем — индекс можно построить). А потому что формат не позволяет эффективно двигать данные и отделять объекты друг от друга. В MongoDB используется BSON.
Плохо когда мысли начинаются с «Что-то мне кажется» — это плохой признак.
Плохо когда мысли начинаются с «Что-то мне кажется» — это плохой признак.
Ох, могу показать проект в котором владелец изобрел велосипед с хранением данных в xml. На мой вопрос «а как же масштабирование и оптимизация» поступил ответ — не использовать движок на проектах с посещаемостью больше 600 хитов в день. При этом кругом ужас-ужас, куча копий главного xml файла и всякий ад, когда этот файл правят руками.
Вопрос обсуждался на уровне преподаватели и студенты, дело было в 1999 году. Тогда этот подход был main stream. Так что на вашем месте, я бы не был столь категоричен.
В догонку почитайте www.citforum.ru тех лет
погуглите на тему DJEM
xml в базе это не всегда база на xml
xml в базе это не всегда база на xml
Вот хорошее видео с ответами на ваши вопросы (=
nosql.mypopescu.com/post/1016320617/mongodb-is-web-scale
nosql.mypopescu.com/post/1016320617/mongodb-is-web-scale
habrahabr.ru/post/204392/
вот перевод
вот перевод
habrahabr.ru/blogs/webdev/95526/ (eventr.com)
вообще непонятно как работает поиск, что там с индексами, с GROUP BY и самое главное как там с JOIN. Я так понимаю, что про типы данных не имеет смысла спрашивать. И еще непонятно какое количество записей может быть в одной колекции.
С индексами там всё замечательно, правда пока нету partial indexes и functional indexes, но будут. В MySQL их тоже нет. С GROUP BY там всё хорошо, есть операция group(). JOIN там нету и не надо. Количество записей 10^79.
простите я не понял про джоины. Можно на примере объяснить?
вот к примеру есть пользователи и есть коментарии, которые пользователи оставляют. Нужно вывести все комментарии пользователя Х, а так основную информацию о пользователе. Можете мне показать какие колекции я должен создать?
вот к примеру есть пользователи и есть коментарии, которые пользователи оставляют. Нужно вывести все комментарии пользователя Х, а так основную информацию о пользователе. Можете мне показать какие колекции я должен создать?
Сначала надо выдернуть инфу о пользователе, а потом комментарии. Коллекцию users и comments.
отлично на странице блога будут показываться комментарии всех пользователей, скажем их 100. к каждому комментарию нужно показывать информацию о пользователе — это что, нужно по каждой записи делать запрос к коллекции Users?
«Сьешь сладенького, говорят мозгам помогает, тем у кого они есть конечно» (С) Шматрица
А вам не приходило в голову собрать все уникальные ID-шники комментаторов в массив, и сделать один единственный запрос?
А вам не приходило в голову собрать все уникальные ID-шники комментаторов в массив, и сделать один единственный запрос?
а потом джойнить массивы? или просто хранить каждую коллекцию в своем массиве. Иногда требуется более трех джоинов за раз, в данном случае все преврятится в кучу кода. Да и после каждого запроса собирать уникальные ID тоже знаете ли.
Пока джоинов не будет — работать можно только с простыми данными.
Пока джоинов не будет — работать можно только с простыми данными.
Не вижу смысла в том чтобы копировать одни и те же данные в массив. Ну это всё от прямоты рук зависит на самом деле, можно и не сильно страшный код написать.
Не надо обобщать, многие проекты не пользуются джойном и держат сложные структурированные базы данных.
Не надо обобщать, многие проекты не пользуются джойном и держат сложные структурированные базы данных.
хотелось бы на них взглянуть. Сложно себе представляю нормализованную БД сложной структуры без джоинов.
Легко!
Один из проектов (full ajax) кеширует данные на клиенте, а жоин происходит во время рендера. Я скажу, что прирост скорости доставляет. =)
Один из проектов (full ajax) кеширует данные на клиенте, а жоин происходит во время рендера. Я скажу, что прирост скорости доставляет. =)
на счет joinов далеко ходить не надо — Facebook…
www.insight-it.ru/masshtabiruemost/arkhitektura-facebook/
www.insight-it.ru/masshtabiruemost/arkhitektura-facebook/
выдернуть все комментарии, из них выбрать массив ид юзеров (уникальных будет всегда меньше, чем общее число комментов), по этому массиву выбрать инфу. в обычных бд тоже такой же подход и он гибче и используя только основные команды, делает все быстрее.
Коллекцию документов post (если речь о блоге), в которую внедрены документы comment (в том числе без всяких проблем древовидные комментарии), ссылающиеся (специальный тип поля) на документы коллекции user. В общем случае (отвечаю на вопрос ниже) да, придётся делать как это называется 1+N запрос вместо одного с джойном, вернее их придётся делать, если документы не связаны отношением типа «родитель-дети» или «автор-посты». В вашем примере так не получится — комменты должны явно ссылаться или на своего автора и неявно на пост (тогда одним запросом можно получить все комменты к посту) или явно на пост и неявно на автора (тогда можно получить все комменты автора без проблем). Сходу приходят в голову варианты обхода проблемы: кэширование запросов, «денормализация базы» (то есть хранить с комментом не только ссылку на его автора, но и, например, ник, чтобы сделать линк на профиль, причём в данном конкретнм варианте даже не надо беспокоиться о синхронизации данных — ники, как правило, изменить невозможно) и есть ещё встроенная в Моного mapreduce engine, что-то вроде хранимых процедур (пишутся они, кстати, на обычном Javascript) — наверное с её помщью можно, особенно учитывая прозрачную горизонтальную масштабируемость — обработка map/reduce функции будет выполниться на всех серверах. Тлчнее не скжу, настолько ещё не углубился, ни в функции, ни в шардинг
В этом доке очень наглядный пример реализации сложного SQL запроса с помощью Mongo. sql-to-mongodb.pdf
Ещё вот этот линк поможет в перестройки логики с SQL на манер Mongo. =)
Ещё вот этот линк поможет в перестройки логики с SQL на манер Mongo. =)
спасибо за ссылки — теперь более менее все становится на свои места. Может я немного старомоден, но мне кажется что менять простой и понятный запрос
SELECT a.*, c.* FROM articles a INNER JOIN categories c ON a.category_id = c.id WHERE a.shared = 1
на
find_function = function(cond){
var categoriesHash = {};
var categoryIds = [];
db.categories.find(cond)
.forEach(function©{
categoriesHash[c._id.toString()] = c;
categoryIds.push(c._id);
});
var result = [];
db.articles.find({category_id: {"$in": categoryIds}}).forEach(function(a) {
a.category = categoriesHash[a.category_id.toString()];
result.push(a);
});
return result;
}
db.articles.eval(find_function);
db.articles.eval(find_function, {shared: 1});
немного не по мне. Дело вкуса конечно. ну и конечно я сомневаюсь, что тут будет высокая производительность.
SELECT a.*, c.* FROM articles a INNER JOIN categories c ON a.category_id = c.id WHERE a.shared = 1
на
find_function = function(cond){
var categoriesHash = {};
var categoryIds = [];
db.categories.find(cond)
.forEach(function©{
categoriesHash[c._id.toString()] = c;
categoryIds.push(c._id);
});
var result = [];
db.articles.find({category_id: {"$in": categoryIds}}).forEach(function(a) {
a.category = categoriesHash[a.category_id.toString()];
result.push(a);
});
return result;
}
db.articles.eval(find_function);
db.articles.eval(find_function, {shared: 1});
немного не по мне. Дело вкуса конечно. ну и конечно я сомневаюсь, что тут будет высокая производительность.
В любом более менее адекватном обзоре, чуть ли не первым пунктом, говорится о целях. Каждая БД хороша в своей области.
Да и приведённый выше пример — всего лишь механика. Автор не затронул тонкости логического отличия подходов. Я имеюю ввиду «JOIN сделать возможно, а смысл?».
Архитектор системы должен расчитывать на большой «вес» одной записи. В структуру можно поместить целое дерево взаимосвязей, что автоматически отметает жойны мелких таблиц.
Я сразу слышу вопрос про изменяемые данные в отдельно взятой «мелкой таблице». Для этого в монго есть механизм ссылок. Подробнее в документации.
Да и приведённый выше пример — всего лишь механика. Автор не затронул тонкости логического отличия подходов. Я имеюю ввиду «JOIN сделать возможно, а смысл?».
Архитектор системы должен расчитывать на большой «вес» одной записи. В структуру можно поместить целое дерево взаимосвязей, что автоматически отметает жойны мелких таблиц.
Я сразу слышу вопрос про изменяемые данные в отдельно взятой «мелкой таблице». Для этого в монго есть механизм ссылок. Подробнее в документации.
1) По поводу JOIN можно эмулировать (видео, слайды [слайд 52])
2) По поводу GROUP BY тоже есть (выглядеть будет примерно так — пример с книги):
2) По поводу GROUP BY тоже есть (выглядеть будет примерно так — пример с книги):
db.runCommand({"group" : {
... "ns" : "stocks",
... "key" : "day",
... "initializer" : {"time" : 0},
... "$reduce" : function(doc, prev) {
... if (doc.time > prev.time) {
... prev.price = doc.price;
... },
... "condition" : {"day" : {"$gt" : "2010/09/30"}}
... })
НЛО прилетело и опубликовало эту надпись здесь
Хочу поделиться ссылками, которые мне помогли при изучении MongoDB.
Соответствие MySQL и MongoDB запросов:
memo.undr.su/2010/01/27/sootvetstvie-mysql-i-mongodb-zaprosov/
www.dealtaker.com/blog/2010/05/12/php-mongodb-sitting-in-a-tree-part-1/
Соответствие MySQL и MongoDB запросов:
memo.undr.su/2010/01/27/sootvetstvie-mysql-i-mongodb-zaprosov/
www.dealtaker.com/blog/2010/05/12/php-mongodb-sitting-in-a-tree-part-1/
Где стоит использовать MongoDB? Можно какие-нибудь примеры из жизни с пояснением чем тут лучше подходит MongoDB, а не, например, MySQL?
любую «цепочную» информацию очень удобно хранить в монгодб, например цепочка «друзья друзей»
m.habrahabr.ru/post/88246/
m.habrahabr.ru/post/88246/
Хороший материал. Советую добавить ссылку на этот топик в разделе Q&A
Может в NoSQL перенести?
За перевод спасибо, отличный материал. MongoDB действительно выглядит очень интересным решением, но я пока не встретил нормального описания вопроса сохранности информации. Что будет, если вдруг произойдет сбой? Как делается бэкап и т.д. В данный момент я боюсь потери информации.
blog.mongodb.org/post/381927266/what-about-durability — это почему они отказались от single server durability. Правда эту фичу сделают в 1.8: jira.mongodb.org/browse/SERVER-980
Как делать бекапы и т.п. описано в мануале вполне понятным языком.
В теории, кроме отказов винтов, вы теряете изменения максимум за 60 секунд (время по-умолчанию для fsync'a). На практике же я встречал посты о том, что операция repair может испортить базу. Как с этим обстоит сейчас — не знаю.
Короче, мне кажется, если у вас только 1 сервер, то стоит дождаться версию 1.8.
Как делать бекапы и т.п. описано в мануале вполне понятным языком.
В теории, кроме отказов винтов, вы теряете изменения максимум за 60 секунд (время по-умолчанию для fsync'a). На практике же я встречал посты о том, что операция repair может испортить базу. Как с этим обстоит сейчас — не знаю.
Короче, мне кажется, если у вас только 1 сервер, то стоит дождаться версию 1.8.
На практике же я встречал посты о том, что операция repair может испортить базу.
Я тоже про это слышал. Это и пугает.
Про бекапы почитаю детальнее, но хотелось бы узнать во что это выливается практически. Я так понял, что при бекапе база блокируется на запись. А на сколько быстро работает бекап при различных объемах базы, например?
Статья интересная в качестве обзора MongoDB, да интересно было бы посмотреть на проект перенесенный с mysql, если это вообще возможно и стоит ли оно того…
Спасибо за статью, рекомендую вам посмотреть на
Doctrine MongoDB Object Document Mapper (ODM) от автора Doctrine ORM.
Doctrine MongoDB Object Document Mapper (ODM) от автора Doctrine ORM.
Так удобнее смотреть www.doctrine-project.org/projects/mongodb_odm
Спасибо за перевод, все никак не доходили руки посмотреть, что за зверь. Теперь дойдут)
А вот здесь уже собственно код примера…
// disconnect from server
$conn->close();
} catch (MongoConnectionException $e) {
die('Error connecting to MongoDB server');
} catch (MongoException $e) {
die('Error: '. $e->getMessage());
}
?>
// disconnect from server
$conn->close();
} catch (MongoConnectionException $e) {
die('Error connecting to MongoDB server');
} catch (MongoException $e) {
die('Error: '. $e->getMessage());
}
?>
соединение можно и не закрывать
с 1.7 (dev) версии консольный клиент поддерживает автокомплит
з.ы. можно использовать дев-клиент + стабильный демон
з.ы. можно использовать дев-клиент + стабильный демон
Давно искал такую статью, вообщем спасибо то что нужно.
Имхо, не показано (или я пропустил?) самое интересные вещи в Монго и сородичах. Такое ощущение, что обычная реляционная БД с извращенным (с точки зрения SQL :) ) принципом. Я загорелся нереляционными документориентированными БД когда узнал, что в хранлище GAE (очень близком к Монго прежде всего по идеологии) в одной коллекции можно хранить документы с абсолютно разными полями. Простейший (для знатоков ООП и архитектурных паттернов) пример — в одной «таблице» можно хранить все экземпляры (объекты) какой-то иерархии классов (включая все объекты модели/приложения, так, в принципе, поступает CouchDB — без разделения на «таблицы»/«коллекции» — единый сторадж/репозиторий для объектов) без всяких «наследование в одной таблице», «наследование с таблицей для конкретного класса» и т. п. с нерациональным использованием места или проблемами ведения единого примари кей в нескольких таблицах.
А вот в хорошей литературе «sharding» все-таки переводят как «секционирование».
Но точно так же там переводят и partitioning.
Но точно так же там переводят и partitioning.
Странно. Мы говорим о БД или о том как программировать с использованием данной БД?
Когда мы говорим о реляционных БД мы рассуждаем не о том как писать SQL или как его включать в исходный код, а о том как структурированы данные в БД, каким образом распределяется пространство, как производится оптимизация запросов и т.д., а здесь? Смотрите как красиво код получается, ну и что с этого? Каким образом выделяется пространство под документы? Каким образом строятся индексы? Индексы строятся по документу или по отдельным значениям?
Когда мы говорим о реляционных БД мы рассуждаем не о том как писать SQL или как его включать в исходный код, а о том как структурированы данные в БД, каким образом распределяется пространство, как производится оптимизация запросов и т.д., а здесь? Смотрите как красиво код получается, ну и что с этого? Каким образом выделяется пространство под документы? Каким образом строятся индексы? Индексы строятся по документу или по отдельным значениям?
Именно то, что искал. Спасибо большое!
интресно, а существует ли какой-то механизм коллбеков на добавление/удаление данных в коллекцию?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Getting Started with MongoDB and PHP