web-dev-qa-db-ja.com

NoSQLのトランザクション？

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

transactionsnosql
69
Timmy

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

一般に、マスターとマスターのレプリケーションを行うものは、一貫性を低下させ、可用性を高めます。したがって、適切な問題に対して適切なツールを選択する必要があります。

多くの場合、単一のドキュメント（または行など）レベルでトランザクションが提供されます。たとえば、MongoDBの場合、単一のドキュメントに原子性がありますが、ドキュメントは非常に豊富であるため、通常はこれで十分に機能します-詳細 here 。

36
dm.

これは、NoSQLデータベースに適用される最も近い答えです。 Heroku.comのAdam Wigginsの2007年のブログ投稿にあります。

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

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

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

  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と私のニーズにおそらく十分であることは正しいです。それにもかかわらず、オープンソースツールと「 Razorbladesの竜巻 」というハウツーWebサイトでNoSQLデータベースをどこまで利用できるかを見るのは楽しいでしょう。

17
da01

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

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

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

16
csaba

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

転送をどのようにキューに入れるかを指定した例は、非常にきれいで整然としています。

しかし実際には、送金には手数料や他の口座への支払いが含まれる場合があります。人々は、別のアカウントからの特定のカードを使用した場合にボーナスを受け取ります。または、同じシステム内のアカウントから別のアカウントへの手数料を受け取る場合があります。手数料または支払いは金融取引によって異なる場合があり、各取引のクレジットおよびデビットを示す簿記システムを維持する必要がある場合があります。

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

トランザクションを本当に使用したいのはそのためです。 1つの行への書き込みがうまくいかない場合は、金融取引データの一貫性が失われることなく、一連の更新全体をロールバックできます。

13
Payment Engineer

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

  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ごとにすべてのメッセージを確認し、受信または完了した状態があるかどうかを確認できます-ユーザーのバランスを考慮してください。

6
alexey28

DBに依存しますが、...一般的に言って、これを達成するには 'Optimistic transaction' を使用できますが、確認する必要があると思いますデータベース実装の atomicity 保証を理解するため（たとえば、どの種類の書き込みおよび読み取り操作がアトミックか）。

ネット上でいくつかの議論があるようですHBase トランザクションそれはどんな助けでも。

2
ziya

強力な整合性と実装されたトランザクションを備えたスカラーは、SQLデータベースではありません。

1
Julian Hille

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

1
Cross

SQL DBでは常にNoSQLアプローチを使用できます。 NoSQLは一般に「キー/値データストア」を使用しているようです。NoSQLのパフォーマンスと柔軟性の利点を実現しながら、これを好みのRDBMSにいつでも実装できるため、トランザクション、ACIDプロパティ、使いやすいDBAからのサポートなどの良いものを保持できます、例えばなどのテーブル経由

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

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

個人的には、データを操作するための言語に縛られないように、TEXT表現を好みます。シリアル化されたJavaを使用すると、レポート作成のためにPerlのコンテンツにアクセスできることを意味します。TEXTはデバッグが容易であり、一般に開発者として動作します。

1
Brian

きっと他にもある

1
Dima Tisnek

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

0
rystsov