OracleをPostgreSQLに置き換え、DLPシステム内のパーティショニングを操作する機能

今日は、DLPソリューションにとって非常に重要なトピック、つまりデータストレージ用のDBMSの選択に触れたいと思います。 歴史的に、ロシアのほとんどのDLPはこれらの目的でOracleデータベースを使用していました。 これにより、特定の財務上の制限が顧客に課せられます。Oracleライセンスのコストは、DLPシステムのコストに計上されます。 これにより、製品ユーザーのオーディエンスを減らす特定のフィルターが作成されます。技術的にも経済的にも、誰もがOracle DBMSを購入できるわけではありません。

現在、輸入代替が国内を移動するとき、公共部門は（だけでなく）無料のDBMSをサポートするDLPの需要を生み出しています。 これは非常に具体的な衝動ですが、無料のDBMSに急いでいるため、製品の利便性、パフォーマンス、機能を維持することが重要です。 この記事では、PostgreSQLサポートを実装し、Solar Dozorでパーティションスキームを開発して、この問題をどのように解決したかについて説明します。

Oracle vs PostgreSQL

Solar Dozorシステムは、リレーショナルDBMSをメインストレージシステムとして使用します。 最近まで、DBMSを選択するための基準は非常に単純でした。つまり、ボリュームと、アーカイブを運用可能と「オンデマンド」に分割する能力です。

データベースのボリュームに関して、経験的に導き出された特定の制限がありました。3〜4 TBを超えてはなりません（これは約500万件の傍受メッセージです）。 これらの値を超えると、システムの大幅な低下が観察されました。古いデータを削除するクエリを定期的に実行する必要があるためにIOに負荷がかかり、バキューム処理が行われ、クエリの実行速度が低下しました（大きなサンプルでは、​​テーブルは実際に完全にスキャンされました）。 したがって、必要なボリュームの推定値がこれらの数値を超えた場合、データストレージには常にOracle DBMSが使用されました。

2番目の基準-アーカイブを運用と「オンデマンド」に分割する能力は、DBMSでパーティションを実装する必要があると読むことができます。 2016年まで、Solar Dozor DLPシステムは、Oracle DBMSでのパーティショニングのみをサポートしていました。

お客様の予算は限られており、場合によっては単にOracleライセンスを購入する余裕がないこともありました。 そのため、10〜15 TBのストレージ容量を持つ一部のプロジェクトでは、PostgreSQLの使用を開始しました。

PostgreSQLでのパーティション分割の実装方法

Solar Dozorシステムのアーキテクチャと機能により、OracleとPostgreSQLの両方のデータベースをいくつでも接続できます。 同時に、データベースごとに、データベースで検索するか、メッセージをアーカイブするかを指定できます。 そのため、最初に1つまたは異なるサーバー上に複数のPostgreSQL DBMSインスタンスを作成し、1か月ごとに順番にデータを書き込むことにしました。 保管期間の終了後、最も古いベースが再作成されました-等々。 しかし、このソリューションはサポートの点で非常に高価であり、非常に狭い顧客層にのみ適していました。

データパーティショニングの次の実装も「1つのセクション-1つのデータベース」という考え方に基づいて構築されましたが、現在はすべてのデータベースが同じPostgreSQLインスタンス内に作成されています。 対応するユーティリティは、セクションを含むすべての操作用に作成されており、このようなスキームは複数の顧客にとって非常にうまく機能しました。 それに基づいて、一部はOracleに移行しました。

ただし、この実装には、Solar Dozorの多くのサービスの機能に関連する多くの問題がまだありました。 多数のセクションがある場合、インスタンスごとに同時に1000以上の接続を維持する必要がありました。 さらに、新しいリリースがリリースされたときにデータスキーマを更新することはあまり便利ではありませんでした。

最終的に、PostgreSQL自体が提供するパーティション分割を使用することにしました。 つまり、メッセージが配置された日付を参照するキーがあるすべてのテーブルについて、このキーに制限を加えた継承ラベルが作成されます。 データは、セクションごとに個別に作成されるトリガーによって、目的のテーブルセットに配置されます。 このようなスキームにより、必要なすべての機能が提供されます。クエリを実行すると、要求が行われている期間中、それらのデータセクションのみがディスクから生成されます。 セクションを循環から削除する必要がある場合、テーブルは基本継承から削除され、その後ダンプされます。 管理ユーティリティは、オフライン/オンライン翻訳、追加、削除、ダンプなどのすべてのセクション用に作成されています。

この実装はOracleの真の代替となり、数十テラバイトのデータをオンラインで保持し、低速のストレージシステムのアーカイブに数十個のデータを保持できるようになりました。 すべての新規顧客に、PostgreSQLでのパーティション分割を提供しています。 Oracleパーティショニングを使用している既存のお客様がPostgreSQLに切り替えたい場合は、新しいデータをPostgreSQLに書き込み、古いデータは廃止されるまでOracleに残すことをお勧めします。

特に顧客が製品の古いバージョンのデータを無効にしている場合、開発と実際の移行作業の両方が非常に高価であるため、OracleからPostgreSQLへの特別なデータ移行手順を記述することは不適切であることがわかりました。 そして、そのようなリクエストはほとんどありません。

DLPシステムでデータベースパーティショニングを使用して達成されたこと

生産性を向上

