190

NoSQLは、リレーショナルデータベースとACID保証の歴史を破る非リレーショナルデータストアを指します。人気のあるオープンソースのNoSQLデータストアは次のとおりです。

  • Cassandra（表形式、Javaで記述、Cisco、WebEx、Digg、Facebook、IBM、Mahalo、Rackspace、Reddit、Twitterで使用）
  • CouchDB（Erlangで書かれたドキュメント、BBCとEngine Yardで使用）
  • Dynomite（Key-Value、Erlangで記述、Powersetで使用）
  • HBase（Key-Value、Javaで記述、Bingで使用）
  • Hypertable（表形式、C ++で記述、Baiduで使用）
  • Kai（Key-Value、Erlangで記述）
  • MemcacheDB（Key-Value、Cで記述、Redditで使用）
  • MongoDB（C ++で記述されたドキュメント、Electronic Arts、Github、NY Times、Sourceforgeで使用）
  • Neo4j（グラフ、Javaで記述、一部のスウェーデンの大学で使用）
  • Project Voldemort（Key-Value、Javaで記述、LinkedInで使用）
  • Redis（Key-Value、Cで記述、Craigslist、Engine Yard、Githubで使用）
  • Riak（Key-Value、Erlangで記述、ComcastおよびMochi Mediaで使用）
  • Ringo（Key-Value、Erlangで記述、Nokiaが使用）
  • Scalaris（Key-Value、Erlangで記述、OnScaleで使用）
  • Terrastore（ドキュメント、Javaで記述）
  • ThruDB（C ++で記述され、JunkDepot.comで使用されるドキュメント）
  • 東京内閣/東京暴君（Key-Value、Cで記述、Mixi.jp（日本のソーシャルネットワーキングサイト）で使用）

あなた（SOリーダー）がデータストアを使用して解決した特定の問題と、使用したNoSQLデータストアについて知りたいのですが。

質問：

  • NoSQLデータストアを使用して解決したスケーラビリティの問題は何ですか？
  • どのNoSQLデータストアを使用しましたか？
  • NoSQLデータストアに切り替える前にどのデータベースを使用しましたか？

私は直接の経験を探していますので、それがない限り答えないでください。

4

15 に答える 15

50

私の現在のプロジェクトは実際に。

正規化された構造での18,000個のオブジェクトの格納：8つの異なるテーブルにまたがる90,000行。それらを取得してJavaオブジェクトモデルにマップするのに1分かかりました。これにより、すべてが正しくインデックス付けされます。

軽量のテキスト表現を使用してキーと値のペアとして保存します。1つのテーブル、18,000行、3秒ですべてを取得し、Javaオブジェクトを再構築します。

ビジネス用語では、最初のオプションは実行可能ではありませんでした。2番目のオプションは、アプリが機能することを意味します。

テクノロジーの詳細：SQLとNoSQLの両方でMySQLを実行しています！優れたトランザクションサポート、パフォーマンス、およびデータを破損しないための実証済みの実績、かなり適切なスケーリング、クラスタリングのサポートなどのためにMySQLを使用します。

MySQLのデータモデルは、キーフィールド（整数）と大きな「値」フィールドになりました。基本的には大きなテキストフィールドです。

新しいプレーヤー（CouchDB、Cassandra、MongoDBなど）は、それぞれがそれ自体で優れた機能/パフォーマンスを提供しますが、私たちの状況には常に欠点があったため（たとえば、Javaサポートの欠落/未熟）、どのプレーヤーも使用しませんでした。

MySQLを（ab）使用することの追加の利点-関係的に機能するモデルのビットは、キー/値ストアデータに簡単にリンクできます。

更新：これは、上司が私を撃ったように、実際のビジネスドメイン（「製品」は使用しません）ではなく、テキストコンテンツを表現する方法の例ですが、再帰的な側面（1つのエンティティ、ここ他のものを「含む」製品）。うまくいけば、正規化された構造では、これがかなりの数のテーブルになる可能性があることは明らかです。たとえば、製品をそのフレーバーの範囲に結合したり、他の製品が含まれているなどです。

Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]
于 2010-02-23T09:16:33.997 に答える
49

