Ответ на задание 1
В реляционной базе данных товары разных категорий часто
требуют большого количества таблиц или большого числа необязательных полей.
Документная база данных позволяет хранить объекты с
различной структурой в одной коллекции.
Например, документ ноутбука:
{
"productId": 101,
"name":
"Laptop Pro",
"category": "Laptop",
"price":
450000,
"processor": "Intel Core i7",
"ram": 16,
"storage":
512
}
Документ одежды может иметь другую структуру:
{
"productId": 102,
"name":
"Winter Jacket",
"category": "Clothing",
"price":
45000,
"size":
"L",
"material": "Polyester",
"color":
"Black"
}
Оба документа могут находиться в одной коллекции, несмотря
на различный набор полей.
Это является одним из преимуществ документной модели: она
предоставляет гибкость структуры данных.
Однако это не означает, что NoSQL всегда лучше реляционной
базы. Если система содержит большое количество строго структурированных
взаимосвязанных данных и требует сложных операций JOIN, реляционная модель
может оказаться более подходящей.
Ответ на задание 2
Для добавления документа в MongoDB можно использовать
insertOne():
db.students.insertOne({
name: "Алиев
Арман",
group:
"CS-101",
email:
"arman@example.com",
age: 20
});
Для получения всех студентов группы CS-101:
db.students.find({
group:
"CS-101"
});
Для изменения электронной почты:
db.students.updateOne(
{ name:
"Алиев Арман" },
{
$set: {
email:
"arman.new@example.com"
}
}
);
Для удаления документа:
db.students.deleteOne({
name: "Алиев
Арман"
});
В реальной системе надежнее выполнять изменение и удаление
по уникальному идентификатору документа, например _id, поскольку несколько
студентов могут иметь одинаковое имя.
Основные CRUD-операции MongoDB можно представить следующим
образом:
Create → insertOne()
Read → find()
Update → updateOne()
Delete → deleteOne()
Ответ на задание 3
Для первой системы — кэширования пользовательских сессий
— подходит база данных типа ключ–значение (Key-Value).
Структура может выглядеть следующим образом:
session:87453 → {userId: 125, expires:
"..."}
Доступ к значению осуществляется по уникальному ключу.
Известным примером такой системы является Redis.
Для второй системы — хранения профилей пользователей с
различным набором характеристик — подходит документная база данных.
Например:
{
"userId":
125,
"name":
"Arman",
"skills":
["C#", "SQL", "Docker"],
"city":
"Astana"
}
Другой пользователь может иметь дополнительные или другие
поля. Примером документной СУБД является MongoDB.
Для третьей системы — анализа социальных связей —
подходит графовая база данных.
Данные представляются в виде:
(User A) ── FRIEND ──> (User B)
|
FOLLOWS
|
↓
(User C)
В графовой модели основными элементами являются вершины и
связи между ними. Такой подход удобен, когда отношения между объектами являются
важной частью задачи.
Например, графовая база может использоваться для поиска:
Таким образом, основные категории NoSQL-систем включают Key-Value,
Document, Column-Family и Graph databases, а выбор конкретной модели
зависит от структуры данных и характера выполняемых операций.