タグ付けされた質問 「databases」

いくつかのトランザクションが勝つ（クラッシュの前にコミットされる）、いくつかのトランザクションが失われる（まだコミットされていない）データベースログがあります。授業で、敗者の行動は元に戻す必要があることを学びました。 これを逆方向に行う理由はありますか？誰でも前方への取り消しが間違った結果をもたらすログの簡単な例を与えることができますか？

19 concurrency  databases 

レプリケートされたデータベースなどのレプリケートされたシステムの一貫性基準である、直列化可能性と線形化可能性の違いについて読んでいます。ただし、直列化可能性よりも強力な場合でも、どの場合に線形化可能性が必要になるかはわかりません。 このような強力なプロパティが実際に必要になるシナリオを考えていただけますか？

13 concurrency  databases 

私は、非常に具体的なユースケース向けにインメモリオブジェクトデータベースを設計しています。単一のライターですが、効率的な同時読み取りをサポートする必要があります。読み取りは分離する必要があります。クエリ言語はありません。データベースは次のもののみをサポートします。 属性/属性のセットによってオブジェクト/ -sを取得します（式のサポートがあるかもしれません、例えばx.count < 5） オブジェクトの属性を取得 クエリは、上記の任意の数の操作で構成される必須のスクリプトです。データサイズは<<メモリであるため、ほとんどの属性のすべてのオブジェクトとインデックスは、スワップすることなく快適に収まるはずです。 必要なのは、オブジェクトの属性インデックスのデータ構造です。これは、書き込み時のO（n）であり、書き込みの同時実行性をサポートしませんが、理想的にはO（1）スナップショット（書き込み時のコピー）およびO（logN）アクセスをサポートする必要があります。理想的には、バージョン間で最大限の構造共有を行うことで、読み取りの同時実行性を高めることができます。 私はCTries、コンカレントBST、コンカレントスプレイツリーを見ていましたが、ここで本当に正しい方向を見ているかどうかはわかりません。上記の構造は、私が気にしない挿入の複雑さに多くの注意を払っています。 質問：すぐに使用できるユースケースに適した既知のデータ構造はありますか？ 編集：もう少し考えた後、永続的なBST / Splayツリーが機能するようです。ライターは「マスター」コピーを更新し、クエリは実行の開始時にツリーを取得し、完了後に破棄します。しかし、より良い解決策があるかどうかはまだ興味があります。

12 data-structures  concurrency  databases 

私は、複雑なクエリ持っデータセットを検索するために使用されるが、Sを見つけるためにH 正確な = { S ∈ S | Q （sが） 真であるが }。各クエリは、平均時間を取るトンリニアサーチの全体的な時間があるので、T ⋅ | S | 。私は単純サブクエリQ_Iにダウンクエリを破り、見つけることができますHを約 = { S ∈ S | ∀ のq J（sが）真です}QQQSSSHexact={s∈S∣where Q(s) is True}Hexact={s∈S∣where Q(s) is True}H_\text{exact} = \{s \in S \mid \text{where $Q(s)$ is True}\}tttt⋅|S|t⋅|S|t\cdot |S|Happrox={s∈S∣∀qj(s)is True}Happrox={s∈S∣∀qj(s)is True}H_\text{approx} = \{s\in S \mid \forall q_j(s) …

9 algorithms  optimization  machine-learning  greedy-algorithms  databases 

ソフトウェアのトランザクションメモリのコンテキストで、直列化可能性と線形化可能性を把握しようとしています。ただし、どちらの概念も一般的にトランザクションメモリに適用できると思います。 この時点で、私は両方の主題について次のように理解しています。 シリアライザビリティ 直列化可能性はグローバルプロパティです。これはトランザクションの正確性のプロパティです。与えられたk各トランザクションを実行することのプロセスTkを同時に（すなわち、次々に）順番に実行することができるトランザクションの順序があることを直列化可能性を保証最終結果は同じであるようにトランザクションが同時に実行されるように。したがって、(T1, T2,..,Tk)順次実行できるトランザクションのリストを定義するリストの順列があります。 この特性は私には完全に理にかなっており、私の定義は正しいと思います。この定義は、HerlihyとShavitによる「The Art of Multiprocessor programming」のテキストに基づいています。 線形化可能性 線形化可能性は、並行オブジェクトのローカルプロパティです（たとえば、スレッド間で共有されるクラスのインスタンス）。線形化可能性により、2つのプロセスがそれぞれ、その共有オブジェクトで一連のopメソッド呼び出し（例、queueまたはインスタンス）を実行するときdequeueに、プログラムの順序（プログラマーQueueが記述した順序）を必ずしも保持しない、これらのメソッド呼び出しの順次的な順序付けが保証されます。ダウン）、ただし、各メソッド呼び出しは即座に行われるように見えます（つまり、呼び出しと応答が直接互いに続きます）。一方、各メソッド呼び出しの結果は個別に維持され、結果としてオブジェクトの状態も維持されます。 質問 "On the correctness of TM"GuerraouiとKapalkaによる論文によると、これはTMの文脈における線形化可能性の定義です。 ..共有オブジェクトを説明するために考案された安全プロパティは、TMの修正基準として使用されることがあります。TMの用語では、線形化可能性とは、直感的には、すべてのトランザクションがその存続期間中のある特定の時点で行われたかのように見える必要があることを意味します。 この定義は、私にとって直列化可能性に似ているようです。しかし、この論文では、シリアライザビリティを次のように定義しています。 ..は、データベーストランザクションの最も一般的に必要なプロパティの1つです。大まかに言えば、トランザクションの履歴H（つまり、特定の実行ですべてのトランザクションによって実行されるすべての操作のシーケンス）は、Hでコミットされたすべてのトランザクションが同じ操作を発行し、 Hでコミットされたトランザクションのみの（連続した履歴は、トランザクション間の同時実行性のない履歴です）。 ただし、この定義は、トランザクションからステートメントを並べ替えて、インターリーブできることを意味しているようです。（つまり、トランザクションのすべてのステートメントTがに順番に表示されるわけではないようにステートメントを並べ替えますH）。 私は、上記の個人的な定義が正しいと想定しています。私の実際の質問は、線形化可能性がトランザクションメモリのコンテキストでどのように定義されるかです。トランザクションメモリのセマンティクスが壊れるので、トランザクション内の各メソッド呼び出し（つまり、読み取り/書き込み操作）を個別に説明しても意味がありません。これは明らかに直列化可能性を損なうので、2つの同時トランザクションとそれらのインターリーブについて推論する必要があるのも意味がありません。線形化可能性とは、トランザクション内の個々の操作を並べ替えることができるということですか？線形化可能性が直列化可能性のより強力な形式である場合、操作が単一のトランザクション内で実行される順序は重要ではありません。 要約すると、まず第一に、直列化可能性と線形化可能性に対する私の理解は正しいですか？さまざまな作品で大量の定義を読んだ後、私は混乱しています。次に、一連のトランザクションを線形化できるとはどういう意味ですか？ コメントの中にリンクされた質問も読んだ。しかし、それは私の特定の質問を私に説明しませんでした。 出典 トピックに関するSOの質問（STMについては明確ではありません） /programming/4179587/difference-between-linearizability-and-serializability 2つのhttp://www.bailis.org/blog/linearizability-versus-serializability/に関する非公式の説明 シリアライザビリティに関する元の論文 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.2690&rep=rep1&type=pdf [1]線形化可能性に関する最初の論文 http://www.cs.toronto.edu/~christoff/files/Linearizability-ACorrectnessConditionForConcurrentObjects.pdf

7 distributed-systems  concurrency  databases