LINUX.ORG.RU

MongoDB 1.6.0

 , , ,


0

1

MongoDB — документо-ориентированная система управления базами данных (СУБД) с открытым исходным кодом, не требующая описания схемы таблиц. Написана на языке C++.

Шардинг

Шардинг готов для использования в производстве, давая возможность масштабировать MongoDB горизонтально. При необходимости единственный экземпляр mongod может быть преобразован в распределённый кластер с нулевым временем простоя.

Replica Sets

Replica sets — новый метод репликации, который предоставляет возможность автоматически переключаться среди участников кластера.

Replica pairs объявлен устаревшим; использующим данный функционал рекомендуется перейти на использование replica sets.

Другие улучшения

  • Опция w (и wtimeout) форсирует запись на n серверов до успешного завершения операции (особенно хорошо работает с replica sets)
  • $or-запросы
  • Улучшенная многопоточность
  • $slice-оператор для возвращения части массива (подмассива)
  • 64 индекса на каждую коллекцию (в 1.4 было 40)
  • 64-битные целые могут быть представлены в командной оболочке посредством NumberLong
  • Команда findAndModify теперь поддерживает upserts (аналог SQL MERGE). Также теперь позволяется указывать поле, которое должно быть получено
  • $showDiskLoc — опция для отображения местонахождения документа на диске
  • Поддержка IPv6 и доменных сокетов UNIX
  • C++ клиент отделён от бинарного пакета

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

★★

Проверено: catap ()

Ответ на: комментарий от tailgunner

>Вопрос был «причем здесь ZODB?».

ZODB - Zope Object Database. Объекты и документы это не? Не одно и тоже в контексте скажем форума?

В принципе все тоже самое. Нет map-reduce. Да. Есть словари по которым можно искать, хоть map-reduce делай.

Я к тому, что 10 лет народ использует, а тут столько шума. И да SQL там нет, хотя можно и сделать.

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

> Объекты и документы это не?

По-моему, не. Хотя, конечно, зависит от того, что именно СУБД знает о хранимых объектах.

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

Ну объект это данные + всевозможные манипуляции над ними. Документ это данные (структурированные record или struct).

СУБД знает только 1) Что за поля в рекорде и 2) Какие методы есть.

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

Ах да есть некоторые ограничения по типам того что может хранится тут или там:

class IMark(Interface):
«„„This is the book mark object.““»

url = TextLine(
title=u"URL/Link",
description=u"URL of the website",
default=u"http://www.zope.org",
required=True)

description = Text(
title=u"Description",
description=u"Description of the website",
default=u"",
required=False)

class IBookMarker(IContainer):
«„„This is the container for all book marks.““»

name = TextLine(
title=u"Name of BookMarker",
description=u"A name for BookMarker",
default=u"",
required=True)

def __setitem__(name, obj):
pass

__setitem__.precondition = ItemTypePrecondition(IMark)


class IMarkContained(IContained):
«„„A book mark can only contain in a BookMarker““»

__parent__ = Field(
constraint = ContainerTypesConstraint(IBookMarker))

вот вам внешняя ссылка и ограничение на тип.

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

> СУБД знает только 1) Что за поля в рекорде и 2) Какие методы есть.

вот вам внешняя ссылка и ограничение на тип.

Насколько я понял, в NoSQL нет ни того, ни другого. СУБД никак вообще не понимает структуру документа.

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

>Насколько я понял, в NoSQL нет ни того, ни другого. СУБД никак вообще не понимает структуру документа.

Ни фига себе сказку подсократили.

А как искать по конкретному полю в документе, не понимая структуру? Индексы там строить, на уникальность проверять?

в монго специально используют bson, чтобы быстро бегать по структуре документа.

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

В Mongodb это не так. Структура у экземпляров коллекции есть. Правда создаётся она динамически. Документы одной коллекции могут отличаться. Конечно нет практического смысла хранить в одной коллекции документы не имеющие общих атрибутов, но СУБД это не запрещает. Поиск может производится по любым атрибутам. Жаль, что права доступа к атрибутам документа, его субобъектам и массивам раздавать нельзя.

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

В Zope есть права. Через адаптеры можно делать вьюшки. Так, что.....

