11

最近、HBase (列指向データベースの 1 つ) に取り組み始めました。ソースコードを読んでいると、1 つの疑問が頭に浮かびます。これを尋ねる考え。私の質問は、行指向のデータベースが情報検索 (選択クエリなど) をどのように正確に処理するか、および列指向のデータベースになるとどのように異なるかということです。そして、これらのデータベースが基礎となるフラット ファイルにデータを格納する方法の違い (1 日の終わりに、すべてのデータベースがファイルを使用します)。

この質問のどこかで間違っていた場合に備えて、私を修正してください。

よろしく、クリシュナ

4

3 に答える 3

10

私の理解が正しければ、基礎となるストレージと取得の問題に関心があり、DDL と定義の問題、つまり列指向のデータベースのカテゴリには関心がありませんね。

ベンダーに関係なく、ほぼすべてのストレージが次のような形式であることを理解していると仮定します。

  • インデックスの B ツリー
  • 整理されていないデータのヒープ

その基盤の上に、各ベンダーには最適化と特許取得済みの専門技術があります。例えば。Sybase (行) は次のとおりです。

  • データ行を B ツリーに結合し、ヒープを排除するクラスター化インデックス。

次の問題は、すべてのベンダー (オラクルを除く) がモジュラー設計のかなり洗練されたエンジンを持っており、I/O は速度を得るために低レベルで非同期に処理されることです。I/O の単位はページです。通常、OLTP システムの場合は 2 ～ 8KB、DSS の場合は 8 ～ 64KB です。(行と列の問題を回避していることに注意してください。)したがって、行/列に関係なく、DSS エンジンは大量検索用に構築されています。これは、I/O 要求が少なく、大きなブロックでより多くのインデックス/データ行または列を取得できるためです。

「大規模な I/O」は、エクステント (8 ページ) とより大きな AllocationUnit (256 ページ) を 1 回の I/O 要求でメモリに読み込むことで実行できます。ただし、基本単位はページです。

行と列

  • 行
    • 各行はページ上の連続した単位であり、多数の行がページにパックされます。
    • インデックスの場合、データ構造全体がキーの複合列であるため、それは実際には問題ではありません。インデックス エントリまたはレコードは小さなインデックス エントリ + ポインタであり、より多くのインデックス エントリが同じページにパックされます。
    • 行数が少ない場合は非常に高速です。列集計の要約が遅い
      。
  • 桁
    • 各列は、ページ上の連続した単位です。また、列は数百万のエントリ (行) になる可能性があるため、非常に多くのページに対して実行されます。
    • インデックスは上記の行と同じです。列方向のナビゲーションが高速になるはずの特殊な形式のインデックスが追加されました。
    • それらは柱状の集合体にとって驚異的です。列ベースのデータから行を構築するのが非常に遅い

エンジンに対して実行されるすべてのクエリは、インデックスをナビゲートし、上記のデータ ストレージ構造からデータの行/列を取得する必要があります。

結果は上記の乗算です。

  • 小/大ブロックサイズ、倍

  • 根底にある物理的構造、時代

  • 行/列の向き

それはあなたが探していたものですか？OLTP/DSS の厳密な行指向エンジンである Sybase ASE の上記の一連の技術的な (ウォームでファジーではない) 図があります。興味があれば、私が手に入れることができます。

コメントへの対応

.
つまり、データベースの種類に関係なく、最終的にはページに要約されるということです。

はい。

この場合、データベースのクラスタリングがどのように行われるか。行形式でデータを格納するデータベースを考えてみましょう。このタイプのデータベースのクラスタリングを行っている場合、構造化されたテーブルはどのように正確に異なるノードに運ばれますか (複数のノードがある場合)。このテーブル構造はページにリンクされますか、それとも別のメカニズムを介してリンクされますか。

質問に答える前に、あなたに感謝しなければなりません。あなたのようなレベルの知識を持っている人にとって、あなたがその重要なポイントに到達し、その洞察を得たことは素晴らしいことです. シバキジャイ！

