Hologres:Stress testing data writes, updates, and point queries

Mécanismes d'écriture et de mise à jour

L'outil prend en charge deux modes d'écriture :

• Mode Fixed Copy -- Utilise l'instruction PostgreSQL COPY, optimisée grâce aux plans fixes pour accélérer l'exécution des instructions SQL.

• Mode Insert -- Utilise des instructions INSERT standard, également optimisées via les plans fixes.

Dans les deux modes, l'outil ajoute automatiquement deux colonnes à la table :

Pour chaque colonne TEXT configurée, l'outil écrit une chaîne de la longueur spécifiée, à laquelle est ajoutée la valeur de id. Le test s'arrête lorsque le nombre cible de lignes ou la durée définie est atteint.

Lors des mises à jour, le même schéma incrémental pour id est utilisé. Pour les mises à jour partielles, seul un sous-ensemble des colonnes TEXT est réécrit.

Mécanismes des requêtes ponctuelles

L'outil prend en charge deux modes de requête :

• Mode asynchrone -- L'API de requête ponctuelle est non bloquante. Plusieurs requêtes sont regroupées dans une seule instruction SQL, ce qui maximise le débit. Ce mode convient particulièrement aux scénarios à haut débit, tels que les jointures de tables en temps réel basées sur Flink.

• Mode synchrone -- L'API de requête ponctuelle est bloquante. Chaque requête correspond à une instruction SQL distincte et doit se terminer avant que la suivante ne démarre. Ce mode est idéal pour les scénarios sensibles à la latence.

Pendant le test, l'outil sélectionne aléatoirement une clé primaire dans la plage configurée et exécute une requête ponctuelle. Le test s'arrête lorsque la durée cible est atteinte.

À propos de l'outil de test

holo-e2e-performance-tool est un outil open source développé par l'équipe Hologres. Il intègre la création de table, la génération de données de test et la mesure des performances dans un seul fichier JAR, éliminant ainsi le besoin de préparer séparément les données de test. La clé primaire des données générées est une série d'entiers consécutifs, ce qui garantit un taux de hit complet lors des tests de mise à jour et de requêtes ponctuelles.

Étape 1 : Créer le fichier de configuration

Sur l'instance ECS, créez un fichier nommé test_insert.conf avec le contenu suivant :

# Connection configuration
holoClient.jdbcUrl=jdbc:hologres://<ENDPOINT>:<PORT>/<DBNAME>
holoClient.username=<AccessKey_ID>
holoClient.password=<AccessKey_Secret>
holoClient.writeThreadSize=100

# Write configuration
put.threadSize=8
put.testByTime=false
put.rowNumber=200000000
put.testTime=600000

# Table configuration
put.tableName=kv_test
put.columnCount=20
put.columnSize=20
put.orientation=row

# Other configurations
put.createTableBeforeRun=true
put.deleteTableAfterDone=false
put.vacuumTableBeforeRun=false

Cet exemple crée une table orientée ligne. Pour tester une table orientée colonne ou hybride (ligne-colonne), modifiez la valeur du paramètre orientation en column ou row,column.

Remplacez les espaces réservés par vos valeurs réelles :

Paramètres de configuration

Étape 2 : Exécuter le test

# Fixed Copy mode
java -jar holo-e2e-performance-tool-1.0.0.jar test_insert.conf FIXED_COPY

# Or, Insert mode
java -jar holo-e2e-performance-tool-1.0.0.jar test_insert.conf INSERT

Étape 3 : Consulter les résultats

cat result.csv

Consultez la section Champs de résultat pour connaître le format de sortie.

Mise à jour globale

1. Créez un fichier nommé test_update.conf. Utilisez la même configuration que pour le test d'écriture, mais remplacez la valeur de createTableBeforeRun par false :

   La seule modification par rapport à la configuration du test d'écriture consiste à définir createTableBeforeRun=false. Cela permet de conserver la table et les données existantes.

      # Connection configuration
      holoClient.jdbcUrl=jdbc:hologres://<ENDPOINT>:<PORT>/<DBNAME>
      holoClient.username=<AccessKey_ID>
      holoClient.password=<AccessKey_Secret>
      holoClient.writeThreadSize=100
   
      # Write configuration
      put.threadSize=8
      put.testByTime=false
      put.rowNumber=200000000
      put.testTime=600000
   
      # Table configuration
      put.tableName=kv_test
      put.columnCount=20
      put.columnSize=20
      put.orientation=row
   
      # Other configurations
      put.createTableBeforeRun=false
      put.deleteTableAfterDone=false
      put.vacuumTableBeforeRun=false

2. Exécutez le test :

      java -jar holo-e2e-performance-tool-1.0.0.jar test_update.conf FIXED_COPY

3. Consultez les résultats :

      cat result.csv

Mise à jour partielle

Une mise à jour partielle écrit dans un sous-ensemble des colonnes TEXT. Le paramètre writeColumnCount contrôle le nombre de colonnes mises à jour.

1. Créez un fichier nommé test_update_part.conf. Ajoutez le paramètre writeColumnCount à la section de configuration de la table :

   Avec writeColumnCount=10, 10 des 20 colonnes TEXT sont mises à jour (soit 50 %). Ajustez ce ratio en fonction de votre charge de travail.

      # Connection configuration
      holoClient.jdbcUrl=jdbc:hologres://<ENDPOINT>:<PORT>/<DBNAME>
      holoClient.username=<AccessKey_ID>
      holoClient.password=<AccessKey_Secret>
      holoClient.writeThreadSize=100
   
      # Write configuration
      put.threadSize=8
      put.testByTime=false
      put.rowNumber=200000000
      put.testTime=600000
   
      # Table configuration
      put.tableName=kv_test
      put.columnCount=20
      put.columnSize=20
      put.writeColumnCount=10
      put.orientation=row
   
      # Other configurations
      put.createTableBeforeRun=false
      put.deleteTableAfterDone=false
      put.vacuumTableBeforeRun=false

