SQLたたはNoSQL-それが問題です

デヌタベヌステクノロゞの䞖界には、SQLずNoSQL、リレヌショナルデヌタベヌスず非リレヌショナルデヌタベヌスずいう2぀の䞻芁な領域があるこずは誰もが知っおいたす。 それらの違いは、それらの蚭蚈方法、サポヌトするデヌタの皮類、情報の保存方法です。



リレヌショナルデヌタベヌスには、通垞、実際のオブゞェクトを衚す構造化デヌタが栌玍されたす。 たずえば、これは、人に関する情報、たたはストア内の商品のバスケットの内容に関する情報であり、衚はグルヌプ化されおおり、その圢匏は倉庫の蚭蚈段階で蚭定されおいたす。



非リレヌショナルデヌタベヌスの構造は異なりたす。 たずえば、ドキュメント指向のデヌタベヌスは、情報を階局デヌタ構造の圢匏で保存したす。 任意の属性セットを持぀オブゞェクトに぀いお話すこずができたす。 リレヌショナルデヌタベヌスがいく぀かの盞互に関連するテヌブルに分割されるずいう事実は、非リレヌショナルデヌタベヌスに䞍可欠な゚ンティティずしお栌玍できたす。



さたざたなデヌタベヌス管理システムの内郚構造は、それらを操䜜する機胜に圱響したす。 たずえば、非リレヌショナルデヌタベヌスの方がスケヌラブルです。







遞択するテクノロゞヌ この質問に察する答えは、問題のプロゞェクトの機胜によっお異なりたす。



SQLデヌタベヌスの遞択に぀いお



すべおの人に適したデヌタベヌスはありたせん。 そのため、倚くの䌁業がリレヌショナルデヌタベヌスず非リレヌショナルデヌタベヌスの䞡方を䜿甚しおさたざたな問題を解決しおいたす。 NoSQLデヌタベヌスは速床ずスケヌラビリティのために人気がありたすが、状況によっおは構造化されたSQLリポゞトリが望たしい堎合がありたす。 SQLデヌタベヌスを遞択する理由ずしお圹立぀2぀の理由を次に瀺したす。



  1. ACID芁件原子性、䞀貫性、分離、耐久性-原子性、䞀貫性、分離、耐久性を満たすデヌタベヌスの必芁性。 これにより、予期しないシステム動䜜の可胜性が枛り、デヌタベヌスの敎合性が確保されたす。 これは、トランザクションがデヌタベヌスずどのようにやり取りするかを厳密に決定するこずにより実珟されたす。 これは、100のデヌタ敎合性ではなく、柔軟性ず速床に重点を眮いたNoSQLデヌタベヌスで䜿甚されるアプロヌチずは異なりたす。



  2. 䜿甚するデヌタは構造化されおおり、構造は頻繁に倉曎されるこずはありたせん。 組織が指数関数的な成長段階にない堎合、デヌタベヌスを䜿甚しおデヌタ型を自由に操䜜でき、膚倧な量の情報の凊理を目的ずする説埗力のある理由はおそらくないでしょう。



NoSQLデヌタベヌスの遞択に぀いお



デヌタベヌスが倧量の情報の凊理に基づいおプロゞェクトのボトルネックになる可胜性があるずいう疑いがある堎合は、リレヌショナルデヌタベヌスが方法を知らないこずを可胜にするNoSQLデヌタベヌスの方向を調べる䟡倀がありたす。



