データウェアハウスを複数のデータベースに分割する主な理由は何ですか？
私は、開発用に1つのインスタンスデータベースを約7つのデータベース（データドメインで分割）に、本番用に7つの同一のデータベースに分割することを提案している同僚と協力しています。テストとプロダクションの双対性ロジックを取得しましたが、1つの比較的単純なデータベースを7つのデータベースに分割すると、どのような場合にどのような利点がありますか？私たちのデータウェアハウスは、1つのビジネスインテリジェンスアプリケーションでのみ使用/使用されます。
私はこの方向性を懸念しているので、うまくいけば、この分割について提案された一般的な理由を説明でき、データベースの現在のプロパティの概要を説明できます。
1データベースデータウェアハウス：合計352 GB、203テーブル、170ビュー
分割案：
A: 280 GB
B: 43 GB
C: 28 GB
D: 1 GB
E,F,G: < 1 GB combined
ご覧のとおり、ストレージはリモートで均等に分割されず、80％が1つのデータベースに残っているため、これは提案されている利点の点ですでに頭を悩ませています。エンタープライズレベルのSQL Serverがないため、ハードウェアの観点から、dbをスキーマでパーティション分割することはできません。
分割の理由：
- 現在のdbは最適化が不十分で、ドキュメントがほとんどなく、データ型が最適ではなく、インデックスが最適ではありません。
私の新人の考え：これらの問題はデータベースの分割と無関係ではないですか？それらは単に自分で解決する必要のある問題です。
- 現在のデータベースには372個のオブジェクトがあり、処理が遅くなっています。
私の考え：これは、私の考えではほとんど大きく思えません。
- 1つのデータベースでは、7つのデータベースよりもスキーマ図を文書化して描画することが困難です（複数のデータベースにまたがるビューがあります）。
私の考え：....これは完全にばかげているように見えますが、おそらく私は間違っています。データウェアハウスは、13の「ソースシステム」スキーマによってすでに構成されています。
- 1つのデータベースは、より多くのデータベースのデッドロックにつながります。
-この問題も、複数のデータベースを持つこととはまったく関係ありませんか？デッドロックがテーブルレベルで発生することは私の理解です（実際には通常、行レベルだけですが、ええと）。それでも、すべてのデータ挿入は真夜中に発生し、BIへのダウンストリームのすべての選択は午前2時に発生します。 2つのプロセスが同じテーブルを更新することは、複数のデータベースとは関係ありませんが、そうではありません（デッドロックはどちらの方法でも発生します）。また、個人的には、通常の操作中にテーブルのデッドロックが発生している証拠はありません。
- データベースの技術所有権/所有権。
データベースで作業するのは2人だけです。彼が本当に私たちの「領地」を分離したいと思う可能性があります。本当に問題はありませんでしたが、ユーザー権限をスキーマレベルで決定することはできませんか？
データウェアハウスを複数のデータベースに分割する正当な理由は何ですか？
ここで、データベース全般に関する私の知識をさらに深めたいと思います。はい、たまたま自分の知識にギャップのあるものに対して多くの作業を行っていますが、仕事はそれが何であるか、私が突き刺したものです。これまでのところ、スタッフは素晴らしい仕事をしています（木のノック）。
あなたは間違いなく正しい軌道に乗っています！データベース、特にDWの場合、320GBはそれほど大きくありません。
1）現在のデータベースは最適化が不十分で、ドキュメントがほとんどなく、データ型が最適ではなく、インデックスが最適ではありません。
私の新人の考え：これらの問題はデータベースの分割と無関係ではないですか？それらは単に自分で解決する必要のある問題です。
これはお金の強打です。構成が不十分で最適化および文書化された1つの大きなデータベースを7つの組織化および最適化および文書化されたデータベースに分割することは、時間の無駄です！問題の根本に取り組む必要があります！
2）現在のデータベースには372個のオブジェクトがあり、処理が遅くなっています。
私の考え：これは、私の考えではほとんど大きく思えません。
もう一度、あなたは正しいです！ 372はオブジェクト数の点で明らかに小さいです-多くの大きなサーバーは数十万を持っています。から ここ
データベース内のすべてのオブジェクトの数の合計は、2,147,483,647を超えることはできません。
あなたの370を〜2E9〜= 1.7E-7で割ったので、そのスコアは心配ありません！ :-)
3）1つのデータベースは、7つのデータベースよりもスキーマ図を文書化して描画することが困難です（複数のデータベースにまたがるビューがあります）。
私の考え：....これは完全にばかげているように見えますが、おそらく私は間違っています。データウェアハウスは、13の「ソースシステム」スキーマによってすでに構成されています。
繰り返しますが、あなたは正しいです。それらの間に相互関係がある372のエンティティがある場合、それらを文書化して図表化する必要があります。固有の複雑さを持ちます。あなたができることは、システム全体をサブシステムに分割して文書化し、それらを全体像に合わせようとします-小さなドングリからの大きなオーク成長する！
4）1つのデータベースにより多くのデータベースデッドロックが発生します。
-この問題も、複数のデータベースを持つこととはまったく関係ありませんか？デッドロックがテーブルレベルで発生することは私の理解です（実際には通常、行レベルだけですが、ええと）。それでも、すべてのデータ挿入は真夜中に発生し、BIへのダウンストリームのすべての選択は午前2時に発生します。 2つのプロセスが同じテーブルを更新することは、複数のデータベースとは関係ありませんが、そうではありません（デッドロックはどちらの方法でも発生します）。また、個人的には、通常の操作中にテーブルのデッドロックが発生している証拠はありません。
複数データベースのシナリオで失うのは、同じスキーマ内のACIDトランザクションです。2フェーズコミットを使用できますが、同じスキーマ内のトランザクション（IMHO）ほど堅牢ではありません。テーブルが要件に必要な場合、テーブルをHiveから除外する正当な理由はわかりません。
書き込みが読み取りをブロックしていることについて話しているように見えますか？さて、あなたはまた、深夜にバッチ処理を行い、その後02:00にクエリ処理を行うように見えますか？トランザクション/テーブルを読み取り専用にできる場合は、サーバーエンジンがデータを処理しているときに、サーバーエンジンからある程度の負荷がかかります。これがあなたのシナリオに適用できるかどうかはあなただけが知ることができます！
5）データベースの技術所有権/所有権。
データベースで作業するのは2人だけです。彼が本当に私たちの「領地」を分離したいと思う可能性があります。本当に問題はありませんでしたが、ユーザー権限をスキーマレベルで決定することはできませんか？
確かに、所有権はテーブルレベルであり、サーバーやバージョンに応じて、列レベルや行レベルでアクセス権を付与できます。そのため、所有権のビジネスは完全な赤のニシンです。サーバーDBAが再編成を実行している場合（単にバックアップやその他の日常的なタスクをスケジュールするのではなく）、「すべての領域にアクセスする」必要があります。
あなたはあなたのシステムのすべてのテーブルとフィールドにコメントをするべきです-あなたはそこに「所有権」を置くことができます（データベースの感覚とは対照的に組織的）-コメントテーブルとフィールドはです優れたシステムを文書化する最初のステップ-それは自己文書化になります！
データウェアハウスを複数のデータベースに分割する正当な理由は何ですか？
多くの理由が考えられます。いくつかは multi-tenancy に関連付けられています（マシンリソース（CPU、RAM、HDD、ネットワークの両方）とクライアントの機密性または要件の両方の点で。こことgoogleも参照してください）データベースマルチテナンシー」または同様の。
誰もがそれを言うが、それは苦労です-「文書化は非常に重要です」！最初のステップとして、コメントにテーブルとフィールドを文書化します。すべてのサブシステムのERD図を作成します。これらの手順を実行せずに、システムに何か新しいものを許可しないでください。あなたの新しい役割で最高の幸運を！
それは古典的な straw man 戦術が同僚に取られているように聞こえますが、「データウェアハウスを分割する」と言ったときに正式なデータマートの作成を意味するのでしょうか？
データウェアハウジングへの2つの主要なアプローチは、 Ralph Kimball および Bill Inmon によるものです。書き込みに数分かかる場合の、これら2つの一般的なアプローチの違いに関する概要の概要（ [1] 、 [2] ）を以下に示します。 。
あなたの状況に当てはまると私が信じているのは、Bill Inmonのアプローチが、レポートツールが引き出すData Martsの正式な作成を要求していることです。 ）からのデータ。これらのData Martsは、特定の部門またはビジネスユニットが排他的にアクセスできるように設計されており、同僚がこれに向かっているのかもしれません。コピーの同一の性質は奇妙ですが、現在の形式でデータウェアハウスのコピーを作成してから、特定の部門のデータのみを前述のコピーにロードする方が簡単かもしれません。
あなたが提供したものから、現在のデータウェアハウスはキンボールのアプローチを使用しているようです（ここでData Martsは次元データ内のデータの論理サブセットです）レポートツールが直接アクセスする倉庫。これらの2つの設計アプローチには長所と短所があり、うまくいけば、同僚の問題の核心は、彼または彼女がInmonのアプローチをより快適にすることです。
うまくいけば、これは単に用語の誤解であり、同僚とのこれら2つの異なるアプローチの詳細な議論は、彼または彼女が過去に移動しようとしているハードルについてのいくつかの説明につながるでしょう。