2. Exécutez le test :

      java -jar holo-e2e-performance-tool-1.0.0.jar test_update_part.conf FIXED_COPY

3. Consultez les résultats :

      cat result.csv

Étape 1 : Créer le fichier de configuration

Créez un fichier nommé test_get.conf :

# Connection configuration
holoClient.jdbcUrl=jdbc:hologres://<ENDPOINT>:<PORT>/<DBNAME>
holoClient.username=<AccessKey_ID>
holoClient.password=<AccessKey_Secret>
holoClient.readThreadSize=32

# Test configuration
get.threadSize=8
get.testTime=300000
get.tableName=kv_test
get.async=true
get.vacuumTableBeforeRun=true
get.keyRangeParams=L1-200000000

# Table initialization configuration (used only in PREPARE_GET_DATA mode)
prepareGetData.rowNumber=200000000
prepareGetData.orientation=row
put.columnCount=20
put.columnSize=20

Cet exemple configure des requêtes ponctuelles asynchrones sur une table orientée ligne. Pour tester des requêtes synchrones, définissez get.async=false et ajustez les paramètres threadSize et readThreadSize en conséquence (consultez le tableau des paramètres ci-dessous).

Paramètres des requêtes ponctuelles

Étape 2 : Exécuter le test

Si la table contient déjà des données issues des tests d'écriture ou de mise à jour, ignorez la préparation des données et exécutez directement la requête ponctuelle :

# (Optional) Prepare data -- only if the table has no data
java -jar holo-e2e-performance-tool-1.0.0.jar test_get.conf PREPARE_GET_DATA

# Run the point query test
java -jar holo-e2e-performance-tool-1.0.0.jar test_get.conf GET

Pour utiliser vos propres données métier au lieu des données générées, la table doit disposer d'une clé primaire à colonne unique de type INT ou BIGINT avec des valeurs consécutives.

Étape 3 : Consulter les résultats

cat result.csv

Choisir un format de stockage

Avant d'examiner les chiffres, utilisez ce guide pour sélectionner le format de stockage adapté à votre charge de travail :

20 colonnes

50 colonnes

100 colonnes

Points clés à retenir

• Les tables orientées ligne offrent le débit d'écriture le plus élevé -- environ 3 fois plus rapide que les tables orientées colonne pour un même nombre de colonnes.

• Les mises à jour partielles surpassent les mises à jour globales sur les tables orientées ligne, car moins de colonnes sont réécrites. Sur les tables orientées colonne et hybrides (ligne-colonne), les mises à jour globales peuvent égaler ou dépasser le débit des mises à jour partielles.

• La latence des requêtes ponctuelles est similaire entre les tables orientées ligne et hybrides (ligne-colonne), généralement inférieure à 10 ms pour les tables comportant 20 colonnes.

• Les requêtes ponctuelles asynchrones atteignent un QPS plus élevé que les requêtes synchrones, mais avec une latence légèrement supérieure.

• Le débit d'écriture et de mise à jour diminue à mesure que le nombre de colonnes augmente -- une table orientée ligne comportant 100 colonnes atteint environ 28 % du QPS d'écriture d'une table à 20 colonnes. Le débit des requêtes ponctuelles est moins affecté, conservant 50 à 60 % du QPS à 100 colonnes par rapport à 20 colonnes.

Le client ECS devient un goulot d'étranglement

Symptôme : Le QPS plafonne malgré une faible utilisation du processeur sur l'instance Hologres.

Cause : L'instance ECS exécutant l'outil de test a atteint sa limite d'utilisation du processeur ou de bande passante réseau.

Solution : Surveillez les métriques de processeur et de réseau de l'instance ECS pendant le test. Si l'une des deux ressources est saturée, passez à un type d'instance ECS plus puissant ou réduisez la valeur de threadSize.

QPS inférieur aux attentes

Symptôme : Le QPS est nettement inférieur aux résultats de référence indiqués ci-dessus.

Causes possibles et solutions :

1. Concurrence insuffisante -- Si l'utilisation du processeur Hologres est faible, augmentez la valeur de threadSize (pour les écritures et mises à jour) ou de readThreadSize (pour les requêtes ponctuelles).

2. L'instance a fait l'objet d'un upgrade ou d'un downgrade -- Les caractéristiques de performance diffèrent entre les instances nouvelles et celles redimensionnées. Créez une nouvelle instance pour les tests de référence.

3. Latence réseau -- Vérifiez que l'instance ECS et l'instance Hologres se trouvent dans le même VPC et la même zone.

4. Biais de données -- Si vous utilisez des données personnalisées, une distribution inégale des valeurs de clé de distribution peut concentrer la charge sur un sous-ensemble de shards.

Erreurs de connexion

Symptôme : L'outil de test échoue avec des exceptions liées à la connexion.

Solution : Vérifiez la chaîne de connexion JDBC, l'ID AccessKey et le secret AccessKey. Confirmez que l'instance Hologres autorise les connexions depuis le VPC de l'instance ECS.