sql - リレーショナルデータベースを使用しない正当な理由はありますか?

Question

代替のデータストレージツールを指摘し、古き良きリレーショナルデータベースの代わりにそれらを使用する正当な理由を教えてください。私の意見では、ほとんどのアプリケーションが SQL の能力をフルに活用することはめったにありません。SQL を使用しないアプリケーションを構築する方法を見るのは興味深いことです。

score 148 · Accepted Answer

ファイルシステム内のプレーンテキストファイル

作成と編集が非常に簡単
シンプルなツール (テキストエディタ、grep など) で簡単に操作できます。
バイナリドキュメントの効率的な保存

ディスク上の XML または JSON ファイル

上記と同様ですが、構造を検証する機能がもう少しあります。

スプレッドシート / CSV ファイル

ビジネスユーザーにとって非常に理解しやすいモデル

Subversion (または同様のディスクベースのバージョン管理システム)

データのバージョン管理の非常に優れたサポート

Berkeley DB (基本的にはディスクベースのハッシュテーブル)

概念的には非常に単純です (型指定されていないキー/値のみ)
かなり速いです
管理オーバーヘッドなし
私が信じているトランザクションをサポートします

アマゾンのシンプルDB

Berkeley DB によく似ていると思いますが、ホストされています

Google の App Engine データストア

ホスト型でスケーラビリティが高い
ドキュメントごとのキー値ストレージ (つまり、柔軟なデータモデル)

CouchDB

ドキュメントの焦点
半構造化/ドキュメントベースのデータのシンプルなストレージ

母国語のコレクション (メモリに保存されるか、ディスクにシリアル化されます)

非常に緊密な言語統合

カスタム (手書き) ストレージエンジン

必要なユースケースでは潜在的に非常に高いパフォーマンス

それらについて詳しく知っているとは言えませんが、オブジェクトデータベースシステムについても調べてみてください。

score 26 · Accepted Answer

マット・シェパードの答えは素晴らしい（モッドアップ）ですが、スピンドルについて考えるときは、次の要因を考慮します。

構造 : 明らかにばらばらになっていますか、それともトレードオフを行っていますか?
使用法: データはどのように分析/取得/処理されますか?
ライフタイム : データはどのくらいの期間有効ですか?
サイズ : どのくらいのデータがありますか?

RDBMS に対する CSV ファイルの特別な利点の 1 つは、簡単に圧縮して他のマシンに移動できることです。私たちは大規模なデータ転送を行いますが、1 つの大きな CSV ファイルを使用するだけで十分にシンプルであり、rsync などのツールを使用して簡単にスクリプトを作成できます。大きな CSV ファイルの繰り返しを減らすには、 YAMLなどを使用できます。重要な関係要件がない限り、JSON や XML などを保存するかどうかはわかりません。

言及されていない代替手段については、MapReduce のオープンソース実装であるHadoopを軽視しないでください。これは、分析が必要な大まかに構造化されたデータが大量にあり、データ処理を処理するためにあと 10 台のマシンを追加するだけのシナリオにしたい場合にうまく機能するはずです。

たとえば、約 20 台のマシンでログに記録されたさまざまな機能の基本的にすべてのタイミング数値であるパフォーマンスの分析を試み始めました。すべてを RDBMS に格納しようとした後、いったんデータを集計したら、再度クエリを実行する必要がないことに気付きました。そして、それは私にとって集約された形式でのみ役に立ちます。そのため、ログファイルを保持し、圧縮してから、集計データを DB に残します。

私は「大きな」サイズで考えることに慣れていることに注意してください。

score 10 · Accepted Answer

ファイルシステムはバイナリデータを格納するのに非常に便利ですが、リレーショナルデータベースでは決してうまく機能しません。

score 6 · Accepted Answer

カスタム（手書き）ストレージエンジン/必要なユースケースで非常に高いパフォーマンスを発揮する可能性

http://www.hdfgroup.org/

膨大なデータセットがある場合は、独自のデータセットを作成する代わりに、階層データ形式であるHDFを使用できます。

http://en.wikipedia.org/wiki/Hierarchical_Data_Format：

HDFは、多次元配列、ラスターイメージ、テーブルなど、いくつかの異なるデータモデルをサポートしています。

また、ファイルシステムのように階層的ですが、データは1つの魔法のバイナリファイルに保存されます。

HDF5は、非常に大規模で複雑なデータ収集の管理を可能にするスイートです。