負荷を処理できるように、小さなサブプロジェクトをMySQLからCouchDBに切り替えました。結果は素晴らしかった。

約2年前、http：//www.ubuntuusers.de/（おそらくドイツ最大のLinuxコミュニティWebサイト）で自作ソフトウェアをリリースしました。このサイトはPythonで記述されており、すべての例外をキャッチして、MySQLを利用した別の小さなWebサイトに送信できるWSGIミドルウェアを追加しました。この小さなWebサイトは、ハッシュを使用してさまざまなバグを特定し、発生数と最後の発生数も保存しました。

残念ながら、リリース直後、traceback-loggerWebサイトは応答しなくなりました。メインサイトの本番データベースでいくつかのロックの問題が発生し、ほぼすべてのリクエストで例外がスローされていました。また、テスト段階では調査していなかった他のいくつかのバグもありました。トレースバックロガー送信ページと呼ばれるメインサイトのサーバークラスターは、1秒間に数k回実行されます。そして、それはトレースバックロガーをホストする小さなサーバーにとってはあまりにも多くの方法でした（それはすでに古いサーバーであり、開発目的でのみ使用されていました）。

当時、CouchDBはかなり人気があったので、試してみて、小さなトレースバックロガーを作成することにしました。新しいロガーは単一のPythonファイルのみで構成されており、並べ替えとフィルターのオプションを含むバグリストと送信ページが提供されていました。そして、バックグラウンドでCouchDBプロセスを開始しました。新しいソフトウェアはすべてのリクエストに非常に迅速に対応し、大量の自動バグレポートを表示することができました。

興味深い点の1つは、以前のソリューションが古い専用サーバーで実行されていたのに対し、新しいCouchDBベースのサイトはリソースが非常に限られた共有xenインスタンスでのみ実行されていたことです。また、キー値ストアの強度を使用して水平方向にスケーリングすることもしていません。何もロックせずに同時リクエストを処理するCouchDB/Erlang OTPの機能は、ニーズを満たすのにすでに十分でした。

現在、すばやく作成されたCouchDB-tracebackロガーはまだ実行中であり、メインWebサイトのバグを調査するのに役立つ方法です。とにかく、月に1回程度データベースが大きくなりすぎて、CouchDBプロセスが強制終了されます。しかし、その後、CouchDBのcompact-dbコマンドにより、サイズが数GBから数KBに再び減少し、データベースが再び稼働します（おそらく、そこにcronjobを追加することを検討する必要があります... 0o）。

要約すると、CouchDBは確かにこのサブプロジェクトにとって最良の選択（または少なくともMySQLよりも優れた選択）であり、その仕事はうまく機能しています。

于 2010-02-24T17:59:03.747 に答える
22

Todd Hoffのhighscalability.comには、いくつかのケーススタディを含め、NoSQLに関する多くの優れた記事があります。

商用のVertica列指向DBMSは、（SQLをサポートしていても）目的に合う可能性があります。分析クエリ用の従来のリレーショナルDBMSと比較して非常に高速です。Verticaとmap-reduceを対比するStonebrakerらの最近のCACMペーパーを参照してください。

更新：そして、Twitterが選択したCassandraは、HBase、Voldemort、MongoDB、MemcacheDB、Redis、HyperTableなどの他のいくつかのものよりも優れています。

アップデート2：Rick Cattellが、高性能データストア内のいくつかのNoSQLシステムの比較を公開しました。そして、highscalability.comのRickの論文に対する見解はここにあります。

于 2010-02-23T23:52:04.633 に答える
8

データの一部をmysqlからmongodbに移動しました。スケーラビリティのためではなく、ファイルや非表形式のデータにより適しているためです。

現在、本番環境で次の製品を保管しています。

  • 25千ファイル（60GB）
  • その他の1億3000万の「ドキュメント」（350GB）

毎日の売上高は約10GBです。

