NoSQL（元々は「Not only SQL」または「non-relational」の意味）[ 1]は、従来のテーブルベースのリレーショナルデータベースの構造とは異なる方法でデータを保存および取得するデータベース設計の一種を指します。スプレッドシートのようにデータを行と列に整理するリレーショナルデータベースとは異なり、NoSQLデータベースは、キーと値のペア、幅の広い列、グラフ、ドキュメントなどの単一のデータ構造を使用して情報を保持します。この非リレーショナル設計は固定スキーマを必要としないため、大規模で非構造化されていることが多いデータセットを管理するために簡単に拡張できます。[2] NoSQLシステムは、 SQLのようなクエリ言語をサポートしたり、複数のデータベースタイプが組み合わされたポリグロットパーシステントセットアップでSQLデータベースと連携したりできるため、 「Not only SQL」と呼ばれることもあります[3] [4]非リレーショナルデータベースの歴史は1960年代後半に遡りますが、「NoSQL」という用語はソーシャルメディアプラットフォームなどのWeb 2.0企業のニーズに後押しされて2000年代初頭に登場しました。 [5] [6]

NoSQLデータベースは、そのシンプルな設計、マシンのクラスタにわたるスケーリング機能（水平スケーリングと呼ばれる）、およびデータ可用性の正確な制御により、ビッグデータおよびリアルタイムWebアプリケーションで人気がある。[7] [8]これらの構造は特定のタスクを高速化することができ、多くの場合、固定データベーステーブルよりも適応性が高いと見なされる。[9]しかし、多くのNoSQLシステムでは、厳密な一貫性（CAP定理による）よりも速度と可用性を優先し、結果整合性を使用している。結果整合性とは、更新が最終的にすべてのノードに到達し、通常は数ミリ秒以内であるが、最新データへのアクセスに短い遅延（古い読み取りと呼ばれる）が発生する可能性があるシステムのことである。[10]ほとんどのシステムでは完全なACIDトランザクションサポートが欠如しているが、MongoDBのようにそれを主要機能として含んでいるシステムもある。[11]

導入の障壁

NoSQLの普及を阻む障壁としては、SQLではなく低レベルのクエリ言語を使用していること、テーブル間でアドホック結合を実行できないこと、標準化されたインターフェースが不足していること、リレーショナルデータベースへの多大な投資などが挙げられます。[12]一部のNoSQLシステムでは、書き込みの損失やその他の形でデータが失われるリスクがありますが、先行書き込みログ（変更を適用する前に記録する方法）などの機能は、これを防ぐのに役立ちます。[13] [14]複数のデータベースにまたがる分散トランザクション処理では、データの一貫性を維持することがNoSQLとリレーショナルシステムの両方にとって課題となります。リレーショナルデータベースは個別のデータベースをリンクするルールを適用できず、分散更新を管理するためのACIDトランザクションとX/Open XA標準の両方をサポートするシステムはほとんどないためです。[15] [16]インターフェース環境内の制限は、セマンティック仮想化プロトコルを使用することで克服され、NoSQLサービスはほとんどのオペレーティングシステムからアクセス可能になります。[17]

履歴

Last.fmプレーヤー
Last.fmプレーヤー

NoSQLという用語は、1998年にカルロ・ストロッツィによって、標準的な構造化照会言語（SQL）インターフェースを公開していないものの、リレーショナルデータベースである軽量オープンソースリレーショナルデータベース「ストロッツィNoSQL」の名称として用いられました。 [18]彼のNoSQL RDBMSは、2009年頃のNoSQLデータベースの一般的な概念とは異なります。ストロッツィは、現在のNoSQLの動きは「リレーショナルモデルから完全に逸脱しているため、『NoREL』と呼ぶ方が適切だった」と示唆しています。 [19]これは「リレーショナルではない」という意味です。

