はじめに
並列処理への移行はチューニングの王道とも言えます。リソースの許す限り複数の処理を同時に行うことができれば簡単に性能向上が見込めます。
スケールアウトに対応するMarkLogicにおいて、複数ノードにてクラスタを組むと分散処理を行うことができます。
MarkLogicと並列処理
基本的な戦略は、APサーバからJavaなどのマルチスレッドプログラミングを通じて複数スレッドの実行を行うものです。ロードするContent PumpやXQueryを実行するCoRBはこれに基づいた並列処理を提供します。スレッド数が実行パラメータとして設定されています。CoRBについてはJavaプログラミングコストがなくなるのは便利ですが、個々の処理が独立したトランザクションとして扱われるため、それぞれのエラーがErrorLog.txtに大量に出力されてしまいます。ここは敢えて自身でマルチスレッドプログラムを組むというのもありかもです。
並列処理が可能な条件は、個々の処理が独立した問題であることです。「店ごとに売上合計を計算する」といった場合、A店の売上計算結果はB店の売上計算結果に影響を与えないため、両者は独立した問題として並列処理することができます。
並列処理を行う場合は、CPU/メモリ/ディスクIOの逼迫状況を必ず見ておくことにしましょう。特にSSDではなくHDDを使っている場合はディスクIOに要注意です。
ちなみにContent PumpやCoRBを複数同時に実行させても、全体的な性能は向上しないことが多いです。これは1個のContent Pump/CoRBで既にリソースを使い切っている場合が多いようです。
MarkLogicと分散処理
複数のノードで構成されるクラスタを組んでいる場合、MarkLogicに対する処理を各ノードに分散することが可能です。
Content Pumpによる挿入は、クラスタを組むことによって線形とは言わないまでも処理時間が短縮されます。
一方でCoRBは単体では問い合わせを分散しません。問い合わせを受けたノードに、Eノードの役割(クエリの評価など)が集中してしまいます(ここからDノードの役割は分散されます)。これを回避するためにはロードバランサを挟むか、やはり自作のJavaで問い合わせ先を分散させるかになるかと思います。
くれぐれもロードバランサの設定で、CoRBから各ノードへの同時問い合わせ数を1個に制限してしまうことがないようにしましょう。これでは「分散処理」にはなるのですが、より効果の高い「並列分散処理」にはなりません。この場合、CoRBの実行パラメータでいくらスレッド数設定を上げても無意味です。
おわりに
並列・分散処理はリソースの許す限り高速化が図れる素朴な方法です。ただし、分散処理においてクラスタ構成やロードバランサの利用が前提なるなど大きな予算処置が伴いますので、テラバイト単位の大規模な開発では初めから構想に入れておくべきです。
\def\textsmall#1{%
{\rm\scriptsize #1}
}
免責事項
$\textsmall{当ユーザ会は本文書及びその内容に関して、いかなる保証もするものではありません。}$
$\textsmall{万一、本文書の内容に誤りがあった場合でも当ユーザ会は一切責任を負いかねます。}$
$\textsmall{また、本文書に記載されている事項は予告なしに変更または削除されることがありますので、予めご了承ください。}$