Разделение чтения и записи
Когда бизнес компании продолжает расширяться и число пользователей значительно увеличивается, исходная база данных, скорее всего, не сможет поддерживать себя. Тогда да
- Масштабирование, которое увеличивает производительность аппаратного обеспечения, но, вероятно, число пользователей продолжит расти, и повышение производительности вскоре будет сокращено.
- Разделение чтения и записи: база данных не выдерживает — это просто слишком много чтения и записи, особенно если есть сложные запросы, например, самые популярные продукты последних 24 часов. Он требует очень сложных SQL-операторов, и, конечно, работает медленно.
Однако для разделения чтения и записи база данных должна быть разделена на главные и ведомые библиотеки.
Основные реляционные базы данных на рынке поддерживают репликацию данных, поэтому вы можете разделить базу данных на две функции: мастер и слейв, записывать операции на мастере и синхронизировать мастер-сервер с другими ведомыми.
Офлайн-операции, такие как операции чтения и анализ данных, выполняются на сервере Slave.
Мы знаем, что многие приложения в Интернете читаются, чтобы несколько ведомых могли делить нагрузку и обеспечивать доступность и корректность данных.
Однако соответствующий исходный код приложения также необходимо изменить, и его необходимо изменить для использования главной библиотеки для записи данных, а также для чтения ведомой библиотеки, что эквивалентно переписыванию.
Комплексные запросы
Однако даже после переписывания кода я обнаружил, что производительность всё равно не значительно улучшилась, потому что использовалось слишком много сложных запросов, и мы сказали в компоненте базы данных, что присоединения требуют очень высокой производительности.
Можно ли использовать отдельную таблицу для хранения популярных товаров за последние 24 часа, чтобы нам пришлось использовать только простой SQL?
Другими словами, единый набор таблиц базы не подходит для различных действий, таких как отчёты, поиски, транзакции и т. д.
Текущая таблица предназначена для добавления и модификации данных и не подходит для сложных запросов.
Но нам также нужно учитывать, как обновляется эта база запросов, или можем ли мы терпеть эту задержку, возможно, не обновляется ли она в реальном времени.
CQRS
Можно ли терпеть задержку, нужно рассматривать с точки зрения бизнеса, например, популярные лучшие продукты за последние 24 часа, немного устаревшей информации не оказывает большого влияния, требуется лишь окончательная согласованность.
Мы можем использовать CQRS (Command Query Responsibility Segregation), то есть разделение команд для добавления или изменения команд от обязанностей запроса.
В CQRS акцент делается на разделении чтения (запрос) и записи (команда), потому что данные, читаемые пользователями, обычно устарели, и зачем читать их из базы данных — можно напрямую установить источник данных для чтения. Это может быть кэш, XML, JSON и т.д.
Как решить упомянутую ранее проблему обновления? Вы можете использовать событие, то есть событие, например, когда продукт продается, вы можете опубликовать событие для изменения исходной модели чтения.
Таким образом, синхронизация становится асинхронной благодаря механизму событий.
Наконец, этот метод лучше всего использовать только для сложных запросов, а исходные простые запросы всё равно загружаются в реляционной базе данных. Почему? Поскольку внедрение новой технологии требует определённой цены, такой как синхронные шаги мутации и механизмы событий, мы не можем видеть только преимущества новых технологий, но и недостатки.
|
Опубликовано 04.05.2020 9:58:50
|
|
|
|