Я подозреваю это снова Америку открыли. Документные СУБД. Ок, Смотрим FramerD. Марвин Мински это в 70-х еще развивал. Фрейм состоит из слотов (1 и более).

Например фрейм содержащий информацию о человеке:

Фрейм:
Имя: Иван
Фамилия: Иванов
Отчестов: Иванович

Есть так называемые протофреймы. Это схемы собственно говоря. Тоесть фреймы описывающие человека произошли от протофрейма - «схема человека» (всё условно).

Значением слота может быть ссылка на другой фрейм.

Характеристики СУБД FramerD: Размер дистрибутива СУБД меньше 1mb (когда я смотрел было около 800 кб). 64 битная адресация ограничивает размер базы помоему в 4 террабайта. Несколько машин легко объединяются в кластеры. Запросы на Shceme.

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

В ZODB - тормоза. Судя по отзывам скорость вставки записей 70 зап./сек
В Firebird 12000 зап./сек
В MongoDB 49000 зап./сек

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

И ты учти в ZODB объект это 1500 полей, + логика если надо. А на примере простых кортежей это, да MySQL силен.

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

>> Насколько я понял, в NoSQL нет ни того, ни другого. СУБД никак вообще не понимает структуру документа.

А как искать по конкретному полю в документе, не понимая структуру? Индексы там строить, на уникальность проверять?

Я сказал «СУБД никак не понимает структуру документа». Здесь возражения есть?

Повторяю еще раз для анонимного брата - СУБД не знает. То, что структуру документа знает приложение, как бы очевидно.

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

Я понимаю, что однобоко. Думаю это говорит о значительных архитектурных недоработках. Скорость просто невероятно низкая. Сооетветственно сильно сужается сфера применения ZODB.

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

>Я сказал «СУБД никак не понимает структуру документа». Здесь возражения есть?

Возражения есть.

Постороение индекса для сортировки по полям документа:

db.factories.ensureIndex( { «metro.city» : 1, «metro.state» : 1 } );

// these queries can use the above index:

db.factories.find( { «metro.city» : «New York», «metro.state» : «NY» } );

db.factories.find( { «metro.city» : «New York» } );

db.factories.find().sort( { «metro.city» : 1, «metro.state» : 1 } );

db.factories.find().sort( { «metro.city» : 1 } )

Проверка на уникальность.

db.things.ensureIndex({firstname: 1, lastname: 1}, {unique: true});

db.things.ensureIndex({firstname: 1}, {unique: true});

db.things.save({lastname: «Smith»});

// Next operation will fail because of the unique index on firstname.

db.things.save({lastname: «Jones»});

Все это делается на сервере.

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

Я сказал «СУБД никак не понимает структуру документа». Здесь возражения есть?


Есть. Без знания структуры (атрибутов документа) СУБД не сможет построить индексы. Название коллекций это тоже часть структуры.

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

У меня с вами время ответа второй раз за день до секунды совпадает.

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

Скорость выбоки данных (Выбранные данные пишутся перенаправлением вывода в файл):

Firebird
milliseconds: 7197 records per second: 112171

MongoDB
milliseconds: 4681 records per second: 196299

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

>>Я сказал «СУБД никак не понимает структуру документа». Здесь возражения есть?

Возражения есть.

Постороение индекса для сортировки по полям документа:

db.factories.ensureIndex( { «metro.city» : 1, «metro.state» : 1 } );

То есть единственное, что СУБД знает о документе - это то, что он JSON-коллекция?

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

Нет. Документ не JSON коллекция. Коллекция это набор JSON документов.
Mongodb знает атрибуты документов (экземпляров коллекций) и может их индексировать.

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

>То есть единственное, что СУБД знает о документе - это то, что он JSON-коллекция?

Нет. Именно поэтому там и не json, а его бинарная версия с , что СУБД не просто хранит пару - ключ <-> json документ с тремя операциями выборка, удаление и сохранение документа по ключу, а смотрит внутрь документа и оперирует его составляющими.

Поиск, сортировка, выбор, обновление полей - все есть.

select ssn from users where last_name=«Smith»;

db.users.find({last_name: 'Smith'}, {'ssn': 1});

