どちらの資料も、Docsvisionを使用する人だけでなく、スケーリングテクノロジに関心のあるすべての人にとっても興味深いものです。
私たちがそれについて話している理由についてのいくつかの言葉
私たちが開発しているEDMS / ECMプラットフォームDocsvisionの最新バージョンは、モジュラーアーキテクチャが以前のバージョンとは根本的に異なります。作業速度を維持しながら、システムを拡張する機能(および実質的に無制限)を提供することが重要でした。プラットフォームの新機能の基盤となるテクノロジーの1つは、MS SQLAlwaysOnです。
私の同僚は、新しいプラットフォーム機能の根底にあるスケーリングテクノロジーについてすでに話しました。YouTubeには一連の4つのミニウェビナー、Mediumには一連の3つの記事(記事#1、記事2、記事#3)があります。データベーススケーリングのトピックに専念しています)。これらの資料は、私たちが解決した問題と、それらを解決するために達成したことをより明確に示しています。
データベースサーバーの信頼性とパフォーマンスを向上させるMSSQLAlwaysOnの1つの特定の機能について検討します。
図:1.現在、Docsvisionプラットフォームのアーキテクチャは次のようになっています。
データベースサービスのスケーリング。MS SQL AlwaysOn
Docsvisionプラットフォームのデータベースサービスのパフォーマンスとスケーリングを改善するためのツールには、データベースサーバーのクラスターを作成する機能が含まれています。この機能は、MS SQLAlwaysOnテクノロジーによって提供されます。
Docsvisionデータベース内のAlwaysOn可用性グループは、2つのタスクを同時に実行できます。
- 高い可用性により、システムの動作が中断されることはありません。
- データベースからの読み取りのロードは、部分的にレプリカで実行されます。
常時オンモードの動作の原則は、サーバーのクラスターを作成することです。サーバーのクラスターから、次のものを選択できます。
- マスターサーバー-システム内のすべての変更(読み取り、書き込み)を記録するメインサーバー。
- スレーブサーバーは、システム内のすべての変更を複製するレプリケーションサーバーですが、読み取り専用です。各レプリケーションサーバーは、検索クエリとビューの操作用の中間データを格納するためのデータベース(メタデータ)を格納します。
図: 2.サーバー間の負荷のバランスを取ります。
図からわかるように、システム内のユーザー操作の圧倒的多数は読み取り操作(検索、レポート、ドキュメントのオープン)であるため、私たちが分散するのは読み取りの負荷です。
テスト中、最初はスレーブサーバーよりも強力なマスターサーバーがありました。しかし、約4万人のユーザー数を克服すると、スレーブサーバーが対応できず、逆にマスターが十分に活用されていないことがわかりました。これは、より多くの読み取り要求があり、より多くの負荷を生成することの実際的な確認でした。そのため、まず、ノード間でそれを分散します。
常時オンモードが機能している場合、いくつかのタイプのユーザー要求があります。
- . , , , «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.
MS SQL Alwaysテクノロジーを使用すると、サーバーの容量をスムーズに増やし、増加した負荷を分散させることができます。テストでは、主にデータベースレベルでのスケーリングにより、100,000人以上の同時ユーザーの負荷を達成しました。
ご質問にお答えさせていただきます。