当時Last.fmの開発者だったヨハン・オスカーソンは、2009年初頭に「オープンソースの分散型非リレーショナルデータベース」について議論するイベントを開催し、NoSQLという用語を再導入しました。[20]この名前は、GoogleのBigtable / MapReduceやAmazonのDynamoDBのオープンソースクローンを含む、非リレーショナル分散型データストアの増加を示すために使用されました。

種類と例

NoSQLデータベースを分類する方法は様々で、異なるカテゴリとサブカテゴリがあり、一部は重複しています。以下は、データモデルによる網羅的ではない分類と例です。[21]

キーバリューストア

キーバリュー（KV）ストアは、連想配列（マップまたは辞書とも呼ばれる）を基本的なデータモデルとして用います。このモデルでは、データはキーと値のペアのコレクションとして表現され、各キーはコレクション内で最大1回しか出現しません。[24] [25]

キーバリューモデルは最も単純で非自明なデータモデルの一つであり、より高度なデータモデルはしばしばその拡張として実装されます。キーバリューモデルは、キーを辞書式順序で維持する離散順序モデルに拡張できます。この拡張は計算力が非常に高く、選択的なキー範囲を効率的に取得できます。[26]

キーバリューストアは、結果整合性からシリアル化可能性まで、幅広い一貫性モデルを使用できます。一部のデータベースはキーの順序付けをサポートしています。ハードウェア実装には様々な種類があり、データをメモリ（RAM）に保存するユーザーもいれば、ソリッドステートドライブ（SSD）や回転式ディスク（ハードディスクドライブ（HDD）とも呼ばれます）に保存するユーザーもいます。

ドキュメントストア

ドキュメントストアの中心的な概念は「ドキュメント」です。この定義の詳細はドキュメント指向データベースによって異なりますが、いずれの場合も、ドキュメントはデータ（または情報）を何らかの標準形式またはエンコーディングでカプセル化し、エンコードすることを前提としています。使用されるエンコーディングには、XML、YAML、JSON、そしてBSONのようなバイナリ形式が含まれます。ドキュメントは、データベース内でそのドキュメントを表す一意のキーによってアドレス指定されます。ドキュメント指向データベースのもう一つの特徴は、ドキュメントの内容に基づいてドキュメントを取得するためのAPIまたはクエリ言語を備えていることです。

実装によって、ドキュメントを整理およびグループ化する方法が異なります。

  • コレクション
  • タグ
  • 非表示のメタデータ
  • ディレクトリ階層

リレーショナルデータベースと比較すると、コレクションはテーブル、ドキュメントはレコードに類似していると考えることができます。しかし、両者は異なります。テーブル内のすべてのレコードは同じフィールドの順序を持​​ちますが、コレクション内のドキュメントは全く異なるフィールドを持つ場合があります。

グラフ

グラフデータベースは、有限数の関係で接続された要素からなるグラフとして、関係が適切に表現されるデータのために設計されています。データの例としては、社会関係、公共交通機関のリンク、道路地図、ネットワークトポロジなど が挙げられます。

グラフデータベースとそのクエリ言語

パフォーマンス

NoSQLデータベースのパフォーマンスは通常、 1秒あたりの操作数で測定されるスループットという指標を使用して評価されます。パフォーマンス評価では、本番環境の構成、データベースのパラメータ、予想されるデータ量、同時ユーザーワークロードなど の適切なベンチマークに注意を払う必要があります

ベン・スコフィールドは、NoSQLデータベースのさまざまなカテゴリを次のように評価しました。[28]

パフォーマンスとスケーラビリティの比較は、YCSBベンチマーク を使用して最も一般的に行われます

リレーショナルデータの処理

ほとんどのNoSQLデータベースはクエリ内での結合機能がないため、データベーススキーマは通常、異なる方法で設計する必要があります。NoSQLデータベースでリレーショナルデータを処理するための主な手法は3つあります。（結合をサポートするNoSQLデータベースについては、テーブル結合とACIDサポートを参照してください。）

複数のクエリ

