問題タブ [acid]

大きなExcelから新しいテーブルにデータをインポートするときに、1つのレコードが失敗した場合、何もインポートされません。Atomicityのルールを満たしているので大丈夫だと思います。ただし、ソースデータエラーを修正して再度インポートすると、ID列が1から始まるのではなく、大きな値から始まります。

例えば

結果

ウィキペディアはACIDを次のように説明しています

アトミシティ

Atomicityでは、各トランザクションが「オールオアナッシング」である必要があります。トランザクションの一部が失敗すると、トランザクション全体が失敗し、データベースの状態は変更されません。アトミックシステムは、停電、エラー、クラッシュなど、あらゆる状況で原子性を保証する必要があります。

つまり、SQL Serverは、挿入が失敗した場合にデータベースの状態（ID値）を変更しないように見えます。それで、これはACIDルールに違反しますか？

ところで、PostgreSQLは、挿入が失敗したときにidentity（serial）値を大きくしません。（更新：たまにのみ、コメントを参照してください。これに依存しないでください。）

MongoDB はリレーショナル データベースではなく、製品がリレーショナル アーキテクチャに従っているわけでもありません。しかし、RDBMS の世界から来た人のために、MongoDB が ACID (Atomocity、Consistency、Isolation、Durability) をどの程度サポートしているかを知りたいと思います。それとも、ACID の観点から MongoDB を評価すべきではないのでしょうか?

最後に結果を見る

ドキュメントDBを使用したい（さまざまな理由で）-おそらくCouchDBまたはMongoDB。ただし、複数のドキュメントのトランザクションにもACIDが必要です。

ただし、「追加のみ」のモデルで作業する予定です。変更は新しいドキュメントとして追加されます（追加は追加、更新はコピー+変換データの追加、削除は同じID +削除フラグを持つ空のドキュメントの追加）。定期的に、データベースで圧縮を実行して、最新でないドキュメントを削除します。

それを念頭に置いて、次のアイデアに穴はありますか？

進行中の現在のトランザクションのコレクションを維持します。このコレクションは、進行中のトランザクションのトランザクションID（GUID +タイムスタンプ）を持つドキュメントを保持します。

MVCCに少し似ていて、Gitに少し似ています。開始する前になんとか終了したことがわかっているトランザクションによって、取得コンテキストを設定しました。「トランザクションのリビジョン」ではなく「進行中のトランザクション」のリストを保持することで、単一のシーケンス（したがって単一の実行）を回避します。そしてもちろん、私はコミットされていないトランザクションを読むことを避け、競合のロールバックを提供します。

だから-これに穴はありますか？私のパフォーマンスはひどく損なわれますか？

編集1：お願いします-「複数のドキュメントトランザクションが必要な場合は、ドキュメントデータベースを使用しないでください」を槌で打たないでください。とにかく他の理由でドキュメントデータベースが必要です。

Edit2：取得トランザクションの開始後に開始されるトランザクションからのデータを回避するために、タイムスタンプが追加されました。タイムスタンプをシーケンスIDに変更する可能性があります。

Edit3：これが私が考えた別のアルゴリズムです-それは上記のものよりも良いかもしれません：

新しいアルゴリズム-理解しやすい（そして今回は修正できる可能性があります:)）

開始時にドキュメントはコミットされましたか？
現在実行中のトランザクション（取得を開始する前に開始されたが、その時点ではまだコミットされていないトランザクション）にトランザクションIDを持つドキュメントが表示された場合、それは望ましくありません。トランザクションID>=最上位のトランザクションID（取得を開始した後に開始されたトランザクション）のドキュメントが表示された場合、それは望ましくありません。

ドキュメントは最新（最新バージョン）ですか？
現在のトランザクションID（開始前に開始されたトランザクション）になく、最上位のトランザクションID（開始後に開始されたトランザクション）である、廃止されたドキュメントが表示された場合、過去にコミットを終了したトランザクションがありました。このドキュメントを廃止しました-したがって、私たちはそれを望んでいません。

ソートが損なわれないのはなぜですか？
並べ替えを最後の句として追加するため、実際の並べ替え作業が常に最初に表示されます。実際の並べ替えの「バケット」ごとに、異なるバージョンのモデルオブジェクトを表す複数のドキュメントを取得する場合があります。ただし、モデルオブジェクト間の並べ替え順序は変わりません。

