Рост популярности NoSQL - одно из важнейших изменений технологий управления данными. За счет "не реляционности" достигается высочайшая гибкость, скорость работы и масштабируемость БД. NoSQL не исключает использование реляционных БД, обе технологии с пользой дополняют друг друга. Как можно моделировать NoSQL данные, не имеющие жестких схем, и какую пользу можно получить в результате. Слайды с вебинара Embarcadero. На русском языке

1. МОДЕЛИРОВАНИЕ ДЛЯ NOSQL БД
Кросс-платформенные инструменты для работы с БД
Андрей Совцов
Embarcadero,Москва
email: Andrew.sovtsov@embarcadero.com

2. Embarcadero Technologies
• Основана в 1993
• 3.2 M пользователей - 97% из списка Fortune 2000
• 35+ Наград продуктов за постоянные инновации

3. Темы
1. NoSQL и Реляционные БД
2. NoSQL БД проектируется не так, как
реляционная. Особенности
3. Инструменты для проектирования и
моделирования
4. Моделирование – полезно!
5. Разные схемы драматически влияют на
производительность

4. Что требуется от хранилища данных?
• Удобная для решения моих задач структура
данных
• Скорость и возможность масштабирования
(верт. и гор. )
• Богатые и удобные средства доступа и
разработки приложений

5. Что означает «масштабирование»?
• Перенос обработки как можно ближе к
данным
• Массивно-параллельная обработка
• Использование более дешевого,
стандартного оборудования, но в больших
количествах
• Оптимизация для:
запросов / чтения / вопросов / аналитики

7. NoSQL – не только SQL

8. - это?..
• Самая популярная NoSQL СУБД (на 4 месте в
общем списке)
• Тип NoSQL: Документ-ориентированная СУБД
• Документы представляются как Name/Value
пары в формате BSON
• Binary представление JSON (с минимальными отличиями)
• Встроенные документы и массивы снижают
потребность в операциях join
• Гибкие схемы – для хранения
неструктурированных и комплексных данных
• Легко масштабируется
• Простая установка, open source, free
User
• Name
• Email
Address
Article
• Name
• Slug
• Publish date
• Text
• Author
Tag[]
• Value
Comment[]
• Comment
• Date
• Author
Category[]
• Value
В базе данных MongoDB хранятся
документы

9. MongoDB
Горизонтальная масштабируемость
{ author : “steve”,
date : new Date(),
text : “About MongoDB...”,
tags : [“tech”, “database”]}
Хранит
документы
Приложение
Высокая
производительность
Целостные
данные

10. Богатые возможности
• Богатый язык запросов (полный CRUD)
• GeoSpatial – географические запросы
• Текстовый поиск
• Гибкие схемы
• Aggregation и MapReduce
• GridFS (distributed & replicated file storage для больших
объектов)
• Интеграция с Hadoop, Storm, Solr и т.п.
Автоматическая репликация
данных
Горизонтальное масштабирование

11. Schema для записи/ Schema на чтение
Schema для записи(RDBMS)
Директивное моделирование данных:
• Создать схему БД
• Загрузить данные в формате RDBMS
• Запросы к данным в формате RDBMS
Новые колонки должны быть добавлены ДО
ТОГО, как новые данные будут помещены в
систему.
Хорошо для Known Unknowns
(повторяемости)
Schema на чтение(Hadoop/NoSQL)
Описательное моделирование данных:
• Собрать данные в натуральном формате
• Создать схему
• Запросы к данным в натуральном
формате
Новые данные могут появляться в любое
время и появляться задним числом если
схема правильно описывает их
Хорошо для Unknown Unknowns
(исследования)

12. Терминология MongoDB
RDBMS MongoDB
Catalog / Database Database
Table Collection
Record JSON document
SQL CRUD = Insert, Find, Update,
Delete, и т.п. Аргументы в
формате JSON.
SELECT (joins,
nested SELECT’s,
etc)
Single collection Find (no
joins)
Transaction / ACID Single document / ACID
Foreign key --

13. Устройство MongoDB. Documents. Чтение.
db.Restaurants.Find({})
db.Restaurants.Find({“address.street:”: “2 Avenue”})
• Гибкий язык запросов в формате JSON-document, включающий
разделы:
– Projection – список выдаваемых полей (как список SELECT)
– Match – критерии отбора (аналог WHERE)
– Sort – критерии сортировки (аналог ORDER BY)
• Операции join отсутствуют
• Возвращает cursor с отобранными JSON-документами

15. Хранение медицинских данных (историй больных)
• Hospitals
– Работают доктора
• Doktors
– Лечат пациентов
– Выполняют процедуры
– Работают в больнице
• Patients
– Лечатся у доктора
– Принимают процедуры
• Procedures
– Назначаются пациентам
– Выполняются доктором
– Записываются в журнал
– Различные метрики
• Records
– Относятся к процедурам
– Сложные данные
– Переменное число полей