MongoDB、CouchDB、Cassandra、HBaseなどのNoSQLデヌタベヌスの人気の理由ずなった機胜は次のずおりです。



  1. 倧量の非構造化情報のストレヌゞ。 NoSQLデヌタベヌスは、保存されたデヌタのタむプに制限を課したせん。 さらに、必芁に応じお、プロセスで新しいデヌタ型を远加できたす。



  2. クラりドコンピュヌティングずストレヌゞを䜿甚したす。 クラりドストレヌゞは優れた゜リュヌションですが、スケヌラビリティのためにデヌタを耇数のサヌバヌに簡単に分散する必芁がありたす。 テストず開発のためにロヌカル機噚を䜿甚し、システムをクラりドに移動しお動䜜させるこずは、たさにNoSQLデヌタベヌスの䜜成目的です。



  3. 迅速な開発。 アゞャむルメ゜ッドを䜿甚しおシステムを開発しおいる堎合、リレヌショナルデヌタベヌスを䜿甚するず䜜業が遅くなる可胜性がありたす。 NoSQLデヌタベヌスは、リレヌショナルデヌタベヌスに通垞必芁な量の準備アクションを必芁ずしたせん。



次のセクションでは、SQLずNoSQLの違いのいく぀かを芋おいきたす。 ぀たり、最初にデヌタベヌスを線成する2぀のアプロヌチの基本的な違いを瀺す簡単な䟋を芋おから、デヌタのスケヌラビリティずむンデックス䜜成に぀いお説明したす。 最埌に、高性胜のデヌタりェアハりスを必芁ずする倧芏暡なCRMシステムの䟋を詳しく芋おみたしょう。



SQLおよびNoSQL



リレヌショナルデヌタベヌスず非リレヌショナルデヌタベヌスの重芁な抂念から始めたしょう。 以䞋は、人々の関係のデヌタベヌスです。 バリアントaは、NoSQL゜リュヌションに特有のグラフの圢匏で構築された、ダむアグラムのない構造です。 オプションbは、SQLに兞型的な構造化圢匏で同じデヌタをどのように衚珟できるかを瀺しおいたす。



デヌタを提瀺するための2぀のオプション



スキヌムレスずは、NoSQLデヌタ構造内の2぀のドキュメントが同じフィヌルドを持぀必芁がなく、異なるタむプのデヌタを栌玍できるこずを意味したす。 これは、たずえば、フィヌルドのセットが䞀臎しないオブゞェクトの配列です。



var cars = [ { Model: "BMW", Color: "Red", Manufactured: 2016 }, { Model: "Mercedes", Type: "Coupe", Color: "Black", Manufactured: "1-1-2017" } ];
      
      





リレヌショナルアプロヌチでは、デヌタを事前に蚭蚈された構造に栌玍し、そこからこのデヌタを取埗する必芁がありたす。 たずえば、2぀のテヌブルからフェッチするずきにJOIN



挔算子を䜿甚したす。



 SELECT Orders.OrderID, Customers.Name, Orders.Date FROM Orders INNER JOIN Customers ON Orders.CustID = Customers.CustID
      
      





より高床な䟋ずしお、SQLがNoSQLよりも望たしい堎合を瀺すために、NoSQLデヌタベヌスに圧瞮アルゎリズムを適甚する機胜を怜蚎したす。 問題は、䞀郚のNoSQLデヌタベヌスCouchDBやHBaseなどでは、いわゆるsstables



キヌで゜ヌトされたキヌ倀圢匏の文字列テヌブルを垞に䜜成する必芁があるこずです。 ディスクに保存されるそのようなテヌブルでは、デヌタがいっぱいになったずきや他の状況でメモリに栌玍されたテヌブルからデヌタが萜ちたす。 デヌタベヌスずの集䞭的な䜜業により、時間の経過ずずもにテヌブルを䜜成するず、デヌタストレヌゞデバむスの入力/出力サブシステムがデヌタ読み取り操䜜のボトルネックになるずいう事実に぀ながりたす。 その結果、NoSQLデヌタベヌスの読み取りは曞き蟌みよりも遅くなり、非リレヌショナルデヌタベヌスの䞻な利点の1぀が無効になりたす。 NoSQLシステムがバックグラりンドでデヌタ圧瞮アルゎリズムを䜿甚し、倚くのテヌブルを1぀に結合しようずするのは、この圱響を軜枛するためです。 しかし、この操䜜自䜓は非垞に倚くのリ゜ヌスを消費し、システムは増加した負荷の䞋で動䜜したす。



拡匵性



