Comments 40
«Финальный экзамен отправлен на проверку...»
Проверка после 20 декабря. Не пиши так! А то я не все доделал и слегка напугался… O_O
Проверка после 20 декабря. Не пиши так! А то я не все доделал и слегка напугался… O_O
Говорят, map/reduce в монге блокирующий. И медленный. Т.е. попытка собрать статистику по нескольким миллионам записей будет не очень приятным сюрпризом. Поправьте, если не так.
Кстати, ещё в копилку к подводным камням: count с условием игнорирует индексы и вообще жутко медленный.
Кстати, ещё в копилку к подводным камням: count с условием игнорирует индексы и вообще жутко медленный.
«Говорят, map/reduce в монге блокирующий.» Нет. Не блокирующий. Поэтому при интенсивной записи можно получить не корректную статистику.
«И медленный» Собирал статистику на 6 миллиардах записей. Медленно, но у меня был один сервер. Потенциально есть возможность ускориться за счет применения шард.
«count с условием игнорирует индексы» count — это метод курсора запроса. Т.е. индексы использует. Просто может показаться — запрос не попавший в индекс но с лимитом выполнится быстрее, т. к. полного сканирования не происходит. А count выполнит сканирование.
«И медленный» Собирал статистику на 6 миллиардах записей. Медленно, но у меня был один сервер. Потенциально есть возможность ускориться за счет применения шард.
«count с условием игнорирует индексы» count — это метод курсора запроса. Т.е. индексы использует. Просто может показаться — запрос не попавший в индекс но с лимитом выполнится быстрее, т. к. полного сканирования не происходит. А count выполнит сканирование.
На счет count я всё таки настаиваю.
И map/reduce всё таки блокирующий, хоть и местами:
Самое грустное что map/reduce — однопоточный. :(
И map/reduce всё таки блокирующий, хоть и местами:
- read lock на каждые 100 документов
- The JavaScript code (i.e. map, reduce, finalize functions) is executed in a single thread, taking a JavaScript lock;
- The insert into the temporary collection takes a write lock for a single write.
Самое грустное что map/reduce — однопоточный. :(
Практика MongoDb до v 2 —
MapReduce медленный из-за того, что при сканировании вся коллекция блокируется, что отражается на производительности.
разработчиками рекомендуется не делать skip, а использовать операцию «поиск по больше» так как в первом случае есть линейная сложность, а во втором логарифмическая.
соunt — полной сканирование всего первичного индекса. Быстро, но недостаточно…
MapReduce медленный из-за того, что при сканировании вся коллекция блокируется, что отражается на производительности.
разработчиками рекомендуется не делать skip, а использовать операцию «поиск по больше» так как в первом случае есть линейная сложность, а во втором логарифмическая.
соunt — полной сканирование всего первичного индекса. Быстро, но недостаточно…
В курсе неоднократно отмечалось, что в MongoDB удобно хранить документы, так, как они используются для вывода.
Немного поправлю. MongoDB является документо ориентированной БД. Т.е. все что мы храним это «документы».
Допустим у вас есть блог, там комментарии. Рядом с комментарием выводится имя автора и email. Удобно в объекте, который хранит комментарий также хранить информацию об авторе. Соответственно если у вас что-то поменяется в этом плане — есть вероятность, что надо будет изменять место хранения данных. В принципе это не совсем уж подводный камень и вероятность такого развития событий мала, но что-то в этом утверждении мне не особо понравилось.
Вообще монго не является реляционной БД, хотя какие-то отношения между объектами можно построить. Часто при построении объектов применяется де нормализация, как в вашем примере. С помощью нее можно добиться большого прироста производительности и удобство хранения, но конечно есть и ограничения. Скорее это подводный камень де нормализации а не монго.
Что касается шардинга:
— после переконфигурации — перемещение данных между шардами запускается автоматически — это точно.
— нельзя обращаться к шардам напрямую, только через mongos
— При решардинге рекомендуется все данные шард разбивать пополам или на части кратные степени 2.
— после переконфигурации — перемещение данных между шардами запускается автоматически — это точно.
— нельзя обращаться к шардам напрямую, только через mongos
— При решардинге рекомендуется все данные шард разбивать пополам или на части кратные степени 2.
Периодически с моим крайне несовершенным английским некоторые вещи вводили в ступор. Списывался с англичанином, его путало тоже :) Говорит, много американизмов.
Я все ждал, когда же будет такой пост.
Немного моих ощущений от курса:
Я к сожалению не записался сразу на DBA, хотя к 5ой неделе стало интересно, мне было интересно не столько прохождение экзамена, сколько послушать материал который там дают, Как уже сказано выше 21 Января будет стартовать очередной курс DBA, на который я уже записался, но если есть желание просто ознакомится с материалами лекций, добрый человек уже собрал все видео в списки на youtube
Из основных плюсов для меня были:
+ mongo + python в заданиях
+ неплохие лекции, в которых разжевываются большинство тем. Материал на английском, но понимать речь довольно легко, если есть проблемы, автоматический субтитры на 60-70% правильно распознают речь (кроме специфических слов mongo, db etc.)
+ community
— в курсе for Developers не было ни слова о MapReduce
— задания иногда можно перевести по разному. Тут наверное лучше всего характеризует состояние дел фраза из обсуждения одного задания:
— "… agree, and those are the hardest for not-native-english-speakers."
— «Heck I'm a native English speaker and I evaluate the crap out of what each of the statements mean.»
Ну а теперь плюшки, очень хотел поделиться со всеми снипетом для build mongo в SublimeText2, но на пост это никак не тянуло:
Tools -> Build System -> new build system
сохраняем, пользуемся (CTRL+B)
Вроде 3 строчки, но у меня заняло 2 часа чтобы найти как правильно передавать параметры в shell
чем удобно:
+ привычная подсветка кода + multiline
+ результат билда открывается в консоли sublime (ошибки компиляции тоже показываются)
+ не нужно переключаться между редактором и консолью и копипастить
+ синтаксис тот же что и в mongo shell + js
— мне пока не удалось сделать mongoimport прямо из скрипта
Немного моих ощущений от курса:
Я к сожалению не записался сразу на DBA, хотя к 5ой неделе стало интересно, мне было интересно не столько прохождение экзамена, сколько послушать материал который там дают, Как уже сказано выше 21 Января будет стартовать очередной курс DBA, на который я уже записался, но если есть желание просто ознакомится с материалами лекций, добрый человек уже собрал все видео в списки на youtube
Из основных плюсов для меня были:
+ mongo + python в заданиях
+ неплохие лекции, в которых разжевываются большинство тем. Материал на английском, но понимать речь довольно легко, если есть проблемы, автоматический субтитры на 60-70% правильно распознают речь (кроме специфических слов mongo, db etc.)
+ community
— в курсе for Developers не было ни слова о MapReduce
— задания иногда можно перевести по разному. Тут наверное лучше всего характеризует состояние дел фраза из обсуждения одного задания:
— "… agree, and those are the hardest for not-native-english-speakers."
— «Heck I'm a native English speaker and I evaluate the crap out of what each of the statements mean.»
Ну а теперь плюшки, очень хотел поделиться со всеми снипетом для build mongo в SublimeText2, но на пост это никак не тянуло:
Tools -> Build System -> new build system
{
"selector": "source.js",
"shell":true,
"cmd": ["mongo < ${file}"]
}
сохраняем, пользуемся (CTRL+B)
Вроде 3 строчки, но у меня заняло 2 часа чтобы найти как правильно передавать параметры в shell
чем удобно:
+ привычная подсветка кода + multiline
+ результат билда открывается в консоли sublime (ошибки компиляции тоже показываются)
+ не нужно переключаться между редактором и консолью и копипастить
+ синтаксис тот же что и в mongo shell + js
use test;
//очистили базу если там что то было
db.test.drop();
//заполнили ее заново
for(var i=0; i< 100; i++){
db.test.insert({a: i, b:i, c:i});
}
//query
db.test.find().limit(5).pretty();
— мне пока не удалось сделать mongoimport прямо из скрипта
MapReduce нету, зато про Aggregation Framework много.
Aggregation Framework только в 2.2 появился. Я думаю что MapReduce в изначально именно как механизм для реализации аггрегирующих операций появился, с появлением Aggregation Framefork необходимость в его использовании снизилась, всё-таки он медленнее и сложнее.
Думаю MapReduce в Монго уйдёт в специфическую область, тем более для него Hadoop можно использовать.
Думаю MapReduce в Монго уйдёт в специфическую область, тем более для него Hadoop можно использовать.
Сори не в тему. А кто-нибудь знает ресурс который отслеживает все it и около курсы?
Не все, но много: www.class-central.com/
Кстати, к минусам (субъективным) могу добавить формат лекций.
На мой взгляд видеоформат — это не то, что нужно для таких вещей.
Нужен текст, по которому можно будет быстро пробежаться глазами.
На мой взгляд видеоформат — это не то, что нужно для таких вещей.
Нужен текст, по которому можно будет быстро пробежаться глазами.
Спорно. Это личные особенности — многим нравятся туториалы в формате видео. На Youtube такие популярны.
Я бы сказал, что текст нужен в дополнение, чтобы не бегать по видео. А само видео убирать не нужно — там все как и должно быть: «ручкой» по «бумаге», а не готовая презентация.
Меня в этих лекциях больше всего напрягала рука, мечущаяся по экрану. Лучше бы просто курсор оставили.
В некоторых случаях полезно использовать Sparse для экономии памяти,
например, я в одном из проектов использовал поле "{ update:1 }", для маркирования объектов для передачи в другую систему, при обычном индексе и коллекции в 1М объектов, данный индекс весил порядка 250Мб, после переключения его на «Sparse-индекс», вес индекса был всего несколько килобайт, т.к. объектов для синхронизации, всегда, было не много.
например, я в одном из проектов использовал поле "{ update:1 }", для маркирования объектов для передачи в другую систему, при обычном индексе и коллекции в 1М объектов, данный индекс весил порядка 250Мб, после переключения его на «Sparse-индекс», вес индекса был всего несколько килобайт, т.к. объектов для синхронизации, всегда, было не много.
Да, отличный курс… Было довольно интересно. Exams еще не делал, просто просмотрел. Никаких сложных моментов там не углядел. Думаю сделаю на выходных…
Для себя из курса вынес понимание, что MongoDB это не СУБД в общем смысле этого слова (а ля MySQL, PostgreSQL или, не приведи господь, Oracle). MongoDB — это storage (а la BerkeleyDB, только намного мощнее). Сами монговцы используют именно это слово… Базой данных MongoDB станет вместе с вашим приложением.
Многое из того, что «взрослые» CУБД делают автоматически вам в приложении придется делать вручную… Но это дает вам очень плотный контроль за производительностью, масштабируемостью и надежностью системы. Возможности кластеризации как у весьма серьезных СУБД. Учитывая объем кодовой базы, это весьма неплохо…
Чтобы эффективно использовать mongodb надо четко продумывать набор коллекций и политику кластеризации на перед… Всегда на этапе проектирования можно оценить динамику роста объема данных в коллекциях, какие коллекции возможно придется шардить и т.д… Соответственно продумать структуры ключей для шардинга и прочая…
Ни одного принципиального ограничения, я в MongoDB не вижу. Индексирование по массивам это весьма специфичная штука, я с трудом представляю где может понадобиться индекс с двумя массивами в ключе. Тем более что вам ничего не мешает сделать два индекса (в каждом по массиву) и в запросах будут автоматически использоваться оба индекса…
Те кто будет пытаться бездумно пересесть на монго с mysql или с postgresql тупо переносить схемы бд на коллекции и считать, что count() в sql и это тотже ...find(...).count() в mongodb будут с вероятностью 80% сильно разочарованы…
Меня как старого db-программера (начинал во времена dBase, Foxbase, Paradox и Clipper. Foxpro тогда не имел отношения к MS. А Oracle тогда еще был корявой и некрасивой поделкой) mongodb радует…
Для себя из курса вынес понимание, что MongoDB это не СУБД в общем смысле этого слова (а ля MySQL, PostgreSQL или, не приведи господь, Oracle). MongoDB — это storage (а la BerkeleyDB, только намного мощнее). Сами монговцы используют именно это слово… Базой данных MongoDB станет вместе с вашим приложением.
Многое из того, что «взрослые» CУБД делают автоматически вам в приложении придется делать вручную… Но это дает вам очень плотный контроль за производительностью, масштабируемостью и надежностью системы. Возможности кластеризации как у весьма серьезных СУБД. Учитывая объем кодовой базы, это весьма неплохо…
Чтобы эффективно использовать mongodb надо четко продумывать набор коллекций и политику кластеризации на перед… Всегда на этапе проектирования можно оценить динамику роста объема данных в коллекциях, какие коллекции возможно придется шардить и т.д… Соответственно продумать структуры ключей для шардинга и прочая…
Ни одного принципиального ограничения, я в MongoDB не вижу. Индексирование по массивам это весьма специфичная штука, я с трудом представляю где может понадобиться индекс с двумя массивами в ключе. Тем более что вам ничего не мешает сделать два индекса (в каждом по массиву) и в запросах будут автоматически использоваться оба индекса…
Те кто будет пытаться бездумно пересесть на монго с mysql или с postgresql тупо переносить схемы бд на коллекции и считать, что count() в sql и это тотже ...find(...).count() в mongodb будут с вероятностью 80% сильно разочарованы…
Меня как старого db-программера (начинал во времена dBase, Foxbase, Paradox и Clipper. Foxpro тогда не имел отношения к MS. А Oracle тогда еще был корявой и некрасивой поделкой) mongodb радует…
> Многое из того, что «взрослые» CУБД делают автоматически вам в приложении придется делать вручную…
А можно пример?
> Чтобы эффективно использовать mongodb надо четко продумывать набор коллекций и политику кластеризации на перед…
Это из собственного опыта? Мне просто показалось что наоборот, MongoDB из-за своей гибкости и простоты прощает ошибки, которые можно совершить на начальном этапе. У вас был опыт когда было неудачно выбраны коллекции и т.п. и потом пришлось переделывать? Какие впечатления?
А можно пример?
> Чтобы эффективно использовать mongodb надо четко продумывать набор коллекций и политику кластеризации на перед…
Это из собственного опыта? Мне просто показалось что наоборот, MongoDB из-за своей гибкости и простоты прощает ошибки, которые можно совершить на начальном этапе. У вас был опыт когда было неудачно выбраны коллекции и т.п. и потом пришлось переделывать? Какие впечатления?
А можно пример?
Много чего… Например реализация транзакций, многоколлекционные запросы, учитывать латентность при запросах к slaveOk() secondary серверу… Проще наверное написать, что не придется делать вручную…
Это из собственного опыта? Мне просто показалось что наоборот, MongoDB из-за своей гибкости и простоты прощает ошибки, которые можно совершить на начальном этапе. У вас был опыт когда было неудачно выбраны коллекции и т.п. и потом пришлось переделывать? Какие впечатления?
Конечно из опыта… Продумывать надо всегда не зависимо от того. используешь ты RDBMS или Mongo. Простота документоориентированных БД обманчива. Сложность в них никуда не исчезла. Она просто переместилась в другие аспекты.
Это такой своеобразный закон сохранения сложности… Если этого не учитывать, то вы рано или поздно уткнётесь носом в эту проблему.
С неудачно выбранными коллекциями это первый же опыт всех тех, кто после RDBMS осваивает Документоориентированные базы данных. Всё тот же тупой перенос схем в коллекции. (Например вы решили проект на рельсах перевести на Mongodb подключив mongoid). В итоге элементарный в mysql запрос превращается в mongo в целый ворох запросов по нескольким коллекциям и естественно в сравнении с mysql откровенно тормозит.
Типичный пример: Пользователь с почтовыми адресами. Обычно в mysql это схема user, хранящая например номер квартиры и ссылку на запись в справочнике домов, то в свою очередь на справочник улиц, те на справочник улиц, дальше районы, и могут быть даже города…
Перенесём это в MongoDB и попытаемся определить всех пользователей в некоем одном микрорайоне или даже городе… Прикиньте сами количество запросов, которое вам понадобится и как быстро вы пошлёте все это на…
В продашкне при более-менее нормальном объеме данных это начнёт тормозить нещадно. И в случае жалоб менеджер проекта потребует в кратчайшие сроки вернуть всё назад, и забыть про MongoDB…
Спасибо за статью!
У меня было время только на DBA курс. Как у Вас впечатление? Стоит на Developers записываться или курса DBA достаточно?
У меня было время только на DBA курс. Как у Вас впечатление? Стоит на Developers записываться или курса DBA достаточно?
Несмотря на то, что там многие темы совпадают, в курсе для Developers я не стал полностью смотреть лекции только по Sharding (и думаю зря :)), ибо посмотрел их уже в DBA и решил что в DBA более углубленно должны были дать этот материал. В целом многие темы там пересекаются, но когда смотрел лекции не было желания промотать вперед, ибо «где-то это уже слышал». Мне еще было интересно Python пощупать, я до этого о нем только слышал, поэтому мне было интересно и в Developers классе. Думаю что на Java тоже запишусь, несмотря на то, что лекции скорее всего будут теми же.
Не совсем понимаю, на какие лекции ушло 3 недели по 8 часов? Я изначально думал, что это 2 дня по 8 часов.
«Capped коллекции (manual)
При создании таких коллекций необходимо указать количество записей, который могут храниться в коллекции.»
Точнее, не количество, а общий объем коллекции.
При создании таких коллекций необходимо указать количество записей, который могут храниться в коллекции.»
Точнее, не количество, а общий объем коллекции.
Финальный экзамен M101 «MongoDB for Developers» сдал на 9/10, осталось доделать в M102 последние вопросы про шардинг :)
Курс классный, без особого напряга за 7 недель получил неслабое представление о MongoDB, при выполнении некоторых HW и заданий финального экзамена частенько обращался к их документации, которая, кстати, написана весьма неплохо.
Сейчас пишу на MongoDB небольшой проектик, just for fun :)
Курс классный, без особого напряга за 7 недель получил неслабое представление о MongoDB, при выполнении некоторых HW и заданий финального экзамена частенько обращался к их документации, которая, кстати, написана весьма неплохо.
Сейчас пишу на MongoDB небольшой проектик, just for fun :)
В каком вопросе ошиблись, если не секрет? :)
Конечно не секрет :) во втором, где надо эту Веронику Эспинозу сагрегатить :)
В общем я его делал понемногу каждый день, ну, не очень я разобрался с агрегацией. Самое бесючее, когда написанный запрос возвращает result: [ ], если же че-то возвращал запрос, то это было не 2181.
Вчера вроде получилось, после того как все дискуссии по этому вопросу перечитал, хотя подсказок особых там не было. Но вместо одного запроса я написал функцию на JS. которая просто проверяла все пары из возможных в вопросе (5 там или 6 их), и самое прикольное, что почему-то неправильно получилось, хотя для Эспинозы и recipients запрос возвращал 2181.
Кстати, когда вчера я сделал-таки q2, прошелся по остальным вопросам, на которые уже ответил, перечитывая дискуссии по ним. И ведь подправил еще 2 или даже 3 вопроса, в итоге оочень не зря оказалось это.
Но утром, когда вскрылись результаты, был зол на q2.
В общем я его делал понемногу каждый день, ну, не очень я разобрался с агрегацией. Самое бесючее, когда написанный запрос возвращает result: [ ], если же че-то возвращал запрос, то это было не 2181.
Вчера вроде получилось, после того как все дискуссии по этому вопросу перечитал, хотя подсказок особых там не было. Но вместо одного запроса я написал функцию на JS. которая просто проверяла все пары из возможных в вопросе (5 там или 6 их), и самое прикольное, что почему-то неправильно получилось, хотя для Эспинозы и recipients запрос возвращал 2181.
Кстати, когда вчера я сделал-таки q2, прошелся по остальным вопросам, на которые уже ответил, перечитывая дискуссии по ним. И ведь подправил еще 2 или даже 3 вопроса, в итоге оочень не зря оказалось это.
Но утром, когда вскрылись результаты, был зол на q2.
Ну, сертификат-то в итоге получили? :)
А вы разве сами курс не проходили?
Да, 95% набрал — второй вопрос блин -5%, минимум надо было 65% для сертификата. пару недель назад они писали что через какое-то время после финального экзамена они подпишут и разошлют сертификаты. Насколько я понял, они только в электронном виде)
В январе стартует тот же курс, но вместо питона там джава будет)
Да, 95% набрал — второй вопрос блин -5%, минимум надо было 65% для сертификата. пару недель назад они писали что через какое-то время после финального экзамена они подпишут и разошлют сертификаты. Насколько я понял, они только в электронном виде)
В январе стартует тот же курс, но вместо питона там джава будет)
Я в 8 чуть не ошибся, где вопрос про репликацию и падение мастера. Додумался до правильного ответа когда начал делать домашнюю работу по M102 :) Всё-таки мысль проходить сразу два этих курса — очень правильная.
Sign up to leave a comment.
MongoDB for Developers and DBA