Envoyez des documents vers OpenSearch via l'API ou le SDK. Le traitement des envois est asynchrone : une réponse OK confirme la réception des données par le système, mais pas leur traitement réussi. Surveillez la console OpenSearch pour détecter les erreurs de traitement après chaque envoi.
Vérifiez toujours les valeurs de retour après un envoi. Si le code d'erreur 3007 s'affiche, réessayez la requête. Ignorer les codes d'erreur peut entraîner une perte de données.
Commandes d'envoi
Trois commandes contrôlent l'écriture des documents dans l'index. La différence principale entre add et update tient à la couverture des champs : add écrase tous les champs, tandis que update ne modifie que ceux que vous spécifiez.
| Commande | Fonction | Champs absents de la requête | Le document existe-t-il déjà ? |
|---|---|---|---|
add |
Ajoute ou remplace entièrement un document | Remplacés par des valeurs vides | Supprimé, puis ajouté à nouveau |
update |
Met à jour des champs spécifiques d'un document | Conservent leurs valeurs d'origine | Supprimé, puis ajouté à nouveau |
delete |
Supprime un document par son ID de clé primaire | Sans objet | L'opération réussit même si le document n'existe pas |
Quand utiliser chaque commande
Utilisez
addpour remplacer complètement un document ou en ajouter un nouveau.Utilisez
updatepour modifier certains champs sans écraser les autres.Utilisez
deletepour supprimer un document via son ID de clé primaire.
Fonctionnement de l'envoi de données
OpenSearch traite les requêtes d'envoi de manière asynchrone :
Soumettez une requête d'envoi via l'API ou le SDK avec une méthode HTTP POST.
Le système renvoie
OKpour confirmer la réception.Le système traite les données en arrière-plan.
En cas d'échec du traitement, l'erreur apparaît dans la console OpenSearch.
Consultez régulièrement la console pour détecter rapidement les erreurs de traitement.
Limites et bonnes pratiques
Limite de taille des requêtes HTTP POST
La charge utile maximale de chaque requête HTTP POST est de 2 Mo. Si la charge utile dépasse 2 Mo, le serveur rejette la requête et renvoie une erreur.
Consultez la section Limites pour la liste complète des quotas.
Regroupez vos envois par lots
L'envoi de documents un par un génère de nombreux appels réseau individuels et augmente le risque d'atteindre les limites de débit. Regroupez plusieurs documents dans une seule requête pour améliorer le débit et éviter les erreurs de limitation.
Maintenez chaque lot sous 2 Mo afin de respecter la limite de taille par requête.
Appliquez également l'encodage URL à l'URL et au corps de chaque requête HTTP POST. À défaut, des erreurs de résolution et de signature peuvent survenir.
Données incrémentielles et clés en double
Lors de l'envoi de données incrémentielles depuis une source de données ou via l'API, les documents ayant des valeurs de clé primaire en double sont écrasés.
Gestion des erreurs
| Message d'erreur | Cause | Action |
|---|---|---|
connection timed out |
Interruption du réseau | Réessayez jusqu'à succès |
1000 :system error |
Erreur côté système | Réessayez jusqu'à succès |
push rate exceeds app quota |
Fréquence d'envoi élevée ou charge utile > 2 Mo par seconde | Réessayez jusqu'à succès ; réduisez la taille de la charge utile si l'erreur persiste |
request too frequently |
Dépassement du nombre total d'envois autorisé | Regroupez les documents et envoyez-les via moins de requêtes, mais plus volumineuses |
Synchronisation avec ApsaraDB RDS for MySQL
Le débit et la taille des données synchronisées depuis ApsaraDB RDS for MySQL sont limités. Consultez la section Limites.
Un journal binaire est généré à chaque mise à jour de toutes les tables de la base de données. Si le volume du journal binaire dépasse la limite, les données s'accumulent en file d'attente et des retards de synchronisation se produisent. Pour éviter cela :
Déplacez les tables fréquemment mises à jour dans des bases de données distinctes.
Activez la synchronisation automatique des données pour la table principale et utilisez les opérations API pour synchroniser les tables secondaires.