sql - リレーショナル データベースを使用すべきでない場合

Question

google/bigtable のシナリオ以外で、リレーショナル データベースを使用すべきでないのはどのような場合ですか? その理由と、何を使用する必要がありますか? （「難しい方法」を学びましたか？）

Answer 1

私の経験では、次の条件のいずれかに該当する場合は、リレーショナル データベースを使用しないでください。

• データは、任意の深さの階層またはグラフ (ネットワーク) として構造化されています。
• 典型的なアクセス パターンでは、書き込みよりも読み取りが重視されます。
• アドホック クエリの要件はありません。

深い階層とグラフは、リレーショナル テーブルにうまく変換できません。Oracle のような独自の拡張機能の助けを借りても、CONNECT BYSQL を使用してツリーを追跡するのは大変な苦痛です。

リレーショナル データベースでは、単純な読み取りアクセスに多くのオーバーヘッドが追加されます。トランザクションと参照整合性は強力ですが、一部のアプリケーションではやり過ぎです。そのため、ほとんどが読み取り専用のアプリケーションでは、ファイル メタファで十分です。

最後に、予期しないクエリが予想されない場合は、本格的なクエリ言語を備えたリレーショナル データベースは必要ありません。「営業担当者ごとに、東海岸で 5% 割引の青色のウィジェットをいくつ販売しましたか?」などの質問をするスーツがなく、今後も存在しない場合、あなたは DB なしで生活できます。

Answer 2

リレーショナル データベース パラダイムでは、データの使用法についていくつかの仮定を行います。

• リレーションは、順序付けされていない一連の行で構成されます。
• リレーション内のすべての行には、同じ列のセットがあります。
• 各列には、固定された名前とデータ型があり、すべての行でセマンティックな意味があります。
• リレーション内の行は、主キー列の一意の値によって識別されます。
• 等

これらの仮定は、ある程度の柔軟性を犠牲にして、単純さと構造をサポートします。すべてのデータ管理タスクがこの種の構造に当てはまるわけではありません。たとえば、複雑な属性または可変属性を持つエンティティはそうではありません。リレーショナル データベース ソリューションがサポートしていない領域で柔軟性が必要な場合は、別の種類のソリューションを使用する必要があります。

さまざまな要件を持つデータを管理するためのソリューションは他にもあります。たとえば、セマンティック Web テクノロジでは、メタデータをデータと同様に属性として扱うことで、各エンティティが独自の属性を定義し、自己記述型になることができます。これは、リレーショナル データベースによって課される構造よりも柔軟性がありますが、その柔軟性には独自のコストが伴います。

全体として、各ジョブに適切なツールを使用する必要があります。

「次世代データベース」に対する私の他の回答も参照してください。

Answer 3

3 つの主要なデータ モデル (CJDate、EFCodd) があり、これにフラット ファイルを追加しています。