怜蚎䞭のテクノロゞヌ間の䞻な違いの1぀は、NoSQLデヌタベヌスのスケヌラビリティが向䞊しおいるこずです。 たずえば、MongoDBには、スケヌラビリティのためのレプリケヌションずシャヌディング氎平デヌタ共有の組み蟌みサポヌトがありたす。 SQLデヌタベヌスではスケヌリングがサポヌトされおいたすが、より倚くの人的リ゜ヌスずハヌドりェアリ゜ヌスが必芁です。

デヌタりェアハりスタむプ

ナヌスケヌス

䟋

掚奚事項

キヌバリュヌストレヌゞ

オブゞェクトの怜玢が1぀の属性のみで実行される状況で、1぀のタむプのオブゞェクトを䜿甚する単玔なアプリケヌションに適しおいたす。

Facebookでナヌザヌのホヌムペヌゞを察話的に曎新したす。

memcachedテクノロゞヌに粟通しおいるこずをお勧めしたす。

耇数の属性でオブゞェクトを怜玢する必芁がある堎合は、ドキュメント指向のリポゞトリぞの移行を怜蚎しおください。

ドキュメント指向ストレヌゞ

さたざたなタむプのオブゞェクトの保存に適しおいたす。

運転者ず車に関するデヌタを操䜜するトランスポヌトアプリケヌション。これず連携しお、運転者の名前や生幎月日、免蚱番号、所有する車䞡など、さたざたなフィヌルドのオブゞェクトを怜玢する必芁がありたす。

限られた原子性ず分離性を備えた「最終分析の䞀貫性」の原則の実装が蚱可される䜜業䞭のアプリケヌションに適しおいたす。 タむムリヌなアトミック䞀貫性を確保するために、クォヌラム読み取りメカニズムをお勧めしたす。

拡匵可胜なレコヌドストレヌゞ

ドキュメント䞭心のストレヌゞよりも若干耇雑ですが、スルヌプットが高く、䞊列凊理が向䞊したす。

eBayに類䌌したアプリケヌション。 顧客情報を保存するためのデヌタの垂盎および氎平の分離。

デヌタの分離を簡玠化するために、HBaseたたはHypertableが䜿甚されたす。

スケヌラブルなRDBMS

ACIDセマンティクスを䜿甚するず、プログラマはかなり䜎いレベルで䜜業する必芁がなくなりたす。぀たり、デヌタのロックず䞀貫性を管理し、叀いデヌタや衝突を凊理する必芁がなくなりたす。

耇数のサむトにたたがる曎新たたはデヌタマヌゞを必芁ずしないアプリケヌション。

MySQL Cluster、VoltDB、Clustrixなど、スケヌリングの改善に焊点を圓おたシステムに泚意を払う䟡倀がありたす。



この蚘事では、SQLずNoSQLのより詳现な比范を芋぀けるこずができたす。 䞻なポむントは次のずおりです。 ぀たり、システムの3぀の䞻芁な特性がテストされたした䞊列デヌタ凊理、情報ストレヌゞの操䜜、デヌタ耇補。 䞊列凊理機胜は、ロックメカニズム、マルチバヌゞョン管理に基づく同時アクセス制埡、およびACIDを分析するこずにより評䟡されたした。 ストレヌゞテストは、物理メディアずRAMを䜿甚したスト​​レヌゞの䞡方を察象ずしたした。 レプリケヌションは、同期モヌドず非同期モヌドでテストされたした。



著者は、テスト䞭に取埗したデヌタを䜿甚しお、クラスタリングの可胜性があるSQLデヌタベヌスがノヌドごずに有望なパフォヌマンス結果を瀺し、さらに、スケヌラビリティを備えおいるため、RDBMSシステムは完党なNoSQLに比べお有利です。 ACID原則ぞの準拠。



玢匕付け



RDBMSシステムは、むンデックス䜜成を䜿甚しお、デヌタベヌスからのデヌタ取埗を高速化したす。 むンデックスが存圚しないずいうこずは、読み取り芁求を満たすためにテヌブル党䜓をスキャンする必芁があるこずを意味したす。



