NoSQLシステムの概要

これまでにない量のデータにより、開発者や企業は、30年以上使用されているリレーショナルデータベースの代替を検討するようになりました。 これらのテクノロジーはすべて、 NoSQLデータベースとして知られています 。









主な問題は、リレーショナルデータベースが現在の実際の負荷に対応できないことです（ 高負荷プロジェクトについて話している）。 関心のある特定の3つの領域があります。

• たとえば、Digg（友人が記事をダグした場合に表示される緑色のアイコンに3テラバイト）、Facebook（着信メッセージによる検索に50テラバイト）またはeBay（合計2ペタバイト）の場合のような大量のデータの水平スケーリング
• 個々のサーバーのパフォーマンス
• 柔軟な論理構造設計ではありません。

多くの企業は、巨大なデータ配列を保存およびスケーリングするための新しい方法を見つける必要があります。 最近、非リレーショナルRIAKストレージに関する記事の翻訳を書きました。 この記事では、NoSQLの動きとして理解されている非リレーショナルデータベースとシステムの大部分を検討します。



NoSQLは、Last.fmのJoan Oskarssonがオープンソースの分散データベースについて議論するイベントをホストしたかったときに、 Eric Evan / Racker によって造られました 。



一部の人々は、NoSQLという用語を私たちが誰であるかではなく、私たちがしたくないことに基づいているように聞こえるので、それを認めません。 NoSQLの動きは、リレーショナルデータベースに対する動きではありません。 NoSQLは「 SQLだけではありません」であり、「SQLがまったくない」というわけではありません。



NoSQLという用語は、設計がまったく異なる多数の製品を隠しており、議論する際に、さまざまなシステムについて話し合うことができます。 したがって、これらのシステムを比較するために3つの軸を使用することをお勧めします：スケーラビリティ、データとクエリモデル、データストレージシステム。



例として10個のNoSQLデータベースを選択しました。 これは完全なリストではありませんが、評価には十分です。

拡張性

スケーラビリティとは、レプリケーションを意味するものもあるため、このコンテキストでスケーラビリティについて話すときは、複数のサーバー間でのデータの自動配信を意味します 。 このようなシステムを分散データベースと呼びます。 これらには、 カサンドラ、HBase、リアック、スカラリス、ヴォルデモートが含まれます。 これは、1台のマシンで処理できないデータのボリュームを使用する場合、または配布を手動で管理したくない場合にのみ選択できます。



分散データベースでは、2つのことを確認する必要があります。 複数のデータセンターのサポートと、アプリケーションのために透過的に作業クラスターに新しいマシンを追加する機能です 。









非分散データベースには、 CouchDB、MongoDB、Neo4j、Redis、Tokyo Cabinetなどがあります。 これらのシステムは、分散システムのデータを保存するためのレイヤーとして機能できます。 MongoDBは、限定されたシャーディングサポートを提供し、CouchDBの個別のラウンジプロジェクトを提供します。東京キャビネットは、ヴォルデモートのファイルストレージシステムとして使用できます。

データとクエリモデル

NoSQLデータベースには、非常に多様なデータモデルとクエリAPIがあります。









（関連リンクThrift 、 Map / Reduce 、 Thrift 、 Cursor 、 Graph 、 Collection 、 ネストされたハッシュ 、 get / put 、 get / put 、 get / put ）



カラムファミリシステム（columnfamily）は CassandraとHBaseで使用され、そのアイデアはGoogle Bigtableデバイスを説明するドキュメントから導入されました（CassandraはBigtableのアイデアを少し残し、スーパーカラムを導入しました）。 どちらのシステムにも、見慣れた行と列がありますが、行の数は多くありません。各行には、必要に応じて列が多少あります。列を事前に定義する必要はありません。



キー/値システム自体はシンプルで実装が難しくありませんが、データのクエリや更新のみに関心がある場合は効果的ではありません。 分散システムの上に複雑な構造を実装することも困難です。



ドキュメント指向のデータベースは、本質的にキー/バリューシステムの次のレベルであり、ネストされたデータを各キーに関連付けることができます。 このようなクエリのサポートは、毎回単にBLOB全体を返すよりも効率的です。



Neo4Jには、オブジェクトと関係をグラフのノードとエッジとして保存する、真にユニークなデータモデルがあります 。 このモデルに一致するクエリ（階層データなど）の場合、代替クエリよりも1000倍高速になる可能性があります。



Scalarisは、複数のキーにわたって分散トランザクションを使用する点で独特です。 一貫性と可用性の間のトレードオフの議論はこの記事の範囲を超えていますが、これは分散システムを評価する際に考慮すべき別の側面です。

データストレージシステム

ストレージとは、データをシステム内に保存する方法を意味します。









ストレージシステムは、ベースが通常どの程度の負荷に耐えられるかについて多くのことを教えてくれます。



データをメモリに保存するデータベースは非常に高速です（Redisは1秒あたり最大100,000の操作を実行できます）が、使用可能なRAMのサイズを超えるデータを扱うことはできません。 耐久性（サーバー障害または停電の場合にデータを保存する）も問題になる可能性があります（ 新しいバージョンでは、 追加専用ログのサポートがあります ）。 ディスクに書き込まれると予想されるデータの量は、潜在的に大量です。 RAMにデータストレージを備えた別のシステム-Scalarisは、レプリケーションを使用して寿命の問題を解決しますが、複数のデータセンターへのスケーリングをサポートしていないため、停電時にデータ損失が発生する可能性があります。



MemtablesおよびSSTablesは、データの安全性を確保するためにコミットログに書き込んだ後、メモリへの書き込み要求（memtable）をバッファリングします（これは説明が困難ですが、wiki Cassandra- http: //wiki.apache.org/cassandra/ArchitectureOverviewで詳しく読むことができます ）。 十分な数のレコードを蓄積した後、Memtableはソートされ、すでにSSTableとしてディスクに書き込まれます。 これにより、メモリのパフォーマンスに近いパフォーマンスが得られると同時に、システムはメモリにのみ保存されている場合、実際の問題がなくなります。 （この手順については、セクション5.3および5.4で詳しく説明し、ログに基づいてツリーをマージする- ログ構造化された マージツリー ）



Bツリーは 、非常に長い間データベースで使用されてきました。 信頼性の高いインデックス作成サポートを提供しますが、データの書き込みまたは読み取り時に多数のヘッド位置があるため、磁気ディスク（ まだ最も費用対効果の高い）上のハードディスクを搭載したマシンで使用すると、パフォーマンスが非常に低下します。



おもしろいオプションは、CouchDBでBツリーを使用することです。追加機能（ 追加のみの Bツリー -要素を追加するときに再構築する必要のないバイナリツリー）のみを使用します。

おわりに

NoSQLの動きは、大量のデータの使用に関与する企業の数に対する熱意により、2009年に急成長しました。 膨大な量のデータを整理して透過的にサポートし、このデータを処理および制御できるシステムが増えています。 この短い記事のおかげで、NoSQLシステムの長所について学び、この動きの発展に貢献できることを願っています。