カウンターがトランザクションをシリアルに（一度に1つずつ）実行しないのはなぜですか？
これはRDBMSではないため、実際にはトランザクションがないため、「更新の選択」の場合のようにトランザクションがコミットされるのを待ちません。別のトランザクションは、それが完了するとすぐにアトミックな変更を行うことができます。

圧縮：時々
、圧縮を行う必要があります。本当に古いドキュメントをすべて取得して、別のデータストアに削除します。これは、実行中の取得またはトランザクションには影響しません。

最適化：

1. 条件をクエリ自体に入れます。
2. すべてのインデックスにトランザクションIDを追加します。
3. 同じモデルオブジェクトIDを持つドキュメントが異なるノードにシャーディングされないようにしてください。

費用はいくらですか？
とにかく履歴と監査に複数のドキュメントバージョンが必要だとすると、追加のコストは、カウンターをアトミックに更新し、トランザクションレコードを作成し、各モデルオブジェクトの以前のバージョンを「封印」し（廃止マーク）、トランザクションドキュメントを削除することです。これは大きすぎてはいけません。上記の仮定が有効でない場合、特に検索の場合、追加コストが非常に高くなることに注意してください。

結果：

上記のアルゴリズムを実装しました（マイナーな変更を加えた改訂版）。機能的には、機能しています。ただし、パフォーマンス（少なくとも、マスタースレーブレプリケーショントポロジに3つのノードがあるMongoDBを超える場合、fsyncは必要ありませんが、「コミット」が終了する前にレプリケーションが必要です）はひどいものです。書いたばかりのものをさまざまなスレッドから常に読んでいます。トランザクションコレクションで一定のコレクションロックが発生し、インデックスが一定のロールオーバーに対応できません。10個のフィーダースレッドを使用する小さなトランザクションのパフォーマンスは、20TPSに制限されています。

要するに、良い汎用ソリューションではありません。

Atomicity と Consistency はどう違いますか? どちらも同じことを別の言葉で言っているように見えます。

原子性

トランザクションのすべてのタスクが実行されるか、どれも実行されません。部分的な取引はありません。たとえば、トランザクションが 100 行の更新を開始しても、システムが 20 行の更新後に失敗した場合、データベースはこれらの 20 行への変更をロールバックします。

一貫性

トランザクションは、データベースをある一貫した状態から別の一貫した状態に移行します。たとえば、普通預金口座からの引き落としと当座預金口座への貸方記入を行う銀行取引では、障害によってデータベースが 1 つの口座だけに貸方記入されてはなりません。これにより、データの一貫性が失われる可能性があります。

アトミック性は一貫性のサブセットのように見えます。それから、それは cid(conistency, isolation, duribility) であり、アトミック性はありません

MongoDB を使用してユーザー レコードをドキュメント形式で保存する Android アプリを開発しています。開始の経度と緯度、終了の経度と緯度、合計時間、最高速度、合計距離など、GPS トラックに関する情報を含むいくつかのレコードがあります。

私の質問は、平均速度に関するものです。アプリに平均速度を計算させ、それをドキュメントのフィールドとして保存する必要がありますか?それとも、時間と距離を取得するだけでこれを計算する必要がありますか?

平均速度に基づいてソートする必要がある何千ものレコードがあり、最も合理的なのはドキュメントにも平均速度を保存するようです。ただし、これは、速度が DB の外部で計算される従来の SQL Acid の考え方から脱却します。

レコード コレクションの現在のドキュメント構造は次のようになります。

私はhbaseでのロールバック操作の実装に取り​​組んでいます。私のコンポーネントには、プットを行うためのすべての情報が供給されます（実際には、そのようなプットは数百あります）-テーブル、タイムスタンプ（nullの可能性があります）、ファミリ、修飾子、値。それらをバッファリングしてから、HTable.put（）をバッチで呼び出します。データが事前検証されていないという事実を考慮すると、どのプットも失敗する可能性があります。

put（）が失敗する前にすでに実行されていたことをロールバックする方法を実装しようとしています。

私が見るように、プットをロールバックする3つの方法があります：

1. 新しいアイテムを削除します（そのようなアイテムが以前に存在しなかった場合）
2. 何もしません（以前にまったく同じアイテム（タイムスタンプを含む）が存在した場合）
3. 別のPutを実行します（新しいPutが古い行のデータを変更した場合。注：hbaseでは、データを変更する方法がないことを知っています。「変更」とは、新しいデータが同じ行に書き込まれたことを指します。 / timestamp / family / qualifierであり、古いものは破棄されました-私のセットアップでは、hbaseはアイテムの1つのバージョンのみを保持するように指示されています）。

