LINUX.ORG.RU

Вышла MongoDB 2.0

 , ,


0

1

Вышла очередная стабильная версия MongoDB. Из тех изменений, которые стоит отметить:

  • Журнал теперь включен по умолчанию, данные в нем сжимаются.
  • Индексы стали в среднем на 25% компактнее и быстрее.
  • Для сжатия одиночных коллекций/индексов появилась команда 'comрact' (раньше сжатие можно было делать только через 'repair' всей базы). В отличие от repair, compact не требует для работы удвоенного места на диске, и позволяет гибче работать с репликами.
  • Для реплик добавились теги и приоритеты. Плюс возможность гарантировать распространение критичных данных в группе серверов по окончании команды записи (например, это удобно при создании новых пользователей).
  • В документах теперь можно индексировать несколько гео-координат одновременно (раньше локейшены можно было положить в массив, но такие массивы не индексировались).
  • Oчень большие результаты map/reduce теперь можно складывать в шарды
  • К шардам добавили аутентификацию.
  • Уменьшен размер стека по умолчанию для новых соединений (имеет значение только в конфигурациях с большим количеством клиентов)
  • Начата работа по устранению блокировок при нехватке памяти (когда монга начинает работать с диском).

Разработчики отмечают, что версия 2.0 не означает революционных переделок. Это простое увеличение номера стабильной версии 1.8 на 0.2.

>>> Подробности

★★★★★

Проверено: Tima_ ()
Последнее исправление: Tima_ (всего исправлений: 1)
Ответ на: комментарий от Vit

Ага, помню, ещё весной смотрел у них в Жире. Ну, 2.1 так 2.1 :)

yoghurt ★★★★★
()
Ответ на: комментарий от anonymous

>А с каких это пор на уроках информатики дают рекомендации(!!!) по оформлению номеров релизов? Школоло?

Не поверишь, у меня дома лежит энциклопедия для школьников 5-11 кл. в двух томах, так там в разделе по информатике одной из последних глав шли правила нумерации версий :)

P.S. Книжка была куплена в конце прошлого века

yoghurt ★★★★★
()
Ответ на: комментарий от anonymous

>А с каких это пор на уроках информатики дают рекомендации(!!!) по оформлению номеров релизов? Школоло?

Всегда давали. В книжке Фигурнова(?) была озвучена нумерация версия-релиз-билд.

Собственно, схему давали не для писания программ, а для чтения. Чтобы пользователь понимал, какая версия более новая.

AVL2 ★★★★★
()
Ответ на: комментарий от yoghurt

>Массив элементов, который будет прислан в поддереве, может быть довольно большим, и каждый элемент в нём - куда больше, чем в моём примере. На высоких нагрузках оно становилось неприятно :)

Да, тогда неприятно. В монге емнип нет возможности получить только отдельные части документа.

А вообще, для оптимизаторов есть оракл. Остальное не нужно.

AVL2 ★★★★★
()
Ответ на: комментарий от anonymous

>Опять повылазили веб-макаки со своими хэш-табличками.

Настоящий Программист (тм) обиделся?

anonymous
()
Ответ на: комментарий от anonymous

>Опять повылазили веб-макаки со своими хэш-табличками.

Они просто не знают, что такое декартово перемножение таблиц.

AVL2 ★★★★★
()

Вообще для меня лично самое важное, что появилось в 2.0 - это $and и возможность вкладывать $or друг в друга. Причем появление $and вообще позволяет нам в некоторых случаях отказаться от жутко медленного map/reduce.

YOjick
()
Ответ на: комментарий от yoghurt

>В общем есть коллекция элементов вот такого типа

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

KRoN73 ★★★★★
()
Ответ на: комментарий от AVL2

>В монге емнип нет возможности получить только отдельные части документа.

Есть:

db.myCollection.find({}, {onlyThisFile:1})

theos ★★★
()
Ответ на: комментарий от AVL2

Поля фильтровать можно. Встроенные документы пока только через $slice по порядковым номерам. На 2.1 запланирован «new aggregation framework».

Vit ★★★★★
() автор топика
Ответ на: комментарий от AVL2

>Они просто не знают, что такое декартово перемножение таблиц.

