[Администрирование баз данных] Масштабирование базы данных. Microsoft AlwaysOn
Автор
Сообщение
news_bot ®
Стаж: 7 лет 6 месяцев
Сообщений: 27286
Привет. Меня зовут Тигран Петросян, я ведущий инженер по технической поддержке Docsvision, и сегодня расскажу о применении технологии MS SQL AlwaysOn. Это вторая статья из мини-серии «Масштабируемость системы ECM на предприятии», в которой первая статья моего коллеги была посвящена технологии масштабирования поиска Elasticsearch.
Оба материала могут быть интересны не только тем, кто работает с Docsvision, но и всем, интересующимся технологиями масштабирования.
Пара слов о том, почему мы об этом говорим
Последняя версия СЭД/ECM платформы Docsvision, разработкой которой мы занимаемся, отличается принципиально от предыдущих версий своей модульной архитектурой. Было важно обеспечить возможность масштабировать систему (причём практически неограниченно) с сохранением скорости работы. Одна из технологий, положенных в основу новых возможностей платформы, — MS SQL AlwaysOn.
Мои коллеги уже рассказывали о технологиях масштабирования, положенных в основу новых возможностей платформы: есть серия из 4-х мини-вебинаров на YouTube, серия из 3-х статей на Medium (статья №1, статья 2, а статья №3 как раз посвящена теме масштабирования БД). В этих материалах более чётко обозначено, какие проблемы мы решали и чего достигли в их решении.
Я же рассмотрю одну конкретную функцию MS SQL AlwaysOn, повышающую надёжность и производительность сервера БД.
Рис. 1. Сегодня архитектура платформы Docsvision выглядит так.
Масштабирование сервиса баз данных. MS SQL AlwaysOn
В инструменты повышения производительности и масштабирования сервиса базы данных нашей платформы Docsvision вошла возможность создания кластеров серверов БД. Эту возможность обеспечивает технология MS SQL AlwaysOn.
Группы доступности AlwaysOn в рамках БД Docsvision может выполнять сразу две задачи:
- Высокий уровень доступности обеспечивает бесперебойную работу системы;
- Нагрузка по чтению из БД частично выполняется на репликах.
Принцип работы режима Always On заключается в создании кластера серверов, среди которых выбирается:
- Master-сервер – основной сервер, который фиксирует все изменения в системе (чтение, запись);
- Slave-сервер – репликационный сервер, который дублирует все изменения в системе, но доступен только для чтения. На каждом репликационном сервере хранится БД (Metadata) для хранения промежуточных данных для работы поисковых запросов и представлений.
Рис. 2. Распределение нагрузки между серверами.
Как видно на схеме, мы распределяем именно нагрузку на чтение, поскольку подавляющая часть операций пользователей в системе — это операции чтения (поиск, отчёты, открытие документов).
В ходе тестирования изначально master-сервер у нас был мощнее, чем slave-сервер. Однако, при преодолении цифры примерно в 40 тысяч пользователей, мы увидели, что slave-сервера не справляются, а master, наоборот, недогружен. Это было практическим подтверждением того, что запросов на чтение больше, нагрузки они генерят больше, поэтому в первую очередь мы распределяем её между узлами.
При работе режима Always On различают несколько видов запросов пользователей:
- Запрос отчета. В случае, если у отчета, хранящегося в БД, выставлен признак «Read Only», сервер приложений берет информацию по запросу, хранящуюся на одном из slave-серверов, не нагружая master-сервер работой. Если же у отчета не указан признак «Read Only», то сервер приложений отправляет запрос на master-сервер, т.к. в данном случае будут вноситься изменения в БД.
- Получение данных карточки. В данном случае используется временная метка «Timestamp», которая присваивается каждой карточке при внесении в нее изменений. При каждом новом изменении в карточке счетчик «Timestamp» повышается. При запросе карточки выбирается место чтения, в котором метка «Timestamp» у карточки имеет наивысшее значение: из распределенного кэша (если там тот же Timestamp), какой-то из реплик (если Timestamp реплики больше Timestamp карточки – это означает, что на реплику уже переданы актуальные данные карточки), иначе – с мастера. Если карточка изменялась в текущей сессии, и информация о ней хранится в кэше, система смотрит значение метки «Timestamp» в кэше, а затем ищет на slave-серверах и master-сервере нужную карточку, у которой «Timestamp» соответствует значению в кэше.
- Выполнение поисковых запросов, работа с представлениями. При выполнении данных запросов сервер приложений получает информацию с одного из slave-серверов из области БД «Metadata» (хранилище временной информации о работе поисковых запросов и представлений). Выбор slave-сервера для работы с представлением фиксируется в кэше и при загрузке новых страниц представления и использования остальных методов, которые работают с поисками и представлениями, используется выбранный сервер.
Особенности работы slave-серверов:
- Сервер приложений хранит счетчик вызова каждого slave-сервера, значение которого увеличивается при каждом новом запросе к реплике. Для оптимальной нагрузки и скорости работы серверов используется алгоритм Round Robin, т.е. при каждом новом запросе отчета, представления, поиска выбирается slave-сервер с минимальным счетчиком вызова.
- При репликации существует задержка, связанная со скоростью работы сети. При настройке режима Always On можно задать приемлемое время этой задержки и период проверки соответствия реальной задержки работы slave-сервера заданному значению. Если реальное значение превышает заданное, то slave-сервер становится временно недоступным для запросов. При следующей проверке, если реальное значение задержки будет соответствовать заданному значению, slave-сервер вновь станет доступным для запросов.
- Выполнение запросов к БД может быть перенаправлено с master-а на slave при использовании следующих методов:
— GetCardXmlData – серверный метод, возвращает XML запрошенной карточки;
— SectionReadRowsData – серверный метод, возвращает содержимое строки секции карточки;
— SearchCreateProcessor – все методы поисков;
— ViewCreateProcessor – все методы представлений;
— CardGetState – возвращает состояние карточки;
— ReportGetData – получает результат выполнения отчета;
— RowGetData – возвращает содержимое строки секции карточки;
— RowGetHierarchy – возвращает идентификаторы всех родительских строк в секции для подчиненной строки;
— CardGetType – серверный метод, возвращает тип карточки;
— SessionGetIdList;
— UserGetInfo.
Использование технологии MS SQL Always позволяет плавно увеличивать серверные мощности и распределять повышенную нагрузку. На тестах мы добились нагрузки 100 000+ одновременно работающих пользователей, во многом именно благодаря масштабированию на уровне БД.
Буду рад ответить на вопросы.
===========
Источник:
habr.com
===========
Похожие новости:
- [Высокая производительность, Анализ и проектирование систем, Администрирование баз данных] Надежный выбор лидера в Tarantool Cartridge
- [SQL, Администрирование баз данных, Хранилища данных] Как создавать и использовать словари в ClickHouse
- [Информационная безопасность, Программирование, Администрирование баз данных, Хранение данных] Firebase снова стала предметом исследований
- [Высокая производительность, SQL, Проектирование и рефакторинг, Администрирование баз данных] Трюки с SQL от DBA. Не банальные советы для разработчиков БД (перевод)
- [Ruby, Ruby on Rails, Администрирование баз данных, Хранение данных, Хранилища данных] Миграции данных в Ruby On Rails
- [Высокая производительность, Oracle, Анализ и проектирование систем, Администрирование баз данных] Кэши Tarantool и репликация из Oracle
- [PostgreSQL, Программирование, SQL, Администрирование баз данных] PostgreSQL Antipatterns: «Должен остаться только один!»
- [NoSQL, Администрирование баз данных, DevOps] Lossless ElasticSearch data migration (перевод)
- [Разработка мобильных приложений, Разработка под Android, Администрирование баз данных, Kotlin] Сказ о том, как каскадное удаление в Realm долгий запуск победило
- [Администрирование баз данных, Высокая производительность] 4 августа пройдет практикум «Ускоряем ваше приложение с Tarantool»
Теги для поиска: #_administrirovanie_baz_dannyh (Администрирование баз данных), #_ms_sql_alwayson, #_docsvision, #_bolee_1000 (более 1000), #_administrirovanie_baz_dannyh (
Администрирование баз данных
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 26-Авг 11:42
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 7 лет 6 месяцев |
|
|
Привет. Меня зовут Тигран Петросян, я ведущий инженер по технической поддержке Docsvision, и сегодня расскажу о применении технологии MS SQL AlwaysOn. Это вторая статья из мини-серии «Масштабируемость системы ECM на предприятии», в которой первая статья моего коллеги была посвящена технологии масштабирования поиска Elasticsearch. Оба материала могут быть интересны не только тем, кто работает с Docsvision, но и всем, интересующимся технологиями масштабирования. Пара слов о том, почему мы об этом говорим Последняя версия СЭД/ECM платформы Docsvision, разработкой которой мы занимаемся, отличается принципиально от предыдущих версий своей модульной архитектурой. Было важно обеспечить возможность масштабировать систему (причём практически неограниченно) с сохранением скорости работы. Одна из технологий, положенных в основу новых возможностей платформы, — MS SQL AlwaysOn. Мои коллеги уже рассказывали о технологиях масштабирования, положенных в основу новых возможностей платформы: есть серия из 4-х мини-вебинаров на YouTube, серия из 3-х статей на Medium (статья №1, статья 2, а статья №3 как раз посвящена теме масштабирования БД). В этих материалах более чётко обозначено, какие проблемы мы решали и чего достигли в их решении. Я же рассмотрю одну конкретную функцию MS SQL AlwaysOn, повышающую надёжность и производительность сервера БД.  Рис. 1. Сегодня архитектура платформы Docsvision выглядит так. Масштабирование сервиса баз данных. MS SQL AlwaysOn В инструменты повышения производительности и масштабирования сервиса базы данных нашей платформы Docsvision вошла возможность создания кластеров серверов БД. Эту возможность обеспечивает технология MS SQL AlwaysOn. Группы доступности AlwaysOn в рамках БД Docsvision может выполнять сразу две задачи:
Принцип работы режима Always On заключается в создании кластера серверов, среди которых выбирается:
 Рис. 2. Распределение нагрузки между серверами. Как видно на схеме, мы распределяем именно нагрузку на чтение, поскольку подавляющая часть операций пользователей в системе — это операции чтения (поиск, отчёты, открытие документов). В ходе тестирования изначально master-сервер у нас был мощнее, чем slave-сервер. Однако, при преодолении цифры примерно в 40 тысяч пользователей, мы увидели, что slave-сервера не справляются, а master, наоборот, недогружен. Это было практическим подтверждением того, что запросов на чтение больше, нагрузки они генерят больше, поэтому в первую очередь мы распределяем её между узлами. При работе режима Always On различают несколько видов запросов пользователей:
Особенности работы slave-серверов:
— GetCardXmlData – серверный метод, возвращает XML запрошенной карточки; — SectionReadRowsData – серверный метод, возвращает содержимое строки секции карточки; — SearchCreateProcessor – все методы поисков; — ViewCreateProcessor – все методы представлений; — CardGetState – возвращает состояние карточки; — ReportGetData – получает результат выполнения отчета; — RowGetData – возвращает содержимое строки секции карточки; — RowGetHierarchy – возвращает идентификаторы всех родительских строк в секции для подчиненной строки; — CardGetType – серверный метод, возвращает тип карточки; — SessionGetIdList; — UserGetInfo. Использование технологии MS SQL Always позволяет плавно увеличивать серверные мощности и распределять повышенную нагрузку. На тестах мы добились нагрузки 100 000+ одновременно работающих пользователей, во многом именно благодаря масштабированию на уровне БД. Буду рад ответить на вопросы. =========== Источник: habr.com =========== Похожие новости:
Администрирование баз данных ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 26-Авг 11:42
Часовой пояс: UTC + 5