DSE Graphの構成

dse.yaml Graphオプション

DSE Graphは、dse.yamlのDSE Graph用のクラスター全体のオプションをgraph:キーとgremlin-server:キーの下に格納します。変更する一般的なオプションのほとんどは、以下のセクションで説明されています。特に注意することとして、dse.yamlファイルのGremlin Serverオプションでグラフ・サンドボックスが構成されます。この機能はデフォルトで有効になっており、JVM内での悪意のある攻撃から保護します。

dse.yaml 設定を変更するには、クラスター内の各ノードでファイルを変更し、各ノードを再起動します。dse.yamlでの設定は、対象としているノードのシステム・レベルです。dse.yamlファイルは、OpsCenterを使用して変更することもできます。もう1つの方法は、スキーマAPI構成で説明されている、グラフごとにオプションを設定することです。

remote.yaml Gremlin Consoleオプション

remote.yamlファイルは、GremlinサーバーへのDSE Graph Gremlin Console接続の主要な構成ファイルです。ほとんどのオプションは、自明です。特に、DSE Graphで分析OLAPクエリーを使用している場合は、このファイルに変更が必要なことに注意してください。

レプリケーション係数

グラフのレプリケーション係数（RF）とシステム・レプリケーション係数（システムRF）は、DSEでの読み取りと書き込みのパフォーマンスに影響を与える可能性があります。DSEデータベースと同様に、これらの要因によって、分散グラフ・データベースが複数のノードに格納するデータのレプリカの数が制御されます。

Consistency_mode、datacenter_id、read_consistency、およびwrite_consistency

DSE Graphの整合性レベルは、グラフ操作とDSEデータベース操作の両方で制御されます。consistency_mode設定はグラフ操作を構成し、read_consistencyとwrite_consistency設定はDSEデータベースの読み取り操作と書き込み操作のGraphトランザクション内での整合性レベルを構成します。

Gremlinクエリーは、探索を介してグラフ・データを挿入し、読み取り、および更新するCQLコマンドを実行するため、DSEデータベースの整合性レベル設定がグラフ操作の実行に影響を与える可能性があります。ユーザー定義の頂点IDの読み取りまたは書き込みの整合性レベルは、一般にグラフごとに、read_consistency（デフォルト：ONE）およびwrite_consistency（デフォルト：LOCAL_QUORUM）設定を使用して設定できます。グラフ探索で検索インデックスを使用する場合、read_consistencyは複数データ・センター・クラスターでLOCAL_ONEに設定されます。このオプションはスキーマAPIを使用して設定されます。

schema_mode

データにアクセスするには、次の2つの構成項目が重要です。schema_modeとallow_scanです。

Graphサンドボックスおよびホワイトリスト/ブラックリスト登録されたコード

gremlin_server:
     port: 8182
     threadPoolWorker: 2
     gremlinPool: 0
        scriptEngines:
            gremlin-groovy:
                config:
 #                  sandbox_enabled: false
                       sandbox_rules:
                            whitelist_packages:
                            - org.apache.tinkerpop.gremlin.process
                            - java.nio
                        whitelist_types:
                            - java.lang.String
                            - java.lang.Boolean
                            - com.datastax.bdp.graph.spark.SparkSnapshotBuilderImpl
                            - com.datastax.dse.graph.api.predicates.Search
                        whitelist_supers:
                            - groovy.lang.Script
                            - java.lang.Number
                            - java.util.Map
                            - org.apache.tinkerpop.gremlin.process.computer.GraphComputer
                        blacklist_packages:
                            - java.io
                            - org.apache.tinkerpop.gremlin.structure.io
                            - org.apache.tinkerpop.gremlin.groovy.jsr223
                            - java.nio.channels

フルーエントAPIは、許可できる操作を制限して実行のセキュリティを高めますが、サンドボックスを使用してlambda関数を有効にします。

認証、承認、および暗号化

DSEは、ユーザーによるアクセスの認証または承認、格納されたデータの暗号化によるセキュリティ保護、またはグラフ頂点ラベルまたはグラフに基づく（該当する場合）、SSLを使用したGremlin Consoleのセキュリティ保護ができます。

