問題タブ [durability]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
3 に答える
290 参照

database - 永続ストレージではなく冗長性に基づいて耐久性を実現するデータベースはありますか?

タイトルがはっきりしていなくて申し訳ありませんが、私はそれをよりよく言うことができませんでした。

現在、ジョブキューとして従来のDB(oracle)を使用しており、これらの「ジョブ」はいくつかのノード(マシン)によって消費されます。そのため、DBサーバーはこれらのノードに見舞われ、このデータベースサーバーのソフトウェアとハ​​ードウェアに多額の費用を支払う必要があります。

さて、先日、私はそれを思いついた。

1)システムにはすでに複数のノードがあります
。2)ノードの障害が原因で「ジョブ」が失われることはありませんが、セカンダリストレージに配置する必要がある理由はありません(メモリに常駐できなかった理由はありません。それらが失われない限り)

これを考えると、これらのジョブをメモリ内に保持して、このジョブの少なくともn個のコピーがクラスター全体に存在することを確認し、それによってDBサーバーを取り除くことはできませんか?

そのような技術は利用できますか?

0 投票する
4 に答える
2353 参照

database - インメモリ データベースはどのように耐久性を提供しますか?

より具体的には、耐久性を提供するためにセカンダリ ストレージ (HDD など) を必要としないデータベースはありますか?

注:これは私の以前の質問のフォローアップです

0 投票する
2 に答える
17667 参照

amazon-s3 - 99.99%の耐久性。どういう意味ですか?

AmazonS3は2つのプランを提供しています。

ストレージ(99.999999999%の耐久性のために設計)

冗長性の低いストレージ(99.99%の耐久性を実現するように設計)

特定の年に99.999999999%の耐久性と99.99%のオブジェクトの可用性を提供するように設計されています。

ここにリンクがあります

では、10000個のファイルがある場合、年間2番目の計画で平均して1つ失うと予想できますか?私はそれを正しく解釈していますか?

編集:マビー私はそれをより明確に言わなければなりません:

特に「設計された」部分をどのように解釈しますか。たとえば、99,9%の可用性を提供する場合、私はそれを保証し、1時間ごとにペナルティを支払うかそのようなものを支払います。しかし、99,9%の可用性を実現するようにシステムを設計する場合、システムのダウンタイムは統計平均で0.1%になる可能性があることを認識して、パーツを選択します。

それは必ずしも私が何かを保証するという意味ではありません。そのシステムが設計されているのはまさに...

0 投票する
1 に答える
543 参照

c++ - ActiveMQ-cpp と stomp の耐久性の問題

ActiveMQ-CPP と stomp プロトコルを使用して永続的なコンシューマーとプロデューサーを作成する際に問題があります。ストンプを使用して HornetQ に接続しようとしていますが、非持続状態でメッセージを送受信できます。メッセージの CMSDeliveryMode とともに配信モードを永続的に設定し、通常のコンシューマーの代わりに DurableConsumer を作成して、プロデューサーを永続的に変更しようとしました。しかし、JBoss JMX-Console を見ると、どちらも非耐久性と見なされていました (メッセージは非耐久性として分類され、コンシューマーも非耐久性としてサブスクライブされます)。

統合テストの StompDurableTest も試してみましたが、20 件のメッセージのうち 10 件しか受信しませんでした (コンシューマーがアクティブなときに送信されたもの)。そのため、テストは失敗しました。

統合テストが機能しなかったため、コードではなく、ActiveMQ-cpp または Stomp の構成に関係していると思います。耐久性を有効にするために何か不足していますか?

前もって感謝します、

サーミ語

0 投票する
3 に答える
785 参照

redis - Redis でデータの耐久性を保証するために提供された方法は?

Redis をチェックしたところ、データベース (すべてのデータを揮発性メモリに格納する) がシステム クラッシュの状況でデータの耐久性を提供する方法に興味があります。

0 投票する
1 に答える
468 参照

database - データベースの耐久性とパフォーマンス

私はデータベースで耐久性がどのように達成されるかをたくさん研究しました、そして私がよく理解すればそれはこのように機能します(単純化された):