データベースは、mongodb python api（pymongo）を使用して、apache / wsgi / pythonクライアントを使用して2つのノード（6x450GB sas raid10）に「ペア」構成でデプロイされます。ディスクのセットアップはおそらくやり過ぎですが、それがmysqlに使用するものです。

pymongoスレッドプールとmongodbサーバーのブロックの性質に関するいくつかの問題は別として、それは良い経験でした。

于 2010-02-24T20:33:40.003 に答える
5

直接の経験がないため、太字のテキストに反対して申し訳ありませんが、この一連のブログ投稿は、CouchDBの問題を解決する良い例です。

CouchDB：ケーススタディ

基本的に、textmeアプリケーションはCouchDBを使用して、爆発的なデータの問題に対処しました。彼らは、SQLが遅すぎて大量のアーカイブデータを処理できないことを発見し、それをCouchDBに移しました。これは優れた読み物であり、CouchDBが解決できる問題と、それらがどのように解決したかを理解するプロセス全体について説明しています。

于 2010-02-22T19:51:43.043 に答える
5

PostgresqlとMemcachedに保存していたデータの一部をRedisに移動しました。Key Valueストアは、階層オブジェクトデータの保存に非常に適しています。ORMを使用してBLOBをRDBMSにマッピングするよりも、はるかに高速で、開発時間と労力を大幅に削減して、BLOBデータを保存できます。

私はオープンソースのc＃redisクライアントを持っており、1行でPOCOオブジェクトを保存および取得できます。

var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });

新しいサーバーを追加し、負荷を均等に分割して新しいサーバーを含めることができるため、KeyValueストアの「スケールアウト」もはるかに簡単です。重要なのは、スケーラビリティを制限する中央サーバーがないことです。（ただし、リクエストを分散するには、コンシステントハッシュ法の戦略が必要です）。

Redisは、複数のクライアントに高速で同時のアトミックアクセスを提供するステロイドの「マネージドテキストファイル」であると考えているため、テキストファイルまたは組み込みデータベースを使用していたものはすべてRedisを使用しています。たとえば、すべてのサービスのリアルタイムの結合されたローリングエラーログを取得するには（これは私たちにとって大変な作業でした）、Redisサーバー側のリストにエラーを追加するだけで数行で完了します。次に、リストをトリミングして、最後の1000のみが保持されるようにします。例：

var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);
于 2010-02-28T10:55:09.283 に答える
4

直接の経験はありませんが、このブログエントリは非常に興味深いものでした。

于 2010-02-18T14:01:31.133 に答える
3

ソフトウェアドメインオブジェクト（aSalesOrder、aCustomer ...など）を2次元リレーショナルデータベース（行と列）にマップするための作業には、保存/更新してから、複数のテーブルからドメインオブジェクトインスタンスをインスタンス化するために多くのコードが必要です。 。これらすべての参加を行うことによるパフォーマンスへの影響は言うまでもなく、これらすべてのディスクは、販売注文や顧客レコードなどのドメインオブジェクトを表示/操作するためだけに読み取ります。

オブジェクトデータベース管理システム（ODBMS）に切り替えました。これらは、リストされているnoSQLシステムの機能を超えています。GemStone / S（Smalltalk用）はそのような例です。多くの言語用のドライバーを備えた他のODBMSソリューションがあります。開発者にとって重要な利点は、クラス階層が自動的にデータベーススキーマ、サブクラス、およびすべてになります。オブジェクト指向言語を使用して、オブジェクトをデータベースに永続的にします。ODBMSシステムは、ACIDレベルのトランザクションの整合性を提供するため、金融システムでも機能します。

于 2010-08-27T18:48:01.103 に答える
3

基本的に各デバイスのセンサーの時系列を格納するM2Mシステムでは、MySQL（InnoDB）からcassandraに切り替えました。各データは、（device_id、date）および（device_id、type_of_sensor、date）によってインデックス付けされます。MySQLバージョンには2000万行が含まれていました。

