本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Amazon Neptune 基本操作準則
<a name="best-practices-general-basic"></a>

下列是使用 Neptune 時，您應該遵循的基本操作準則。
+ 了解 Neptune 資料庫執行個體，以便您可以基於效能和使用案例需求適當調地整其大小。請參閱 [Amazon Neptune 資料庫叢集和執行個體](feature-overview-db-clusters.md)。
+ 監控您的 CPU 和記憶體用量。這可協助您了解何時遷移到有更大 CPU 或記憶體容量的資料庫執行個體類別，以達到您需要的查詢效能。您可以設定 Amazon CloudWatch 在使用模式變更或接近部署容量時通知您。這樣做有助於維持系統效能和可用性。如需詳細資訊，請參閱[監控執行個體](feature-overview-db-clusters.md#feature-overview-monitoring-instances)和[監控 Neptune](monitoring.md)。

  因為 Neptune 擁有自己的記憶體管理員，因此在 CPU 用量相當高時，記憶體用量仍相對較低的情況非常正常。在執行查詢時發生記憶體不足異常，便是您需要增加可釋放記憶體的最佳指示。
+ 啟用自動備份並設定備份時段，在方便的時間進行備份。
+ 測試資料庫執行個體的容錯移轉，以了解您的使用案例執行此程序需時多長。它也有助於確保可存取您資料庫執行個體的應用程式，可以在容錯移轉後，自動連線到新的資料庫執行個體。
+ 如果可能，請在相同區域和 VPC 中執行用戶端與 Neptune 叢集，因為使用 VPC 對等互連進行跨區域連線可能會導致查詢回應時間的延遲。對於個位數毫秒的查詢回應，必須將用戶端和 Neptune 叢集保留在相同區域和 VPC 中。
+ 當您建立僅供讀取複本執行個體時，它應該至少與主要寫入器執行個體一樣大。這有助於在檢查時保持複寫延遲，並避免複本重新啟動。請參閱 [避免叢集中的不同執行個體類別](#best-practices-loader-heterogeneous-instances)。
+ 在升級到新的主要引擎版本之前，請務必在其上測試您的應用程式，然後再升級。您可以透過複製資料庫叢集來執行此動作，以便複製叢集可執行新的引擎版本，然後在該複製上測試您的應用程式。
+ 為了便於容錯移轉，所有執行個體最好都應該是相同的大小。

**Topics**
+ [Amazon Neptune 安全最佳實務](best-practices-general-security.md)
+ [避免叢集中的不同執行個體類別](#best-practices-loader-heterogeneous-instances)
+ [避免在大量載入期間重複重新啟動](#best-practices-loader-repeated-restarts)
+ [如果您有大量述詞，請啟用 OSGP 索引](#best-practices-general-predicates)
+ [盡可能避免長時間執行的交易](#best-practices-general-long-running-transactions)
+ [使用 Neptune 指標的最佳實務](best-practices-general-metrics.md)
+ [調校 Neptune 查詢的最佳實務](#best-practices-general-tuning)
+ [在各個僅供讀取複本之間平衡負載](#best-practices-general-loadbalance)
+ [使用臨時的較大執行個體，載入速度更快](#best-practices-loader-tempinstance)
+ [容錯移轉至僅供讀取複本來調整您的寫入器執行個體大小](#best-practices-resize-instance)
+ [在資料預先擷取任務中斷錯誤之後重試上傳](#load-api-reference-status-interrupted)

## 避免叢集中的不同執行個體類別
<a name="best-practices-loader-heterogeneous-instances"></a>

當您的資料庫叢集包含不同類別的執行個體時，可能會在一段時間後發生問題。最常見的問題是，由於複寫延遲，小型讀取器執行個體可能會進入重複重新啟動的週期。如果讀取器節點具有的資料庫執行個體類別組態比寫入器資料庫執行個體的組態還弱，則變更量可能太大，以致讀取器無法跟上。

**重要**  
若要避免複寫延遲所導致的重複重新啟動，請設定資料庫叢集，讓所有執行個體都具有相同的執行個體類別 (大小)。

您可以使用 Amazon CloudWatch 中的 `ClusterReplicaLag` 指標，查看資料庫叢集中寫入器執行個體 (主要執行個體) 與讀取器之間的延遲。`VolumeWriteIOPs` 指標也可讓您偵測叢集中可能會造成複寫延遲的大量寫入活動。

## 避免在大量載入期間重複重新啟動
<a name="best-practices-loader-repeated-restarts"></a>

如果您由於大量載入期間的複寫延遲而遭遇重複僅供讀取複本重新啟動的週期，則您的複本可能無法跟上資料庫叢集中的寫入器。

將讀取器擴展為大於寫入器，或在大量載入期間暫時將其移除，然後在完成後重新建立這些讀取器。

## 如果您有大量述詞，請啟用 OSGP 索引
<a name="best-practices-general-predicates"></a>

如果您的資料模型包含大量不同的述詞 (在大多數情況下，超過一千個)，您可能會遭遇效能降低，而操作成本提高。

若是這種情況，您可以啟用 [OSGP 索引](feature-overview-storage-indexing.md#feature-overview-storage-indexing-osgp)來改善效能。請參閱 [OSGP 索引](features-lab-mode.md#features-lab-mode-features-osgp-index)。

## 盡可能避免長時間執行的交易
<a name="best-practices-general-long-running-transactions"></a>

長時間執行的交易 (唯讀或讀寫) 可能會造成下列種類的非預期問題：

在讀取器執行個體或具有並行寫入的寫入器執行個體上，長時間執行的交易可能會導致不同版本的資料大量累積。這可能會對讀取查詢引入更高的延遲，從而篩選掉其大部分的結果。

在某些情況下，數小時的累積版本可能會導致新的寫入遭到限流。

如果執行個體重新啟動，具有許多寫入的長時間執行的讀寫交易也可能會造成問題。如果執行個體從維護事件或當機重新啟動，則所有未遞交的寫入都會加以復原。這類復原操作通常會在背景執行，而且不會封鎖執行個體回復，但是任何與要回復之操作衝突的新寫入都會失敗。

例如，如果在上次執行時連線中斷之後重試相同的查詢，則在重新啟動執行個體時可能會失敗。

復原操作所需的時間與涉及的變更大小成正比。

## 調校 Neptune 查詢的最佳實務
<a name="best-practices-general-tuning"></a>

 其中一種改善 Neptune 效能的最佳方法，便是調校您最常使用及最資源密集的查詢，降低執行它們的成本。

如需如何調校 Gremlin 查詢的資訊，請參閱 [Gremlin 查詢提示](gremlin-query-hints.md) 和 [調校 Gremlin 查詢](gremlin-traversal-tuning.md)。如需如何調校 SPARQL 查詢的資訊，請參閱 [SPARQL 查詢提示](sparql-query-hints.md)。

## 在各個僅供讀取複本之間平衡負載
<a name="best-practices-general-loadbalance"></a>

讀取器端點循環配置資源路由的運作方式是改變 DNS 項目指向的主機。用戶端必須建立新連線並解析 DNS 記錄，以取得與僅供讀取新複本的連線，因為 WebSocket 連線通常會長時間保持活動狀態。

若要針對連續請求取得不同的僅供讀取複本，請確保用戶端在每次連線時都能解析 DNS 項目。這可能需要關閉連線並重新連接到讀取者端點。

您也可以明確連接到執行個體端點，在各個僅供讀取複本之間對請求進行負載平衡。

## 使用臨時的較大執行個體，載入速度更快
<a name="best-practices-loader-tempinstance"></a>

使用較大的執行個體可提高您的載入效能。如果您不是使用大型的執行個體類型，但您想要更高的載入速度，可以使用較大的執行個體來進行載入，然後將其刪除。

**注意**  
下列程序是用於新的叢集。如果您有現有的叢集，您可以新增較大的執行個體，然後將其提升至主要資料庫執行個體。

**使用較大的執行個體大小將資料載入**

1.  建立具有單一 `r5.12xlarge` 執行個體的叢集。這個執行個體是主要資料庫執行個體。

1. 建立大小 (`r5.12xlarge`) 相同的一個或多個僅供讀取複本。

   您可以建立更小的僅供讀取複本，但如果其大小不足以跟上主執行個體的寫入，則可能必須經常重新啟動。產生的停機時間會大幅降低效能。

1. 在大量載入器命令中，包括 `“parallelism” : “OVERSUBSCRIBE”` 以告訴 Neptune 使用所有可用的 CPU 資源進行載入 (請參閱 [Neptune 載入器請求參數](load-api-reference-load.md#load-api-reference-load-parameters))。然後，載入操作將以 I/O 允許的一樣快速度進行，這通常需要 60-70％ 的 CPU 資源。

1. 使用 Neptune 載入器載入資料。載入工作會在主要資料庫執行個體上執行。

1. 在完成資料載入之後，請務必將叢集中的所有執行個體縮減至相同的執行個體類型，以避免額外的費用和重複的重新啟動問題 (請參閱 [避免不同的執行個體大小](#best-practices-loader-heterogeneous-instances))。

## 容錯移轉至僅供讀取複本來調整您的寫入器執行個體大小
<a name="best-practices-resize-instance"></a>

調整資料庫叢集中執行個體大小 (包括寫入器執行個體) 的最佳方法，就是建立或修改僅供讀取複本執行個體，以便其具有您所需的大小，然後刻意容錯移轉至該僅供讀取複本。您的應用程式看到的停機時間只是變更寫入器 IP 地址所需的時間，應該是 3 到 5 秒左右。

您用來刻意將目前寫入器執行個體容錯移轉至僅供讀取複本執行個體的 Neptune 管理 API 為 [FailoverDBCluster](api-clusters.md#FailoverDBCluster)。如果您是使用 Gremlin Java 用戶端，則可能需要在容錯移轉之後建立新的用戶端物件，以挑選新的 IP 地址，如[這裡](best-practices-gremlin-java-new-connection.md)所述。

確定將所有執行個體變更為相同的大小，讓您避免重複重新啟動的週期，如下所述。

## 在資料預先擷取任務中斷錯誤之後重試上傳
<a name="load-api-reference-status-interrupted"></a>

當您使用大量載入器將資料載入 Neptune 時，結果有時會出現 `LOAD_FAILED` 狀態，而回應中會報告 `PARSING_ERROR` 和 `Data prefetch task interrupted` 訊息以要求詳細資訊，如下所示：

```
"errorLogs" : [
  {
    "errorCode" : "PARSING_ERROR",
    "errorMessage" : "Data prefetch task interrupted: Data prefetch task for 11467 failed",
    "fileName" : "s3://amzn-s3-demo-bucket/some-source-file",
    "recordNum" : 0
  }
]
```

當此錯誤發生時，只要重試一次大量上傳請求。

當出現通常原因不在於您的請求或資料的暫時中斷時，就會出現這個錯誤，而且通常再次執行大量上傳請求就能加以解決。

如果您使用的是預設設定，即 `"mode":"AUTO"` 和 `"failOnError":"TRUE"`，這時載入器會略過其已成功載入的檔案，並恢復其在中斷發生時尚未載入的檔案載入。