http://www.mongodb.org/display/DOCS/Advanced+Queries

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

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

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

А как он будет гарантировать уникальность элементов если база - распределенная и ограничения по уникальности не связаны?

Пример:

db.things.ensureIndex({foo: 1}, {unique: true});

db.things.ensureIndex({bar: 1}, {unique: true});

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

> http://www.mongodb.org/display/DOCS/Advanced+Queries

Чем больше я читаю доки по этой MongoDB, тем сильнее ощущение безжалостного велосипедостроительства. И призраки IMS, CODASYL и ранних реляционных языков запросов с косами стоят...

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

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

не понимаю, в чем тут разница с любой другой СУБД?

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

>Чем больше я читаю доки по этой MongoDB, тем сильнее ощущение безжалостного велосипедостроительства. И призраки IMS, CODASYL и ранних реляционных языков запросов с косами стоят...

Если речь идет об отказе от функционально полного и бесконечного синтаксиса SQL в пользу отрывочных объекто-ориентированных подпорок, то это больше похоже на откат к risc-процессорам.

И причины имхо схожи. Запросы sql, особенно с вложенными подзапросами могут быть сколь угодно сложны, а значит бесконечно трудоемки, а ведь каждый запрос должен быть атомарен, то есть потенциально базу можно легко поставить на колени. В оже время 99% запросов, это простейшие селекты да инсерты, которые гораздо удобней описывать объектом.

Так что это не вилосипед, а объективный процесс оптимизации и баланса между удобством и производительностью.

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

> Вопрос в распределенности базы (в необходимости опрашивать все узлы?) или в том, что ограничения по уникальности не связаны?

не понимаю, в чем тут разница с любой другой СУБД?

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

Интересно, как в MongoDB решается вопрос о том, уникальная ли запись или нет. Могу предположить, что узел, на которых пришел запрос, сначала шлет другим узлам уведомление, что есть желание добавить новую запись. И если никто не против - добавляет запись и снова шлет уведомление (теперь уже о том, что объект добавлен).

Так оно работает?

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

Надо сказать, что индексы тут не при чем. В любом случае, в коллекции документов создается ключ _id и он должен быть уникален.

Интересно, как в MongoDB решается вопрос о том, уникальная ли запись или нет. Могу предположить, что узел, на которых пришел запрос, сначала шлет другим узлам уведомление, что есть желание добавить новую запись. И если никто не против - добавляет запись и снова шлет уведомление (теперь уже о том, что объект добавлен).

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

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

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

AVL2 ★★★★★ ()

Вышел CouchDB SDK для Google Android. Подразделение Palm (Hewlett Packard) заявило что внедрит CouchDB в свой webOS. Другие истории успеха: Ubuntu, BBC, .... Новая база набирает обороты.

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

> Запросы sql, особенно с вложенными подзапросами могут быть сколь угодно сложны, а значит бесконечно трудоемки, а ведь каждый запрос должен быть атомарен, то есть потенциально базу можно легко поставить на колени.

И решить проблему предлагается выполнением JS на стороне сервера... гениально.

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

> кстати, сабж еще к тому же объявлен, как знающий, как оперировать пространственными данными.

У сабжа земля плоская :) . Правда, кроме пингвинов, полярных медведей и пилотов ядерных ракет это мало кого волнует.

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

>Вышел CouchDB SDK для Google Android.

Круто.

А кто-ниюудь знает, как там view отображать через show?

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

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

Да так и есть, потому и вопрос.

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

Если только мастер-узел выполняет запрос, то тогда он - узкое место. Куда делось масштабирование? Или оно распространяется только на чтение?

К тому же, что если база действительно большая, и на один узел не помещается? Делать шардинг? ОК, см. ниже..

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

Это все хорошо тогда, когда происходит чтение.

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

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

>Если только мастер-узел выполняет запрос, то тогда он - узкое место. Куда делось масштабирование? Или оно распространяется только на чтение?

Репликация не регает вопросы масштабирования производительности. Она решает вопросы резервирования данных. И доступности.

Это все хорошо тогда, когда происходит чтение.

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

да тоже самое. Индексы на мастере, он и решает.

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