SQL vs NOSQL：選択方法-IT業界-php.cn

SQL vs NoSQL: How to Choose

SQL vs NOSQL：選択方法

キーテイクアウト

SQLデータベースは、明確に定義された関連データ要件とデータの整合性が重要なプロジェクトに最適です。それらは多くの場合、オンラインストアや銀行システムに使用されます。 NOSQLデータベースは、速度とスケーラビリティが重要な場合、無関係、進化、または不確定なデータ要件を持つプロジェクトに適しています。それらは一般的にソーシャルネットワーク、顧客管理、Web分析システムに使用されます。
SQLデータベースは、倉庫管理システムのような堅牢なデータの整合性とトランザクションサポートを必要とするプロジェクトに必要です。関連データをテーブルに保存し、使用する前にスキーマが必要であり、サポートテーブル結合が必要です。ただし、スキーマは剛性が高く、データが断片化される可能性があるため、開発者やシステム管理者がデータベースを調べることが困難になります。

強力な宣言言語を使用して
多くのサポート、専門知識、ツールを提供しています
JSONのように関連するデータ、name-valueドキュメント
スキーマを指定せずにデータを保存できます

は通常、非定型化する必要があるため、アイテムに関する情報は単一のドキュメントに含まれています

結合を必要としないでください（非正規化された文書が使用されると仮定）
検証なしでいつでもデータをどこにでも保存することを許可します
単一のドキュメントへの更新を保証しますが、複数のドキュメントではありません
優れたパフォーマンスとスケーラビリティを提供します
jsonデータオブジェクトを使用してクエリ
は、より新しい、エキサイティングなテクノロジーです。

SQLデータベースは、要件を決定できるプロジェクトに最適であり、堅牢なデータの整合性が不可欠です。 NOSQLデータベースは、速度とスケーラビリティがより重要な場合、無関係、不確定、または進化するデータ要件に最適です。簡単に言えば：

SQLはデジタルです。正確な仕様を備えた明確に定義された個別のアイテムに最適です。典型的なユースケースは、オンラインストアと銀行システムです
正確なプロジェクトはほとんどありません。どちらのオプションも、浅いまたは自然に非正規化されたデータがある場合、どちらのオプションが実行可能になる可能性があります。ただし、これらの単純化された例のシナリオは、一般化を整えていることに注意してください。あなたは私よりもあなたのプロジェクトについて多くを知っています、そして、私はそれがかなりの利点を提供しない限り、SQLからNOSQLまたはその逆に切り替えることをお勧めしません。それはあなたの選択です。プロジェクトの開始時の長所と短所を考えてみてください。

ホイールを再発明し、SQLベースのアドレス帳システムを実装しましょう。最初の素朴なコンタクトテーブルは、次のフィールドで定義されています。

タイトル
firstName
lastName
性別
電話
メール
address1
address2
address3
city
region
zipcode
国

電話番号が1つある人はほとんどいません。おそらく、土地、モバイル、職場には少なくとも3つが必要ですが、どれだけの配分を割り当ててもかまいません。誰か、どこかでもっと欲しがるでしょう。連絡先が好きなだけ持っているように、別の電話テーブルを作成しましょう。これはデータも正規化します - 数字のない連絡先にヌルは必要ありません。 contact_id

name
番号

メールアドレスと同じ問題があるので、同様の電子メールテーブルを作成しましょう。 contact_id

name
アドレス

（地理的）アドレスを入力したくない場合があります。または、仕事、家庭、ホリデーホームなどの複数の住所を入力することもできます。したがって、新しいアドレステーブルが必要です。 contact_id

name
address1
address2
address3
city
region
zipcode
国
元の連絡先テーブルは次のように削減されました。

タイトル
firstName
lastName
性別

素晴らしい - 連絡先の電話番号、メールアドレス、アドレスを任意の数の電話番号、メールアドレス、住所を保存できる正規化されたデータベースがあります。残念ながら … スキーマは剛性です連絡先のミドルネーム、生年月日、会社、または職務の役割を考慮していません。どのフィールドを追加するかは関係ありません。メモ、記念日、関係ステータス、ソーシャルメディアアカウント、脚の測定、お気に入りのチーズなどの更新リクエストをすぐに受け取ります。すべてのオプションを予測することは不可能です。 d対処する名前と値のペアを持つ他のDataテーブルを作成する可能性があります。データは断片化されています開発者やシステム管理者がデータベースを調べるのは簡単ではありません。また、プログラムのロジックは、複数の結合句を使用して単一の選択ステートメントで連絡先のデータを取得することが実用的ではないため、より遅くなり、より複雑になります。（できますが、結果には電話、電子メール、住所のあらゆる組み合わせが含まれます。誰かが3つの電話番号、5つのメール、2つのアドレスを持っている場合、SQLクエリは30の結果を生成します。最後に、フルテキスト検索は困難です。誰かが文字列「sitepoint」に入力した場合、4つのテーブルすべてをチェックして、連絡先名、電話、電子メール、またはアドレスの一部であるかどうかを確認し、結果をランク付けする必要があります。 WordPressの検索を使用したことがある場合は、それがいかにイライラするかを理解できます。 nosql代替

