問題タブ [acid]

私たちのアーキテクチャは、JAX-WS 仕様で開発された Web サービスで構成されています。

メトロ。これらのサービスは、個別の war として単一の Glass Fish アプリ サーバーにデプロイされます。

ファイル。すべての Web サービスは内部で単一のデータベースを使用します。データアクセス層は Hibernate を使用して実装され、Spring はサービス内のトランザクションの実装に使用されます。複数の Web サービスにまたがるトランザクションを実行したい場合、どのようなアプローチが可能でしょうか?

1. JTA を使用する必要がありますか、それとも回避できますか?
2. Metro でサポートされている WS-AtomicTransaction 仕様を使用する必要がありますか?

無知な質問で申し訳ありませんが、ACID 準拠のデータベース サーバーを必要としないアプリケーションはどれでしょうか? 私は、ACID が常に「そこにある」SQL Server のバックグラウンドを持っており、現在、他の DBMS を調査していると思います。私が考えることができるほとんどすべてのアプリケーションは、原子性または分離のいずれかを必要とします。ありがとう！

私のプロダクションエラーログには、時々表示されます：

SQLSTATE[HY000]: 一般エラー: 1205 ロック待機タイムアウトを超えました。トランザクションを再開してみてください

その時点でどのクエリがデータベースにアクセスしようとしているかはわかっていますが、その正確な瞬間にどのクエリがロックされていたかを調べる方法はありますか?

Mysql が XA トランザクションで ACID プロパティを実現するためにシリアル化可能な分離レベルを必要とする理由、または反復可能な読み取りと XA を使用した場合に何が失われるかを知っている人はいますか?

ただし、分散トランザクションの場合は、SERIALIZABLE 分離レベルを使用して ACID プロパティを実現する必要があります。非分散トランザクションには REPEATABLE READ を使用するだけで十分ですが、分散トランザクションには使用できません。

http://dev.mysql.com/doc/refman/5.6/en/xa.html

InnoDBエンジンが真のシリアル化可能な分離¹を実装するのか、スナップショット分離を実装するのかは、 MySQLのドキュメントからは完全には明らかではありません。これは、紛らわしいことに「シリアル化可能」とも呼ばれます。どちらですか？

MySQL InnoDBがそうでない場合、完全に無料の本番品質のRDBMSはありますか？

¹ここで​​、「真のシリアル化可能な分離」とは、SQL標準による読み取り異常だけでなく、書き込みスキュー異常も存在しないことを意味します。これについては、ここでさらに詳しく説明します。

100,000 人以上のユーザーにサービスを提供する大規模な電子商取引 Web サイトを構築していますが、最初の 1 年間でユーザー数が急速に増加すると予想しています。一般に、このサイトは、ユーザーがリストを作成、更新、および削除できる ebay と非常によく似た機能を果たします。ユーザーは、リストを検索して、興味のあるアイテムを購入することもできます。基本的に、システムにはトランザクション要件と非トランザクション要件があります。

Couch や MongoDB などのスケーラブルなドキュメント ベースの NoSQL データ ストアの機能を活用したいと考えていますが、同時に ACID トランザクション要件をサポートするリレーショナル ストアも必要です。そこで、両方のテクノロジーを使用するハイブリッド ソリューションを考え出しました。

サイトは「主に読み取り」であるため、スケーラビリティのニーズを満たすために、MongoDB データ ストアをセットアップしました。トランザクションのニーズのために、MySQL Cluster をセットアップしました。ミドルウェア コンポーネントとして、JBoss App サーバー クラスターを使用します。

「検索」リクエストが届くと、JBoss はそのリクエストを Mongo に送信して検索を処理します。これにより、MySQL に負担をかけずに非常に迅速に結果が生成されます。リストが作成、更新、削除、または購入されると、JBoss は MySQL に対してトランザクションを処理します。MongoDB と MySQL の同期を維持するために、MySQL に対して JBoss によって処理されるすべてのトランザクション要求には、リスト ID を介して MongoDB 内の対応するドキュメントを更新するビジネス ロジックの最終ステップが含まれます。この文書更新の統合を容易にするために、MongoDB Java API を使用する予定です。

要するに、サイトは主に読み取られるため、このアーキテクチャにより、MongoDB を水平方向にスケールアウトして、より多くのユーザーに対応できるようになります。MySQL を使用すると、JBoss ミドルウェアを通じて MongoDB ストアを更新しながら、リレーショナル データベースの ACID プロパティを活用できます。

