Стратегия базы данных для одновременной операции чтения / записи в ней - PullRequest
Новая
       26

Стратегия базы данных для одновременной операции чтения / записи в ней

0 голосов
/ 06 марта 2020

У меня есть 6 служб, взаимодействующих с одной и той же базой данных SQL Сервер 2016 (Платежи), где некоторые службы выполняют операции записи, а другие - операции чтения. Сервер базы данных содержит другие базы данных, а также базу данных платежей. У нас нет никакой архивной работы в базе данных платежей. Недавно мы получили 99% загрузки процессора, а также проблемы с памятью на сервере базы данных.

Очевидные шаги, которые я могу предпринять, включая

  1. Создание архивных заданий для переноса старых данных в архивную базу данных
  2. Может масштабировать сервер базы данных.

Но все же хочется изучить другие лучшие решения. У меня есть следующие вопросы.

  1. Можем ли мы создать разные базы данных для операций чтения и записи, если да, то как?
  2. Можем ли мы перенести данные на лету в базу данных Sql из РСУБД потому что это быстрее для операции чтения?
  3. Каков наилучший дизайн для таких приложений, где происходят параллельные операции чтения и записи?

1 Ответ

1 голос
/ 06 марта 2020

Хранилище - это компромиссы, поэтому очень сложно найти правильное решение для хранения, не углубляясь в разные аспекты, такие как задержка, доступность, параллелизм, схема доступа и требования безопасности. В этом конкретном случае данные о платежах хранятся, что должно быть конфиденциальным и однозначно исключает некоторые решения для хранения. Как правило, вы должны

  1. кэшировать прочитанные данные, но если одни и те же данные постоянно изменяются, это не будет работать. Кэширование также не работает должным образом, когда ваши операции чтения не публикуются c (т. Е. Не могут использоваться повторно для нескольких вызовов чтения, предпочтительно для нескольких пользователей), что возможно в этом случае, поскольку мы имеем дело с данными платежей.
  2. База данных чтения / записи и база данных ведомых только для чтения также является «распространенным» шаблоном для масштабирования операций чтения. Это не масштабирует записи, хотя. Опять же, это зависит от того, может ли приложение работать с «задержкой репликации».
  3. Sharding - это общая схема доступа для масштабирования записей. Это сопряжено с другим бременем агрегации запросов между узлами и т. Д. c (в некоторых базах данных).
  4. Наконец, на основе схемы доступа к данным реорганизуйте схему и используйте различные базы данных. CQRS (сегрегация ответственности за командные запросы) - один из способов достижения этого, но он имеет свои плюсы и минусы. Для более подробной информации: https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs

Несколько лет назад я прочитал эту книгу, которая мне очень помогла в понимании этих понятий: https://www.amazon.com/Scalability-Startup-Engineers-Artur-Ejsmont/dp/0071843655

...