当社の連絡先データは人々に関係しています。それらは予測不可能であり、異なる時間に異なる要件を持っています。連絡先リストは、NOSQLデータベースを使用することで利益を得ます。NOSQLデータベースは、連絡先コレクションの単一のドキュメントに個人に関するすべてのデータを保存します。

この例では、連絡先のタイトルや性別を保存していません。他の人に適用する必要のないデータを追加しました。それは問題ではありません - 私たちのNOSQLデータベースは気にしません。そして、私たちは自由にフィールドを追加または削除することができます。連絡先のデータは単一のドキュメントに含まれているため、単一のクエリを使用して一部またはすべての情報を取得できます。フルテキスト検索も簡単です。 Mongodbでは、すべての連絡先のインデックスを定義できます使用したテキストフィールド：

<span>{
</span>  <span>name: [
</span>    <span>"Billy", "Bob", "Jones"
</span>  <span>],
</span>  <span>company: "Fake Goods Corp",
</span>  <span>jobtitle: "Vice President of Data Management",
</span>  <span>telephone: {
</span>    <span>home: "0123456789",
</span>    <span>mobile: "9876543210",
</span>    <span>work: "2244668800"
</span>  <span>},
</span>  <span>email: {
</span>    <span>personal: "bob@myhomeemail.net",
</span>    <span>work: "bob@myworkemail.com"
</span>  <span>},
</span>  <span>address: {
</span>    <span>home: {
</span>      <span>line1: "10 Non-Existent Street",
</span>      <span>city: "Nowhere",
</span>      <span>country: "Australia"
</span>    <span>}
</span>  <span>},
</span>  <span>birthdate: <span>ISODate</span>("1980-01-01T00:00:00.000Z"),
</span>  <span>twitter: '@bobsfakeaccount',
</span>  <span>note: "Don't trust this guy",
</span>  <span>weight: "200lb",
</span>  <span>photo: "52e86ad749e0b817d25c8892.jpg"
</span><span>}</span>

ログイン後にコピー

次に、以下を使用してフルテキスト検索を実行します。

db<span>.contact.createIndex({ "$**": "text" });</span>

ログイン後にコピー

db<span>.contact.find({
</span>  <span>$text: { $search: "something" }
</span><span>});</span>

ログイン後にコピー

シナリオ2：ソーシャルネットワーク

ソーシャルネットワークは同様の連絡先データストアを使用する場合がありますが、関係リンク、ステータスの更新、メッセージ、「いいね」などのオプションを備えた機能セットで拡張されます。これらの施設は、ユーザーの需要に応じて実装され、ドロップされる場合があります。それらがどのように進化するかを予測することは不可能です。加えて：

一部のユーザーが考えるものにもかかわらず、ステータスの更新に失敗すると、グローバルなメルトダウンや財政的損失が発生する可能性は低いです。アプリケーションのインターフェイスとパフォーマンスは、堅牢なデータの整合性よりも優先度が高くなります。

このドキュメントは長くなる可能性がありますが、最新のアップデートなど、配列のサブセットを取得できます。すべてのユーザーのステータス履歴全体をすばやく検索することもできます。アップデートを投稿するときに、絵文字の選択肢を導入したいと考えています。これは、更新配列に新しいエントリにグラフィックリファレンスを追加する問題です。 SQLストアとは異なり、以前のメッセージ絵文字をnullに設定する必要はありません。プログラムロジックは、絵文字が設定されていない場合、デフォルトまたは画像を表示できます。

