На днях вышел новый стабильный релиз mongodb. В этой версии был добавлен ряд нововведений таких как новый GUI для визуальной работы с mongodb, INNER JOIN, валидация документа и т.д. некоторые из этих свойств мы и рассмотрим на небольших примерах ниже.
Частичный (partial) индекс
MongoDB 3.2 предоставляет возможность создавать индексы только для тех документов коллекции, которые которые будут соответствовать указанному фильтру. Индексация только части нужных документов в коллекции, имеет ряд плюсов, таких как более низкие требования к хранению, и снижение затрат на производительность, для создания и поддержания индекса. Вы можете указать опцию partialFilterExpression для всех типов индекса MongoDB.
Для создания частичного индекса используется метод db.collection.createIndex() с новой опцией partialFilterExpression. В следующем примере создадим составной индекс, который будет индексировать только те документы, у которых рейтинг больше 5.
Частичный индекс предоставляет больший набор возможностей, чем разреженный индекс и поэтому является более предпочтительным. Частичный индекс, предлагает более выразительный механизм, для указания какие документы лучше индексировать. Разреженные индексы выбирают документы для индексации исключительно на основании наличия индексированного поля. Пример поведения разреженного индекса с помощью частичного индекса:
Рассмотрим еще один пример с частичным индексом, тут поле по которому будет проводиться индексирование name, а поле, по которому будут отфильтрованы документы, другое:
В mongodb нельзя создавать несколько версий индекса, отличающихся только параметрами. Нельзя создавать много частичных индексов, которые отличаются только параметрами фильтра. В более ранних версиях mongodb не поддерживались частичные индексы. Все sharded кластеры, наборы реплик и все узлы должны работать на mongodb 3.2. _id индекс не может быть частичным индексом. Ключ также шарда не может быть частичным индексом.
Рассмотрим коллекцию restaurants, содержащую следующие документы и выглядящие таким образом:
Начиная с версии 3.2, mongodb, предоставляет возможность проверки документов в процессе обновления и вставки. Правила валидации задаются при явном создании коллекции с помощью опции validator, либо с помощью команды collMod для уже существующей коллекции. Опция validator принимает документ, который соответствует определённым выражениям, за исключением $geoNear, $near, $nearSphere, $text и $where.
Рассмотрим следующий пример создания валидации при создании коллекции contacts:
MongoDB также предоставляет опцию validationLevel, которая определяет, насколько строго MongoDB применяет правила валидации, для существующих документов во время их обновления, и опция validationAction, которая определяет, должен ли mongodb отклонить документы, которые нарушают правила проверки.
Поведение
Валидация происходит во время обновления и вставки документов. При добавлении валидации в коллекцию, уже существующие документы остаются не модифицируются.
Существующие документы
Можно контролировать как mongodb обрабатывает существующие документы используя опцию validationLevel. По умолчанию, validationLevel является strict, и mongodb применяет правила проверки для всех вставок и обновлений. Если validationLevel установлен как moderate, то тогда правила валидации при вставке и обновлении документов, применяются только к документам, которые полностью соответствуют критериям валидации.
Рассмотрим следующие документы в коллекции contacts:
Теперь в коллекции contacts есть валидатор. И теперь если мы будем обновлять документ с {_id: 125876}, mongodb будет применять правила валидации, поскольку существующий документ соответствует критериям. А для документа { _id:860000 }, mongodb не применит правила валидации на обновления, так как документ не соответствует правилу проверки. Если нам нужно отключить валидацию, мы можем установить опцию validationLevel как off.
Принять или отклонить бракованные документы
В опции validationAction, определяется как поступить с документами которые нарушили правила валидации. По умолчанию validationAction, выставлен как error и MongoDB отклоняет любые вставки и обновления документов, если есть нарушение правила проверки. Когда validationAction установлен как warn, MongoDB журналирует документы, но позволяет выполнять вставки и обновления.
В следующем примере создается коллекция contacts с валидатором, указывающим, что вставленные или обновленные документы должны соответствовать по крайней мере одному из трех следующих условий:
поле phone должно быть строкой
поле email должно проверятся регулярным выражением на соответствие
поле status должно быть либо Unknown либо Incomplete.
Следующий инсерт должен привести к сбою, но, поскольку, правило валидации validationAction установлено как warn, то операция записи запишет в журнал и выполнится успешно.
2015-10-15T11:20:44.260-0400 W STORAGE [conn3] Document would fail validation collection: example.contacts doc: { _id: ObjectId('561fc44c067a5d85b96274e4'), name: "Amanda", status: "Updated" }
Ограничения
Нельзя назначать валидацию для коллекций admin, local. И нельзя указать валидатор для коллекций system.*
Нововведения агрегационного фреймворка и INNER JOIN
$lookup — связывание нескольких коллекций. Хоть этот оператор и назвали свой inner join для mongodb мне все-таки кажется, что этот вопрос немного шире, и его надо рассматривать в контексте связывания разных типов документов, а не коллекций. Я описывал этот вопрос довольно подробно тут. Сам $lookup имеет следующий синтаксис:
{
$lookup:
{
from: <коллекция для связывания>,
localField: <поле из входящий документов>,
foreignField: <поле из документов из другой коллекции>,
as: <исходящий массив>
}
}
В примере у нас есть две коллекции: Коллекция orders в которой находятся следующие документы:
Следующая агрегационная операция, для коллекции orders, свяжет документы из orders, с документами из коллекции inventory, используя поле item из orders и поле sku из inventory:
В PostgreSQL 9.5, который вот-вот должен выйти, тоже появилась похожая возможность.
$indexStats — возвращает статистику использования каждого индекса. Возвращает статистику использования каждого индекса для коллекции. Если запущена с контролем доступа, пользователь должен иметь привилегии, которые включают indexStats.
Синтаксис:
{ $indexStats: { } }
Для примера возьмем коллекцию orders, содержащую следующие документы:
$stdDevSamp — вычисляет стандартное отклонение выборки входных значений. Доступен из $group и $project, игнорирует не цифровые значения и, если такое передано, возвращает null. Для примера возьмем коллекцию users:
Чтобы рассчитать стандартное отклонение случайной выборки пользователей, сначала используем оператор $sample для выборки 100 пользователей, и тогда используем $stdDevSamp для калькуляции.
$isArray — определяет, является ли операнд является массивом. Синтаксис { $isArray: [ ] } В примере есть коллекция warehouses содержащая следующие документы:
В mongodb 3.2, оператор $project, стал поддерживать использование квадратных скобок [], чтобы непосредственно создавать новый массив из полей. В примере есть документ:
Для согласования с CRUD (Create/Read/Update/Delete) API драйверов, для mongo shell были добавлены дополнительные методы.
db.collection.bulkWrite() — Выполняет несколько операций записи, с элементами управления для порядка исполнения. Следующий код, представляет собой неупорядоченный bulkWrite(), из шести операций:
С ordered : false, результаты работы могут отличаться. Например, deleteOne или deleteMany может удалить больше или меньше документов в зависимости от порядка расположения операций insertOne, updateOne, updateMany или replaceOne.
db.collection.deleteMany() — эквивалент db.collection.remove(). db.collection.deleteOne() — эквивалент db.collection.remove(), но с justOne установленным как true Например — db.collection.remove( , true ) или db.collection.remove( , { justOne: true } ). db.collection.findOneAndDelete() — эквивалент db.collection.findAndModify(), но с remove установленным как true. db.collection.findOneAndReplace() — эквивалент db.collection.findAndModify(). db.collection.findOneAndUpdate() — эквивалент db.collection.findAndModify(), но с установленными для update атомарными операторами. db.collection.insertMany() — эквивалент db.collection.insert() с массивом документов в качестве параметра. db.collection.insertOne() — эквивалент db.collection.insert() в качестве параметра один документ. db.collection.replaceOne() — эквивалент метода db.collection.update( , ) для обновления документа как параметра для . db.collection.updateMany() — эквивалент db.collection.update( , , { multi: true, ... }) с использованием опции multi установленной как true. db.collection.updateOne() — эквивалент db.collection.update( , )
WiredTiger и fsyncLock
Начиная с MongoDB 3.2, хранилище WiredTiger поддерживает команду fsync с опцией lock или метода mongo shell db.fsyncLock(). То есть, для хранилища WiredTiger, эти операции могут гарантировать, что файлы данных не изменятся, обеспечивая согласованность в при создании резервных копий. Также в этой версии WiredTiger является хранилищем по умолчанию.
Новое GUI compass
В новом Mongodb, впервые, от разработчиков появилось GUI причем не не одно. Начнем с MongoDB Compass. После первого анонса когда кроме картинки еще ничего не было я подумал что compass скорее всего будет c web интерфейсом. Моей первой nosql базой был couchdb и тогда мне очень нравился futon.
Но оказалось что compass, является обычной десктопной программой, и к сожалению только под Mac OS и Windows. И насколько я понял без возможности редактирования, а только с возможностью просмотра документов, и с возможностью делать запросы.
Итак, чтоб локально немного поиграться с этим GUI поставим под Windows mongoDB и немного настроим, чтобы все заработало: Скачиваем, при установке лучше выбирать «вручную» и указать место для установки C:\mongodb. После этого запустим от имени администратора консоль и создадим несколько папок:
mkdir c:\data\db
mkdir c:\data\log
А потом создав в каталоге с установкой C:\mongodb\mongod.cfg файлик впишем там пару строчек:
В принципе, всё. Но у меня не получилось приконнектиться к базе пока я не запустил в консоли клиент к монго, c:\mongodb\mongo.exe
После этого скачиваем по ссылке сам compass, там надо символически заполнить пару полей и устанавливаем. После этого запускаем и видим окошко приветствия: Если все удачно то коннектимся и в открывшемся окне, видим слева список коллекций и баз, по центру визуальное представление документов находящихся в выделенной коллекции. Представление предназначено исключительно для составления запросов, кои сверху в строке видны.
Ну, а справа, в колонке, если её открыть с помощью специальной стрелочки (наверное, единственная полезная штука) эти самые документы в виде json.
В целом, общие впечатления такие, что GUI это скорее имиджевый ход, чем несущий какую-то реальную пользу сообществу.
P.S. Просьба о грамматических ошибках и ошибках перевода писать в личку.
Установка mongodb под windows Справка по compass Скачать mongodb compass
Документация по новым свойствам Частичный индекс Валидация документов