Это просто «типа крутые» программисты не видели систем где такую безсхемность строят поверх оракловских БД, т.к. обновление структуры не должно останваливать процессинг ни на секунду. А монга избавляет от необходимости реализовывать это. Хотя она очень бедная в смысле инструментария и языка запросов-обработки, что сильно уменьшает ее границы использования.

theos ★★★
()
Ответ на: комментарий от KRoN73

>Так это получается коллекция внутри коллекции? Нафига, когда можно сделать отдельную коллекцию?

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

theos ★★★
()
Ответ на: комментарий от yoghurt

Ну так где-то золотая середина должна быть :)

Как по мне, так один объект — один документ.

Ты, например, объект автора документа тоже ембеддить будешь? А если автор подпись поменяет? :)

KRoN73 ★★★★★
()
Ответ на: комментарий от theos

>Если вложенная коллекция небольшая, то удобно получить ее сразу вместе со всем объектом, а не в два приема.

Если бы было удобно, то не возникало бы таких вопросов ;)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

> Так это получается коллекция внутри коллекции? Нафига, когда можно сделать отдельную коллекцию?

1. Чтобы не делать JOIN, которого нет в mongo. 2. Операции над документами атомарны. Транзакций (для операций над несколькими документами нет).

В документации Mongo рассказано, когда лучше делать одну коллекцию, а когда разносить не нескольким.

P.S. Создатели MongoDB не фанатики, они четко осознают, для чего они создали базу, какие у нее преимущества и когда лучше использовать другие решения. Причем все это у них написано в документации.

anonymous
()
Ответ на: комментарий от KRoN73

>Ты, например, объект автора документа тоже ембеддить будешь? А если автор подпись поменяет? :)

Конечно нет, в этом случае авторов надо в отдельную коллекцию выводить. А в приведенном мною - элементы в items у каждого документа могут быть свои, т.е. они локальны по отношению к документу

yoghurt ★★★★★
()
Ответ на: комментарий от KRoN73

>Так это получается коллекция внутри коллекции? Нафига, когда можно сделать отдельную коллекцию?

ну и здравствуй SQL с его подселектами.

AVL2 ★★★★★
()
Ответ на: комментарий от anonymous

>Чтобы не делать JOIN, которого нет в mongo

Межобъектный JOIN — это зло, которое привязывает гвоздями к бэкенду.

Я как-то и на SQL стараюсь топики форума извлекать отдельно, юзеров — отдельно. На запрос больше, а итоговая нагрузка — меньше.

Операции над документами атомарны

Ну так прекрасно. Объекты — атомарны. Что ещё нужно?

Создатели MongoDB не фанатики

И это хорошо. А то, глядишь, у кого-то будет перекос в сторону — «все данные одного документа — в одну запись коллекции!»

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

Опять повылазили веб-макаки со своими хэш-табличками.

:)) ну похапэ же стал скучен... давайте теперь базы данных исковеркаем!

PS «Первым делом мы испортим самолёты...»

matumba ★★★★★
()
Ответ на: комментарий от yoghurt

>А в приведенном мною - элементы в items у каждого документа могут быть свои, т.е. они локальны по отношению к документу

Тогда — да. Но зачем тогда этот огород с внутренними ID? Может там задачу саму переформулировать нужно?

KRoN73 ★★★★★
()
Ответ на: комментарий от theos

>Это просто «типа крутые» программисты не видели систем где такую безсхемность строят поверх оракловских БД, т.к. обновление структуры не должно останваливать процессинг ни на секунду.

дело не в процессинге, а в ведении журнала состояний. И оракл здесь не при чем. Нельзя делать декомпозицию для данных, которые не должны автоматом менятся для всех вхождений.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

>ну и здравствуй SQL с его подселектами.

Нет, но разные объекты разных классов желательно хранить в разных коллекциях. И не встраивать внутрь одного объекта другой без особой надобности.

А SQL тут совсем не у дел. Я эту логику с любыми бэкендами практикую. И потому, кстати, от них не завишу.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>Тогда — да. Но зачем тогда этот огород с внутренними ID? Может там задачу саму переформулировать нужно?

да ничего им не нужно переформулировать. Просто есть жирные документы, которые хотелось бы получать по частям. И вроде как такая возможность есть.

