「內(nèi)存數(shù)據(jù)庫」調(diào)整插入和數(shù)據(jù)負載的HANA性能
插入和數(shù)據(jù)加載將寫入新數(shù)據(jù)，而SELECT、UPDATE或DELETE等其他操作必須對現(xiàn)有數(shù)據(jù)進行操作。
因此，典型的性能因素是部分不同的。如果你想提高插入和數(shù)據(jù)加載的性能，你可以考慮以下方面:
Area Details
Lock waits
參見1999998，如果需要，優(yōu)化鎖等待情況。插入必須等待鎖的典型情況是:
- 重要的保存點階段
- 同一主鍵的并發(fā)插入
- SAP HANA內(nèi)部鎖
- 同一表上的DDL操作已激活
Columns
在插入期間，必須分別維護每一列，因此插入時間在很大程度上取決于表列的數(shù)量。
Indexes
每個現(xiàn)有索引都會減慢插入操作的速度。檢查是否可以在大量插入和數(shù)據(jù)加載期間減少索引的數(shù)量。SAP BW提供了在數(shù)據(jù)加載期間自動刪除和重新創(chuàng)建索引的可能性。主索引通常不能被刪除。
Bulk load
如果加載了大量記錄，就不應該對每條記錄執(zhí)行插入。相反，您應該盡可能利用批量加載選項(即使用單個插入操作插入多個記錄)。
Parallelism
如果加載了大量記錄，則應該考慮客戶端上的并行性，以便使用到SAP HANA的多個連接來加載數(shù)據(jù)。
Commits
確保在執(zhí)行大規(guī)模插入時定期執(zhí)行COMMIT (after each bulk of a bulk load)。
Delta merge
大的增量存儲會降低負載性能，所以要確保定期執(zhí)行增量合并。
避免重復合并小的增量存儲或使用大量未提交的數(shù)據(jù)，以避免不必要的開銷。
Table vs. record lock
如果只可能進行一次非并行插入，并且不需要對底層表進行并發(fā)更改，那么使用全局表鎖而不是大量的單獨記錄鎖可能會很有用。表鎖可以通過以下方式設置:
LOCK TABLE "
之后，SAP HANA不再需要維護單獨的記錄鎖。這種方法也適用于INSERT…選擇可以在內(nèi)部并行化的操作。
Savepoints
需要保存點將修改后的數(shù)據(jù)寫入磁盤。通常的主要意圖是盡可能縮短阻塞保存點階段，同時接受較長的保存點持續(xù)時間。在大量導入期間，相反的情況可能更好:保存點更短，阻塞階段增加的風險更大。較短的保存點可以減少寫入磁盤的數(shù)據(jù)量，還可以減少需要保留的日志量，從而降低文件系統(tǒng)溢出的風險。
在大量更改期間，可以考慮以下參數(shù)調(diào)整來減少總體保存點持續(xù)時間:
- lower values for global.ini -> [persistence] -> savepoint_max_pre_critical_flush_duration (e.g. 300 instead of 900)
- higher values for global.ini -> [persistence] -> savepoint_pre_critical_flush_retry_threshold (e.g. 10000 instead of 3000)
Bugs
以下SAP HANA bug可能會對插入性能產(chǎn)生負面影響:
Impacted RevisionsDetails 1.00.120 - 1.00.122.11
2.00.000 - 2.00.012.00如果大量的空間數(shù)據(jù)是在沒有提交的情況下逐行插入的，那么由于SAP HANA bug和調(diào)用堆棧模塊AttributeEngine::spatialae::DeltaComponents::reserveDocid所花費的大量時間，性能可能會很差。作為“GeometryDeltaAttribute鎖”上的次要影響爭用是可能的。
典型的吞吐量
- 問題情況，如長臨界保存點階段或其他鎖
- < 500 records / second
- 正常的、連續(xù)的單行插入
- 1,000 - 10,000 records / second
- 高度并行的批量加載
- 1,000,000 records / second
原文：https://www.stechies.com/performance-inserts-data-loads-tuned/
本文：https://pub.intelligentx.net/tuning-hana-performance-inserts-and-data-loads
