OpenStore est un moteur de stockage de journaux élastique, efficace et rentable, développé par l'équipe Alibaba Cloud Elasticsearch pour les scénarios d'analyse de journaux. Il offre un stockage serverless avec une facturation à l'utilisation basée sur la consommation réelle de données, éliminant ainsi le besoin de provisionner la capacité de stockage à l'avance. OpenStore va au-delà de la séparation traditionnelle entre données chaudes et froides, simplifiant l'ingestion des données et réduisant davantage les coûts de stockage pour les données cloud à grande échelle.
Cette fonctionnalité est disponible dans certaines régions, notamment Chine (Hong Kong).
Contexte
Dans les scénarios d'analyse de journaux et d'observabilité, les exigences commerciales ou réglementaires imposent souvent la conservation des données à long terme à des fins d'archivage et d'audit. Avec Elasticsearch open source, cela implique généralement une séparation des données chaudes et froides. Les données âgées de plus de 30 jours sont souvent déplacées vers d'autres supports de stockage, tels que OSS, via des snapshots de cluster. Bien que cette approche fonctionne pour l'archivage à long terme, vous ne pouvez pas interroger directement les données archivées. Pour les interroger, vous devez d'abord restaurer le snapshot dans un cluster et attendre l'initialisation des index, ce qui est complexe et augmente les coûts de stockage à long terme.
OpenStore est une fonctionnalité clé d'Alibaba Cloud Elasticsearch 7.10 Kernel-enhanced Edition. Combiné au service géré Indexing Service, il prend en charge les écritures à faible coût et haute concurrence ainsi que la conservation des données à long terme pour l'analyse des journaux. Créez un cluster 7.10 Kernel-enhanced Edition à la demande et activez la fonctionnalité OpenStore.
Vérifiez si OpenStore est activé et consultez ses informations de stockage dans la section Node Visualization de la page Basic Information de votre cluster. Pour plus d'informations, consultez la rubrique View cluster status and node information.
Pour un cluster avec OpenStore et Indexing Service activés, le service de stockage sous-jacent garantit une haute disponibilité des données. Par conséquent, la fonctionnalité Auto Snapshot n'est pas prise en charge.
Avantages
Stockage massif : OpenStore utilise un modèle de stockage serverless avec facturation à l'utilisation, éliminant le besoin de planification préalable de la capacité. La facturation est horaire selon l'utilisation réelle, permettant d'atteindre 100 % d'utilisation du stockage.
Coût réduit : Les données peuvent être modifiées et mises à jour en temps réel. Le tiering automatisé des données élimine les configurations complexes du cycle de vie des index, simplifiant la configuration initiale. Les coûts de stockage sont jusqu'à 60 % inférieurs à ceux des disques SATA locaux et 70 % inférieurs à ceux des ultra disks.
Haute disponibilité : Une architecture dissociant le calcul du stockage permet à plusieurs réplicas de partager une seule copie de données sans coût supplémentaire. Le service de stockage sous-jacent garantit une haute disponibilité des données et offre une durabilité allant jusqu'à 99,9999999999 % (douze neufs).
Amélioration des performances de requête : Pour les tâches typiques de requête et d'analyse de journaux, les performances sont améliorées de 100 % par rapport aux disques SATA locaux et sont comparables à celles des ultra disks ou des PL0 ESSDs.
Limitations
Les limitations suivantes s'appliquent lors de l'achat et de l'utilisation d'OpenStore.
|
Catégorie |
Description |
|
Région |
OpenStore est disponible uniquement dans les régions suivantes. Les régions réellement disponibles sont affichées sur la page d'achat.
|
|
Version du cluster |
Seuls les clusters Elasticsearch 7.10 Kernel-enhanced Edition prennent en charge OpenStore. |
|
Spécifications du cluster |
Seules les spécifications optimisées pour le stockage suivantes sont prises en charge pour OpenStore : 8 cœurs 64 Go et 16 cœurs 64 Go. |
|
Capacité de stockage du cluster |
La capacité de stockage maximale par nœud est de 30 To. Remarque
Si vous avez besoin d'une capacité de stockage par nœud plus élevée, vous pouvez soumettre un ticket pour demander jusqu'à 50 To. |
|
Nombre de réplicas de shard |
Lorsque vous activez OpenStore, vous devez configurer au moins un réplica par shard. Avertissement
Plusieurs réplicas partagent une seule copie de données sans coût de stockage supplémentaire. Les réplicas garantissent la fiabilité de l'accélération en écriture pour le stockage local. Si vous ne configurez pas de réplicas, les données récemment écrites peuvent être perdues et ne pourront pas être récupérées. |
|
Modèle d'index |
Remarque
Pour supprimer manuellement un index OpenStore, vous devez supprimer à la fois l'index et son alias correspondant. |
|
Configuration du cycle de vie de l'index |
La personnalisation de l'action |
|
Limitations des requêtes |
|
|
Limite de shards par cluster |
Il est recommandé de maintenir moins de 80 000 shards par cluster. |
|
Limite de shards par nœud |
Il est recommandé de maintenir moins de 3 000 shards par nœud. |
|
Taille par shard |
Il est recommandé de maintenir moins de 40 Go par shard. |
|
Débit d'écriture du disque de données |
300 Mo/s si l'utilisation du disque de données est inférieure à 85 %. 100 Mo/s si l'utilisation du disque de données est supérieure ou égale à 85 %. |
Cas d'utilisation
OpenStore est idéal pour les scénarios nécessitant l'écriture et le stockage de grands volumes de données à long terme, tels que la recherche de journaux et l'analyse de métriques. Il convient parfaitement aux charges de travail avec un faible QPS de requête et une tolérance plus élevée à la latence des requêtes.
Le moteur de stockage hybride intelligent convient également aux scénarios commerciaux qui nécessitent des mises à jour de données en temps réel sans séparation stricte entre données chaudes et froides.
Architecture de stockage hybride
Cette architecture offre les avantages suivants :
Dissociation du calcul et du stockage : Contrairement aux architectures traditionnelles de séparation des données chaudes et froides, cette conception dissocie davantage les ressources de calcul et de stockage. Vous n'avez plus besoin de gérer la capacité de stockage. Cette architecture fournit un stockage élastique à l'utilisation et tire parti des principes cloud-native pour améliorer l'évolutivité du cluster. Elle accélère considérablement la migration et la récupération des index, ce qui la rend idéale pour les scénarios de données à grande échelle.
Facilité d'utilisation : Grâce à une gestion entièrement automatisée du cycle de vie des index, il vous suffit de configurer des politiques de cycle de vie simples. Le moteur gère la séparation des données chaudes et froides et migre automatiquement les données vers OpenStore.
Cohérence des données : OpenStore utilise un protocole de consensus basé sur Raft pour garantir la cohérence des données sur tous les supports de stockage. Il gère automatiquement le tiering des données et l'accélération du cache sans intervention de l'utilisateur et prend en charge les mises à jour de données en temps réel.
Tests de performance
-
Environnement de test
Jeu de données : Un jeu de données issu d'un scénario typique d'analyse de journaux.
-
Spécifications du cluster : Les clusters utilisés pour la comparaison partagent la même configuration, optimisée pour l'analyse de journaux.
Nombre de nœuds : 10
Nombre de shards : 108
-
Conditions de requête :
Type de requête : tri
Nombre de documents : 3 800 000 000
-
Résultats des tests
Type de stockage
Temps de requête
Disque SATA local
Plus de 30 s
ultra disk
12 229 s
OpenStore
15 841 s
-
Conclusion du test :
Avec des configurations de cluster identiques, la latence de requête pour les données de journal sur OpenStore est nettement inférieure à celle des disques SATA locaux et comparable à celle des ultra disks. OpenStore coûte environ 60 % de moins par unité que les ultra disks et utilise une facturation à l'utilisation, éliminant le besoin d'acheter de la capacité à l'avance.
Métriques connexes
|
Métrique |
Valeur |
|
Latence d'accès (succès du cache local) |
0,2 ms |
|
Latence d'accès (échec du cache local) |
50 ms à 400 ms |
|
Débit d'accès (succès du cache local) |
1 Go/s |
|
Débit d'accès (échec du cache local) |
750 Mo/s |
|
Cas d'utilisation |
Données rarement consultées, telles que les journaux de surveillance, les commandes historiques et les données archivées |