16. Реляционное решение

17. Реляционная модель данных
• Запросы по любому полю
• Замена по месту
• Универсальная для всех запросов и операций
• Табличное, «плоское» хранение
• Сложные нормализованные, «жесткие» схемы
• Каждое поле содержит единственное значение
строго определенного типа
• Нормализация приводит к необходимости
операций JOIN «мелких» таблиц
• Поддержка межтабличных транзакций на
уровне СУБД

18. Rich Documents : сложные и гибкие структуры данных
{
first_name: ‘Paul’,
surname: ‘Miller’,
cell: ‘+447557505611’
city: ‘London’,
location: [45.123,47.232],
Profession: [banking, finance, trader],
cars: [
{ model: ‘Bentley’,
year: 1973,
value: 100000, … },
{ model: ‘Rolls Royce’,
year: 1965,
value: 330000, … }
]
}
Fields can contain an array of sub-documents
Fields
Typed field values
Fields can contain
arrays

19. Документальная модель данных
• «Представляем» данные больше на уровне важнейших сущностей
(верхнего уровня)
• Учитываем как они будут представлены в физической БД
• Можно применять агрегирование информации
Преимущества ‘Rich Documents’
• E-commerce (например, Magento): много «движущихся» частей в
БД. Сложно что-то изменить – нужно «тронуть» слишком многое
• Реализация на MongoDB: весь Purchase Order целиком содержится
в одном документе – все изменения затрагивают только это
документ

20. Критерии проектирования схемы документальной БД
• Предполагаемые схемы доступа к данным:
• CRUD
• Как мы обрабатываем эти данные?
– Динамические запросы
– Вторичные индексы
– Атомарные изменения
– Использование Map Reduce
• % Read/Write
• Типы Update – модификации
данных
• Типы важнейших и наиболее
частых запросов
• Жизненный цикл данных
Главное правило
Проектируйте документы для
конкретных приложений

21. Моделирование отношений
• В документной модели отсутствуют операции JOIN. Реализуются в
приложениях
• «Отношения» отражают связи в реальном мире
• Существует несколько способов реализации отношений в
документной модели данных
• Выбор зависит от самих данных и приложений
• Шаблоны:
– 1:1
– 1:M
– M:N

22. Ссылки
Procedure
{
"_id" : 333,
"date" : "2003-02-09T05:00:00"),
"hospital" : “County Hills”,
"patient" : “John Doe”,
"physician" : “Stephen Smith”,
"type" : ”Chest X-ray",
”result" : 134
}
Results
{
“_id” : 134
"type" : "txt",
"size" : NumberInt(12),
"content" : {
value1: 343,
value2: “abc”,
…
}
}
• Используются две разные коллекции и ссылка
• Аналогично реляционной модели
В MongoDB нет
многодокументных
транзакций. Реализуются
в приложении

23. Вложенный документ
Procedure
{
"_id" : 333,
"date" : "2003-02-09T05:00:00"),
"hospital" : “County Hills”,
"patient" : “John Doe”,
"physician" : “Stephen Smith”,
"type" : ”Chest X-ray",
”result" : {
"type" : "txt",
"size" : NumberInt(12),
"content" : {
value1: 343,
value2: “abc”,
…
}
}
}
Advantages
• Доступковсейинформациизаодинзапрос
• НенужнореализовыватьJOINитранзакциив
приложении
• Атомарнаямодификациядокумента
• Недостатки
• Вбольшихдокументахвыдаетсямноголишних
полейиданных
• Размердокументаограничен16MB

24. Атомарные операции
• Операции с документами - атомарны
db.patients.update({_id: 12345},
{$inc : {numProcedures : 1},
$push : {procedures : “proc123”},
$set : {addr.state : “TX”}})
• Нет поддержки транзакций с несколькими документами
db.beginTransaction();
db.patients.update({_id: 12345}, …);
db.procedure.insert({_id: “proc123”, …});
db.records.insert({_id: “rec123”, …});
db.endTransaction();

25. {
_id: 2,
first: “Joe”,
last: “Patient”,
addr: { …},
procedures: [
{
id: 12345,
date: 2015-02-15,
type: “Cat scan”,
…},
{
id: 12346,
date: 2015-02-15,
type: “blood test”,
…}]
}
Patients
Вложенность
2 способа реализации отношений 1:M
{
_id: 2,
first: “Joe”,
last: “Patient”,
addr: { …},
procedures: [12345, 12346]}
{
_id: 12345,
date: 2015-02-15,
type: “Cat scan”,
…}
{
_id: 12346,
date: 2015-02-15,
type: “blood test”,
…}
Patients
Ссылки
Procedures
©mongodb.org