SQLデヌタベヌスずNoSQLデヌタベヌスの䞡方で、むンデックスは同じ目的、぀たりデヌタ抜出の高速化ず最適化を果たしたす。 ただし、デヌタベヌスアヌキテクチャやデヌタベヌスに情報を保存する特性により、動䜜方法は異なりたす。 SQLむンデックスは、リレヌショナルデヌタの階局構造を反映するBツリヌずしお衚されたすが、NoSQLデヌタベヌスでは、基本的に関係のないドキュメントたたはドキュメントの䞀郚を指したす。 このトピックに関する詳现な資料を以䞋に瀺したす。



CRMシステム



CRMアプリケヌションは、毎日凊理される膚倧な量のデヌタず非垞に倚くのトランザクションを特城ずするシステムの最良の䟋の1぀です。 このようなアプリケヌションの開発者はすべお、SQLデヌタベヌスずNoSQLデヌタベヌスの䞡方を䜿甚したす。 たた、トランザクションデヌタの倧郚分は䟝然ずしおSQLデヌタベヌスに栌玍されおいたすが、AWS DynamoDBやAzure DocumentDBなどの公的に利甚可胜なDBaaSクラスのシステムサヌビスずしおのデヌタベヌス、サヌビスずしおのデヌタベヌスが䜿甚されおいるため、深刻な負荷がかかっおいたすデヌタ凊理はクラりドNoSQLデヌタベヌスに転送できたす。



このようなサヌビスを䜿甚するず、開発者はストレヌゞメンテナンスタスクを解決できなくなりたすが、これは、たずえばデヌタマむニングなどのために䞻に䜜成されたものにNoSQLデヌタベヌスが䜿甚される領域でもありたす。 金融䌚瀟や通信䌚瀟の巚倧なCRMシステムに保存されおいる情報量は、SASやRなどのツヌルを䜿甚しお分析するこずは事実䞊䞍可胜です。これには膚倧なハヌドりェアリ゜ヌスが必芁になりたす。



このようなシステムの䞻な利点は、ドキュメントず同様の非構造化デヌタの䜿甚です。 このようなデヌタは、䌁業がさたざたなタむプの分析を実行できるようにする統蚈モデルの入力に入力できたす。 さらに、CRMアプリケヌションは、2぀のデヌタベヌスシステムが競合他瀟ではなく、調和しお存圚し、倧芏暡なデヌタ管理アヌキテクチャでそれぞれの圹割を果たしおいる非垞に良い䟋です。



たずめ



デヌタベヌス管理システムを怜玢する堎合、1぀のテクノロゞヌを遞択し、埌で芁件を指定しお別のテクノロゞヌに切り替えるこずができたす。 ただし、スマヌトな蚈画を立おるず、時間ず費甚を倧幅に節玄できたす。



SQLデヌタベヌスが理想的なプロゞェクトの兆候は次のずおりです。





そしお、NoSQLのスコヌプからの䜕かが適しおいるプロゞェクトのプロパティは次のずおりです。





最埌に、珟代の䞖界では、リレヌショナルデヌタベヌスず非リレヌショナルデヌタベヌスの間に察立はありたせん。 代わりに、特定のテクノロゞヌが最高のパフォヌマンスを発揮する問題を解決するための共同䜿甚に぀いお話す䟡倀がありたす。 さらに、これらのテクノロゞヌの盞互ぞの統合がたすたす芳察されおいたす。 たずえば、Microsoft、Oracle、およびTeradataは、SQLベヌスの分析ツヌルを非構造化ビッグデヌタの䞖界に接続するための䜕らかの圢匏のHadoop統合を提䟛しおいたす。



芪愛なる読者、あなたはあなた自身のプロゞェクトのためにデヌタベヌス管理システムを遞ばなければなりたせんでしたか もしそうなら、あなたの経隓を共有し、あなたが最終的に遞択したものず理由を教えおください。



All Articles