Basculer une recherche Algolia sur une réplique pendant l’indexation

200 000 fiches réindexées sans la moindre interruption de service de recherche : c’est l’objectif visé par ce mécanisme de bascule, pensé pour qu’un visiteur qui lance une recherche pendant qu’un job de réindexation complète tourne sur le même index Algolia ne reçoive jamais un résultat partiel, incomplet, ou temporairement incohérent avec ce qui existait juste avant.

Ce snippet documente une approche pour éviter ce risque : réindexer sur un index de réserve entièrement séparé, puis basculer un alias Algolia vers ce nouvel index une fois, et seulement une fois, la réindexation intégralement terminée et vérifiée.

Le problème posé par une réindexation en place

Réindexer directement l’index de production consiste à ajouter, mettre à jour ou supprimer des enregistrements sur l’index que les visiteurs interrogent en temps réel. Pendant la durée du job — plusieurs minutes à plusieurs dizaines de minutes selon le volume — l’index se trouve dans un état transitoire : certaines fiches déjà traitées reflètent la nouvelle version des données, d’autres encore la version précédente, et en cas d’échec partiel du job, l’index peut rester durablement dans cet état mixte.

Le principe de l’alias et de l’index tampon

Algolia propose un mécanisme d’alias d’index (« index alias »), qui permet à l’application de toujours interroger un nom logique stable (catalogue_production) pointant en réalité vers un index physique différent selon le moment. La réindexation complète se fait sur un index physique distinct, jamais interrogé directement par le site tant qu’il n’est pas prêt :

$client = \Algolia\AlgoliaSearch\SearchClient::create(
    'APP_ID', 'ADMIN_API_KEY'
);

$index_tampon = $client->initIndex( 'catalogue_reindex_tmp' );

// Réindexation complète, par lots, sur l'index tampon
foreach ( array_chunk( $enregistrements, 1000 ) as $lot ) {
    $index_tampon->saveObjects( $lot );
}

// Une fois tous les lots confirmés, bascule atomique de l'alias
$client->moveIndex( 'catalogue_reindex_tmp', 'catalogue_production' );

La méthode moveIndex() d’Algolia effectue en réalité un renommage atomique côté serveur Algolia : l’index tampon devient l’index de production, l’ancien index de production étant supprimé, sans qu’aucune requête de recherche n’observe jamais d’état intermédiaire. C’est ce comportement, documenté par Algolia comme une opération atomique, qui élimine le risque de résultats partiels pendant la bascule elle-même.

Vérification avant bascule

Avant d’appeler moveIndex(), un contrôle de cohérence a été ajouté pour éviter de basculer vers un index tampon incomplet en cas d’échec silencieux d’un lot :

$nombre_attendu = count( $enregistrements );
$statistiques   = $index_tampon->getSettings(); // vérif config appliquée
$nombre_reel    = $client->initIndex( 'catalogue_reindex_tmp' )
    ->search( '', [ 'hitsPerPage' => 0 ] )['nbHits'];

if ( $nombre_reel < $nombre_attendu * 0.98 ) {
    throw new \RuntimeException(
        "Réindexation incomplète : $nombre_reel sur $nombre_attendu attendus."
    );
}

Le seuil de tolérance à 98 % laisse une marge pour des fiches légitimement exclues (produits désactivés en cours de traitement, par exemple) sans masquer un échec massif du job.

Variantes possibles

• Pour un catalogue mis à jour en continu plutôt que par gros batch nocturne, un flux d’événements incrémental (ajout, mise à jour, suppression) reste préférable à ce mécanisme d’alias, réservé aux réindexations complètes périodiques.
• Conserver l’ancien index quelques heures avant suppression définitive (variante avec copyIndex() plutôt que suppression immédiate) permet un retour arrière rapide en cas de problème détecté après coup.
• Les paramètres de configuration de l’index (facettes, règles de tri personnalisées) doivent être répliqués sur l’index tampon avant la bascule, sous peine de perdre ce réglage lors du renommage.

Une bascule atomique côté fournisseur de recherche vaut toujours mieux qu’une réindexation en place, dès que le catalogue dépasse quelques milliers de fiches.

En résumé

Ce snippet ne traite pas de la tarification Algolia liée au doublement temporaire du nombre d’enregistrements pendant la réindexation (l’index tampon coexiste brièvement avec l’index de production), un point à vérifier séparément selon le plan souscrit. Sur ce catalogue de plus de 200 000 fiches, la bascule via alias a permis de réindexer intégralement sans qu’aucun visiteur n’ait jamais reçu de résultat de recherche incohérent ou partiel pendant l’opération.