Разделяне между четене и запис
Когато бизнесът на компанията продължава да се разширява и броят на потребителите значително нараства, оригиналната база данни вероятно няма да може да се поддържа сама. Тогава да
- Scal-in, което разширява производителността на хардуера, но вероятно броят на потребителите ще продължи да расте, а повишената производителност скоро ще бъде изядена.
- Разделяне между четене и писане: Базата данни не може да издържи, няма нищо повече от прекалено много четене и писане, особено ако има сложни заявки като най-популярните продукти през последните 24 часа. Изисква много сложни SQL оператори и, разбира се, е бавен за изпълнение.
Въпреки това, за да се разделят четенията и записите, базата данни трябва да бъде разделена на master и slave библиотеки.
Основните релационни бази данни на пазара поддържат репликация на данни, така че можете да разделите базата данни на две роли: Master и Slave, да пишете операции върху главния сървър и да синхронизирате главния сървър с други подчинени сървъри.
Офлайн операции като четене и анализ на данни се извършват на Slave сървъра.
Знаем, че много приложения в интернет се четат, така че множество подчинени могат да споделят натоварването и да гарантират наличността и коректността на данните.
Въпреки това, съответният оригинален код на приложението също трябва да бъде модифициран и трябва да се промени, за да се използва главната библиотека за запис на данни, а подчинената библиотека при четене на данни, което е еквивалентно на пренаписване.
Комплексни заявки
Въпреки това, дори след пренаписване на кода, установих, че производителността все още не е значително подобрена, защото са използвани твърде много сложни заявки, а в компонента на базата данни казахме, че присъединяването е много интензивно за производителност.
Можем ли да използваме отделна таблица за съхранение на популярните продукти от последните 24 часа, така че да използваме само прост SQL?
С други думи, един набор от таблици в базата данни е неподходящ за различни поведения като отчети, търсения, транзакции и др.
Текущата таблица е проектирана да добавя и модифицира данни и не е подходяща за сложни заявки.
Но също така трябва да вземем предвид как тази база заявки се обновява, или дали можем да понесем това забавяне, дали може да не се обновява в реално време.
CQRS
Дали забавянето може да бъде толерирано, трябва да се разглежда от бизнес гледна точка, като например най-популярните продукти през последните 24 часа – малко остаряла информация няма голямо значение, а само крайната последователност е необходима.
Можем да използваме CQRS (Command Query Responsibility Segregation), тоест разделяне на командите за добавяне или модифициране на команди от отговорностите за заявки.
В CQRS акцентът е върху разделянето на четене (заявка) и запис (команда), тъй като данните, четени от потребителите, обикновено са остарели, така че защо да се четат от базата данни, можете директно да установите източник на четени данни. Може да е кеш, може да е XML, JSON и т.н.
Как да реша проблема как да се обнови, споменат по-рано? Можете да използвате Event, тоест събитие, например когато продукт се продаде, можете да публикувате събитие, за да промените оригиналния Read Model.
По този начин синхронизацията става асинхронна чрез механизма на събитията.
Накрая, този метод е най-добре да се използва само за сложни заявки, а оригиналните прости заявки все още се изтеглят в релационната база данни. Защо? Тъй като въвеждането на нова технология изисква цена, като стъпки на синхронни мутации и механизми на събития, не можем да виждаме само предимствата на новите технологии, но и недостатъците.
|
Публикувано в 4.05.2020 г. 9:58:50 ч.
|
|
|
|
