82

データベースの代替をスケーリングするためにNoSQLを調べています。このようなことに敏感なトランザクションベースのものが必要な場合はどうすればよいですか？

4

11 に答える 11

45

一般的に、NoSQLソリューションは、リレーショナルデータベースよりも軽量なトランザクションセマンティクスを備えていますが、それでもある程度のアトミック操作の機能を備えています。

一般に、マスターマスターレプリケーションを実行するものは、一貫性の点でより少なく、より多くの可用性を提供します。したがって、適切な問題に対して適切なツールを選択する必要があります。

多くは、単一のドキュメント（または行など）レベルでトランザクションを提供します。たとえば、MongoDBの場合、単一のドキュメントにアトミック性がありますが、ドキュメントはかなり豊富な場合があるため、通常はかなりうまく機能します。詳細については、こちらをご覧ください。

于 2010-02-06T19:35:30.363 に答える
18

これは私が見つけた最も近い答えであり、どのNoSQLデータベースにも当てはまります。これは、Heroku.comのAdamWigginsによる2007年のブログ投稿にあります。

データベーストランザクションを使用して、ある銀行口座から別の銀行口座への送金をラップする古い例は、トータルブルです。正しい解決策は、元帳イベント（アカウント間の転送）のリストを保存し、現在の残高を元帳の合計として表示することです。関数型言語でプログラミングしている（またはそのように考えている）場合、これは明らかです。

差出人：http：//adam.heroku.com/past/2007/12/17/a_world_without_sql/（彼のWebサイトはスケーラビリティに関するアイデアに最適です。）

私は上記の段落を次のように解釈しました：

  1. メンバーアカウントのデータベースを作成します。
  2. メッセージングキューを作成します。「元帳」というニックネームを付けます。
  3. バックグラウンドワーカーを追加して、キュー内の各要求を実行します。

より詳しい情報。キュー/バックグラウンドワーカー：http ：//adam.heroku.com/past/2009/4/14/building_a_queuebacked_feed_reader_part_1/

クライアント（別名メンバーまたは顧客）は、次の手順に従ってお金を引き出します。

  1. お金を引き出すためのリクエストを送信します。
  2. リクエストはサーバーに送信されます。
  3. サーバーはそれをキューに入れます。メッセージは次のとおりです。「5,000ドルを取り出してください。」
  4. クライアントが表示されます：「リクエストが実行されるまでお待ちください...」
  5. クライアントマシンは2秒ごとにサーバーをポーリングし、「要求は実行されましたか？」と尋ねます。
  6. サーバーでは、バックグラウンドワーカーが、他のメンバーからの以前の要求を先入れ先出し方式で実行しています。最終的に、彼らはあなたのクライアントのお金を引き出すという要求に到達します。
  7. リクエストが実行されると、クライアントには新しい残高のメッセージが表示されます。

Node.jsまたはRuby/Rackに慣れている場合は、Heroku.comを使用して小さなモックアップをすばやく作成できます。

一般的な考え方は、データベースに組み込まれたトランザクションを使用するよりも非常に簡単で、はるかに優れているように思われます。これにより、スケーリングが非常に困難になります。

免責事項：私はまだこれを実装していません。実用的な必要はありませんが、好奇心を持って読んでいます。はい、@ gbnは、トランザクションを含むRDBMSがTimmyと私のニーズにおそらく十分であることは正しいです。それでも、オープンソースツールと「レイザーブレードの竜巻」と呼ばれるハウツーWebサイトを使用してNoSQLデータベースをどこまで利用できるかを見るのは楽しいでしょう。

于 2010-08-15T18:02:16.067 に答える
16

NoSQLは、Key-Value、ドキュメント、グラフ、ワイド列ストアなど、さまざまなツールとサービスのセットをカバーしています。彼らは通常、データ処理を分散することにより、データストアのスケーラビリティを改善しようとします。トランザクションには、DBがユーザー操作を実行する方法のACIDプロパティが必要です。ACIDは、スケーラビリティを向上させる方法を制限します。ほとんどのNoSQLツールは、オペレーションの整合性基準を緩和して、フォールトトレランスとスケーリングの可用性を実現します。これにより、ACIDトランザクションの実装が非常に困難になります。

分散データストアの一般的に引用される理論的推論は、CAP定理です。一貫性、可用性、およびパーティションの許容度を同時に達成することはできません。SQL、NoSQL、およびNewSQLツールは、あきらめるものに応じて分類できます。良い数字がここにあるかもしれません。

ACIDに代わる新しい、より弱い要件のセットはBASEです（「基本的に利用可能、ソフト状態、結果整合性」）。ただし、結果整合性のあるツール（「最終的にアイテムへのすべてのアクセスは最後に更新された値を返す」）は、銀行などのトランザクションアプリケーションではほとんど受け入れられません。ここでは、メモリ内の列指向の分散SQL / ACIDデータベース（VoltDBなど）を使用することをお勧めします。これらの「NewSQL」ソリューションを検討することをお勧めします。

于 2012-08-23T16:39:14.083 に答える
13

このスレッドのお金の取引のアドバイスにコメントしたかっただけです。トランザクションは、送金で本当に使用したいものです。