MySQL：

  • マスター-マスター同期でセットアップします。同期の喪失に関してはほとんど問題が発生しませんでした。それはストレスがたまり、特に最初は修正するのに何時間もかかる可能性がありました。
  • 挿入時間は問題ではありませんでしたが、データが大きくなるにつれて、クエリにはますます多くのメモリが必要になりました。問題は、インデックスが全体として考慮されることです。私の場合、メモリにロードするために必要なインデックスの非常に薄い部分のみを使用していました（デバイスの数パーセントのみが頻繁に監視され、最新のデータに含まれていました）。
  • バックアップするのは大変でした。Rsyncは、大きなInnoDBテーブルファイルに対して高速バックアップを実行できません。
  • 時間（時間）がかかりすぎたため、重いテーブルのスキーマを更新できないことがすぐに明らかになりました。
  • データのインポートには数時間かかりました（最後にインデックス作成が行われた場合でも）。最善の救済計画は、データベースのコピー（データファイル+ログ）を常に数個保持することでした。
  • あるホスティング会社から別のホスティング会社に移動することは本当に大きな問題でした。レプリケーションは非常に慎重に処理する必要がありました。

カサンドラ：

  • MySQLよりもインストールが簡単です。
  • 大量のRAMが必要です。2GBのインスタンスは、最初のバージョンでは実行できませんでした。現在は1GBのインスタンスで動作できますが、わかりません（データのフラッシュが多すぎます）。私たちの場合、8GBで十分でした。
  • データの整理方法を理解すれば、保存は簡単です。リクエストはもう少し複雑です。しかし、一度それを回避すると、それは本当に速いです（あなたが本当にしたいのでなければ、あなたは本当に間違いをすることはできません）。
  • 前のステップが正しく行われた場合、それは超高速のままです。
  • データはバックアップ用に編成されているようです。すべての新しいデータは新しいファイルとして追加されます。私は個人的には良いことではありません。毎晩、シャットダウンの前に（通常はアップグレードのために）データをフラッシュして、読み取るログが少ないため、復元にかか​​る時間が短縮されます。圧縮されているため、ファイルはあまり作成されません。
  • データのインポートは地獄のように高速です。そして、ホストが多ければ多いほど速くなります。ギガバイトのデータのエクスポートとインポートはもう問題ではありません。
  • スキーマがないことは非常に興味深いことです。なぜなら、ニーズに合わせてデータを進化させることができるからです。これは、同じ列ファミリーに同時に異なるバージョンのデータがあることを意味する場合があります。
  • ホストの追加は簡単でしたが（高速ではありません）、マルチデータセンターのセットアップでは追加していません。

注：私はelasticsearch（luceneに基づくドキュメント指向）も使用しており、NoSQLデータベースと見なす必要があると思います。分散されており、信頼性が高く、多くの場合高速です（複雑なクエリの中には、パフォーマンスが非常に悪いものもあります）。

于 2013-04-08T18:28:42.777 に答える
2

私はしません。処理中に呼び出すことができるシンプルで無料のKey-Valueストアを使用したいのですが、そのようなものはWindowsプラットフォームには存在しません。今はSqliteを使っていますが、東京キャビネットのようなものを使いたいです。BerkeleyDBにはライセンスの「問題」があります。

ただし、Windows OSを使用する場合は、NoSQLデータベースの選択肢が限られています。また、C＃プロバイダーが常に存在するとは限りません

私はMongoDBを試しましたが、それはSqliteの40倍速かったので、多分それを使うべきです。しかし、私はまだ単純なインプロセスソリューションを望んでいます。

于 2010-02-18T09:02:38.290 に答える
2

私はredisを使用して、マシン間でログメッセージを保存しました。実装は非常に簡単で、非常に便利でした。Redisは本当に素晴らしい

于 2010-02-18T22:12:22.783 に答える
2

固定スキーマがないことが私たちにとって大きな利点だったため、postgresデータベースをCouchDBドキュメントデータベースに置き換えました。各ドキュメントには、そのドキュメントへのアクセスに使用される可変数のインデックスがあります。

于 2010-02-24T18:28:40.397 に答える
1