このアーキテクチャに問題はありますか? 一貫性、可用性、および分割耐性を同時に提供できるプラットフォームはありません。NoSQL システムは通常、一貫性をあきらめます。しかし、少なくともこのハイブリッド アプローチでは、システムの複雑さが増すという犠牲を払って 3 つすべてを実現できます。私たちの要件はすべて満たされているので、それで問題ありません。

ATM がクラッシュしたとき (どうやら Windows XP を実行していたようです)、ATM を使用していた男と話していて、お金を奪われました。

先行書き込みロギングを備えたトランザクション データベースは、ATM がクラッシュした場合でも、データベースを一貫した状態に保つことができます (つまり、ATM と顧客の口座にいくらのお金があるべきかを常に知ることができます)。ただし、現金の支払いは単なる DB トランザクションではなく、即時の操作ではないため、現金の支払いの前または後にトランザクションをコミットする必要がありますか? どちらの場合も、ATM が適切なタイミングでクラッシュすると、銀行または顧客のどちらかがお金を失う可能性があります。

この問題に対する完璧な (または少なくとも合理的に完璧な) 解決策はありますか?

私が考えることができる 1 つの方法は、ATM に金額をカウントする機能があった場合です。ATM が最初にトランザクションをコミットしてから現金を払い出した場合、クラッシュから回復すると、ATM は保証された一貫性のあるデータベースに従って、含まれているはずの額を超える追加のお金をすぐに払い出すことができます。

しかし、ハードウェアの観点からは、それが本当に実現可能かどうかはわかりません。

どう思いますか？この問題に対処する他の方法はありますか?

私はデータベースと SQL Server の初心者です。

そのため、インターネットでデータベースについて検索したところ、データベースがACID (原子性、一貫性、分離、耐久性)プロパティに従うか従う場合に、データベースが良いと言われていることがわかりました。

Microsoft SQL Server (現在のバージョンまたはそれ以前のバージョン)は内部的に ACID プロパティに従っているか、アプリケーションで MS SQL Server を使用している場合は、アプリケーションが ACID プロパティに従うようにコーディングを記述する必要があるのではないかと思います。

要するに：ACIDプロパティを維持することは、データベースのタスク（または責任）またはアプリケーションプログラマー のタスクです。

ありがとう..

私は、信頼できる方法でデータを永続化する必要があるアプリに取り組んでいます。つまり、アプリケーションのクラッシュや終了などに直面しても、更新を全か無かで永続化する必要があります。

ただし、Core Data がサポートできる回復力のレベルに関する情報はあまり見つかりません。また、周りを見渡すと、Core Data が破損している可能性があるようです。これは正しいですか、それとも Core Data は、信頼できるデータ ストレージをサポートするために必要な高レベルおよび低レベルのACIDプロパティを提供できますか?

どの API がこれらの保証を提供するかについて具体的に教えてください。たとえば、保存中にクラッシュが発生した場合でも (おそらく別のスレッドで)、保存はすべての更新をコミットするか、まったくコミットしないことが保証されますか?

少し前に、MySQL が ACID 方式で動作するように、アプリケーションを完全に再コーディングしました。

すべての関数の最上位レベルで、次のようなことを行います。

関数「dosomething」内で、次のようなユーザーに例外がスローされます。

また

プログラムの流れをコントロールできるように。問題がある場合は、発生したすべてをロールバックし、問題がなければコミットします。それはすべて非常にうまく機能しましたが、これまでに遭遇した欠陥が1つだけあります. ユーザーが直面する問題がいつ発生するかを確認できるように、例外ログを追加しました。しかし、問題は、エラーを記録するテーブルが InnoDB の場合、それもトランザクションに含まれ、問題がある場合はロールバックされるため、エラーが保存されないことです。これを回避するために、基本的にエラー ログ テーブル MyISAM を作成しただけなので、ロールバックが完了しても変更は残っています。

今、トランザクションから除外したい他のビットについて考えています。たとえば、アプリケーション内で管理者にメールを送信して、問題を警告するのに役立ちます。

親トランザクション内にデータベース挿入を含めないようにする方法はありますか? アプリケーション/DB の設計に関して、私は間違った道をたどりましたか? これを処理できる他の方法はありますか?

ありがとう、ドミニク