<span>{
</span>  <span>name: [
</span>    <span>"Billy", "Bob", "Jones"
</span>  <span>],
</span>  <span>company: "Fake Goods Corp",
</span>  <span>jobtitle: "Vice President of Data Management",
</span>  <span>telephone: {
</span>    <span>home: "0123456789",
</span>    <span>mobile: "9876543210",
</span>    <span>work: "2244668800"
</span>  <span>},
</span>  <span>email: {
</span>    <span>personal: "bob@myhomeemail.net",
</span>    <span>work: "bob@myworkemail.com"
</span>  <span>},
</span>  <span>address: {
</span>    <span>home: {
</span>      <span>line1: "10 Non-Existent Street",
</span>      <span>city: "Nowhere",
</span>      <span>country: "Australia"
</span>    <span>}
</span>  <span>},
</span>  <span>birthdate: <span>ISODate</span>("1980-01-01T00:00:00.000Z"),
</span>  <span>twitter: '@bobsfakeaccount',
</span>  <span>note: "Don't trust this guy",
</span>  <span>weight: "200lb",
</span>  <span>photo: "52e86ad749e0b817d25c8892.jpg"
</span><span>}</span>

ログイン後にコピー

シナリオ3：ウェアハウス管理システム

倉庫を監視するシステムを検討してください。記録する必要があります：

間違いを最小限に抑えることが不可欠です。製品が消えたり、異なる製品が既に保管されている場所に移動することはできません。最も単純な形式では、ある物理領域から別の領域へのアイテムの転送を記録するか、ロケーションAから削除して場所Bに配置します。これは同じアクションの2つの更新です。

強制データの整合性とトランザクションサポートを備えた堅牢なストアが必要です。 SQLデータベースのみが（現在）それらの要件を満たします。

自分自身を公開！

これらのシナリオが役立つことを願っていますが、すべてのプロジェクトは異なり、最終的には独自の決定を下す必要があります。 （しかし、私たちの開発者は、彼らがどれほど優れているかに関係なく、私たちの技術的な選択を正当化することに熟達しています！） 最良のアドバイス：できるだけ多くのテクノロジーに自分自身をさらしてください。その知識により、SQLまたはNOSQLに関して理性的かつ感情的に公平な判断を下すことができます。幸運を祈ります。 SQL対noSQL

に関するよくある質問（FAQ）
SQLおよびNOSQLデータベースはいくつかの点で異なります。 SQLデータベースはリレーショナルです。つまり、テーブルと行でデータを編成します。データを定義および操作するために、構造化クエリ言語（SQL）を使用します。一方、NOSQLデータベースは非関連性であり、ドキュメントベース、列ベース、グラフベース、またはキー価値ペアのいくつかの方法でデータを保存できます。これらは、分散データの大規模なセットを使用するのに特に役立ちます。最大の重要性。また、複雑なクエリを実行する必要がある場合にも有益です。 SQLデータベースは酸に準拠しています。信頼できるトランザクションが確保されます。時間の経過とともに不明確または変更されています。柔軟性、スケーラビリティ、速度を提供するため、リアルタイムアプリケーションとビッグデータに適した選択肢になります。同じプロジェクトに共存できます。これは、ポリグロット持続アーキテクチャとして知られています。データベースの選択は、アプリケーションの各部分の特定の要件に依存します。
人気のあるSQLおよびNOSQLデータベースは何ですか？
一般的なSQLデータベースには、MySQL、Oracle、PostgreSQLが含まれます。人気のNOSQLデータベースには、MongoDB、Cassandra、およびRedisが含まれます。テーブルと関係。 NOSQLデータベースでは、NOSQLデータベースのタイプに応じて、データモデリングをさまざまな方法で実行できます。ドキュメント、キー値、列、またはグラフ。 > SQLデータベースは通常、より強力なハードウェアを追加することで垂直にスケーリングしますが、NOSQLデータベースはより多くのサーバーを追加することで水平方向にスケーリングしますトラフィック。
cap定理とは何ですか？sqlとnosqlにどのように適用されますか？

cap定理は、分散データストアが同時に次の3つの保証のうち2つ以上を提供することは不可能であると述べています：一貫性、可用性、およびパーティション許容度。 SQLデータベースは一貫性と可用性を優先しますが、NOSQLデータベースは可用性とパーティション許容度を優先します。トランザクション用。一方、NOSQLデータベースは、通常、すべての酸性特性を提供しません。代わりに、彼らはベース（基本的に利用可能、ソフトステート、最終的に一貫性のある）モデルに焦点を当てています。複雑なクエリを必要とする会計システムやシステムなどの行取引。 NOSQLデータベースは、コンテンツ管理システム、リアルタイム分析、IoTアプリケーションのように、大量のデータを処理し、水平方向にスケーリングする必要があるアプリケーションに最適です。

以上がSQL vs NOSQL：選択方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。