1つのクエリですべてのデータを取得するのではなく、目的のデータを取得するために複数のクエリを実行するのが一般的です。NoSQLクエリは従来のSQLクエリよりも高速であることが多いため、追加のクエリにかかるコストは許容範囲内です。過剰な数のクエリが必要な場合は、他の2つのアプローチのいずれかが適切です

キャッシュ、レプリケーション、非正規化データ

外部キーのみを保存するのではなく、モデルのデータと共に実際の外部値を保存するのが一般的です。例えば、各ブログコメントにはユーザーIDに加えてユーザー名が含まれる場合があり、これにより、別の検索を必要とせずにユーザー名に簡単にアクセスできます。しかし、ユーザー名が変更されると、データベース内の多くの場所でユーザー名を変更する必要があります。したがって、このアプローチは、書き込みよりも読み取りがはるかに多い場合により効果的です。[29]

データのネスト

MongoDBのようなドキュメントデータベースでは、より多くのデータをより少数のコレクションに格納するのが一般的です。たとえば、ブログアプリケーションでは、ブログ投稿ドキュメント内にコメントを保存することで、1回の検索ですべてのコメントを取得できます。したがって、このアプローチでは、特定のタスクに必要なすべてのデータが1つのドキュメントに含まれます

ACIDと結合のサポート

データベースのドキュメントにACID特性（原子性、一貫性、独立性、永続性）または結合操作のサポートが記載されている場合、そのデータベースはACID特性または結合操作をサポートしているとみなされます。ただし、これは必ずしも、ほとんどのSQLデータベースと同様に、その機能が完全にサポートされていることを意味するわけではありません。

  1. ^ 結合は必ずしもドキュメントデータベースに適用されるわけではありませんが、MarkLogicはセマンティクスを使用して結合を行うことができます。[30]
  2. ^ MongoDBはバージョン5.1までシャードコレクションからの結合をサポートしていませんでした。[31]
  3. ^ OrientDBは外部レコードへの直接リンクを保存することで、リンクを使用した1:1結合を解決できます。[32]

NoSQLデータベースにおけるクエリの最適化とインデックス作成

DynamoDB、MongoDB、Cassandra、Couchbase 、HBase、Redisなどのさまざまな NoSQL データベースは、インデックスが作成されていないフィールドをクエリするときにさまざまな動作を示します。多くのデータベースでは、このようなクエリに対してテーブル全体のスキャンまたはコレクション スキャンが実行され、データを取得した後にフィルター操作が適用されます。ただし、最新の NoSQL データベースには、クエリ パフォーマンスを最適化するための高度な機能が組み込まれていることがよくあります。たとえば、MongoDB は複合インデックスとクエリ最適化戦略をサポートし、Cassandra はセカンダリ インデックスとマテリアライズド ビューを提供し、Redis は特定のユース ケースに合わせたカスタム インデックス メカニズムを採用しています。Elasticsearch などのシステムでは、効率的なテキストベースの検索に転置インデックスを使用しますが、インデックスが作成されていないフィールドに対してはフル スキャンが必要になることがあります。この動作は、多くの NoSQL システムの設計が、任意のフィールドに対する最適化されたクエリではなく、スケーラビリティと効率的なキーベースの操作に重点を置いていることを反映しています。その結果、これらのデータベースは基本的なCRUD操作とキーベースの検索には優れていますが、結合やインデックスなしのフィルタリングを含む複雑なクエリへの適合性は、データベースの種類（ドキュメント、キーと値、ワイドカラム、グラフ）と特定の実装によって異なります。[33]

参照