AVL2 ★★★★★
()
Ответ на: комментарий от KRoN73

>Тогда — да. Но зачем тогда этот огород с внутренними ID?

Чтобы читать их выборочно по id :) Мы сильно запаривались по уменьшению передаваемых по сети данных от клиента к серверу и назад, приходилось идти вот на такие ухищрения. Мутное дело было, в общем.

yoghurt ★★★★★
()
Ответ на: комментарий от KRoN73

>Нет, но разные объекты разных классов желательно хранить в разных коллекциях.

А смысл тогда в nosql? Это его фишка - хранение разных объектов.

И не встраивать внутрь одного объекта другой без особой надобности.

В NoSQL атомарность операций есть только в рамках одного документа. Так что или встраивай или реализуй транзакции с локами etc, то есть, вернись в SQL.

А SQL тут совсем не у дел. Я эту логику с любыми бэкендами практикую. И потому, кстати, от них не завишу.

А это вообще бессмыслица. Не зависеть от бэкендов, это значит не использовать их возможности.

AVL2 ★★★★★
()
Ответ на: комментарий от KRoN73

>Ну так прекрасно. Объекты — атомарны. Что ещё нужно?

Если объект, это накладная, то да. А если объект, это шапка/подвал накладной, а отдельно десяток объектов, это строчки в этой накладной, то даже безопасно выбрать этот документ ты не сможешь.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

>А смысл тогда в nosql?

Начать можно с того, что NoSQL — это всё, что Не-SQL // Ваш К.О.

Это, например, и key-value.

Нельзя сравнивать в лоб. Смотреть нужно по задаче. И не нужно чураться реляционности только потому что это не SQL. У меня реляционность местами с plain-text'ом и то есть :D Так получается проще и удобнее.

В NoSQL атомарность операций есть только в рамках одного документа

И прекрасно. Если у нас вместо двух сущностей в одном документе — два документа с разными сущностями, то их общая атомарность и не нужна.

Не зависеть от бэкендов, это значит не использовать их возможности.

Да. Обычный разумный размен производительности на скорость написания, универсальность и надёжность. Потери смешные, выигрыш — большой.

Или ты из тех, кто пишет в машинных кодах, потому что Си++ даёт слишком большие потери в производительности? ;)

KRoN73 ★★★★★
()
Ответ на: комментарий от AVL2

>Если объект, это накладная, то да. А если объект, это шапка/подвал накладной

Тут — да. Но это достаточно частный случай.

KRoN73 ★★★★★
()
Ответ на: комментарий от AVL2

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

В монге то как раз можно, это в кауче нельзя.

EvilBlueBeaver
()
Ответ на: комментарий от KRoN73

> Ты, например, объект автора документа тоже ембеддить будешь? А если автор подпись поменяет? :)

Так наоборот же. автор - первичный документ. документы автора - вложенные в виде списка.

EvilBlueBeaver
()
Ответ на: комментарий от EvilBlueBeaver

>Так наоборот же. автор - первичный документ. документы автора - вложенные в виде списка.

Что делать, если у документа более одного автора? Дублировать документы? :)

Нет, без реляционности в таких случаях — никак.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>> Что делать, если у документа более одного автора? Дублировать документы? :)

Нет, без реляционности в таких случаях — никак.

Ну монго и не претендует на универсальность. но когда можно четко выделить документ - все ок. Кстати в случае с многими авторами и реляционная модель не шибко удобна. В реляционной модели нет связи «многие-ко-многим».

EvilBlueBeaver
()
Ответ на: комментарий от EvilBlueBeaver

>Так наоборот же. автор - первичный документ. документы автора - вложенные в виде списка.

Что есть хорошо только до того момента, пока документов не становится десяток тысяч.

anonymous
()
Ответ на: комментарий от anonymous

> Что есть хорошо только до того момента, пока документов не становится десяток тысяч.

И что плохого в этом? Места в отдельной коллекции они меньше занимать не будут. Можно делать выборку нужных документов, а можно и не делать. что не так?

EvilBlueBeaver
()
Ответ на: комментарий от EvilBlueBeaver

>И что плохого в этом? Места в отдельной коллекции они меньше занимать не будут. Можно делать выборку нужных документов, а можно и не делать. что не так?

