
私は決して狂信的ではありません。実際のプロジェクトでは、最適な組み合わせは、通常のリレーショナルデータベースと特殊なデータウェアハウスからのものです。 キーと値のペアだけでなく、オブジェクトに関する追加のメタ情報も保存するより高度なシステムは、機能の面で既にデータベースに近づいています。作業が行われている情報の単位であるため、ドキュメント指向データベース(リポジトリ)と呼ばれることもあります。ドキュメントとその関連データです。
2番目の基準または機能は分布です。 DBMSの場合、これは多くの場合非常に複雑に解決されるか、サードパーティツールの助けを借りて解決されます。 データウェアハウスはDHT( 分散ハッシュテーブル )に基づいて構築され、最初は分散作業の準備が整っており、個々のノードの障害に対するスケーラビリティと耐性を提供します。 一部のシステムでは、これは環境を犠牲にして解決されます(たとえば、ストレージがErlang VM上で実行される場合)、後者は組み込みの分散作業ツール(たとえば、JavaシステムのJGroups )またはMemcachedなどの独自のソリューションを使用します。
クラウド環境で作業するためのそのようなシステムの完全な準備はそれほど重要ではありません。そのようなストレージがAmazon(S3およびSimpleDB)で機能するのは、何の役にも立ちません。 Googleの有名なBigTableは、ほとんどの場合、キーと値のペアを保存および処理するための単なるシステムでもあります。 APIはシンプルであり、ささいなこともあります(ただし、標準のSQL DBよりも単純ですが、内部デバイスは常にそうではありません)ため、ソリューションは完全に拡張(読み取りと書き込みの両方)します。 。 したがって、クラスターを持っているか、持っている場合は、そのような決定を検討してください。 ただし、言及する価値のある点が1つあります。このようなシステムは、多くの場合、メモリにデータを格納する場合にのみ機能しますが、通常のリレーショナルデータベースに格納するなど、永続的なストレージが必要な場合は、バックエンドシステムが使用されますデータとそのパラメーターの制限(および速度低下)。
なぜこれを適用できるのですか? はい、別々の独立したブロックに分割できる大量の(ほぼ無制限の)データを保存する必要がある場合はどこでも。 これは、個々の記事、写真、ビデオ、または他の大きなバイナリオブジェクト、ログエントリ、ユーザープロファイル、セッションデータ(ちなみに、 以前に実験的なオープン開発、アプリケーションのPHPセッションの分散ストレージ用のJavaセッションサーバーを発表しましたが、同様のソリューションがあります) 工業用Zendプラットフォーム )。 ほとんどの場合、すべてはバイナリデータのセット、またはシリアル化された形式のデータまたはコードを含むテキスト文字列のいずれかに制限されているため、処理プログラムでさらにデータを使用するか、すぐにクライアントに渡すことができます-これは、 Nginxプラグインが行うことです。要求されたコンテンツがあり、スクリプトへのアピールを完全にバイパスして直接提供します。 現在、たとえば、チャットサーバーを設計していますが、そこでは、メインデータストアと同様に、分散キャッシュ(JGroupsを介したレプリケーションでキャッシュを使用するJavaシステム)が使用されます。これは、キーと値の形式の基本的に同じデータストアです。
さて、理論的には、市場に存在するストレージシステム(もちろん、オープンソース)を見てみましょう。
- プロジェクトヴォルデモートは、最も興味深いプロジェクトの1つです(これについて詳しく説明する予定です)。 Javaで作成され、パーティショニングとデータ複製が実装されています。 BerkleyDBまたはMySQLを使用して永続的なストレージが必要な場合、独自のストレージを追加できます。ストレージシステムはプラグインに基づいているため、非常に簡単です。 残念ながら、Javaアプリケーション用のAPI(または他のクライアント用のFacebook Thriftプロトコルの使用)のみがあるようです。 構造化データ(配列)、blob(バイナリデータパケット)、およびデータのプレーンテキストを保存できます。 ホットスケーリングにはいくつかの困難があります;新しいノードをクラスターに追加するのは簡単なアクションではありません。
- ScalarisはErlangベースのトランザクションストレージシステムで、ディスク上の永続ストレージを使用せず、メモリ内のデータのみを処理します。 フォールトトレランスのために、シャーディングとレプリケーション、および「非ブロッキングPaxosコミットプロトコル」が使用されます(その詳細を調べる必要があります)。 サーバーには、Java、Erlang、および他のクライアントと対話するための組み込みJSON RPC用のAPIがあります。 いつでも簡単に拡張できます(Erlangのプラットフォームはこれに完全に適合しています)。
- MemcacheDB- すでにこのシステムについて書きましたが 、BerkeleyDBを使用してディスク上のレプリケーションとストレージのみを使用します。 おそらく、インストール中および使用中のすべてのプロジェクトの中で最も単純であり、Memcachedに基づくインフラストラクチャを既に使用している場合、このシステムはそれに完全に適合します。
- ThruDBは、 Apache Thriftフレームワーク (Facebookによって開発されたThriftプロトコルのオープン開発プロジェクト)に基づくプロジェクトです。 実際、これは1つのプロジェクトではなく、インフラストラクチャを構築するための一連のサービス全体(順番に、他のオープンソース開発に基づいています)-実際には、MySQL、Amazon S3、BerkeleyDB、およびキューサービスのバックエンドを備えたストレージサービス自体ですメッセージングサービス、スケーリングサービス、ドキュメントストレージシステム、さらにはインデックス作成およびデータ取得サービス(CのJava LuceneポートCLuceneを使用)。 クライアントライブラリはさまざまな言語で使用できます。原則として、Thriftプロトコルポートで十分です。 これらの機能の多くが一度に必要な場合、非常に興味深いソリューションです。
- Apache CouchDBは、クライアントと対話するためにRESTful HTTP / JSON APIを使用するErlangベースのドキュメント指向のストレージシステムです。 配布には、増分双方向レプリケーションと自動競合解決が使用されます。 ところで、JavaScriptをドキュメントクエリ言語として使用できます。 安定性のために、ディスク上のデータストレージ(ネイティブ形式)および他のノード上のレプリケーションが使用されます。 プロトコルのネットワークの性質に基づいて、データベースは、Webページ(JS)からの直接リクエストを含むJSON HTTPリクエストを生成できる任意のクライアントおよびプラットフォームで動作できます。
リストには、 Hadoop HBase 、 Cassandra 、 Hypertable 、 Dynomite 、 Kai 、 Ringoなどのシステムが含まれていませんでした。
主にこれらのタイプのシステムでは、特殊な言語とプラットフォーム(Erlangはここではほとんど競合していません)またはJavaなどの既に古典的で主流になっている深刻なシステムを使用し、まれにC / C ++での独自の開発に基づいていることに注意してください。
必ずしもウェブではない高性能システムを開発していますか? 特定のデータストレージが必要ですか、それを最も簡単な方法で受け取りたいが、一瞬も停止することなく「上下」にスケールしますか? 大量のデータがあるかもしれませんが、それらはすべて単純で、文字列またはシリアル化された構造とバイナリブロックになりますか? 信頼できるデータストレージ、分散型、耐障害性が必要ですか? これらの質問の少なくとも1つの答えが「はい」の場合、リストから少なくともいくつかのプロジェクトを確認する必要があります。おそらく、プロジェクトが負荷に耐え、自信を持って開発できるようになるでしょう。
PS私が書くことを私に押し付けた元の記事 -システムの良い比較表があります。