ペタバイトのNASA/JPLリモートセンシングデータを考えてみてください。

score 6 · Accepted Answer

ACIDが必要ない場合は、おそらくRDBMSのオーバーヘッドは必要ありません。したがって、最初にそれが必要かどうかを判断します。ここで提供されるRDBMS以外の回答のほとんどは、ACIDを提供していません。

score 6 · Accepted Answer

Prevayler を試す: http://www.prevayler.org/wiki/ Prevayler は RDBMS の代替です。サイトには詳細があります。

score 4 · Accepted Answer

こんばんは

考えられる 1 つのケースは、モデリングしているデータがリレーショナルデータベースで簡単に表現できない場合です。

その一例として、携帯電話事業者が携帯電話ネットワークの基地局を監視および制御するために使用するデータベースがあります。

これらのケースのほとんどすべてで、OO DBが使用されています。これは、商用製品か、オブジェクトの階層を可能にする自己ロールシステムです。

私は、無名のままである大企業の 3G 監視アプリケーションに取り組んできましたが、そのロゴは赤ワインのしみ (-: ) であり、そのような OO DB を使用して、通信網。

このような DB の調査は、通常、SQL から完全に解放された独自の技術を使用して行われます。

HTH。

乾杯、

ロブ

score 3 · Accepted Answer

数年前に作成された、OODBMSが組み込まれたJADEというRADツールがありました。DBエンジンの初期の化身も、DigitalkSmalltalkをサポートしていました。非RDBMSパラダイムを使用してアプリケーション構築をサンプリングしたい場合は、これが出発点になる可能性があります。

他のOODBMS製品には、Objectivity、GemStoneが含まれます（Smalltalkバージョンを実行するには VisualWorks Smalltalkを入手する必要がありますが、Javaバージョンもあります）。この分野にはいくつかのオープンソースの研究プロジェクトもありました。EXODUSとその子孫であるSHOREが思い浮かびます。

悲しいことに、この概念は死に絶えたように見えました。これはおそらく、明確に見える標準がなく、SQLベースのRDMBSシステムに比べてアドホッククエリ機能が比較的劣っていたためです。

OODBMSは、相互接続されたノードのグラフとして最もよく表されるコアデータ構造を持つアプリケーションに最適です。私は以前、典型的なOODBMSアプリケーションはマルチユーザーダンジョン（MUD）であり、部屋にはプレイヤーのアバターやその他のオブジェクトが含まれると言っていました。

score 3 · Accepted Answer

オブジェクトデータベースはリレーショナルデータベースではありません。データベースにいくつかのオブジェクトを詰め込むだけの場合、これらは非常に便利です。また、バージョン管理をサポートし、データベースに既に存在するオブジェクトのクラスを変更します。最初に頭に浮かぶのはdb4oです。

score 3 · Accepted Answer

場合によっては (金融市場データやプロセス制御など)、RDBMS ではなくリアルタイムデータベースの使用が必要になることがあります。ウィキリンクを参照

score 1 · Accepted Answer

多くの場合、BTreeファイルはリレーショナルデータベースよりもはるかに高速です。SQLiteには、パブリックドメインにあるBTreeライブラリが含まれています（この用語を大まかに使用するのではなく、純粋に「パブリックドメイン」のように）。

率直に言って、マルチユーザーシステムが必要な場合は、適切なサーバーリレーショナルデータベースを使用しないように多くの説得が必要になります。

score 1 · Accepted Answer

また：*組み込みシナリオ-通常、本格的なRDBMSよりも小さいものを使用する必要がある場合。Db4oはそのような場合に簡単に使用できるODBです。*迅速なまたは概念実証の開発-永続性レイヤーについて心配することなく、ビジネスに集中したい場合

score 1 · Accepted Answer

1

KISS：小さくシンプルに保つ

于 2008-09-28T10:29:20.840 に答える

score 1 · Accepted Answer

ファイルシステムに保存されているファイルを使用するだけで、長い道のりを歩むことができます。RDBMS では BLOB の処理が改善されていますが、特にクエリが単純な場合 (個々の項目を列挙して選択する場合) は、これが画像データなどを処理する自然な方法になる可能性があります。

RDBMS にうまく適合しないその他のものは、階層データ構造であり、地理空間データと 3D モデルも扱いにくいと思います。