В монге есть ограничение на размер документа. Если документы представляют собой что-то большее, чем строчку текста да id, то можно в этот размер упереться.

А в couch будут большие по объёму и медленные для генерации b-tree для view.

anonymous
()
Ответ на: комментарий от anonymous

> В монге есть ограничение на размер документа. Если документы представляют собой что-то большее, чем строчку текста да id, то можно в этот размер упереться.

А в couch будут большие по объёму и медленные для генерации b-tree для view.

Для сохранения чего-то большего, чем строчка текста или id в MongoDB есть GridFS, а в CouchDB есть attachments.

И хотел бы я на вас посмотреть, как вы большие куски текста или mp3-шечки будете хранить в mysql :)

EvilBlueBeaver
()
Ответ на: комментарий от EvilBlueBeaver

>Можно делать выборку нужных документов, а можно и не делать. что не так?

Которые вложены в документ автора в виде списка? Запрос не покажешь? :)

yoghurt ★★★★★
()
Ответ на: комментарий от AnDoR

>> нафиг эти форки, уж лучше на firebird для веба переползать, правда грустно будет без автоинкремента и большой кучи ненужных типов данных.

Пьяный, что ли?

неужели не видно, что дельфятник - они по жизни такие дремучие.

anonymous
()
Ответ на: комментарий от yoghurt

> Которые вложены в документ автора в виде списка? Запрос не покажешь? :)

Да на здоровье. Правда из своей базы.

db.players.find({_id: «1»}, {«map.tiles»: {$slice: 5}})

выбирает 5 первых тайлов изсписка тайлов, которые лежат в карте, которая представляет из себя вложенный объект.

Есть еще $elemMatch но это уже немного другое

EvilBlueBeaver
()
Ответ на: комментарий от EvilBlueBeaver

Ну, слайцы это немного не то :) Как я писал выше, выдёргивать из вложенных списков отдельные элементы по определенному условию монга, по ходу, так и не научилась.

yoghurt ★★★★★
()
Ответ на: комментарий от yoghurt

> Ну, слайцы это немного не то :) Как я писал выше, выдёргивать из вложенных списков отдельные элементы по определенному условию монга, по ходу, так и не научилась.

Ну вот лично мне такая возможность не нужна. а вот дергать данные по игроку одним простым запросом вместо кучи джойнов или кучи мелких запросов еще как нужно.

EvilBlueBeaver
()
Ответ на: комментарий от yoghurt

А для вывода тех же статей постранично слайсы отлично подходят.

EvilBlueBeaver
()
Ответ на: комментарий от EvilBlueBeaver

>Для сохранения чего-то большего, чем строчка текста или id в MongoDB есть GridFS, а в CouchDB есть attachments.

Только по содержимому аттачмента искать не получается. А документ может быть кучей разных строк и текстов, которые активно используются в поиске. Статьи, например.

И хотел бы я на вас посмотреть, как вы большие куски текста или mp3-шечки будете хранить в mysql :)

Так я это, за mysql и не агитирую, я как раз люблю nosql решения, они мне под задачи подходят:)

anonymous
()
Ответ на: комментарий от anonymous

> Только по содержимому аттачмента искать не получается. А документ может быть кучей разных строк и текстов, которые активно используются в поиске. Статьи, например.

Ну так для полнотекстового поиска используются более другие решения :)

EvilBlueBeaver
()
Ответ на: комментарий от anonymous

> А с каких это пор на уроках информатики дают рекомендации(!!!) по оформлению номеров релизов? Школоло?

Да чувак, ты - школоло.

У вас на уроках информатики изучали «Вордъ» и «Виндоузь»? Соболезную. ;)

На нормальных изучают основы computer science, программирование, общепринятые практики. Нумерация релизов относится к общепринятым практикам. И если какому-то дебилу кажется, что точка в номере релиза отделяет целую часть от дробной, то лучше бы он все же не прогуливал уроки.

rtvd ★★★★★
()
Ответ на: комментарий от anonymous

> В монге есть ограничение на размер документа.

А как же подход, что можно все запихнуть в один документ? С одной стороны радуемся, что все можно загнать в одну сущность и не делать join, а с другой молимся, чтобы не перегрузить больше допустимого? В чем фишка?

rtvd ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.