私は過去にCouchbaseを使用しましたが、リバランスの問題やその他の多くの問題が発生しました。現在、私はいくつかのプロダクションプロジェクトでRedisを使用しています。Redisクラスターのスケーリングを処理するRedisのマネージドサービスであるredislabs.comを使用しています。オブジェクトの永続性に関するビデオをhttp://thomasjaeger.wordpress.comのブログで公開しました。このビデオでは、プロバイダーモデルでRedisを使用する方法と、C＃オブジェクトをRedisに格納する方法を示しています。見てください。

于 2015-01-04T01:14:02.233 に答える
1

これを読んでいる人は、3.0がリリースされたので、もう一度Couchbaseを試してみることをお勧めします。初心者向けの200以上の新機能があります。Couchbase Serverのパフォーマンス、可用性、スケーラビリティ、および簡単な管理機能により、非常に柔軟で可用性の高いデータベースが実現します。管理UIが組み込まれており、APIがクラスターノードを自動的に検出するため、アプリケーションからDBへのロードバランサーは必要ありません。現時点ではマネージドサービスはありませんが、AWS、RedHat Gears、Cloudera、Rackspace、CloudSoftなどのDockerコンテナなどでcouchbaseを実行できます。リバランスに関しては、具体的に何を参照しているかによって異なりますが、Couchbaseは、設計どおり、ノード障害後に自動的にリバランスしません。ただし、管理者は最初のノード障害に対して自動フェイルオーバーを設定できます。APIを使用すると、レプリカvbucketsにアクセスして読み取りを行ってからアクティブにするか、RestAPIを使用して監視ツールでフェイルオーバーを実施できます。これは特殊なケースですが、実行することは可能です。

ノードが完全にオフラインで戻ってこないか、新しいノードが自動的にバランスを取る準備ができていない限り、ほとんどのモードでリバランスしない傾向があります。ここでは、最もパフォーマンスの高いNoSQLデータベースの1つが何であるかを知りたいと思っている人を支援するためのガイドをいくつか紹介します。

  1. Couchbase Server 3.0
  2. 管理ガイド
  3. REST API
  4. 開発者ガイド

最後に、分散クエリについてN1QLを確認することもお勧めします。

  1. N1QLチュートリアル
  2. N1QLガイド

読んでいただきありがとうございます。さらにサポートが必要な場合は、私または他の人に知らせてください。

オースティン

于 2015-01-07T00:08:14.250 に答える
0

私は過去にVerticaを使用しました。これは、列型圧縮に依存し、ディスクの読み取りを促進し、ハードウェアを最大限に活用するために必要なストレージを削減します。データの読み込みが速く、同時実行性が高いため、最小限のレイテンシでより多くのユーザーに分析データを提供できます。

以前は、数十億のレコードを持つOracleデータベースにクエリを実行していましたが、パフォーマンスは非常に最適ではありませんでした。SSDで最適化した後でも、クエリの実行には8〜12秒かかりました。したがって、より高速な読み取り最適化された分析指向のデータベースを使用する必要性を感じました。リーンサービスレイヤーの背後にあるVerticaClustersを使用すると、1秒未満のパフォーマンスでAPIを実行できます。

Verticaは、クエリの実行を最適化する形式でデータをプロジェクションに格納します。マテリアライズドビューと同様に、プロジェクションは、クエリで使用されるたびに結果セットを計算するのではなく、ディスクまたはSSDに保存します。プロジェクションには次の利点があります。

  1. データを圧縮およびエンコードして、ストレージスペースを削減します。
  2. データベースクラスター全体の分散を簡素化します。
  3. 高可用性とリカバリを提供します。

Verticaは、セグメンテーションを使用してクラスター全体にデータを分散することにより、データベースを最適化します。

  1. セグメンテーションは、データの一部をノードに配置します。
  2. すべてのノードにデータを均等に分散します。したがって、各ノードはクエリプロセスの一部を実行します。
  3. クエリはクラスター上で実行され、すべてのノードがクエリプランを受け取ります。
  4. クエリの結果は集約され、出力の作成に使用されます。

詳細については、Verticaのドキュメント@https://www.vertica.com/knowledgebase/を参照してください。

于 2019-02-04T08:36:44.117 に答える