Amazon S3のようなサービスは、SQL をサポートしない単純なストレージモデル (キー -> 値) を提供します。そこで重要になるのがスケーラビリティです。

特にユーザーが使い慣れた環境でデータを操作できるようにする必要があり、それを行うための完全なアプリケーションを構築することが現実的でない場合は、Excel ファイルも役立ちます。

score 1 · Accepted Answer

データを格納する方法は多数あります。「リレーショナルデータベース」でさえ、単一のユーザーベースのリレーショナルデータベースであるかのようにローカルファイル (複数可) を操作するコードの単純なライブラリから、さまざまな代替手段をカバーしています。複数のユーザーを処理できるファイルベースのシステムから、本格的な「サーバー」ベースのシステムまで、幅広い選択肢があります。

私たちは XML ファイルをよく使用します - 適切に構造化されたデータ、必要に応じて編集を行う機能、人間が読めるものと同じようにクエリを実行するための優れたツールを取得し、db エンジンの動作 (またはdb エンジン)。これは、本質的に読み取り専用のもの（この場合、他のデータベースから生成されないことが多い）や、必要に応じてデータをロードして保存できるシングルユーザーシステムでもうまく機能しますが、機会を生み出していますマルチユーザー編集が必要な場合の問題については、少なくとも単一のファイルを編集します。

私たちにとってはそれだけです-SQLを実行するものを使用します（MSは、.DLLから実行して単一ユーザーのものをエンタープライズサーバーまで実行する一連のツールを提供し、それらはすべて同じSQLを話します(下端に制限があります)) または、(私たちにとって) 冗長性が問題になることはめったにないため、XML を形式として使用します。

現在、アプリでバイナリデータを操作する必要はないので、そのような疑問は生じません。

マーフ

score 1 · Accepted Answer

アプリケーションデータが非常にキー/値指向であり、本質的に階層的である場合は、従来の SQL データベースの代わりに LDAP サーバーの使用を検討することをお勧めします。

score 1 · Accepted Answer

"within 10 words of" などの近接演算子でクエリできる全文データベース。

リレーショナルデータベースは、多くの目的で理想的なビジネスツールです。理解と設計が簡単で、十分に速く、「全力を尽くす」ことができる天才によって設計および最適化されていなくても十分です。

しかし、一部のビジネス目的ではフルテキストインデックス作成が必要ですが、リレーショナルエンジンはこれを提供しないか、後付けとして追加します。特に、法律や医療の分野では、大量の構造化されていないテキストを保存して処理する必要があります。

score 1 · Accepted Answer

私は RDBMS を提供します :) セットアップや管理に問題がなければ、SQLite をお勧めします。SQL を完全にサポートする RDBMS に組み込まれています。任意の列に任意のタイプのデータを格納することもできます。

たとえば、ログファイルに対する主な利点: 巨大なファイルがある場合、どのように検索しますか? SQL エンジンを使用すると、インデックスを作成するだけで、操作が劇的に高速化されます。

全文検索について: SQLite には全文検索用のモジュールもあります。

データへの素敵な標準インターフェースをお楽しみください:)

score 1 · Accepted Answer

CAP定理はそれを簡潔に説明しています。SQL は主に「強整合性: 更新があってもすべてのクライアントが同じビューを表示する」を提供します。

score 0 · Accepted Answer

リレーショナルデータベースを使用しない理由の1つは、大量のデータセットがあり、そのデータに対して超並列分散処理を実行したい場合です。グーグルのウェブインデックスはそのような場合の完璧な例でしょう。

Hadoopには、 Hadoop分散ファイルシステムと呼ばれるGoogleファイルシステムの実装もあります。

score 0 · Accepted Answer

SQLiteの代わりにLuaを強くお勧めします-一種のデータストレージ。

なぜなら：

この言語は、そもそもデータ記述言語として設計されました
構文は人間が読める形式です（XMLは人間が読める形式ではありません）
パフォーマンスを向上させるために、Luaチャンクをバイナリにコンパイルできます

これは、受け入れられた回答の「母国語コレクション」オプションです。アプリケーションレベルとしてC/C ++を使用している場合は、構成/データの読み取りまたは書き込みのためだけにLuaエンジン（100kBのバイナリ）を投入するのが完全に合理的です。

sql - リレーショナル データベースを使用しない正当な理由はありますか?

21 に答える 21

Related

Reference

sql - リレーショナルデータベースを使用しない正当な理由はありますか?