クレントの視点:

  1. トランザクションを開始します。
  2. テーブル値に挿入...
  3. トランザクションのコミット

DBエンジンの観点:

  1. トランザクション開始インジケーターをログファイルに書き込みます
  2. クライアントによって行われた変更をログファイルに書き込みます
  3. トランザクションコミットインジケーターをログファイルに書き込みます
  4. ログファイルをHDDにフラッシュします(これにより、データの耐久性が保証されます)
  5. クライアントに「OK」を返します

私が観察したこと:

クライアントアプリケーションはシングルスレッドアプリケーション(1つのデータベース接続)です。私は400トランザクション/秒を実行できますが、ファイルに何かを書き込んでからこのファイルをHDDにfsyncする簡単なテストでは、150同期/秒しか実行されません。クライアントがマルチスレッド/マルチ接続の場合、DBエンジンがトランザクションをグループ化し、いくつかのトランザクションごとに1つのfsyncを実行すると想像しますが、そうではありません。

私の質問は、たとえばMsSQLが、トランザクションのコミットごとにログファイル(fsync、FlushFileBuffersなど)を実際に同期するのか、それとも他の種類の魔法の背後にあるのかということです。

0 投票する
2 に答える
1156 参照

mongodb - 単一のマシンでMongoDBを使用してサーバー障害が発生した場合のデータ損失を回避するにはどうすればよいですか?

私は、mongoDBがすぐにデータをディスクに書き込まないことを読みました。これは定期的に行われます。

これに対処する方法について何か考えはありますか?

0 投票する
3 に答える
447 参照

rdbms - 一般的な ACID RDBMS はコミットごとにディスクに同期しますか?

ACID の 'D' は、ウィキペディアで次のように定義されている「耐久性」を意味します。

ただし、これは、フラッシュされるだけでなく、成功として報告される前に、すべてのトランザクションをディスクに同期する必要があることを意味します。(「flush」=オペレーティング システム レベルに送信、「sync」=物理ディスク プラッタに送信)。これにより、トランザクション レートの高い RDBMS を実装することができなくなります。

一般的な RDBMS は本当にすべてのトランザクションを同期しますか?

0 投票する
1 に答える
212 参照

mongodb - MongoDB 書き込みの懸念は、以前の書き込みに関する保証を行いますか?

MongoDB には構成可能な耐久性があります: 更新操作を行うときに、「書き込み懸念」を指定して、データが (たとえば) ディスクにフラッシュされ、X スレーブに複製された場合にのみ更新が完了したと見なされるようにシステムに指示できます。 .

現在の更新ではなく、それ以前の書き込みについて何らかの保証はありますか? 3 つのドキュメントを更新したい場合、それらすべてにコストのかかる書き込み懸念をタグ付けする必要がありますか?それとも、最後の操作だけで問題を発行するだけで十分ですか?

また、この推論は、接続プール (つまり、3 つの異なる接続で行われる 3 つの更新) とシャーディング (つまり、複数のシャードに影響する 3 つの更新) の使用によって影響を受けますか?

0 投票する
1 に答える
4382 参照

mongodb - MongoDB ジャーナリングの仕組み

これが私の見解であり、それが正しいか間違っているかはわかりません。

ジャーナリング ログは「やり直し」ログです。データファイルの変更を記録します。

たとえば、1 つのレコードのフィールド値を 'a' から 'b' に変更したい場合、mongodb は dbfile を変更する方法 (すべての名前空間、データ、インデックスなどを含む) を見つけてから、mongodb は次のように書き込みます。ジャーナルの修正。

その後、mongodb は dbfile に対するすべての実際の変更を行います。ここで何か問題が発生した場合、mongoDB の再起動時にジャーナルが読み取られます (存在する場合)。次に、dbfile を変更して、データ セットの一貫性を保ちます。

そのため、ジャーナルには、変更するデータは記録されませんが、代わりに dbfile を変更する方法が記録されます。

私は正しいですか?ジャーナルのフォーマットに関する詳しい情報はどこで入手できますか?