Slide 1
Slide 1 text
Переход от монолитной
архитектуры к распределенной
Александр Бындю
http://byndyu.ru
8-я конференция .NET разработчиков
6 апреля 2014
dotnetconf.ru
Slide 2
Slide 2 text
2
Обо мне
1. Владелец компании ByndyuSoft http://byndyusoft.com
2. Консультант по вопросам разработки приложений и организации работы IT
компаний, Certified CIAgile Professional
3. Внештатный сотрудник Академии АйТи
4. Технический блог http://blog.byndyu.ru
5. Преподаю в ЮУрГУ и ЧелГУ
6. Тренер на AgileCamp
7. Организую конференции .NET-разработчиков
http://dotnetconf.ru
8. Веду группу по проблемам разработки приложений
https://groups.google.com/forum/?hl=ru&fromgroups#!forum/dotnetconf
Slide 3
Slide 3 text
3
Требования рынка
1. Много данных
2. Много пользователей
3. Быстрое масштабирование
4. Быстрое внесение изменений
Slide 4
Slide 4 text
4
Теорема CAP
1. Consistency
(согласованность данных)
2.Availability
(доступность)
3.Partition tolerance
(устойчивость к разделению)
Slide 5
Slide 5 text
5
Теорема CAP
Выбираем любые два свойства
A C
P
Slide 6
Slide 6 text
6
Какие реализации?
Consistency + Availability
(MSSQL на сервере)
Consistency + Partition tolerance
(MSSQL на кластере с транзакцией)
Availability + Partition tolerance
(NoSQL решения)
Slide 7
Slide 7 text
7
Consistency + Availability
Надежность,
Предсказуемость,
Исторически так
сложилось
Slide 8
Slide 8 text
8
1. Создаем UI
2. Сборку BL
3. Сборку DAL
4. Создаем DB
5. …
6. Profit!
UI
Services
BL
DAL
DB
Slide 9
Slide 9 text
9
Website Сервис1 Сервис2
Shared DB
CA
Slide 10
Slide 10 text
10
DB
Get data Set data
Set data Get data
Slide 11
Slide 11 text
11
Slide 12
Slide 12 text
12
Решим проблему с нагрузкой на
чтение данных
Slide 13
Slide 13 text
13
Что делать?
1. Оптимизировать скрипты выборки
2. Убираем ORM для лучшей оптимизации
3. Убираем весь код выборки в хранимки
4. Оптимизируем индексы
5. Денормализуем данные
Slide 14
Slide 14 text
14
Денормализация v1.0
Создать дополнительные колонки в текущих
таблицах
SELECT pt.Code
FROM Products p
INNER JOIN ProductType pt ON
p.ProductTypeID = pt.ProductTypeID
WHERE p.ProductID = 20
Slide 15
Slide 15 text
15
Денормализация v2.0
Создать отдельные таблицы/view для
денормализованных данных
Slide 16
Slide 16 text
16
Денормализация v3.0
Создать еще одну БД (хранилище) c
«плоскими» данными для чтения
1. Отдельная реляционная БД с «плоскими»
данными без связей
2. Различные NoSQL
3. Поисковые системы
Slide 17
Slide 17 text
17
cRud
1. «Плоский» SQL
2. NoSQL
3. Поисковые системы
4. Кэши
5. …
«Плоские» данные
UI
Только
выборка
Slide 18
Slide 18 text
18
CrUD
1. Domain-driven design (DDD)
2. N- tier, onion,… architecture
3. ORM (NHibernate, Entity Framework,…)
Приложение
База
данных
Presenter
UI
Domain Model
Validation
...
Slide 19
Slide 19 text
19
Отделяем чтение от записи
Приложение
MongoDB
Command
UI
Domain Model
Validation
...
Query Query Model
База
данных
Redis
Sphinx
...
Slide 20
Slide 20 text
20
Горизонтальное масштабирование
• Cassandra
• ElasticSearch
• Couchbase
• …
Client
Node1
Node2
Node3
...
MongoDB
Redis
Sphinx
...
Slide 21
Slide 21 text
21
Облачная инфраструктура
Масштабируемся в один клик!
Даешь больше равноценных нодов!
Slide 22
Slide 22 text
22
ложение
MongoDB
Domain Model
Validation
...
Query Model
База
данных
?
Redis
Sphinx
...
Как синхронизировать
хранилища?
Slide 23
Slide 23 text
23
Обновляем синхронно
Приложение
MongoDB
mand
Domain Model
Validation
...
uery Query Model
База
данных
Redis
Sphinx
...
Slide 24
Slide 24 text
24
Приложение
MongoDB
mmand
Domain Model
Validation
...
uery Query Model
База
данных
Redis
Sphinx
...
С
о
б
ы
т
и
е
С
о
б
ы
т
и
е
Ш
и
н
а
д
а
н
н
ы
х
Обновляем асинхронно
Slide 25
Slide 25 text
25
BASE-архитектура
Availability + Partition tolerance
1. Basically Available
(сбой в некоторых узлах не приводит к отказу в обслуживании)
2. Soft-state
(не согласованное состояние)
3. Eventually consistent
(в конце концов информация будет консистентна)
Slide 26
Slide 26 text
26
Eventually consistent
Какое время уйдет
на синхронизацию?
Slide 27
Slide 27 text
27
Пример из проекта с Couchbase
Slide 28
Slide 28 text
28
Чтение данных разгрузили,
что с записью?
Slide 29
Slide 29 text
29
Website Сервис1 Сервис2
Shared DB
CA
Slide 30
Slide 30 text
30
Очереди сообщений
Отправитель Получатель
1. Создание 5. Обработка
2. Отправка
3. Доставка
4. Отправка
Канал
Slide 31
Slide 31 text
31
DB
1. Сервисы
сбора данных
1. Сервисы
сбора данных
Сервис1
1. Сервисы
сбора данных
1. Сервисы
сбора данных
Сервис2
1. Сервисы
сбора данных
1. Сервисы
сбора данных
Сервис3
1. Сервисы
сбора данных
1. Сервисы
сбора данных
...
Шина сообщений
Событие Событие Событие Событие
Slide 32
Slide 32 text
32
Инструменты для очереди
Утилиты:
1. RabbitMQ
2. NServiceBus
3. ActiveMQ
Облачные инструменты:
1. IronMQ, SQS
2. Windows Azure Queues
Slide 33
Slide 33 text
33
Пример на
реальном проекте
Slide 34
Slide 34 text
34
Slide 35
Slide 35 text
35
Slide 36
Slide 36 text
36
1. Сервисы
сбора данных
2. Скачивание
HTML
3. Создание
сущностей
4. Анализ
данных
DB
+ Fulltext Search
Sphinx
Веб-приложение
Slide 37
Slide 37 text
37
1. Сервисы
сбора данных
1. Сервисы
сбора данных
1. Сервисы
сбора данных
1. Сервисы
сбора данных
1. Сервисы
сбора данных
2. Скачивание
HTML
3. Создание
сущностей
4. Анализ
данных
DB
Fulltext Search
Sphinx
Веб-приложение
Шина сообщений (IronMQ)
AWS S3
Slide 38
Slide 38 text
38
1. Сервисы
сбора данных
1. Сервисы
сбора данных
1. Сервисы
сбора данных
1. Сервисы
сбора данных
1. Сервисы
сбора данных
2. Скачивание
HTML
3. Создание
сущностей
4. Анализ
данных
DB
Веб-приложение
Шина сообщений (IronMQ)
AWS S3
Sphinx
Sphinx
Sphinx
Sphinx
Redis
Redis
Redis
Slide 39
Slide 39 text
39
Полезные ссылки
1. Eventually Consistent – Revisited, Werner Vogels
2. If You Have Too Much Data, then 'Good Enough' Is Good
Enough, Pat Helland
3. Ошибки в системах баз данных, согласованность "в
конечном счете" и теорема CAP
, Майкл Стоунбрейкер
4. CAP theorem, Wikipedia
5. Reporting Database, Martin Fowler
6. BASE: An Acid Alternative, Dan Pritchett
Slide 40
Slide 40 text
40
Спасибо за внимание!
Буду рад ответить на ваши
вопросы лично или через:
blog.byndyu.ru
alexanderbyndyu
[email protected]