• フラットファイル（構造はさまざまです-「愚かな」フラットテキストから、巧妙なツールと組み合わされた文法に準拠したファイルまで、非常に巧妙なことを行い、コンパイラとそれらができることを考え、新しいものをモデル化する際のアプリケーションを絞り込みます）
• 階層型(ツリー、ネストされたセット - 例: xml およびその他のマークアップ言語、レジストリ、組織図など。何でもモデル化できますが、整合性ルールを表現するのは簡単ではなく、検索を自動的に最適化するのは難しく、一部の検索は高速で、一部は高速です。非常に遅い ）
• ネットワーク(ネットワーク、グラフ - 例: ナビゲーション データベース、ハイパーリンク、セマンティック Web、ここでもほとんどすべてをモデル化できますが、検索の自動最適化が問題になります)
• リレーショナル(一次述語ロジック - 例: リレーショナル データベース、検索の自動最適化)

階層とネットワークの両方がリレーショナルで表現でき、リレーショナルは他の 2 つで表現できます。

リレーショナルが「優れている」と見なされる理由は、データ検索言語だけでなくデータ定義言語でも宣言型の性質と標準化が行われていることです。これには、安定したスケーラブルなマルチユーザー管理システムでバックアップされた強力な宣言型データの整合性が含まれます。

メリットには代償が伴います。ほとんどのプロジェクトでは、予見可能な将来に使用できるフォームに長期データを保存するシステム (マルチアプリケーション) に適した比率であることがわかっています。

システムを構築するのではなく、おそらく 1 人のユーザー向けの 1 つのアプリケーションを構築していて、データを使用する複数のアプリケーションや複数のユーザーを必要としないことがかなり確実である場合、すぐに、より高速なアプローチを見つけることができるでしょう。 .

また、格納するデータの種類とそのモデル化方法がわからない場合は、リレーショナル モデルの強みが無駄になります。

または、データの整合性をあまり気にしない場合 (これで問題ありません)。

すべてのデータ構造は、特定の種類の使用に合わせて最適化されています。適切にモデル化されたリレーショナルのみが、意味的に偏りのない方法で「現実」を表現しようとします。リレーショナル データベースの使用経験が乏しい人は、通常、他の種類のデータ モデルを使用した場合の経験がはるかに悪いことに気づいていません。恐ろしい実装が可能であり、特にリレーショナル データベースでは、複雑なモデルを比較的簡単に構築できるため、かなりのモンスターを手にすることになる可能性があります。それでも、xml で同じモンスターを想像しようとすると、いつも気分が良くなります。

リレーショナル モデルがいかに優れているかを示す一例として、IMO は、複雑さと SQL に関する質問の短さの比率です。

Answer 4

このトピックについてほぼ毎日議論し、RDMBSではなく分散ハッシュなどを選択したプロジェクトに関する多くの記事が掲載されているHighScalabilityブログにアクセスすることをお勧めします。

簡単な（しかし非常に不完全な答え）というのは、すべてのデータが効率的な方法でテーブルにうまく変換されるわけではないということです。たとえば、データが本質的に1つの大きな辞書である場合、古いRDBMSよりもはるかに高速な代替手段がおそらくあります。そうは言っても、それは主にパフォーマンスの問題であり、プロジェクトでパフォーマンスが大きな問題ではなく、たとえば安定性、一貫性、信頼性が重要である場合、これらのテクノロジを詳しく調べることにはあまり意味がありません。 RDBMSは、はるかに成熟した十分に開発されたスキームであり、すべての言語とプラットフォームでサポートされており、豊富なソリューションから選択できます。

Answer 5

15年前、私は信用リスクシステム（基本的には大きな木の歩行システム）に取り組んでいました。私たちはHPUXとsolarisでSybaseを使用していましたが、パフォーマンスが私たちを殺していました。私たちはSybaseから直接コンサルタントを雇いました。次に、OOデータベース（この場合はオブジェクトストア）に切り替えて、パフォーマンスが約100倍向上しました（コードの記述も約100倍簡単になりました）

しかし、そのような状況は非常にまれです。リレーショナルデータベースが最初の選択肢として適しています。

Answer 6

スキーマが大きく異なる場合、リレーショナル データベースで苦労することになります。これは、XML データベースまたはキーと値のペアのデータベースが最適に機能する場所です。または、IBM DB2 を使用して、リレーショナル データと XML データの両方を単一のデータベース エンジンで管理することもできます。

Answer 7

約 7 ～ 8 年前、私は Web サイトで働いていましたが、当初の予想を超えて人気が高まり、パフォーマンス面で問題が発生しました。私たちは皆、Web ベースのプロジェクトに比較的慣れていなかったので、通常のデータベース分離を超えて別のサーバーに何をすべきか、ロード バランシングなどについて大きな負担がかかりました。

ある日、私はかなり単純なことを考えました。サイトはユーザーに基づいていたので、ユーザーのプロファイルは、他のユーザーが検索できるユーザー プロファイル ページとして表示されるユーザー ID、多くの情報変数など、通常の方法でデータベース テーブルに格納されていました。 . 私はすべてのデータを単純な html ファイルにフラッシュし、既にユーザー プロファイル ページとして準備されており、大幅なブースト (基本的にはキャッシュ) が得られました。ユーザーがプロファイル情報を編集すると、元の html ファイルを解析し、編集用に配置してから、html をファイル システムにフラッシュするシステムも作成しました。

ユーザーがお互いに送信したメッセージに似たものを作りました。基本的に、INSERT や UPDATE を回避して、システムがデータベースを完全にバイパスできるようにできるところはどこでも、大幅な改善が得られました。当たり前のことのように聞こえるかもしれませんが、それは啓発的な瞬間でした。これは、リレーショナル セットアップ自体を回避することではありませんが、データベース (KISS) を完全に回避することです。