はい、これはクラスター化された DBMS の重要な設計上の問題であり、重要な制限の問題であり、クラスタリングに関連するさまざまな設計上の問題の中でも特に重要です。ベンダーがこの問題をうまく処理すれば、クラスターはうまく機能します。そうでない場合、クラスターは犬の朝食です。

IT のすべては物理法則に支配されています。無料のものはありません。機能のすべての機能には、コスト、処理、またはストレージがあります。MS のマーケティング パンフレットを除いて、魔法はありません。

優れたクラスター化された DB アーキテクチャ

クラスター化された DBMS をすべて知っているわけではありません。私は Sybase CE と Oracle RAC をよく知っています。Sybase IQ の実用的な知識。

  • Oracle RACはずっと以前から存在しており、より成熟しています。この重大な問題をかなりひどく処理します。そのため、最終的にはそれ自体と競合することになり、元の見積もりよりもはるかに多くの CPU パワー (ノードではなくコア、CPU) が必要になります。ノードが多いほど、競合が多くなります。
    .
    Oracle の非 RAC アーキテクチャはくだらない、より正確には存在しないことに注意してください。そのため、RAC には土台となる土台があります。
    .
    言うまでもなく、安定性は死んだクマを吸う.
    .

  • Sybase CEは 1 年しか経っていません。しかし、アーキテクチャは素晴らしく、この重大な問題を非常にうまく処理しています。SAN 上のページのバージョンは 1 つだけです。すべてのノードが SAN に接続されています。どのノードもページを読み書きできます。ノードはプライベート LAN によって接続されます (ネットワーク上の他のすべてで使用される通常のクライアント/サーバー LAN に加えて)。ノードは、ロックに加えて、ロードバランシングなどのためのノード間通信を調整します
    。
    結局のところ、同時実行性を最大にするには、Sybase CE を使用しても、データベースを論理的に分割する必要があります。これにより、各ノードのワークロードが分離され、異なるファイルパスにアクセスするか、共有データベースの物理領域が分離されます。

  • Sybase IQはすでに 100% 列指向です。それは彼らのDWオファリングです。すでに完全な負荷分散を行っています。クラスターとして使用できますが、上記の CE の意味でのクラスター化は使用できません。中に入れるべきだった

貧弱なクラスター化された DB アーキテクチャー

クラスター化された dbms の犬の朝食タイプは、愚かなことをします。いくつかをリストするには：

  • すべてのノードにページを保存します[大量の複製]が、更新されたページをクラスター内で移動する必要があります

  • MVCC を使用して問題を解決します (ただし、MVCC ははるかに多くのオーバーヘッドがあり、実際には同時実行性が低下するため、MVCC 自体が戦っています)

専用 DB サーバーに適していないクラスター

基本的にクラスターは一部のアプリケーションには最適ですが、専用の db サーバー (1 つの事実を 1 か所で管理、共有リソースをまとめて管理、ロックの競合はデータが 1 か所にあるため、1 か所で管理すると最も効率的) には愚かなアイデアです。 ）。db サーバーにクラスターを推奨することは決してありません。

  • SANの問題と同じです。確かに、多くの人がデータベース ストレージを SAN 内に配置していますが、最高速度と、SAN に接続された他のサーバーの負荷の問題からの分離のために、ローカル ディスクに匹敵するものはありません。

  • VMWareの問題と同じ。確かに、多くの人が db サーバーを VMWare ホスト ユニットとして確立していますが、最高速度を得るには、VMWare のオーバーヘッドを取り除きます。シャーシ内の他のホスト ユニットの負荷の問題から分離するには、専用のハード ボックスに移動します。

