Eventually-Consistent Storage Backends

2510 ワード
  • Janusgraphが最終一貫性のあるストレージバックエンドで動作する場合、データの一貫性を保証するために、Janusgraphを使用して最終一貫性の特性をサポートする必要があります.(つまり、いくつかのデータの最終的な一貫性を保証したくない場合は、使用しなくてもよいし、パフォーマンスの観点からJanusGraphは格納されている要素に一貫性を保証しない.)
  • 最終コンシステンシストレージバックエンドをサポート:Apache Cassandra or Apache HBAse
  • 以下では、データ(頂点、属性、エッジ、インデックス)の一貫性を保証する方法についてまとめる.以下のストレージバックエンドは、いずれも最終的な一貫性を有するストレージバックエンドを指す.ストレージバックエンドに最終的な一貫性がない場合、以下の措置でもデータの一貫性を保証することはできない
    • .

    Data Consistency

  • ストレージバックエンドはトランザクション分離を提供しないため、JanusGraphはデータの一貫性を保証するためにロックメカニズム
    • を通過しなければならない.
  • 効率のためにJanusGraphはデフォルトでロックを使用しませんが、ユーザーは一貫性を保証するschema要素に対してロックを使用することを選択できます.
  • データ整合性の設定方法:
    • //element  ：Property、VertexLabel、Index、EdgeLabel
//ConsistencyModifier.LOCK 
JanusGraphManagement.setConsistency(element, ConsistencyModifier.LOCK)

    ケース

  • では、consistentNameプロパティ、byConsistentNameインデックスがロックされ、データの一貫性が保証されます.
    • mgmt = graph.openManagement()
name = mgmt.makePropertyKey('consistentName').dataType(String.class).make()
index = mgmt.buildIndex('byConsistentName', Vertex.class).addKey(name).unique().buildCompositeIndex()
mgmt.setConsistency(name, ConsistencyModifier.LOCK) // name， name SINGLE
mgmt.setConsistency(index, ConsistencyModifier.LOCK) //  name 
mgmt.commit()

    ロックによるデータ整合性の保証原理

  • トランザクションでコンシステンシ制約のある要素を変更すると、トランザクションが終了すると(tx.commit()JanusGraphは、トランザクションが終了した後に検証することに注意)データのコンシステンシを保証するために次のポリシー(楽観ロック)を実行します.
  • 1.トランザクションが新しくオープンし、コンシステンシ制約されたすべての要素に対してロック
    • が取得されます.
  • 2.新しいトランザクションでは、すべての要素の値をデータベースから再読み込みし、トランザクション内の要素のステータスが変更後の要素の前のステータスであることを確認します.そうでない場合は、同時修正の問題が発生し、PermanentLocking exceptionが放出されます.
  • 3.トランザクションステータスをデータベース
    • に保存
  • 4.すべてのロックを解除します.

  • ロックメカニズムには、ローカル競合検出、失敗シーン検出
    • の最適化もあります.

    JanusGraphロック実装クラス

  • JanusGraphはロックプロトコルをインタフェース抽象化し、現在2つの実装が提供されている.
  • 1.A locking implementation based on key-consistent read and write operations that is agnostic to the underlying storage backend as long as it supports key-consistent operations (which includes Cassandra and HBase). This is the default implementation and uses timestamp based lock applications to determine which transaction holds the lock.
  • 2.A Cassandra specific locking implementation based on the Astyanax locking recipe.

  • 注:データの一貫性を厳格に保証する必要があるアプリケーションでは、トランザクション・独立性レベルのストレージ・バックエンドを使用することを推奨します.

    • Data Consistency without Locks


    ---更新待ち
    WebフロントエンドストレージのセッションストレージとlocalStorage
    エーテル坊swarmの構築と使用