転送をどのようにキューに入れるかを示した例は、非常に素晴らしく、きちんとしています。

しかし実際には、送金には手数料や他の口座への支払いが含まれる場合があります。人々は、別のアカウントからの特定のカードを使用することでボーナスを獲得したり、同じシステム内の自分のアカウントから別のアカウントに手数料を受け取ったりする場合があります。手数料や支払いは金融取引によって異なる可能性があり、各取引の貸方と借方を表示する簿記システムを維持する必要がある場合があります。

これは、1つのアカウントの貸方が、1つ以上のアカウントの借方になる可能性があるため、複数の行を同時に更新する必要があることを意味します。まず、更新前に何も変更できないように行をロックしてから、書き込まれたデータがトランザクションと一致していることを確認します。

そのため、本当にトランザクションを使用したいと考えています。1つの行への書き込みで問題が発生した場合は、金融取引データの一貫性を損なうことなく、大量の更新をロールバックできます。

于 2011-11-07T22:58:42.897 に答える
6

1つのトランザクションと2つの操作（たとえば、1つは$ 5,000を支払い、2つ目は$ 5,000を受け取る）の問題は、同じ優先度の2つのアカウントがあることです。1つのアカウントを使用して2番目（または逆の順序）を確認することはできません。この場合、1つのアカウントのみが正しい（確認されている）ことを保証でき、2番目のアカウント（確認されている）は失敗している可能性があります。失敗する理由を見てみましょう（メッセージアプローチを使用して、送信者は受信者によって確認されます）：

  1. レシーバーアカウントに+$5,000を書き込む
  2. 成功した場合-送信者アカウントに-$5,000を書き込みます
  3. 失敗した場合-再試行するか、キャンセルするか、メッセージを表示します

＃1の節約を保証します。しかし、＃2が失敗した場合、誰が保証しますか？逆順も同様です。

ただし、これは、トランザクションなしでNoSQLを使用して安全に実装することは可能です。送信者側と受信者側から確認され、操作が実行されたことを保証する3番目のエンティティの使用が常に許可されます。

  1. 一意のトランザクションIDを生成してトランザクションエンティティを作成する
  2. + $ 5,000を受信者アカウントに書き込みます（トランザクションIDを参照）
  3. 成功した場合-送信するトランザクションの状態を設定します
  4. sednedアカウントアカウントに-$5,000を書き込みます（トランザクションIDを参照）
  5. 成功した場合-受信するトランザクションの状態を設定します

この取引記録は、マッサージの送受信に問題がないことを保証します。これで、トランザクションIDですべてのメッセージを確認でき、メッセージの状態が受信または完了したかどうかを確認できます。ユーザーのバランスを考慮に入れます。

于 2012-04-23T07:50:42.460 に答える
2

DBによって異なりますが、...一般的には、「オプティミスティックトランザクション」を使用してこれを実現できますが、データベース実装のアトミック性の保証（たとえば、どのような種類の書き込みおよび読み取り操作がアトミックであるか）を確実に理解する必要があると思います。）。

それが助けになるなら、 HBaseトランザクションについてネット上でいくつかの議論があるようです。

于 2010-02-06T18:26:26.637 に答える
1

SQLDBではいつでもNoSQLアプローチを使用できます。NoSQLは一般的に「キー/値データストア」を使用しているようです。これはいつでも好みのRDBMSに実装できるため、トランザクション、ACIDプロパティ、友好的なDBAからのサポートなどの優れた機能を維持しながら、NoSQLのパフォーマンスと柔軟性のメリットを実現できます。 、たとえば、

CREATE TABLE MY_KEY_VALUE_DATA
(
    id_content INTEGER PRIMARY KEY,
    b_content  BLOB
);

ボーナスとして、ここにフィールドを追加して、コンテンツを他の適切なリレーショナルテーブルにリンクしながら、かさばるコンテンツをメインのBLOB（またはaptの場合はTEXT）フィールドに保持できます。

個人的にはTEXT表現が好きなので、データを操作するための言語に縛られることはありません。たとえば、シリアル化されたJavaを使用すると、Perlからコンテンツにアクセスしてレポートを作成できます。TEXTはデバッグも簡単で、通常は開発者として使用できます。

于 2010-02-23T09:32:15.820 に答える
1

確かに他にもあります

于 2013-01-16T08:51:20.290 に答える
1

スカラーは、強力な一貫性と実装されたトランザクションを備えたnosqldbです。

于 2012-06-05T19:44:07.457 に答える
1

そのため、非構造化データアプローチの力でエンタープライズアプリケーションで「実際の」トランザクションを使用できるようにするNoSQLドキュメントストアソリューションを作成しています。http://djondb.comをご覧になり、役立つと思われる機能を自由に追加してください。

于 2012-07-06T20:31:53.090 に答える
0

比較と設定をサポートしている場合は、NoSQLソリューションの上に楽観的なトランザクションを実装できます。GitHubページにMongoDBでそれを行う方法の例と説明を書きましたが、適切なNoSQLソリューションで繰り返すことができます。

于 2012-10-06T07:51:04.213 に答える