日本マイクロソフトの平山です。今回の連載では引き続きSQL Server 2012フルテキスト検索で強化された機能を紹介します。派手なかたちで目に触れる機会は少ないのですがSQL Server2012フルテキスト検索では、パフォーマンスを向上させるために数多くの取り組みが行われています。今回の記事ではじっくりそれらの点について触れてみたいと思います。
パフォーマンスの改善
SQL Server の新しいバージョンがリリースされるたびに、フルテキストに関連するデータ格納方式は大きく進化を遂げてきました。かつてフルテキスト検索で使用されるオブジェクトは、データベース外の単なるOSファイルとして管理されていました。そのため、運用面のコストやセキュリティ面のリスクといった観点から、あまり望ましくない状態にありました。そのような状況を改善するために、通常のオブジェクトと同様にデータベース内で管理できるようにすることが急務でした。その結果としてSQL Server 2008からは、ほぼ全てのオブジェクトをデータベース内に取り込むことができています。
一方、データ構造の統合を実現するための作業の優先度があまりに高いため、フルテキスト検索に関わる各種操作のパフォーマンスを向上させるための実装が、やや後手に回っていた感があったのも事実です。
しかし、SQL Server 2012ではついにパフォーマンスに関わる部分にメスが入れられ、大幅に改善されています。そのなかでも代表的なものをいくつか見ていきましょう。
検索処理の並列化
実は SQL Server 2008 R2 まで、フルテキストインデックスに対する検索は、たった一つのスレッドで実行されていました。そんな状況であれば、当然のことながら巨大なサイズのフルテキストインデックスに対しては、それなりの検索時間が必要となってしまうのは自明ともいえました。そして、ついにSQL Server 2012 からは複数スレッドによって検索処理の並列実行が行わるようになりました。これによって、より大きなフルテキストインデックスに対する検索スピードを短縮することでき、スケーラビリティの向上につながります。
マスターマージ処理の並列化
フルテキストインデックスの検索処理と共に、更新処理も並列で実行されるようになりました。
フルテキストインデックスは、フラグメントと呼ばれるデータ構造を使用して管理されています。作成された当初はひとつのフラグメントで構成されています。それが長い期間にわたる運用を経た後では、複数のフラグメントに増えてしまうことが一般的です。それはフルテキストインデックスが参照している元テーブルにデータが追加されたなどの理由によって、新たに小さなフラグメントが追加されていくからです。
複数のフラグメントに増えてしまうことのデメリットは、ディスクに無駄なスペースを占有する点と、メモリ上にも本来であれば不要な領域を使用してしまう点です(メモリ上にロードするフラグメントが増えるため)。
そのような理由から一定期間ごとに、数が増えてしまったフラグメントをひとつにまとめる作業(マスターマージ処理)を運用に組み込むことが推奨されています。
SQL Server 2008 R2 までは、マスターマージ処理がひとつのスレッドだけを使用して行われていました。想像に難くないと思いますが、サイズの非常に大きなテーブルではとても長い時間が必要でした。数日から1週間といった期間が必要となってしまうような場合さえありました。
SQL Server 2012 からは、マスターマージ処理が複数スレッドをつかった並列処理で行われることから、運用作業の負荷を大幅に軽減することができます。
マスターマージ処理を行うためのステートメントは従来と変わりありません。
ALTER FULLTEXT CATALOG フルテキストカタログ名
REORGANIZE
GO
マスターマージ処理の並列度は次のシステムストアドプロシージャで管理します。