DSE Graphのセキュリティは、DSEのセキュリティにより管理されます。DSE Graphでは、Gremlin Consoleを安全に使用するために構成を変更する、dse.yamlファイルのgremlin-server:キーでGraphサンドボックスを変更するなど、独自の構成をいくつか行う必要があります。

DSE Graphは、DSE監査を使用した監査もサポートしています。「データベース監査の設定」を参照してください。

lambdaの制限

allow_scan

データにアクセスするには、次の2つの構成項目が重要です。schema_modeとallow_scanです。

cache

タイムアウト

タイムアウト設定は、クライアント側とサーバー側の両方で、さまざまな方法でDSE Graphの障害の原因になる可能性があります。クライアント側では、Gremlin Consoleからのコマンドが、Gremlinサーバーに到達する前にタイムアウトになる可能性があります。Gremlin Consoleでコマンド:remote config timeout noneを発行すると、デフォルトの最大タイムアウト3分を時間制限なしにオーバーライドできます。Gremlin Consoleに入力された要求はGremlinサーバーに送信され、Consoleは、要求を中止してユーザーに制御を返す前に応答を待機します。タイムアウトがnoneに変更されると、要求は決してタイムアウトしません。これは、複雑な探索や大規模なデータセットの場合に、サーバーに要求を送信して戻るまでにかかる時間がデフォルトのタイムアウトよりも長い場合に便利です。

サーバー側では、クラスター全体のタイムアウト設定、realtime_evaluation_timeout_in_seconds（デフォルト：30秒）またはanalytic_evaluation_timeout_in_minutes （デフォルト：1008分）は、それぞれ、OLTP探索またはOLAP探索が評価されるのを待機する最大時間になります。これらの設定は、dse.yamlファイルに設定されています。探索評価のタイムアウト動作を特定のグラフに対してオーバーライドする必要がある場合、evaluation_timeoutをグラフごとに設定して、OLTPまたはOLAP探索評価タイムアウトのいずれかをオーバーライドできます。複雑な探索が実行中にタイムアウトする場合は、適切なタイムアウト設定に変更するとエラーが修正されます。

dse.yamlファイルで調整できる追加のサーバー側設定は、schema_agreement_timeout_in_ms（30秒）で、スキーマを変更する際にスキーマ・バージョンがクラスター全体で合意するのを待機する最大時間です。特にインデックスが定義されている大きなスキーマがクラスターに送信される場合、データがグラフに送信される前にこの設定で調整が必要になる場合があります。

最後に、dse.yamlファイルで、system_evaluation_timeout_in_seconds（デフォルト：180秒）が、グラフ・システムが評価を要求するのを待つ最大時間として定義されます。グラフの作成または削除は、この設定の影響を受けるシステム要求であり、他のタイムアウト・オプションとは相互作用しません。

external_vertex_verify and internal_vertex_verify

これらの設定により、正確性の検証と読み込みパフォーマンスの向上との間のトレードオフが可能になります。たとえば、ユーザー定義の頂点ID external_vertex_verify（デフォルト：true）または自動生成頂点ID internal_vertex_verify（デフォルト：false）を持つ大きなデータセットを読み込む場合、これらのオプションは重要です。データがまだない新しいクリーンなグラフがあり、データに含まれる頂点IDがグラフに既に存在するかどうかを確認しない場合は、該当するオプションをfalseに設定し、DSE Graph Loaderによるデータの読み込みを高速化します。もちろん、データが既にあり、新しく読み込んだデータセットで上書きしない場合は、該当するオプションにtrue値を使用する必要があります。

tx_autostart and max_query_queue

大きなGraphSONファイルを読み込む場合、tx_autostartを使用すると、読み込み中に10,000要素に到達すると、クエリーで自動的に新しいトランザクションを開始できます。大きなファイルを読み込むときに制限を回避するもう1つの有効な方法は、ノード・システム・レベルでの制限を削除するようにmax_query_queueを dse.yaml ファイルで構成することです。