傍受されたメッセージはすべてDLPシステムに保存されます。 DLPタスクの場合、情報がいつ送信され、傍受されたかを知ることが重要です。 したがって、インターセプトされたすべてのメッセージにはタイムラインへの明確なリンクがあります。 したがって、傍受の日付、より正確には、傍受の瞬間に最も近いものとしてDLPシステムで処理するメッセージの受信の日付によるRANGEパーティショニングを使用します。 そのため、パーティション分割を使用する場合、データは期間ごとに細分化されます。 通常、1週間の期間が使用されます。

このような内訳の利点は何ですか？ ほとんどの場合、DLPシステム内の要求は、非常に限られた短い期間だけ行われます。 したがって、3〜6か月間データを保存し、1-2〜4週間情報を要求すると、ディスクシステムから読み取られるデータが少なくなるため、ソリューションの速度が大幅に向上します。 パーティション化された回路とパーティション化されていない回路の両方が、かなりの数の異なるインデックスを並列に構築することは明らかです。 ただし、ここでは、フルスキャンを実行する必要があるか、インデックスを使用する方が良いかは、DBオプティマイザーに任せています。 パーティショニングが使用される場合、限られた量のディスクスペースを占有する、常にかなり明確なデータの一部になります。

管理作業の軽減

クエリ実行速度は、パーティション分割を使用する利点の1つにすぎません。 もう1つの利点は、データ保持期間の管理を大幅に簡素化する機能です。 パーティショニングがない場合、古いデータを毎日または毎週削除するように要求する必要があります。そうしないと、データベースの特定のボリュームに達すると、パフォーマンスとメンテナンスの問題が始まります。 パーティショニングは、特定のセクションの古いデータの削除をより単純な削除操作に減らします。 Oracleでは、このために2つのパーティションテーブルスペースとそれらのデータファイルをディスクシステムから削除するだけで十分です。 PostgreSQLでは、このセクション用に作成されたデータベースを削除する必要があります。

今後のSolar Dozorリリースでは、継承テーブルを使用する標準的な方法を使用して、PostgreSQLのパーティション分割が実装されます。 したがって、新しいバージョンでは、セクションを削除すると、このセクションを担当するテーブルが削除されます。

データストレージコストを削減する

DLPでのデータパーティショニングの大きな利点は、データアーカイブを運用可能な、いわゆる「デマンドアーカイブ」に分割できることです。 この分離の本質は何ですか？

ほとんどのお客様にとって、直近/運用アクセスで過去3〜6か月のデータを傍受することが重要です。 この期間よりも古いものは、一般的に削除する準備ができています。 ただし、多くの人は、傍受したメッセージの全量に基づいて調査を実行できるように、このデータを保持したいと考えています。 これは、会社の内部セキュリティ標準と、多くの標準に準拠するための要件の両方によって決定されます。 長い保存期間には、数十テラバイトのディスク容量が必要です。 さらに、SAS 10kディスクは通常オンラインアーカイブ用に設計されており、これらの数十テラバイトの入力は非常に高価です。 パーティションスキームでは、運用上の可用性の期間を超えたデータを検索エンジンから簡単に切断し、低速で安価なストレージシステムに配置できます。 多くのお客様がオフラインアーカイブストレージ用にSATAディスクを購入していますが、他のお客様はテープライブラリを使用しています。これは、全ストレージ期間中に数回だけ必要となる200〜300テラバイトのデータを保存する必要がある場合に特に重要です。 次の方法で実装されます。

オラクル
廃止されたセクションの表スペースはオフラインで転送され、その後、このセクションのデータファイルは、それらのために準備されたストレージに転送されます。 切断されたセクションに関連する期間を検索する必要が生じた場合、データファイルが戻され、セクションが接続され、クエリを実行できます。 その後、セクションはオフになり、格納されます。

PostgreSQL
廃止されたセクションはオフラインに切り替えられ、このセクションを担当するテーブル（またはデータベース）をダンプ（pg_dump）し、データベースからこれらのテーブルを削除します。 ダンプは、準備されたオフラインストレージに保存されます。 さらに、Oracleとの類推により、このデータが要求されると、削除されたテーブルはダンプ（pg_restore）から復元されます。 セクションはオンラインで転送され、その後、セクションを検索できます。 調査の最後に、セクションがオフラインになり、テーブルが削除されます-場所が解放されます。

これらすべての切断/接続操作を実行するには、資格のあるOr​​acleまたはPostgreSQL DBMS管理者である必要はありません。 これを行うには、セクションのステータスの表示、接続、切断、削除などを可能にする特別なユーティリティがあります。 Oracleの場合、セクションを切断/接続し、セクションを別のディレクトリに移動する操作の一部は、Webインターフェイスから直接利用できます。 DBMS内でパーティションを作成および無効化する自動化により、メンテナンスの人件費の問題がなくなります。 残っているのは、無効なセクションを準備済みリポジトリにコピーすることだけですが、管理者の特別な資格は必要ありません。

まとめ

その結果、Solar Dozor DBMSのパーティショニングのおかげで、製品のパフォーマンスと検索速度が向上しました。 アーカイブの管理が容易になりました-傍受したデータは簡単にアンロードされ、ディスクリソースが解放され、必要に応じて元に戻されます。 これらはすべて自動的に行われるため、DBMSを管理するために別の資格のある専門家を雇う必要はありません。 最後に、顧客はデータを任意の期間保存でき、同時にストレージシステムに多くを費やす必要はありません。