大規模なデータベース（数百ガガバイト以上）のバックアップは、1つの簡単な理由からかなり役に立たない演習です。バックアップからの復元には数日かかる場合があります。 データベースがビジネスに絶えず使用され、データが連続ストリームでデータベースにロードされる場合、これは受け入れられません。 バックアップシステムへの増分バックアップの場合は、バックアップの上で直接有効にできる状況が多少良くなります。 ただし、この方法はすべてのデータベースに適しているわけではなく、ディスクに書き込まれたファイルを変更しないデータベースにのみ適しています。 たとえば、MySQLの場合、この方法は適切ではなく、すべてのテーブルは単一のテーブルスペース（InnoDB）にあるか、個別のファイル（MyISAM）にあります。 Vertikaの場合、これは可能なオプションです。データは非個人的なファイルに記録され、記録後には変更されず、削除されるだけです。 ただし、クラスターシステムの場合は、プライマリシステムとバックアップシステムのトポロジを同一にする必要があります。 プライマリシステムに障害が発生した場合、データの整合性に問題がある可能性もあります。
バックアップシステムを維持するためにレプリケーションが使用される場合があります。 ただし、バイナリログを書き込む必要があるため、レプリケーションはパフォーマンスを大幅に低下させることを理解する必要があります。レプリケーションが同期の場合は同期が必要です。 大量のデータフローを伴う分析アプリケーションでは、1秒間に数千または数万のレコードをデータベースに絶えずロードする必要がある場合、これは受け入れられない可能性があります。
どうする？ かなり前に、データベースレベルではなくソースレベルで発生する、システムのクローン作成または多重化のメカニズムを考え出し、実装しました。 相互接続されていない複数の「ほぼ」同一のシステムをサポートしますが、同じデータを同じ方法でロードします。 ユーザーが分析データベースに直接何かを直接書き込むことはないため、これを行うことができます。 このようなクローンには、もう1つの重要な利点があります。実際の戦闘データと負荷を備えた1つ以上のテストシステムを使用できます。 もう1つの利点は、ステージング展開とQAです。 新しい機能を備えたシステムの動作を現在の戦闘と比較して、エラーを時間通りにキャッチできます。
そのため、クローンを作成すると次のことが可能になります。
- 永続的に準備ができているライブバックアップシステムまたは複数の
- 異なる目的または負荷分散のために同一のシステムを使用する
- データが同じで設定が異なるシステムがある（たとえば、軽い要求または重い要求に対して最適化されている）
- 戦闘データと負荷を備えたテストシステムを用意する
- 新しい機能を段階的に展開して、エラーのリスクを減らします
- あるシステムを別のシステムのデータで復元する（コピー）
- すべてを透過的に管理
そして、これらすべてはパフォーマンスのペナルティーなしで、最小限のリスクで行われます。 ただし、言及すべき問題もあります。
- システム間のデータ整合性の監視
- 新しいシステムをゼロから開始する
これらの問題の両方を100％の精度で解決することは非常に困難ですが、必要ありませんでした。 経済的に重要な統計が一致すれば十分であり、詳細なデータはわずかに異なる場合があります。 どちらの場合も、ライブシステムで意味のあるデータをコピーすることにより、データの同期を行うことができます。 したがって、正確なコピーを取得するかどうかを選択するための完全な制御とスペースが常にありました。
説明されているアプローチは、何度も助けてくれました。 さらに、彼はシステムを異なるデータベース（異なるベンダー）に配置することを許可しましたが、同じアルゴリズムを使用していました。 したがって、あるデータベースから別のデータベースへの移行を簡素化します。
更新：コメントを受け取った後、いくつかの明確化が必要でした。
おそらく、どのような種類のデータを処理するのかを開始して書く価値がありました。 提案されたアプローチはさまざまなケースで機能するものと確信していますが、詳細は害になりません。
数種類のソースからのデータを処理し、ストレージにロードします。 これは：
- 広告キャンペーンインプレッションの統計とコンテキストを登録するランタイムサーバーからのログ
- ログを正しく解釈できるようにするオントロジーと説明
- パートナーのサイトからのデータ
このデータはすべてリポジトリにアップロードされ、顧客、パートナー、所有ユーザー、および表示する対象、場所、方法に基づいて決定を行うさまざまなアルゴリズムによって使用されます。 データベースの障害は、ビジネスを停止してお金を失うだけでなく、障害中に蓄積されたデータを「追いつく」必要があることも意味します。 そして、効率は非常に重要です。 したがって、バックアップシステムの問題はアイドル状態ではありません。
データ量が多い。 生ログは1日に数テラバイトを消費しますが、処理された形式でははるかに少なくなります。 戦闘基地は着実に成長しており、現在は数テラバイトを消費しています。
ソースレベルでのクローン作成または多重化は、バックアップの問題を解決するための優れた、シンプルで比較的安価な方法であり、多くの利点もあります。 この記事の目的は、具体的な実装ではなく、実用的なアイデアを説明することでした。 このアイデアの適用可能性は、ストア内のデータがETLを介してのみダウンロードされる場合に非常に一般的です。