Ambos os materiais podem ser de interesse não apenas para aqueles que trabalham com o Docsvision, mas também para todos os interessados em tecnologias de dimensionamento.
Algumas palavras sobre por que estamos falando sobre isso
A última versão da plataforma EDMS / ECM Docsvision, que estamos desenvolvendo, difere fundamentalmente das versões anteriores em sua arquitetura modular. Era importante fornecer a capacidade de dimensionar o sistema (e quase ilimitadamente), mantendo a velocidade do trabalho. Uma das tecnologias subjacentes aos novos recursos da plataforma é o MS SQL AlwaysOn.
Meus colegas já falaram sobre as tecnologias de escalonamento subjacentes aos novos recursos da plataforma: há uma série de 4 mini-webinars no YouTube , uma série de 3 artigos sobre o Médio ( artigo nº 1 , artigo 2 e artigo nº 3apenas dedicado ao tópico de dimensionamento de banco de dados). Esses materiais indicam mais claramente quais problemas resolvemos e o que alcançamos para resolvê-los.
Vou considerar um recurso específico do MS SQL AlwaysOn que aumenta a confiabilidade e o desempenho do servidor de banco de dados.

Figura: 1. Hoje, a arquitetura da plataforma Docsvision é assim.
Escalonando o serviço de banco de dados. MS SQL AlwaysOn
As ferramentas para melhorar o desempenho e escalonamento do serviço de banco de dados de nossa plataforma Docsvision incluem a capacidade de criar clusters de servidores de banco de dados. Este recurso é fornecido pela tecnologia MS SQL AlwaysOn.
Os grupos de disponibilidade AlwaysOn no banco de dados do Docsvision podem executar duas tarefas ao mesmo tempo:
- A alta disponibilidade garante a operação ininterrupta do sistema;
- A carga na leitura do banco de dados é parcialmente executada nas réplicas.
O princípio de funcionamento do modo Always On é criar um cluster de servidores, entre os quais você pode escolher:
- Servidor mestre - o servidor principal que registra todas as alterações no sistema (leitura, gravação);
- O servidor escravo é um servidor de replicação que duplica todas as alterações no sistema, mas é somente leitura. Cada servidor de replicação armazena um banco de dados (Metadados) para armazenar dados intermediários para a operação de consultas de pesquisa e visualizações.

Figura: 2. Equilibrar a carga entre os servidores.
Como você pode ver no diagrama, é a carga de leitura que distribuímos, já que a grande maioria das operações do usuário no sistema são operações de leitura (pesquisa, relatórios, abertura de documentos).
Durante o teste, inicialmente tínhamos um servidor mestre mais poderoso do que um servidor escravo. Porém, ao superarmos a cifra de cerca de 40 mil usuários, vimos que os servidores escravos não conseguiam dar conta, e o mestre, ao contrário, era subutilizado. Essa foi uma confirmação prática de que há mais solicitações de leitura, elas geram mais carga, então primeiro distribuímos entre os nós.
Quando o modo Always On está funcionando, existem vários tipos de solicitações do usuário:
- . , , , «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.
Usar a tecnologia MS SQL Always permite que você aumente suavemente as capacidades do servidor e distribua a carga aumentada. Nos testes, alcançamos uma carga de mais de 100.000 usuários simultâneos, em grande parte devido ao dimensionamento no nível do banco de dados.
Terei prazer em responder suas perguntas.