DB ベンダーがクラスターにこだわる理由

  1. ああ、そこには価値がありますが、今ではなく、将来です。AFAIC、Sybase アーキテクチャは時間の経過とともに優勢になり、他のすべてのアーキテクチャは道に迷うでしょう。すべてのベンダーは通常どおりコピーします。

    Sybase CE の真の力は次のとおりです。

    • true 100% のアップタイム (クラスターにノードを追加し、メンテナンスのために古いノードを停止できる) および

    • 完全に動的な負荷分散 (既存のノードが 4 x クアッド コアであるとします。一時的な 4 x クアッド コア ノードを追加し、古いノードを停止し、2 つのクアッド コアを挿入し、それを起動し、一時ノードを停止します) 60 秒間、どのキーボードにも指がない状態で、獣全体のバランスが再調整されます。

    いくつかの単一ノード サーバーの毎晩のデータベース メンテナンス スケジュールをずらすことができるショップは、かなりの金額を節約できます。イン/アウトを切り替えるための追加のマシンがいくつかあるだけです。

  2. データ ウェアハウスは少し異なります。それらはほとんど読み取り専用です。したがって、クラスターでホストすることは問題ありません (多くのリーダー ノード、1 つのライター ノードのみ、競合なし、ページが読み取られているときにページが書き込まれていることを気にする人はいません)。Sybase IQ はそのような製品です。

列指向の Sybase CE

  1. Sybase IQ はすでに列指向であり、クラスタに展開できますが、前述の CE の意味でのクラスタリングはできません。列はページにマップされます。上記のGood Clustered Db Architectureに含める必要がありましたが、現在修正されています。

  2. 価値のある列指向と行指向を組み合わせたハイブリッドについては知りません。

  3. しかし、その質問に対する完全な答えは、Sybase ASE や ASE/CE などの純粋な Db (DW ではない) を使用し、真の第 6 正規形データベースを実装することです。これは究極のノーマライゼーションであり、削減不可能な NF であり、速度やピボットの容易さなど、いくつかの実質的な利点があります。ページに列指向のストレージを提供します。SQL は 6NF を完全にはサポートしていないため、(格納された) 6NF 構造から 5NF 行を提供するビューを提供する必要があります。開発者が使用する SQL コードを生成できるように、カタログの拡張機能を作成しました。

于 2010-11-11T09:25:31.880 に答える
9

あなたの質問の問題点の 1 つは、長年のデータベース用語である「列指向」が、NOSQL コミュニティによって、本来の意味とはまったく異なるものを説明するために流用されたことです (「乗っ取られた」と言う人もいます!)。「列指向」の両方の意味は現在でも最新のものですが、非常に異なる DBMS 製品を指しています。そのため、どちらについて話しているのかを明確にすることが役立つことがよくあります。この場合、それは用語の NOSQL の意味です。

列指向データベースの本来の意味では、あなたの質問に対する答えは、情報を取得する方法に違いはないということです。列ストアは別のデータ モデルではなく、単に内部ストレージの別のタイプの表現です。

ただし、NOSQL コミュニティでは、列ストアという用語は別の種類のデータ モデルを指します。

ここに良い説明があります：

http://dbmsmusings.blogspot.com/2010/03/distinguishing-two-major-types-of_29.html

于 2010-11-11T07:44:42.697 に答える
2

行指向のデータベース、別名「従来の RDBMS」(MySQL、Oracle、DB2 など) は、トランザクションのセカンダリ インデックス更新を使用し、ほとんどの場合、セカンダリ インデックスに B-Tree のような構造を使用します。

列指向データベース、別名「NoSQL」(Google Big Table、HBase、Cassandra など) は、主キー インデックス (B ツリーではない) に単純化された構造を使用します。

列指向のデータベースは、「従来の」トランザクション セカンダリ インデックスをサポートしていません。「逆インデックス」を維持することは、ユーザーの責任です。

Cassandra は、行の B-Tree のようなインデックスをサポートしています。行の各セルにはタイトルがあり、セルはタイトルによって物理的に並べ替えられます。

もう1つの（おそらく非常に重要な）違い：Oracleの無数のレコードの場合、主キーのBツリーを維持する必要があり、そのサイズも無数のようになります。「主キーで検索」のパフォーマンスが良くありません。

一方、Cassandra または HBase で「幅の広い行」を作成し、同様の「セル」を単一の幅の行にまとめることができます。「主キー インデックス」のサイズは数百万分の 1 になり、「主キーによる検索」は超高速です (B ツリーではなく、クラスター化された検索です)。

于 2012-12-05T16:38:43.143 に答える