CQRS

The Command and Query Responsibility Segregation (CQRS) - принцип или патерн чијом применом се раздвајају операције које мењају податке од операција које служе за читање података.

Патерн CQRS примењује принцип императивног програмирања раздвајања команди и упита - сommand-query separation (CQS). Операције мењања података називамо командама (commands) док операције читања називамо упитима (queries). CQS је уведен Bertrand Meyer-ом за време рада над програмским језиком Eiffel. Принцип гласи да метода мора бити или командом која врши неку радњу или упитом који враћа податке, али не може истовремено бити једно и друго. Другим речима упит не може да мења одговор а команда не добија одговор.

Традиционална архитектура

У традиционалним архитектурама, исти модел података се користи за упите и ажурирање базе података. То је једноставно и добро функционише за основне CRUD операције. У сложенијим апликацијама, међутим, овај приступ може постати незграпан. На пример, на страни за читање, апликација може да изврши много различитих упита, враћајући објекте за пренос података (DTO) различитих облика. Мапирање објеката може постати компликовано. На страни писања, модел може имплементирати сложену валидацију и пословну логику. Као резултат тога, можете завршити са превише сложеним моделом који ради превише. Временом количина података расте, а време извршавања упита се, услед њихове комплексности, обично повећава по некој законитости зависној од количине података. Такође, услед коришћења заједничког модела за упис и читање а самим тим и заједничке базе која је уско грло, систем обично може само да скалира вертикално (нпр. коришћењем више меморије или повећањем процесорске моћи), што значи да је ограничено и скупо а врло брзо долази до тренутка кад више није могуће проширење. Радна оптерећења читања и писања су често асиметрична, са веома различитим захтевима за перформансама и вертикалним маштабиањем.

Решење

CQRS раздваја читање и писање у различите моделе, користећи команде за ажурирање података и упите за читање података. Поседовање засебних модела упита и ажурирања поједностављује дизајн и имплементацију. Међутим, један недостатак је што се CQRS код не може аутоматски генерисати из шеме базе података користећи механизме као што су O/RM алати. Пошто су дефинисани раздвојени интерфејси ка корисничком интерфејсу (или неком другом систему) за упис и читање, могуће је користити и различите моделе. Иако се иста база података користи и у једном и у другом моделу, постоји могућност да се користе посебни прикази које нуди сама база података. CQRS користи два модела података: један за читање уноса и други за мутирајуће стање. CQRS подстиче асинхроно генерисање материјализованих погледа који су посебно дизајнирани и оптимизовани за руковање било којим сложеним упитима.

Засебне базе података

Поред засебних софтверских компоненти, врло често се ове две гране и припремају за одвојену инсталацију базе података како би могле и одвојено да скалирају. Најчешће је потреба за читањем података доста већа, а та асиметричност може да се осликава и у скалирању компоненти система.

Command Handler прихвата команду и примењује је над моделом за упис података. Модел за упис на основу команде и тренутног стања ресурса, може да направи обавештења (events) и објави их синхроно или асинхроно користећи разне принципе и технике, а које ће да се употребе за синхронизацију података између модела за управљање командама и база које су подршка моделу за читање и приказ података.

Највећа предност оваквог приступа јесте могућност коришћења база података која највише одговара моделу који је користи. За модел за читање података могу да се размотре различите технике за смештање података укључујћи употребу релационих, NoSQL, Full Text Search, Graph, Distributed Cache и других база и алата. Такође, сам развој апликације без заједничког модела може да обавља више тимова.

Познати проблеми CQRS

Све горе наведене предности омогућавају да се сервиси скалирају много више од традиционалног решења заснованог на RDBMS -у. Међутим, постоје компромиси за коришћење ове технике:

• Пошто се складиште упита попуњава асинхроно, подаци на крају постају конзистентни.
• Систем може да изгуби својства ACID трансакције. Међутим, развијене су различите корисне технике за руковање трансакцијским захтевима без ACID -а.
• Трошкови складиштења се повећавају како се одржава више копија података.
• Потребна је додатна инфраструктура.

CQRS и Event Sourcing

CQRS образац се често користи заједно са Event Sourcing патерном. Системи засновани на CQRS-у користе одвојене моделе података за читање и писање, од којих је сваки прилагођен релевантним задацима и често се налази у физички одвојеним складиштима. Када се користи са шаблоном Event Sourcing, складиште догађаја је модел писања и званични је извор информација. Модел читања система заснованог на CQRS -у пружа материјализоване приказе података, обично као високо денормализоване погледе. Ови прикази су прилагођени интерфејсима и захтевима за приказ апликације, што помаже да се максимизирају перформансе приказа и упита. Модел се тиме додатно компликује, међутим у неким случајевима и процесима које апликација треба да подржи, добијају се разне погодности, пре свега:

• Једноставнији упис у командном моделу. Нпр. нема блокирања уписа и закључавања ентитета у бази кад више корисника истовремено мења исте податке
• Поновни преглед догађаја који су претходили неком тренутку
• Репродукција догађаја и израчунавање стања до неког тренутка како би се обезбедили подаци за модел за приказ података, било да је нека нова база за читање или корекције на постојећој, прикупљање података за неке друге алате, нпр. за статистику, предикцију, обраду уз помоћ вештачке интелигенције и сл.