26. Общие рекомендации. Отношения 1:1 и 1:M
• Как правило, используйте встраивание
– Доступ ко всей информации за один шаг
– Преимущество атомарных модификаций
– Нет дополнительного дублирования
– Поиск и построение индексов по любому полю
например, { “phones.type”: “mobile” }
• Исключения:
– Документы размером более 16 MB
– Большое число редко используемых полей
{
_id: 2,
first: “Joe”,
last: “Patient”,
addr: { …},
procedures: [
{
id: 12345,
date: 2015-02-15,
type: “Cat scan”,
…},
{
id: 12346,
date: 2015-02-15,
type: “blood test”,
…}]
}
©mongodb.org

27. Реляционный подход к отношениям M:N
Join table
Physicians
name
specialty
phone
Hospitals
name
HosPhysicanRel
hospitalId
physicianId
X
NoSQL: Отсутствуют операции JOIN
Используйте массивы
©mongodb.org

28. {
_id: 1,
name: “Oak Valley Hospital”,
city: “New York”,
beds: 131,
physicians: [
{
id: 12345,
name: “Joe Doctor”,
address: {…},
…},
{
id: 12346,
name: “Mary Well”,
address: {…},
…}]
}
Отношения M:N
Способ 1: вложение объектов ‘doktor’ в коллекцию ‘hospitals’
{
_id: 2,
name: “Plainmont Hospital”,
city: “Omaha”,
beds: 85,
physicians: [
{
id: 63633,
name: “Harold Green”,
address: {…},
…},
{
id: 12345,
name: “Joe Doctor”,
address: {…},
…}]
}
Дублирование
©mongodb.org

29. {
_id: 1,
name: “Oak Valley Hospital”,
city: “New York”,
beds: 131,
physicians: [12345, 12346]
}
Отношения M:N
Способ 2: Ссылки
hospitals
{
_id: 2,
name: “Plainmont Hospital”,
city: “Omaha”,
beds: 85,
physicians: [63633, 12345]
}
{
id: 63633,
name: “Harold Green”,
address: {…},
…}
doktors
{
id: 12345,
name: “Joe Doctor”,
address: {…},
…}
{
id: 12346,
name: “Mary Well”,
address: {…},
…}
©mongodb.org

30. Отношения M:N. Общие рекомендации
• Что применять, вложения или ссылки
определяется:
1. Дублированием данных
• Вложение может привести к дублированию
данных
• Это допустимо в системах, где мало
модификаций, много операций чтения
2. Ссылки помогут если связанных объектов слишком
много
• Гибридный подход
• Использовать оба способа
{
_id: 2,
name: “Oak Valley Hospital”,
city: “New York”,
beds: 131,
physicians: [12345, 12346]}
{
_id: 12345,
name: “Joe Doctor”,
address: {…},
…}
{
_id: 12346,
name: “Mary Well”,
address: {…},
…}
Hospitals
Reference
Doktors

31. Подгонка схемы к важным запросам
{
"_id" : 593340651,
"first" : "Gregorio",
"last" : "Lang",
"addr" : {
"street" : "623 Flowers Rd",
"city" : "Groton",
"state" : "NH",
"zip" : 3266
},
"physicians" : [10387 33456],
"procedures” : ["551ac”,“343fs”]
}
{
"_id" : "551ac”,
"date" :"2000-04-26”,
"hospital" : 161,
"patient" : 593340651,
"physician" : 10387,
"type" : "Chest X-ray",
"records" : [ “67bc6”]
}
Patient Procedure
Пример: найти всех пациентов,
кому делали рентген грудной
клетки (Сhest x-rays)

32. Подгонка схемы к важным запросам (оптимизация)
{
"_id" : 593340651,
"first" : "Gregorio",
"last" : "Lang",
"addr" : {
"street" : "623 Flowers Rd",
"city" : "Groton",
"state" : "NH",
"zip" : 3266
},
"physicians" : [10387 33456],
"procedures” : [
{id : "551ac”,
type : “Chest X-ray”},
{id : “343fs”,
type : “Blood Test”}]
}
{
"_id" : "551ac”,
"date" :"2000-04-26”,
"hospital" : 161,
"patient" : 593340651,
"physician" : 10387,
"type" : "Chest X-ray",
"records" : [ “67bc6”]
}
Patient Procedure
Пример: найти всех пациентов,
кому делали рентген грудной
клетки (Сhest x-rays)

33. Другие стандартные шаблоны проектирования
• Наследование
Решается легко за счет гибкой схемы
• Деревья
– Фактически – отношения 1:m, m:n (графы)
– В качестве ссылок могут использоваться _id «родителей» или «детей»
– Деревья могут быть очень «высокими»
– Чаще всего применяется «гибридный подход»
• Очереди: например, упорядоченный список заданий, задание
должно выполниться только один раз, список выполняющихся
– Поле “in_progress”: F|T
– Поиск: db.jobs.findAndModify({…})

