Both materials may be of interest not only to those who work with Docsvision, but also to everyone interested in scaling technologies.
A few words about why we are talking about it
The latest version of the EDMS / ECM platform Docsvision, which we are developing, differs fundamentally from previous versions in its modular architecture. It was important to provide the ability to scale the system (and almost unlimitedly) while maintaining the speed of work. One of the technologies underlying the platform's new capabilities is MS SQL AlwaysOn.
My colleagues have already talked about the scaling technologies underlying the platform's new capabilities: there is a series of 4 mini-webinars on YouTube , a series of 3 articles on Medium ( article # 1 , article 2 , and article # 3just devoted to the topic of database scaling). These materials more clearly indicate what problems we solved and what we achieved in solving them.
I will consider one specific feature of MS SQL AlwaysOn that increases the reliability and performance of the database server.
Figure: 1. Today the architecture of the Docsvision platform looks like this.
Scaling database service. MS SQL AlwaysOn
The tools for improving the performance and scaling of the database service of our Docsvision platform include the ability to create clusters of database servers. This feature is provided by MS SQL AlwaysOn technology.
AlwaysOn availability groups within the Docsvision database can perform two tasks at once:
- High availability ensures uninterrupted operation of the system;
- The load on reading from the database is partially performed on replicas.
The principle of operation of Always On mode is to create a cluster of servers, among which you can choose:
- Master server - the main server that records all changes in the system (reading, writing);
- Slave server is a replication server that duplicates all changes in the system, but is read-only. Each replication server stores a database (Metadata) for storing intermediate data for the operation of search queries and views.
Figure: 2. Balancing the load between servers.
As you can see in the diagram, it is the load on reading that we distribute, since the overwhelming majority of user operations in the system are read operations (search, reports, opening documents).
During testing, we initially had a master server more powerful than a slave server. However, when overcoming the figure of about 40 thousand users, we saw that the slave servers were unable to cope, and the master, on the contrary, was underutilized. This was a practical confirmation that there are more read requests, they generate more load, so first of all we distribute it among the nodes.
When Always On mode is working, there are several types of user requests:
- . , , , «Read Only», , slave-, master- . «Read Only», master-, .. .
- . «Timestamp», . «Timestamp» . , «Timestamp» : ( Timestamp), - ( Timestamp Timestamp – , ), – . , , «Timestamp» , slave- master- , «Timestamp» .
- , . slave- «Metadata» ( ). slave- , , .
slave-:
- slave-, . Round Robin, .. , , slave- .
- , . Always On slave- . , slave- . , , slave- .
- master- slave :
- GetCardXmlData – , XML ;
- SectionReadRowsData – , ;
- SearchCreateProcessor – ;
- ViewCreateProcessor – ;
- CardGetState – ;
- ReportGetData – ;
- RowGetData – ;
- RowGetHierarchy – ;
- CardGetType – , ;
- SessionGetIdList;
- UserGetInfo.
Using MS SQL Always technology allows you to smoothly increase server capacities and distribute the increased load. In tests, we achieved a load of 100,000+ concurrent users, largely due to scaling at the database level.
I will be glad to answer your questions.