私の新しい会社では、インポート、ステージング、監査、ディメンション、ファクトテーブルなど、データウェアハウスに関連付けられているすべてのデータを同じ物理データベースにまとめています。
私は何年もの間データベース開発者であり、この機能と形式の統合は私が知っているすべてに反しているようです。
これにより、セキュリティ、バックアップ/復元、およびパフォーマンス管理の問題が手動で集中的に発生するようです。
これは業界で行われていることですか？それをするかしないかの実質的な理由はありますか？
プラットフォームはNetezzaです。サイズはテラバイト、数億行です。
この質問への回答から私が得ようとしているのは、この道がどれほど正しいか間違っているかをしっかりと理解することです。あなたの経験から、これが将来私たちに問題を引き起こす道であるかどうかを議論するために私が焦点を当てるべき問題は何ですか。大したことではないのなら、それも知りたいです。
すべてのセグメント（在庫、CRM、請求...）にデータベースを使用します。パフォーマンスの欠点はなく、メンテナンスと概要ははるかに優れています。
一般的には、別のデータベースを使用することをお勧めします。これは私が本番環境で常に使用しているのを見た構成であり、あなたが言ったように、両方のデータベースは根本的に異なる目的/使用パターンなどを持っているので、それは本当に非常に理にかなっています。
遅れるよりはましですが、Netezza の場合:
クロス データベースのクエリ中にパフォーマンス ヒットはありません。Netezza ではSELECT、データベース間の操作、 no INSERT、UPDATEまたはDELETE許可されたステートメントのみが許可されます。
これは、次のことができないことを意味します。
THISDB(ADMIN)=>INSERT INTO OTHERDB..TBL SELECT * FROM THISDBTABLE;
\c OTHERDBしかし、あなたはそれを行うことができます
OTHERDB(ADMIN)=>INSERT INTO TBL SELECT * FROM THISDB..THISDBTABLE;
また、クロスデータベース オブジェクトでマテリアライズド ビューを作成することもできません。次に例を示します。
OTHERDB(ADMIN)=>CREATE MATERIALIZED VIEW BLAH AS SELECT * FROM THISDB..THISDBTABLE;
管理は、作成するデータベースの種類を決定する場所である可能性があります (おそらく、かなり前に既に決定していますが)。インフラストラクチャによっては、TEST/QA システムと PROD システムが同じボックスにある場合もあれば、別のボックスにある場合もあります。
1 つの物理サーバーを使用している場合、そのサーバー上のインスタンスが少ないほど、管理が簡単になり、プロセスがより効率的になります。
2 つのインスタンスを同じ物理サーバーに置くと、次のようになります。
ネガ:
良い点:
では、停止ウィンドウと CPU とメモリのどちらがあなたにとってより重要でしょうか?
同じ物理サーバー上で複数のインスタンスを使用すると、パフォーマンス管理の問題を手動で解決することがはるかに難しくなります。インスタンスの 1 つの正常性を見ると、問題ないように見えるかもしれませんが、ユーザーはパフォーマンスの低下を報告しているため、次のインスタンスを調べて、問題がそこから来ている可能性があるかどうかを確認する必要があります... など、インスタンスごとに.
複数のインスタンスがあると、セキュリティも難しくなります。せいぜい単一のインスタンスと同じくらい難しいですが、決して簡単ではありません。2 つの管理者アカウント (SYS など)、複製プロセス アカウントなどがあります。
複数のインスタンスを持つ方がよいと考える理由を教えてください。
条件を明確にできますか。「同じデータベース内」と言うとき、同じインスタンスまたは同じ物理サーバーを意味しますか。ステージングを新しいインスタンスに移動した場合、同じ物理ハードウェアに存在しますか?
人々はインスタンスにこだわりすぎていると思います。同じハードウェアに 2 つのインスタンスを配置する場合、すべての数が 2 倍になるだけで、ほとんどメリットがありません。すべてのサーバー プロセスが 2 回実行され、すべてのメモリ プールが半分に削減されます。
つまり、2 つの別々の物理的なボックスを本当に意味していたとしましょう...
12 ウェイ ボックスを 2 つ購入するとします (簡単に説明します)。その日の db サーバーのステージングが完了すると、これらの 12 個の CPU が浪費されます。ユーザーが荷物をまとめて家に帰ると、製品 DW CPU が浪費されます。CPU サイクルは壊れやすく、元に戻すことはできません。しかし、24 ウェイ ボックスが 1 つある場合、ステージング DB は夜間に 20 個の CPU を使用してサマリー テーブルを構築するための優れた並列実行を行うことができ、ユーザーは日中のプロセスの容量を 2 倍にすることができます。
つまり、同じハードウェアを意味していたとしましょう。
「これにより、セキュリティ、バックアップ/復元、およびパフォーマンス管理の問題がより手動で集中的に行われるようです。」
同じハードウェアを共有するインスタンスが多いほど、パフォーマンスの問題を解決するのが難しくなることが保証されています。保証します。
安全
インスタンスレベルでどのようなセキュリティを行っていますか?
バックアップ
インスタンス レベルでバックアップしている DW は何ですか? テーブルスペースではなく、インスタンス全体をバックアップしていますか? そのパターンは特定のサイズで失敗するようです。
プラットフォーム: NETEZZA
特にツールに精通していません。したがって、単一のボックスの単一のインスタンスである場合、分割は物理的というよりも論理的に見えるため、それらが存在する理由はパフォーマンスではなく管理のためです。データベースを追加しても、CPU やメモリを増やすことはできませんよね? そのため、それに勝るパフォーマンスがないようには見えません。各 DB が個別のプロセスを追加している (パフォーマンス ヒット) か、Oracle のスキーマのように完全に論理的である可能性があります。各データベースが新しいプロセスによって管理されている場合、それらの間を移動するデータは IPC を意味します。
たぶん、Netezza タグの追加が何らかの牽引力になるでしょう。
考慮すべき点 a) 1 つまたは複数のステージング、監査、ディメンション、およびファクト テーブルのデータを結合する必要がある場合は、それらを 1 つのデータベースに保持することをお勧めします。
b) 通常、ディメンション テーブルとファクト テーブルを同じデータベースに保持し、最も頻繁に結合される列に分散して、Netezza の「共存結合」機能を活用します。
c) すべてのオブジェクト (DB、テーブル、ビューなど) へのアクセスを管理するために、SQL 付与パーミッションを使用できる必要があります。
テーブルが同じスキーマ (データベース) にある場合、読み込みと出力の速度が向上します。当たり前のことだけど……言っちゃった。
1 つのスキーマに入れるテーブルが多いほど、オーバーヘッドが大きくなります。バックアップ時間、バックアップのサイズ、使いやすさ。
私がいる場所では、1 つのデータ ウェアハウス内に複数の TB データベースが多数あります。私たちの経験則では、単一の読み込みプロセスまたは単一のレポート クエリがデータベースにまたがる必要はありません。これにより、「同様の」テーブルがまとめられますが、バックアップと不測の事態のプロセスにある程度の余裕が生まれます。また、データの「検索」も少し簡単になります。
この規則を破る必要があるプロセスについては、あるデータベースから別のデータベースにデータを移動するか、プロセスがスキーマ間で結合できるようにします。
私は Netezza に詳しくないので、どのような選択肢があるのか 100% 確信が持てません。