問題タブ [column-oriented]

私は現在、Webアプリケーションのパフォーマンスを改善しようとしています。アプリケーションの目的は、を提供すること(real time) analyticsです。star schemaいくつかのファクトテーブルと多くのディメンションテーブルに類似したデータベースモデルがあります。データベースはMysqlとMyIsamエンジンで実行されています。
ファクトテーブルのサイズは簡単に数百万を超える可能性があり、一部のディメンションテーブルも数百万に達する可能性があります。
ここで重要なのは、ディメンションテーブルがファクトテーブルに結合され、集計が行われると、selectクエリが非常に遅くなる可能性があるということです。これを聞いて最初に頭に浮かぶのは、データを事前に計算してみませんか？ユーザーは自由にカスタマイズ可能な複数のフィルターを使用できるため、これは不可能です。

ですから、私が必要としているのは、あらゆる目的に適したオールインワンシステムです;）残念ながら、それはまだ発明されていませんでした。そこで、2つの既存のシステムを組み合わせるというアイデアにたどり着きました。row orientedaとcolumn orientedデータベースの混合（例：infinidbまたはinfobright）。mysql MyIsamソリューション（高速挿入および行ベースのクエリ用）を維持し、列指向データベース（いくつかの列での高速集計操作用）を追加し、cronjobを介して定期的に（毎晩）入力します。問題は、現在のデータ（リアルタイムである必要があります）が照会される場合です。したがって、両方のデータベースからデータを取得する必要があり、複雑になる可能性があります。

infinidbを使用した最初のテストでは、いくつかの列の集計で非常に優れたパフォーマンスが示されたため、これがアプリケーションの高速化に役立つと思います。

だから問題は、これは良い考えですか？誰かがすでにこれを行ったのでしょうか？たぶんそれを行うためのより良い方法があります。

私はまだ列指向データベースの経験がなく、そのスキーマがどのように見えるかもわかりません。最初のテストでは、同じstar schema like構造だけでなく構造でも良好なパフォーマンスが示されましたbig table like。

この質問がSOに当てはまるといいのですが。

MonetDBを使った経験はありますか？現在、MySQLデータベースが大きくなりすぎて、クエリが遅くなりすぎています。列指向のパラダイムによれば、挿入は遅くなりますが（私はまったく気にしません）、データの取得は非常に速くなります。MonetDBに切り替えるだけで、データ検索のパフォーマンスが向上する可能性はありますか？MonetDBは十分に成熟していますか？

C-storeに掲載された論文に従って、私はその部分を理解していませんでした

最も有利な射影を使用してクエリを解決できるように、異なる順序でいくつかの重複する射影に表の要素を冗長に格納します。

まず、データベーステーブルの「冗長」列を構成する列がどのように導出されるのか理解できませんでしたか?

次に、上記の点に関して、「冗長」とマークされたこれらの列は、テーブルに作成されるすべてのプロジェクションに格納する必要がないことを理解しています。クエリがそのような列を要求する場合、クエリに応答するために必要なのは射影の 1 つだけです。私は正しいですか？

インターネットでいくつかの論文やドキュメントを読んで、Cassandra データ モデルに関する多くの矛盾した情報を見つけました。それを列指向のデータベースとして識別し、他の人は行指向として識別し、両方のハイブリッドな方法として定義する人がたくさんいます。

Cassandraがファイルを保存する方法について私が知っていることによると、*-Index.dbファイルを使用して*-Data.dbファイルの正しい位置にアクセスし、そこにブルームフィルター、列インデックス、そして列を保存します必要な行。

私の意見では、これは厳密に行指向です。足りないものはありますか？

これは、InfragisticsUltraWinGrid列に関連する質問です。

Infragistics2.Win.UltraWinGrid.v10.3を使用しています

画像でわかるように、列は上にあり、左から右にまたがっています。

上から下にまたがる左側の列で同じデータを表示できますか？

設定はどこですか？
ありがとう。

ドキュメント指向の NoSQL DB は、単一のルックアップ キー以上のクエリを実行できるという点で、KV モデルの「拡張」であることを理解しています。しかし、何かが「ドキュメント」になると、すでにリレーショナル モデルが組み込まれているように感じます。

私には、この JSON と、 andフィールドjson_objectsを持つテーブル、および 2 番目のテーブルへの外部キー リレーションシップの違いがわかりません。fizzbuzzwidgets

また、Cassandra のような「列型」DB は、単純なリレーショナル/テーブル DB のように聞こえます。

ドキュメント指向の DB と列指向の DB の違いは何ですか? (RDBMS とは) 違いますか? 特定の状況下で、リレーショナル DB よりも優れた解決に最適な問題は何ですか? 前もって感謝します！

NoSQL 用語には 4 つのカテゴリがあります。

1. キーと値のストア
2. ドキュメント指向
3. グラフ
4. 列指向。

私の見解では、これらすべてのデータ モデリングの定義は同じです。違いとは何ですか?

キー\値データベースは、OOP のオブジェクトのような構造でデータを保持します。データへのアクセス権は、一意のキーに基づいています。

列指向はキー\値のようなアプローチです! ただし、キー\値では、クエリで値にアクセスできません。つまり、クエリはキーベースです。

2 つの異なるカテゴリの 1 番目と 2 番目の写真を比較します。

ドキュメント指向では、行のようなコレクションにデータを格納します。データへのアクセスは、一意のキーに基づいています。コレクションには、キー\値などのデータが格納されます。ただし、値によってデータにアクセスできます。

ご覧のとおり、これら 3 つのカテゴリでは、一意のオブジェクトを指定するための一意のキーと、詳細についてのキーと値のいくつかのペアを定義します。

グラフ db は少し異なります。

では、定義と現実世界の違いは何ですか?

Infobright には、約 4,000 万行のファクト テーブルがあります。以下に示すようなクエリをそのテーブルで実行すると、10 分以上かかります。

これを調整する理由と方法はありますか？

ところで、ハードウェアの仕様は AWS m1.large です。したがって、ネットワーク遅延はさておき、これは依然としてかなりの時間間隔です。

キー/値、ドキュメント、グラフ、列指向の 4 種類の NoSQL データベースを詳細に比較しています。

主に以下に基づいて比較しています。

• 同時実行
• クエリ
• 取引
• スキーマ
• レプリケーション
• スケーリング

この比較に追加すべきものは何ですか?

必要な情報を得るのに役立つブログ、論文、本、ビデオを提供してもらえますか?