したがって、問題は、これら3つのプットをどのように区別するかということです。もちろん、特定のアイテムについてhbaseにクエリを実行することは問題ですが、数百のアイテムに対して単純なget / scanを実行することは、私にはあまり効率的ではないようです。

だから私はhbaseでバッチ取得/スキャンを行う方法を探しています。

データを保存するには、データベースまたはファイルシステムの 2 つの標準的な方法があります。これらの間に、データベースには、データの整合性を維持するための少なくとも 2 つの利点があります。

• スキーマ: データの意図した構造を宣言し、データがこの構造を満たすことを保証できます
• 完全な ACID プロパティによるトランザクション性

これらの重要な機能を提供するファイルシステム、またはファイルシステムの上にあるファイルシステムマネージャーはありますか?

たとえば、1 つのディレクトリ内のデータを管理するプログラム、私が提供するスキーマ、およびアトミック性を確保するためにトランザクションを使用してこのディレクトリを更新する CRUD 命令を発行するプログラムを想像します。

たとえば、スキーマは帰納的に定義される場合があります。

その後、 が満たされないため、命令CREATE /container1/image.jpg <contents>は失敗します。これは、/container1が満たされないことpdfcontainerを意味します。/root

私はDelphiXE2をDISQLitev3（基本的にSQLite3の移植版）と一緒に使用しています。同時書き込みがないことを除いて、SQLite3のすべてが大好きです。特に、このプロジェクトではマルチスレッドに大きく依存しています:(

私のプロファイラーは、それについて何かをする必要があることを明らかにしたので、このアプローチを使用することにしました。

1. DBにレコードを挿入する必要があるときはいつでも、INSERTを実行する代わりにwrite、特別なフォーラーでSQLクエリを実行します。

   WriteToFile_Inline(SPECIAL_FOLDER_PATH + '\' + GUID, FileName + '|' + IntToStr(ID) + '|' + Hash + '|' + FloatToStr(ModifDate) + '|' + ...);

2. 毎分timer起動する（メインアプリスレッドに）を追加し、これらのファイルを解析してから、トランザクションを使用してクエリを挿入します。

3. 最後にそれらの一時ファイルを削除します。

その結果、パフォーマンスが500％向上しました。さらに、この手法はACIDSPECIAL_FOLDER_PATHです。停電後はいつでもスキャンして、見つけたINSERTを実行できます。

良い結果にもかかわらず、私は使用された方法にあまり満足していません（控えめに言ってもハックです）、高速ルックアップアクセス、スレッドセーフ、ACIDリストのようなジェネリックがあれば、これははるかにクリーン（そしておそらくより速い？）

だから私の質問は：Delphi XE2についてそのようなことを知っていますか？

PS。上記のコードを読んでいる多くの人がショックを受けていると信じており、この時点で私を侮辱し始めます！私のゲストになってください、しかしあなたがより良い（すなわちより速い）ACIDアプローチを知っているなら、あなたの考えを共有してください！

非トランザクション データベースを使用して、アプリケーション レベルで部分的なトランザクションサポートを実装する手法は何ですか?

そのような技術へのリンクを共有していただけますか?

結果整合性システムと従来の ACID システムを混在させるパターンはありますか?

ACID のようなトランザクションを必要とするメインフレーム上の一部 (少なくとも 2 つ) のレガシー システムにデータを保存したいと考えています。これらのメインフレーム データベース (OldWorld と呼びましょう) は、同じプロセス内の同じトランザクション マネージャーの下で実行されているため、メインフレーム システムの一貫性は問題ありません。

非メインフレーム環境 (これを NewWorld と呼びましょう) で mainframe-tm および ACID 対応のリレーショナル データベースを使用して XA-Transactions を処理できるトランザクション マネージャーがあります。しかし、私は XA-Transaction を使用したくありません。これは、メインフレーム側で実行時間の長いロックで問題が発生することが多く、多くの場合、両方の世界ですべての ACID 機能を必要としないためです。私は常に一貫したメインフレームを望んでいます (OldWorld のすべてのデータは OldWorld 内で一貫しています)。NewWorld System は、メインフレーム側からデータを読み取る際に、不整合データ (新旧の不一致) を処理できます。OldWorld にデータを格納するために使用される操作は簡単で、機能的に失敗しない「追加のみの操作」を節約できます (技術的に失敗する可能性がありますが、これは常に一時的な失敗である必要があります)。