34. Time Series Data : медицинский мониторинг
Жизненные показатели:
• Кровяное давление
• Пульс
• Уровень кислорода в крови
Постоянно выдают данные
• Раз в минуту
©mongodb.org

35. Из приборов приходят данные
{
deviceId: 123456,
spO2: 88,
pulse: 74,
bp: [128, 80],
ts: ISODate("2013-10-16T22:07:00.000-0500")
}
• Реляционный подход: один документ в минуту для устройства

36. Rich Document
{
deviceId: 123456,
spO2: { 0: 88, 1: 90, …, 59: 92},
pulse: { 0: 74, 1: 76, …, 59: 72},
bp: { 0: [122, 80], 1: [126, 84], …, 59: [124, 78]},
ts: ISODate("2013-10-16T22:00:00.000-0500")
}
• Один документ для прибора в час (с поминутной модификацией)

37. Влияние схемы на производительность и ресурсы
Document Per Minute Document Per Hour
Number Documents
52.6 B 876 M
Total Index Size 6364 GB 106 GB
_id index 1468 GB 24.5 GB
{ts: 1, deviceId: 1} 4895 GB 81.6 GB
Document Size 92 Bytes 758 Bytes
Database Size 4503 GB 618 GB
• 100K приборов
• данные за 1 год
100000 *
365 * 24 *
60
100000 *
365 * 24
100000 *
365 * 24 *
60 * 130
100000 *
365 * 24 *
130
100000 *
365 * 24 *
60 * 92
100000 *
365 * 24 *
758

38. Архитектура и модели в эпоху NoSQL
• Модели данных содержат гораздо больше, чем просто диаграммы
• Есть много вариантов использования NoSql. Рассмотрите все
способы
• Современные архитектуры данных чаще всего представляют
смешанные решения. Нельзя поддерживать только одну часть из
общего

39. Классические СУБД и технологии Hadoop могут работать вместе
Программная
аналитика
Стандартные
Средства (SQL)
Реляционные
Многоструктурные
данные
SQL
Hadoop
DW
Stagingdata
Data
Warehouse
Анализ
данных
Delphi, Java, C++, C#, PHP, Python,
Perl, Ruby

40. Где еще пригодятся инструменты Embarcadero для работы с БД

41. N

43. Итоги
• Проектирование данных для NoSQL отличается от RDBMS
• Хотя основные принципы проектирования данных те же
• Сфокусированность на том, как приложения обрабатывают данные
• Легкая эволюция схемы для соответствия изменившимся
требованиям
• Проект данных оказывает драматическое влияние на
производительность и масштабирование
• Пользуйтесь новой степенью свободы разумно

44. Передовая поддержка Big Data в Data Architect
• MongoDB
– Сертификация для MongoDB версий 2.x и 3.0
– Поддержка прямого проектирования (генерация незаполненного шаблона
на JSON)
– Улучшения аутентификации
• Сертификация для HDP 2.1
• Поддержка Sybase IQ 15.x, 16.x

45. Архитектура данных, управляемая бизнесом
• ER/Studio улучшает обозримость и совместное использование
информационных активов
• Более эффективное и автоматизированное моделирование данных
• Распространение общих моделей и метаданных в рамках компании
• Ведение бизнес-глоссариев с четкими терминами и определениями
• Создает основу решений для соответствия нормам, DG (data
governance), и MDM (master data management)

46. ER/Studio Enterprise Team Edition
47
Включает:
ER/Studio Data Architect
Моделирование и анализ информационных активов
компании для получения новых прибылей
ER/Studio Team Server
Совместная работа с корпоративными моделями
данных и метаданными
Repository
Управление объектами моделей с применением
версионности и Agile-методик управления
изменениями
MetaWizard
Интеграция разнообразных источников данных с
помощью кросс-платформенных метаданных
Business Architect
Создание концептуальных и моделей бизнес-
процессов для понимания контекста данных
Software Architect
Визуальный анализ и проектирование ПО на UML s
Viewer
Data Lineage
UDM
Дополнительные продукты

47. Пользователи ER/Studio

48. Спасибо за внимание!
Powering Today’s Applications and Data
Андрей Совцов
Embarcadero
Email: Andrew.Sovtsov@Embarcadero.com
Blog: http://embt.co/ASovtsov
Tel: +7(495)708 4393
Записи вебинаров: http://embt.co/MrAndySova
Блоги Embarcadero
(все языки):
http://community.embarcadero.com/index.php/blogs
Более подробно о семействе продуктов
ER/Studio:
http://www.embarcadero.com/data-modeling
Ознакомительная версия:
http://www.embarcadero.com/downloads

49. Вопросы?

50. Приложения