参考文献

  1. ^ http://nosql-database.org/ 「NoSQLの定義：次世代データベース。主に非リレーショナル、分散型、オープンソース、水平スケーラブルといった点に焦点を当てています。」
  2. ^ 「NoSQLデータベースとは？ | IBM」www.ibm.com . 2022年12月12日. 2024年8月9日閲覧。
  3. ^ 「NoSQL (Not Only SQL)」。NoSQLデータベース、Not Only SQLとも呼ばれる
  4. ^ Fowler, Martin . 「NosqlDefinition」。NoSQLの支持者の多くは、NoSQLはSQLに「ノー」という意味ではなく、むしろSQLだけではないという意味だと主張している。
  5. ^ Mohan, C. (2013). 「歴史は繰り返す：NoSQL騒動の賢明な側面とそうでない側面」（PDF） . Proc. 16th Int'l Conf. on Extending Database Technology.
  6. ^ 「Amazonが『NoSQL』データベースで未来へ回帰」WIRED、2012年1月19日。 2017年3月6日閲覧。
  7. ^ Leavitt, Neal (2010). 「NoSQLデータベースは期待に応えられるのか？」(PDF) . IEEE Computer . 43 (2): 12– 14. Bibcode :2010Compr..43b..12L. doi :10.1109/MC.2010.58. S2CID  26876882.
  8. ^ 「RDBMSがデータベース市場を席巻、しかしNoSQLシステムが追い上げている」DB-Engines.com、2013年11月21日。 2013年11月24日閲覧。
  9. ^ Vogels, Werner (2012年1月18日). 「Amazon DynamoDB – インターネット規模のアプリケーション向けに設計された高速かつスケーラブルなNoSQLデータベースサービス」 All Things Distributed . 2017年3月6日閲覧。
  10. ^ 「Jepsen: MongoDB stale reads」Aphyr.com 2015年4月20日. 2017年3月6日閲覧。
  11. ^ 「MongoDB ACIDトランザクション」GeeksforGeeks . 2024年3月12日. 2024年10月25日閲覧。
  12. ^ Grolinger, K.; 東野, WA; Tiwari, A.; Capretz, MAM (2013). 「クラウド環境におけるデータ管理：NoSQLとNewSQLのデータストア」（PDF） . Aira, Springer . 2014年1月8日閲覧。
  13. ^ 「Typesafe Reactive Platformにおける大規模データ分析」Slideshare.net 2015年6月11日. 2017年3月6日閲覧。
  14. ^ Fowler, Adam. 「NoSQLに関する10の誤解」. Dummies.com . 2017年3月6日閲覧。
  15. ^ 「No! to SQL and No! to NoSQL」Iggyfernandez.wordpress.com 2013年7月29日. 2017年3月6日閲覧。
  16. ^ Chapple, Mike. 「ACIDモデル」. about.com . 2016年12月29日時点のオリジナルよりアーカイブ。2012年9月26日閲覧。
  17. ^ Lawrence, MySQLとMongoDBを含むリレーショナルSQLおよびNoSQLシステムの統合と仮想化 (2014). 「MySQLとMongoDBを含むリレーショナルSQLおよびNoSQLシステムの統合と仮想化」.国際計算科学および計算知能会議1 .
  18. ^ Lith, Adam; Mattson, Jakob (2010). 「大規模データ向けストレージソリューションの調査：リアルタイムデータ抽出とバッチデータ挿入のための高性能かつスケーラブルなデータストレージソリューションの比較」（PDF） . チャルマース工科大学コンピュータサイエンス・エンジニアリング学部. p. 70. 2011年5月12日閲覧。
  19. ^ 「NoSQLリレーショナルデータベース管理システム：ホームページ」Strozzi.it、2007年10月2日。 2010年3月29日閲覧。
  20. ^ "NoSQL 2009". Blog.sym-link.com. 2009年5月12日. 2011年7月16日時点のオリジナルよりアーカイブ。 2010年3月29日閲覧。
  21. ^ Strauch, Christof. 「NoSQLデータベース」(PDF) pp.  23– 24 . 2017年8月27日閲覧。
  22. ^ https://apacheignite.readme.io/docs Ignite ドキュメント
  23. ^ https://www.infoworld.com/article/3135070/data-center/fire-up-big-data-processing-with-apache-ignite.html fire-up-big-data-processing-with-apache-ignite
  24. ^ Sandy (2011年1月14日). 「キーバリューストアとNoSQLムーブメント」. Stackexchange . 2012年1月1日閲覧。キーバリューストアは、アプリケーション開発者がスキーマレスなデータを保存することを可能にします。このデータは通常、キーを表す文字列と、「キーバリュー」関係において値とみなされる実際のデータで構成されます。データ自体は通常、プログラミング言語のプリミティブ型（文字列、整数、配列）か、プログラミング言語のバインディングによってキーバリューストアにマーシャリングされたオブジェクトです。この構造により、固定データモデルの必要性がなくなり、適切なフォーマットが可能になります。
  25. ^ Seeger, Marc (2009年9月21日). 「キーバリューストア：実践的概要」(PDF) . Marc Seeger . 2012年1月1日閲覧.キーバリューストアは、データの保存とアクセスに関して、リレーショナルデータベースシステムに代わる高性能な選択肢を提供します。本稿では、現在利用可能なキーバリューストアのいくつかと、それらのRubyプログラミング言語とのインターフェースについて簡潔に概説します。
  26. ^ Katsov, Ilya (2012年3月1日). 「NoSQLデータモデリングテクニック」. Ilya Katsov . 2014年5月8日閲覧。
  27. ^ 「TerminusDB オープンソースのインメモリドキュメントグラフデータベース」. terminusdb.com . 2021年12月16日閲覧。
  28. ^ Scofield, Ben (2010年1月14日). 「NoSQL - リレーショナルデータベースの終焉(?)」 . 2014年6月26日閲覧。
  29. ^ 「リレーショナルからNoSQLへの移行：始め方」Couchbase.com . 2019年11月11日閲覧。
  30. ^ 「MarkLogicで結合ができない？ セマンティクスの問題だ！ - General Networks」Gennet.com。2017年3月3日時点のオリジナルよりアーカイブ。 2017年3月6日閲覧。
  31. ^ 「シャードコレクションの制限」. docs.mongodb.com . 2020年1月24日閲覧。
  32. ^ 「SQLリファレンス・OrientDBマニュアル」OrientDB.com . 2020年1月24日閲覧。
  33. ^ サリバン、ダン. NoSQL for Mere Mortals . ISBN 978-0134023212。

