データをディスクに保存するのではなく、なぜデータベースを使用するのですか？
データベースの代わりに、データをJSONにシリアル化し、必要に応じて保存してディスクにロードします。すべてのデータ管理はプログラム自体で行われるため、SQLクエリを使用するよりも高速かつ簡単です。そのため、なぜデータベースが必要なのかまったく理解できませんでした。
データをディスクに保存するだけでなく、データベースを使用する必要があるのはなぜですか？
- データベース内のデータをクエリできます（質問してください）。
- データベースからデータを比較的迅速に検索できます。
- JOINを使用して、2つの異なるテーブルのデータを関連付けることができます。
- データベース内のデータから意味のあるレポートを作成できます。
- データには組み込みの構造があります。
- 特定のタイプの情報は常に1回だけ保存されます。
- データベースは [〜＃〜] acid [〜＃〜] です。
- データベースはフォールトトレラントです。
- データベースは非常に大きなデータセットを処理できます。
- データベースは並行です。複数のユーザーがデータを破壊せずに同時に使用できます。
- データベースは適切に拡張されます。
つまり、多種多様な非常に賢い人々によって長年にわたって開発された、広く知られている実証済みのテクノロジーの恩恵を受けることができます。
データベースが過剰であることが心配な場合は、SQLiteをチェックしてください。
ロバートが言ったことにはすべて同意しますが、ディスクにデータを保存するだけでなく、データベースをいつ使用するべきかについては彼からは言われませんでした。
したがって、スケーラビリティ、信頼性、フォールトトレランスなどについてRobertが言ったことに加えて、これを見てください。
RDBMSを使用する場合について、考慮すべきいくつかのポイントを次に示します。
- リレーショナルデータがある、つまり、製品を購入する顧客がいて、それらの製品にサプライヤーとメーカーがある
- 大量のデータがあり、関連情報をすばやく見つけられるようにする必要がある
- 特定された以前の問題、つまりスケーラビリティ、信頼性、ACIDコンプライアンスについて心配する必要があります。
- ビジネス上の問題を解決するには、レポートツールまたはインテリジェンスツールを使用する必要があります
NoSQLを使用する場合について
- 保存する必要のある構造化されていないデータがたくさんある
- スケーラビリティとスピードのニーズ
- 通常、スキーマを事前に定義する必要はありません。そのため、要件を変更する場合は、これが適切な場合があります。
最後に、いつファイルを使用するか
- ファイルシステムが処理できる妥当な量の非構造化データがある
- あなたは構造、関係を気にしません
- スケーラビリティや信頼性は気にしません（ただし、ファイルシステムに応じて、これらは可能です）。
- データベースが追加するオーバーヘッドを望まない、または処理できない
- ファイルシステムに属する構造化されたバイナリデータ（画像、PDF、ドキュメントなど）を扱っています。
誰も言及していないように見える1つのことは、レコードのインデックス付けです。あなたのアプローチは現時点では問題なく、あなたは非常に小さなデータセットを持ち、それにアクセスする人はほとんどいないと思います。
より複雑になるにつれて、実際にはデータベースを作成しています。なんといっても、データベースはディスクに保存された一連のレコードです。ファイルを作成する場合でも、 MySQL 、 SQLite など、ファイルを作成する場合でも、どちらもデータベースです。
不足しているのは、データベースシステムを使いやすくするためにデータベースシステムに組み込まれている複雑な機能です。
頭に浮かぶ主なものは、索引付けです。 OK、10または20、さらには100または1000のレコードをシリアル化された配列またはJSON文字列に保存し、ファイルから取り出してそれを反復することができます相対的に 早く。
ここで、10,000、100,000、または1,000,000のレコードがあるとします。誰かがログインしようとすると、数百メガバイトのファイルを開いて、プログラムのメモリにロードし、同様のサイズの情報の配列を引き出して、数十万件のレコードを繰り返し処理する必要があります。アクセスしたいレコードを1つ見つけます。
適切なデータベースを使用すると、レコードの特定のフィールドにインデックスを設定して、データベースにクエリを実行し、巨大なデータセットであっても非常に迅速に応答を受け取ることができます。これを Memcached のようなものと組み合わせたり、自家製のキャッシュシステム（たとえば、検索結果を別のテーブルに10分間保存したり、他の誰かがその後すぐに同じこと）、そして非常に高速なクエリが得られます。手動でファイルを読み書きしているときに、このような大きなデータセットでは得られないものです。
索引付けに緩く関連するもう1つのことは、情報の転送です。上で述べたように、数百メガバイトまたは数千メガバイトのファイルがある場合、その情報をすべてメモリにロードし、手動で（おそらく同じスレッドで）反復処理してからデータを操作する必要があります。
データベースシステムでは、独自のスレッドまたは独自のサーバーで実行されます。プログラムとデータベースサーバーの間で送信されるのはSQLクエリであり、送信されるのはアクセスしたいデータだけです。データセット全体をメモリにロードするのではなく、送受信するのはデータセット全体のごく一部です。
[〜＃〜] tldr [〜＃〜]
アプリケーションに対して本質的に有効な短期間のデータストアの技術的な決定を行ったようです。カスタムデータストア管理ツールを作成することにしました。
あなたは連続体に座っており、どちらの方向にも移動するオプションがあります。
長期的には（ほぼ100％ではありませんが）、問題が発生する可能性が高く、既存のデータストアソリューションを使用するように変更した方がよいでしょう。対処しなければならない特定の、非常に一般的で予測可能なパフォーマンスの問題があり、独自のツールを使用するのではなく、既存のツールを使用するほうがよいでしょう。
アプリケーションに組み込まれ、アプリケーションで直接使用される（小さな）カスタム目的のデータベースを作成したようです。実際のディスクの書き込みと読み取りを管理し、その組み合わせをデータストアとして扱うのは、OSとファイルシステムに依存していると思います。
あなたがしたことをするとき
あなたはデータストレージのスイートスポットに座っています。 OSとファイルシステムのデータストアは、非常に便利でアクセスしやすく、クロスプラットフォームのポータブルです。この組み合わせは非常に長い間使用されており、ほとんどすべての標準のデプロイメント構成で確実にサポートされ、アプリケーションを実行できます。
また、コードを記述するのも簡単です。 [〜＃〜] api [〜＃〜] はかなり単純で基本的なものであり、機能させるために必要なコード行は比較的少なくなります。
一般に、次のような場合は、実行したことを行うのが理想的です。
- 新しいアイデアのプロトタイピング
- パフォーマンス、賢明なスケーリングが必要になる可能性が非常に低いアプリケーションの構築
- データベースをインストールするためのリソースの不足などの異常な状況による制約
代替案
一連のオプションがあり、ここから進むことができる2つの「方向」があります。私は「ダウン」と「アップ」と考えています。
ダウン
これは適用する可能性が最も低いオプションですが、完全を期すためにここにあります。
必要に応じて、downを実行できます。つまり、OSとファイルシステムを完全にバイパスして、実際にディスクから直接書き込みと読み取りを行います。この選択は通常、極端な効率が必要な場合にのみ関連します-たとえば、最小限/小さい MP プレーヤーデバイスを考えてください [〜＃〜] ram [〜＃ 〜] 完全に機能するOS、または Wayback Machine のようなものでは、非常に効率的な大量のデータ書き込み操作が必要です（ほとんどのデータストアは、書き込みが遅いため、読み取りが速くなる代わりに、圧倒的に遅くなります。ほとんどすべてのアプリケーションのより一般的な使用例）。
アップ
ここにはいくつかのサブカテゴリがありますが、これらは完全に排他的ではありません。一部のツールは両方にまたがり、それぞれにいくつかの機能を提供します。いくつかのツールは、あるモードでの作業から別のモードでの作業に完全に切り替えることができます。また、いくつかのツールを互いに重ねて、アプリケーションの異なる部分に異なる機能を提供することもできます。
より強力なデータストア
データ操作の複雑さを管理するために独自のアプリケーションに依拠しながら、ますます大量のデータを保存する必要があることに気づくかもしれません。 Key-Valueストアの全範囲が利用可能であり、関連する機能のサポートの範囲が異なります。 NoSQL ツールは、このカテゴリおよびその他のカテゴリに分類されます。
これは、以下があなたのアプリケーションを説明するときにスケールアップする明白な道です：
- 異常に重い読み取り依存
- 高いパフォーマンスと低い（短期的な）一貫性の保証（多くの場合、「最終的な一貫性」を提供）をトレードオフしてもかまいません。
- ほとんどのデータ操作と一貫性の欠如を「直接」管理しています（実際には、おそらく最初はサードパーティのツールを使用することになりますが、最終的にはこれをアプリケーションまたはカスタムの中間層に組み込みます）。 。
- 「比較的単純な」データ操作要件を使用して、保存しているデータ量やデータを検索する能力を大規模に拡張しようとしています。
ここには少しゆらぎの余地があります-より遅い読み取りのために、より良い読み取り一貫性を強制できます。さまざまなツールとオプションが、データ操作API、インデックス作成、その他のオプションを提供します。これらのオプションは、特定のアプリケーションを簡単に作成するのに適しています。したがって、上記のポイントがアプリケーションをほぼ完全に説明している場合、より強力なデータストアソリューションで作業するのに「十分近い」可能性があります。
よく知られている例： CouchDB 、 MongoDB 、 Redis 、Microsoftのようなクラウドストレージソリューション Azure 、Google App Data StoreとAmazonのECE。
より複雑なデータ操作エンジン
データストレージアプリケーションの「SQL」ファミリおよびその他の一連のアプリケーションは、純粋なストレージエンジンよりも、データ操作ツールとしてよく説明されています。それらは、データのストレージを超えて、そしてしばしばキーバリューストア側で利用可能なものを超えて、幅広い追加機能を提供します。次の場合は、この方法を使用する必要があります。
- たとえパフォーマンスが低下する可能性があるとしても、読み取りの一貫性は絶対に必要です。
- あなたは非常に複雑なデータ操作を効率的に実行しようとしています-非常に複雑なJOINとUPDATE操作、 data cubes とスライスなどを考えてください...
- パフォーマンスと硬直性をトレードオフしても問題ありません（テーブルなどの強制的で固定されたデータストレージ形式は、簡単かつ/または効率的に変更できないと考えてください）。
- 多くの場合、より複雑なツールとインターフェースのセットを処理するためのリソースがあります。
これはデータベースまたはデータストアのより「伝統的な」考え方であり、ずっと以前から存在していました。そのため、ここで利用可能なlotがあり、多くの場合、対処する複雑さの多く。それは可能ですが、ある程度の専門知識と知識が必要であり、単純なソリューションを構築し、複雑さの多くを回避します。ただし、ほとんどの場合、サードパーティのツールとライブラリを使用して、そのほとんどを管理することになります。
よく知られている例は MySQL 、 SQL Server 、Oracleのデータベース、および DB2 です。
仕事を外部委託する
複雑さの管理を支援するために、データストレージツールとアプリケーションの間に介在する最新のサードパーティツールとライブラリがいくつかあります。
データストアの管理と操作にかかるほとんどまたはすべての作業を最初は取り除き、理想的には、必要な場合にのみ、複雑さへのスムーズな移行を可能にします。これは起業家精神と研究の活発な分野であり、すぐにアクセスして使用できる最近のいくつかの結果があります。
よく知られている例は [〜＃〜] mvc [〜＃〜] tools（ Django 、 Yii ）、 Ruby on Rails 、および Datomic 。さまざまなデータストアのAPIのラッパーとして機能するツールとライブラリが文字通り数十あるため、ここで公平にするのは困難です。
PS：テキストよりも動画を好む場合は、Rich Hickeyのデータベース関連の動画をいくつか見たい場合があります。彼は、データストアの選択、設計、および使用に関わる考え方のほとんどを説明するのに優れています。
質問のコメントで説明するようなリストのような単純なデータがある場合、SQLデータベースはあまり役に立ちません。多くの人がまだそれらを使用しています。なぜなら、データが時間とともに複雑になる可能性があること、そしてデータベースでの作業を簡単にするライブラリがたくさんあるからです。
しかし、単純なリストをロードしてメモリに保持し、必要に応じて書き込む場合でも、いくつかの問題が発生する可能性があります。
プログラムが異常終了すると、データが失われたり、ディスクへのデータの書き込み中に問題が発生したりして、ファイル全体が強制終了される可能性があります。これを処理するために独自のメカニズムをロールすることができますが、データベースは、これを戦いで実証された手法を使用して処理します。
データが大きくなりすぎて頻繁に更新され始めた場合、すべてのデータのシリアル化と保存は大きなリソースを消費し、すべての速度が低下します。パーティション分割の方法を考え出す必要があるので、それほど高価ではありません。データベースは、フォールトトレラントな方法でディスクに変更されたものだけを保存するように最適化されています。また、これらは設計されているため、必要なデータをいつでもすばやくロードできます。
また、SQLデータベースを使用する必要はありません。 NoSQL "databases"を使用できますが、多くの場合、JSONを使用してデータを格納します。しかし、これはフォールトトレラントな方法で行われ、データをインテリジェントに分割、照会、および複数のコンピューター間でインテリジェントに分割できる方法で行われます。
また、混同する人もいます。ログイン情報を格納するために Redis のようなNoSQLデータストアを使用する場合があります。次に、リレーショナルデータベースを使用して、より複雑なデータを格納し、より興味深いクエリを実行する必要があります。
同時実行性と信頼性の問題に焦点を当てた多くの回答が見られます。データベースには、同時実行性、信頼性、パフォーマンス以外の利点もあります。それらは、バイトと文字がメモリでどのように表されるか気にしないことを可能にします。言い換えると、データベースを使用すると、プログラマは「方法」ではなく「何」に集中できるようになります。
答えの1つはクエリに関するものです。 「SQLデータベースへの質問」は、質問の複雑さにも対応します。開発中にコードが進化するにつれて、「fetch all」などの単純なクエリを簡単に拡張して、「property1がこの値と等しいすべてをフェッチしてから、property2でソートする」ことができます。プログラマがそのようなクエリのデータ構造を最適化する必要はありません。ほとんどのクエリのパフォーマンスは、特定のプロパティのインデックスを作成することで高速化できます。
他の利点は関係です。クエリを使用すると、異なるデータセットのデータを相互参照してから、ループをネストするほうが簡単です。たとえば、ユーザーと投稿が異なるデータセット（またはDBテーブルまたはJSONオブジェクト）であるシステムで投稿が3つ未満のユーザーからのすべてのフォーラム投稿の検索は、読みやすさを犠牲にすることなく1つのクエリで実行できます。
全体として、SQLデータベースは、データボリュームが大きくなる可能性がある場合（1000個を超えるオブジェクトとしましょう）、単純な配列よりも優れています。
ファイルシステムはNoSQLデータベースの説明に適合します。そのため、データの保存方法を決定するときは、RDBMSを優先してそれを却下するだけでなく、それを使用することを確実に検討する必要があると思います。
ファイルシステム（およびNoSQL全般）の1つの問題は、データ間の関係の処理です。これが主要なブロッカーではない場合は、今のところRDBMSをスキップします。また、ファイルシステムをストレージとして使用することのプラス面も覚えておいてください。
- ゼロ管理
- 複雑性が低く、セットアップが簡単
- 任意のオペレーティングシステム、言語、プラットフォーム、ライブラリなどで動作します
- 構成設定のみがディレクトリです
- テストするのは簡単
- 既存のツール、バックアップ、変更などで調べるのは簡単です
- 優れたパフォーマンス特性とオペレーティングシステムによる十分な調整
- 開発者が理解しやすい
- 依存関係なし、追加のドライバーなし
- セキュリティモデルは簡単に理解でき、オペレーティングシステムの基本部分です
- データに外部からアクセスできない
（ ソース ）
ファイルシステムはデータベースの一種です。たぶん、他の皆のようなRDBMSが話しているのではなく、厳密に言えばDBです。抽象化されたストレージとプログラムが通信するためのAPIを備えたルックアップデータ（ファイルコンテンツ）へのキー（ファイル名）を提供します。
つまり、データベースを使用しています。他の投稿は、さまざまなタイプのデータベースの利点について議論することができます...
データを変更する複数のプロセス（ユーザー/サーバー）がある場合は、データベースが必要です。次に、データベースは、それらが互いの変更を上書きするのを防ぐのに役立ちます。
データがメモリよりも大きい場合は、データベースも必要です。現在使用可能なメモリがあるため、これにより実際に多くのアプリケーションでデータベースを使用できなくなります。
あなたのアプローチは、「インメモリデータベース」のナンセンスよりも間違いなく優れています。これは本質的にあなたのアプローチですが、多くのオーバーヘッドが追加されています。
特定のアプリケーションにRDBMSが必要かどうかを常に自問する必要があります。必要なすべてのツールとフレームワークを最初から自動的に想定する設計プロセスで作成されたアプリケーションが多すぎます。リレーショナルデータベースは非常に一般的で、多くの開発者が以前と同様のアプリケーションに取り組んできたため、プロジェクトが開始する前に自動的に組み込まれます。多くのプロジェクトでこれを回避できますので、あまり厳しく判断しないでください。
プロジェクトなしでプロジェクトを開始したのですが、それは機能します。 SQLを待たずにこれを起動して実行する方が簡単でした。それには何の問題もありません。
このプロジェクトが拡大し、要件がより複雑になると、構築が困難になるものもあります。別の方法を研究してテストするまで、どちらが優れているかをどのようにして知るのですか？あなたはProgrammersに質問して、炎を取り除き、この質問に答えることができます。それを学んだら、データベースのいくつかの利点を処理するために、自分の言語で何行のコードを記述してもよいかを検討できます。ある時点で、車輪を再発明しています。
多くの場合、簡単なのは相対的です。ユーザーがコードを記述しなくても、Webページを構築してフォームをデータベーステーブルに接続できるフレームワークがいくつかあります。マウスが苦手な方は、これが問題になるかもしれません。誰もが知っていることですが、これはスケーラブルでも柔軟でもありません。なぜなら、すべてをGUIに密結合することは禁じられているからです。プログラマーではない人がプロトタイプを作成しました。 [〜＃〜] yagni [〜＃〜] がここにたくさんあります。
[〜＃〜] orm [〜＃〜] SQLを学習するのではなく、選択した言語で操作することを学びたい場合は、SQLを学習しますが、インストールして、テーブルを作成してプルしますSQLを使用した一般的なデータベースの一部のデータ（Select * From;は驚異的なものではありません）。簡単です。そのため、そもそも誰かが作成したのです。情報に基づいた決定を下すために、それほど大きな投資をしているようには見えません。おそらく、パフォーマンステストも実行できます。
データをディスクに保存する[〜＃〜] is [〜＃〜]特に、各オブジェクトを独自のファイルに置く場合は、データベースに書き込みますレコードのキーとなるファイルの名前で。また、ファイルを読み取るためのルックアップ時間を最小限に抑えるには、キーの最初の数文字に基づいてサブディレクトリを作成します。
たとえば、key = ghostwriterはg/ho/stwriter.jsonまたはg/h/o/stwriter.jsonまたはg/ho/ghostwriter.jsonまたはg/h/o/ghostwriter.jsonに格納されます。キーの分布に基づいて命名方式を選択します。それらがシーケンス番号である場合、5/4/3/12345.jsonは他の方法よりも優れています。
これはデータベースであり、必要なことをすべて実行している場合は、その方法で実行します。今日では、それはGDBMやBerkeley dbのようなNoSQLデータベースと呼ばれています。非常に多くの選択肢。まず必要なものを理解し、次にmemcachedなどのget/setインターフェースやCRUDインターフェースなどの詳細に対処するためのインターフェースライブラリを構築します。データベース形式を変更する必要がある場合は、ライブラリを交換できます。異なる特性を持つ。
PostgreSQLやApache Derby DBなどの一部のSQLデータベースでは、独自に作成したデータベースを含む多くのNoSQL形式でSQLクエリを実行できることに注意してください。 MyBatisについては不明ですが、似ている可能性があります。
NoSQLの誇大広告を避けます。機能について読み、パフォーマンスと機能をテストし、それがアプリケーションのニーズにどの程度一致するかに基づいて選択します。
http://www.hdfgroup.org/HDF5/ は、人々があまり考慮しない、興味深いもう1つの広く使用されているデータストア形式です。
データが同時に更新されるとすぐに、データベース（メモリ内データベースの場合もある）を使用したアプローチの方がより正確でパフォーマンスが高くなる可能性があります。同時更新、トランザクション、キャッシング、非同期I/Oなどについて心配する必要があります。