Розділення читання та запису
Коли бізнес компанії продовжує зростати, а кількість користувачів значно зростає, початкова база даних, ймовірно, не зможе підтримувати себе. Тоді так
- Масштабування, що збільшує продуктивність апаратного забезпечення, але, ймовірно, кількість користувачів продовжить зростати, а підвищення продуктивності незабаром буде знищене.
- Розділення читання та запису: база даних не витримує — це просто надмірне читання і запис, особливо якщо є складні запити, як-от найпопулярніші продукти за останні 24 години. Він вимагає дуже складних SQL-операторів і, звісно, працює повільно.
Однак, щоб розділити читання та запис, базу даних потрібно розділити на головні та підлеглі бібліотеки.
Основні реляційні бази даних на ринку підтримують реплікацію даних, тому можна розділити базу даних на дві ролі: Master і Slave, записувати операції на майстер-сервері та синхронізувати головний сервер з іншими підлеглими серверами.
Офлайн-операції, такі як операції читання та аналіз даних, виконуються на сервері Slave.
Ми знаємо, що багато додатків в Інтернеті читаються, щоб кілька підлеглих могли розподіляти навантаження і забезпечувати доступність і коректність даних.
Однак відповідний оригінальний код додатку також потрібно змінити, і його потрібно змінити, щоб використовувати головну бібліотеку для запису даних, а також використовувати підлегливу бібліотеку для читання даних, що еквівалентно переписуванню.
Складні запити
Однак навіть після переписування коду я виявив, що продуктивність все одно не була суттєво покращена, оскільки використовувалося надто багато складних запитів, і ми вже казали в компоненті бази даних, що приєднання є дуже продуктивними.
Отже, чи можемо ми використовувати окрему таблицю для зберігання популярних продуктів за останні 24 години, щоб нам довелося використовувати лише простий SQL?
Іншими словами, один набір таблиць бази даних є недоречним для різних дій, таких як звіти, пошуки, транзакції тощо.
Поточна таблиця призначена для додавання та модифікації даних і не підходить для складних запитів.
Але нам також потрібно враховувати, як оновлюється база запитів, або чи можемо ми терпіти цю затримку, чи може вона не оновлюватися в реальному часі.
CQRS
Чи можна терпіти затримку, потрібно розглядати з бізнесової точки зору, наприклад, найпопулярніші продукти за останні 24 години, трохи застарілої інформації не має великого значення, потрібна лише остаточна узгодженість.
Ми можемо використовувати CQRS (Command Query Responsibility Segregation), тобто розділення команд для додавання або зміни команд від обов'язків запиту.
У CQRS акцент робиться на розділенні читання (Запит) і запису (Команда), оскільки дані, які читають користувачі, зазвичай застарілі, тож навіщо читати з бази даних — можна безпосередньо встановити джерело даних для читання. Це може бути кеш, XML, JSON тощо.
Як вирішити згадану раніше проблему оновлення? Ви можете використовувати Event, тобто подію, наприклад, коли продукт продається, ви можете опублікувати подію для зміни оригінальної моделі читання.
Таким чином, синхронізація стає асинхронною через механізм події.
Нарешті, цей метод найкраще застосовувати лише для складних запитів, і початкові прості запити все ще отримуються у реляційній базі даних. Чому? Оскільки впровадження нової технології вимагає певної ціни, такої як синхронні кроки мутації та механізми подій, ми не лише бачимо переваги нових технологій, а не недоліки.
|
Опубліковано 04.05.2020 09:58:50
|
|
|
|