参考文献

  • Sadalage, Pramod; Fowler, Martin (2012). NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence . Addison-Wesley. ISBN 978-0-321-82662-6。
  • ダン・マクリアリー、アン・ケリー（2013年）。NoSQLを理解する：マネージャーと私たち以外の人々のためのガイド。マニング社。ISBN 9781617291074。
  • Wiese, Lena (2015). SQL、NoSQL、クラウド、分散データベースのための高度なデータ管理. DeGruyter/Oldenbourg. ISBN 978-3-11-044140-6。
  • ストラウチ、クリストフ (2012).「NoSQLデータベース」(PDF) .
  • Moniruzzaman, AB; Hossain, SA (2013). 「NoSQLデータベース：ビッグデータ分析のためのデータベースの新時代 - 分類、特性、比較」arXiv : 1307.0191 [cs.DB].
  • Orend, Kai (2013). 「NoSQLデータベースの分析と分類、およびオブジェクトリレーショナル永続化レイヤーの置き換え能力の評価」CiteSeerX  10.1.1.184.483 .
  • クリシュナン、ガネーシュ。クルカルニ、サラン。ダドバワラ、ダルメシュ・キリット。 「バージョン管理された情報の共有、統合、およびレポートのための方法とシステム」。
  • シュトラウフ、クリストフ著「NoSQLホワイトペーパー」（PDF）。シュトゥットガルト：メディア大学
  • Edlich, Stefan. 「NoSQL データベース リスト」。
  • Neubauer, Peter (2010). 「グラフデータベース、NOSQL、Neo4j」
  • Bushik, Sergey (2012). 「ベンダーに依存しないNoSQLデータベースの比較：Cassandra、HBase、MongoDB、Riak」NetworkWorld.
  • Zicari, Roberto V. (2014). 「NoSQLデータストア - 記事、論文、プレゼンテーション」. odbms.org .