MongoDB 1.6.0

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

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

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

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

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

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

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

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

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

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))

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4TB Это без учета размера самих данных в слотах.

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

А почему так кособоко? Только вставка. http://zope3.ru/stati/testiruem-zodb-na-skorost

У меня девочки колотят куда меньше, чем менеджеры считают отчеты.

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

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

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

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

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

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

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

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

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

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»});

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

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

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

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

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

Firebird
milliseconds: 7197 records per second: 112171

MongoDB
milliseconds: 4681 records per second: 196299

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

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

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

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

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

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

>То есть единственное, что СУБД знает о документе - это то, что он 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

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

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

http://www.mongodb.org/display/DOCS/Geospatial+Indexing

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

Пример:

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

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

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

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

Map != структура.

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

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

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

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

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

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

>Map != структура.

Что хотел сказать?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Круто.

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

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

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

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

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

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

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

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

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

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

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

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

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

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