Статьи

Понимание документов на основе MongoDB NoSQL

Сентябрь 27, 2018

Введение: MongoDb NoSQL

В этой статье рассматриваются различные аспекты RDBMS и то, где RDBMS преодолевает препятствия в корпоративном мире. В этой статье также рассказывается о том, как мы можем преодолеть эти препятствия, ослабив некоторые ключевые аспекты СУРБД. В нем также говорится о том, как решение на основе NoSQL вписывается в это и как популярное решение MongoDb NoSQL .

СУБД, связанные с масштабируемостью, производительностью и гибкостью предприятия

СУРБД развились из сильных корней в математике, таких как теории отношений и множеств. Некоторые из аспектов — проверка схемы, нормализованные данные, чтобы избежать дублирования, атомарность, блокировка, параллелизм, высокая доступность и одна версия правды .

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

Учтите, что нам нужно хранить огромное количество заказов на покупку, и мы начали разделять , один из способов разделения состоит в том, чтобы иметь таблицу OrderHeader в одном экземпляре Db и информацию LineItem в другом. А если вы хотите вставить или обновить информацию о заказе, вам необходимо обновить обе таблицы атомарно, и вам нужен менеджер транзакций для обеспечения атомарности. Если вы хотите увеличить масштаб в плане обработки и хранения данных, вы можете только увеличить пространство на жестком диске и объем оперативной памяти.

Самый простой способ достичь масштабирования в RDBMS — это вертикальное масштабирование

MongoDb NoSQL

Давайте рассмотрим другую ситуацию: из-за изменений в нашем бизнесе мы добавили новый столбец в таблицу LineItem под названием LineDesc. И представьте, что это приложение было запущено в производство. После того, как мы развернем это изменение, нам нужно будет отключить сервер и на некоторое время вступить в силу.

Достижение масштабируемости, производительности и гибкости предприятия

Основными требованиями современных корпоративных систем являются:

  1. Гибкие возможности в плане масштабирования базы данных, чтобы несколько экземпляров базы данных могли обрабатывать информацию параллельно
  2. Гибкость в плане изменений в базе данных может быть поглощена без длительных простоев сервера
  3. Уровень приложения / средний уровень не обрабатывает несоответствие объектно-реляционного импеданса. Можем ли мы справиться с этим, используя такие методы, как JSON?

Давайте вернемся к нашему примеру PurchaseOrder и ослабим некоторые аспекты СУБД, такие как нормализация (избегание объединений множества строк), атомарность и посмотрим, сможем ли мы достичь некоторых из вышеуказанных целей.

Ниже приведен пример того, как мы можем хранить PurchaseOrder (есть и другой лучший способ хранения информации).

orderheader:{
orderdescription: “Krishna’s Orders”
date:"Sat Jul 24 2010 19:47:11 GMT-0700(PDT)",
lineitems:[
{linename:"pendrive", quantity:"5"}, {linename:"harddisk", quantity:"10"}
]
}

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

Вы можете хранить их как коллекцию объектов / документов. Гипотетически, если нам нужно хранить несколько миллионов BuyOrders, мы можем разделить их на группы и хранить в нескольких экземплярах.

Если вы хотите получить PurchaseOrders на основе определенных критериев, например, всех заказов на поставку, в которых одна из позиций является «pendrive», мы можем попросить все отдельные экземпляры извлечь «параллельно» на основе тех же критериев и одного из них можно консолидировать список и вернуть информацию клиенту. Это концепция горизонтального масштабирования

MongoDb NoSQL

Поскольку отдельной схемы Table не существует, а определение схемы включено в объект JSON, мы можем изменять структуру документа, а также сохранять и извлекать данные, просто изменяя уровень приложения. Это не требует перезагрузки базы данных.

Наконец, структура объекта — JSON, мы можем напрямую представить ее веб-уровню или мобильному устройству, и они будут отображать его.

NoSQL — это классификация базы данных, которая разработана с учетом вышеупомянутых аспектов.

MongoDb: NoSQL на основе документов

База данных MongoDb NoSQL основана на документах, что является одним из перечисленных методов для хранения и извлечения данных. Существует несколько баз данных NoSQL, которые имеют значение упорядоченного ключа, например Redis , Cassandra,  которые также используют эти подходы, но намного проще.

Если вам нужно привести аналогию с RDBMS, то коллекции в MongoDb похожи на таблицы, а документы похожи на строки. Внутри MongoDb хранит информацию в виде двоичных сериализуемых JSON-объектов, называемых BSON . MongoDb поддерживает синтаксис запросов в стиле JavaScript для извлечения объектов BSON.

MongoDb NoSQL

Типичные документы выглядят как ниже,

post={
author:“Hergé”,
date:new Date(),
text:“Destination Moon”,
tags:[“comic”,“adventure”] }

> db.post.save(post)

------------

>db.posts.find()  {

_id:ObjectId(" 4c4ba5c0672c685e5e8aabf3"),
author:"Hergé",
date:"Sat Jul 24 2010 19:47:11 GMT-0700(PDT)",
text:"Destination Moon",
tags:["comic","adventure"]
}

В MongoDb атомарность гарантируется в документе. Если вам необходимо добиться атомарности за пределами документа, им нужно управлять на уровне приложения. Ниже приведен пример,

Много ко многим:

products:{
_id:ObjectId("10"),
name:"DestinationMoon",
category_ids:[ObjectId("20"),ObjectId("30”)]}
categories:{
_id:ObjectId("20"),
name:"adventure"}

//All products for a given category

>db.products.find({category_ids:ObjectId("20")})

//All categories for a given product
product=db.products.find(_id:some_id)

>db.categories.find({

_id:{$in:product.category_ids}
})

[feedly mini]

В типичном стеке, в котором используется MongoDb, имеет смысл использовать среду на основе JavaScript. Хороший веб-фреймворк, мы используем Express / Node.js / MongoDb stack. Хороший пример того, как использовать этот стек, здесь .

MongoDb NoSQL также поддерживает шардинг, который поддерживает параллельную обработку / горизонтальное масштабирование. Для получения дополнительной информации о том, как типичная BigData обрабатывает параллельную обработку / горизонтальное масштабирование, см . Ссылку Рикли Хо

Типичные сценарии использования MongoDb включают: ведение журнала событий, аналитика в реальном времени, управление контентом, электронная коммерция. Случаи использования, когда это не очень подходит, — Банковская система транзакций, Хранилище данных не в реальном времени.

Рекомендации:

 

36
Share: