Lindorm propose plusieurs moteurs : le moteur de tables larges, le moteur de séries temporelles, le moteur de recherche, le moteur de calcul et le moteur de streaming. Ces moteurs sont compatibles avec des API open source telles que HBase, Cassandra, S3, OpenTSDB, Solr et HDFS , et prennent en charge les requêtes SQL, le traitement des séries temporelles ainsi que la recherche en texte intégral.
Chaque moteur peut être mis à l'échelle indépendamment pour s'adapter aux charges de travail dynamiques. Le moteur de tables larges et le moteur de séries temporelles offrent un débit élevé en cas de forte concurrence.
Sélectionner un moteur
Sélectionnez un ou plusieurs moteurs en fonction de vos besoins. Le tableau suivant décrit chaque moteur.
|
Moteur |
Compatibilité |
Scénario |
Description |
|
Moteur de tables larges (LindormTable) |
Compatible avec SQL, l'API HBase, le langage de requête Cassandra (CQL) et l'API Amazon S3. |
Adapté à la gestion et à l'analyse des métadonnées, des commandes, des factures, des profils utilisateurs, des informations sociales, des flux d'actualités, des journaux et des trajectoires. |
Un moteur distribué conçu pour les données semi-structurées et structurées à grande échelle. Il prend en charge les index secondaires globaux, les recherches multidimensionnelles, les colonnes dynamiques et le TTL. Il gère des dizaines de millions de requêtes concurrentes et stocke jusqu'à plusieurs centaines de pétaoctets de données. Par rapport à HBase open source : débit en lecture/écriture multiplié par 3 à 7, latence P99 divisée par 10, ratio de compression doublé et coût de stockage réduit de 50 %. Inclut la séparation des données chaudes et froides. Le service intégré GanosBase prend en charge les données spatiales et spatio-temporelles pour les requêtes de trajectoires historiques à grande échelle. |
|
Moteur de séries temporelles (LindormTSDB) |
Fournit une API HTTP et est compatible avec l'API OpenTSDB. |
Convient au stockage et au traitement des données de séries temporelles, telles que les données de mesure et les données opérationnelles des appareils, dans des scénarios comme l'IoT et la surveillance. |
Un moteur distribué optimisé pour les données de séries temporelles. Il prend en charge les requêtes SQL, des algorithmes de compression dédiés aux séries temporelles pour améliorer les ratios de compression, les requêtes et agrégations de chronologies multidimensionnelles, le sous-échantillonnage et la mise à l'échelle élastique. |
|
Moteur de recherche (LindormSearch) |
Compatible avec SQL et les API Apache Solr et Elasticsearch. |
Idéal pour interroger de grands volumes de données, tels que des journaux, du texte et des documents. Par exemple, vous pouvez utiliser le moteur de recherche pour effectuer des recherches dans les journaux, les factures et les profils utilisateurs. |
Un moteur de recherche distribué avec découplage du stockage et du calcul. Il indexe de manière transparente les données des moteurs de tables larges et de séries temporelles pour accélérer les requêtes. Prend en charge la recherche en texte intégral, l'agrégation, les requêtes complexes multidimensionnelles, la mise à l'échelle horizontale, l'architecture « une écriture, multiples lectures », la reprise après sinistre inter-zones et le TTL. |
|
Moteur de calcul (LDPS) |
Compatible avec l'API Apache Spark. |
Adapté aux scénarios tels que la production de grands volumes de données, l'analytique interactive, l'apprentissage computationnel et le calcul de graphes. |
Un service de calcul distribué natif du cloud compatible avec les modèles et les API Spark de la communauté. Intégré profondément aux moteurs de stockage Lindorm, il exploite les caractéristiques et les index des données sous-jacentes pour une exécution efficace des jobs distribués. |
|
Moteur de streaming |
Compatible avec SQL et l'API Apache Kafka. |
Convient aux scénarios tels que le traitement des données IoT, le traitement des journaux d'application, l'analyse de vieillissement logistique, le traitement des données de voyage et le traitement des trajectoires en temps réel. |
Un moteur destiné au stockage et au traitement léger des données de streaming. Il stocke les données de streaming dans Lindorm pour un traitement en temps réel. Combiné au service GanosBase du moteur de tables larges, il permet l'analyse de trajectoires en temps réel, telle que le géorepérage et les statistiques régionales. |
Sélectionner les spécifications et la quantité de nœuds
Lindorm prend en charge la mise à l'échelle horizontale des nœuds de moteur. L'ajout de nœuds résout des problèmes tels qu'une latence élevée et des performances instables. Toutefois, l'ajout de nœuds seul ne peut pas résoudre les problèmes de points chauds sur un seul nœud ; vous devez plutôt mettre à niveau la spécification du nœud. La spécification du nœud détermine la capacité de gestion des points chauds sur un seul nœud. Les nœuds avec des spécifications inférieures peuvent subir une charge excessive ou des erreurs de mémoire insuffisante (OOM) en cas de trafic intense.
Évaluez votre charge de travail et choisissez les spécifications de nœud appropriées. Pour mettre à niveau les spécifications des nœuds, utilisez la console Lindorm. Pour plus d'informations, consultez la rubrique Modifier le type d'instance. Pour obtenir de l'aide, contactez le support technique Lindorm (ID DingTalk : s0s3eg3).
Moteur de tables larges (LindormTable)
Les nœuds LindormTable prennent en charge des spécifications allant de 4 cœurs / 8 Go à 32 cœurs / 256 Go, avec une mise à l'échelle horizontale. Choisissez une spécification en fonction de votre taux de requêtes par nœud (lignes/s) et du nombre de régions.
Lorsque Product Type est défini sur Lindorm, la spécification minimale pour LindormTable est de 4 cœurs / 16 Go.
Certaines optimisations de performance nécessitent des nœuds disposant de plus de 16 Go de mémoire, et certaines optimisations d'écriture requièrent au moins 3 nœuds. Nous recommandons au moins 3 nœuds avec 8 cœurs / 32 Go chacun (16 cœurs / 64 Go étant préférable).
Spécifications recommandées :
< 1 000 requêtes/s par nœud, < 500 régions par nœud : 4 cœurs / 16 Go.
< 20 000 requêtes/s par nœud, < 1 000 régions par nœud : 8 cœurs / 32 Go ou supérieur.
-
> 20 000 requêtes/s par nœud, > 1 000 régions par nœud : 16 cœurs / 64 Go ou supérieur.
ImportantLe taux de requêtes et le nombre de régions ne sont pas les seuls facteurs à prendre en compte pour choisir les spécifications des nœuds.
-
Pour les charges de travail complexes, les recommandations ci-dessus peuvent être insuffisantes. Choisissez une spécification supérieure si l'un des cas suivants s'applique :
La taille des lignes atteint des kilo-octets ou des méga-octets.
Les requêtes SCAN utilisent des filtres complexes.
Le taux de succès du cache est faible — la plupart des requêtes lisent depuis le disque.
L'instance contient de nombreuses tables.
Pour les services en ligne, choisissez une mémoire plus importante pour améliorer les taux de succès du cache.
Pour les tâches hors ligne à forte charge (MapReduce, Spark) ou pour un TPS/QPS très élevé, choisissez davantage de cœurs CPU.
Si l'utilisation du CPU reste à 70 % ou plus, envisagez de mettre à niveau la spécification du nœud.
-
Moteur de séries temporelles (LindormTSDB)
Les nœuds LindormTSDB prennent en charge des spécifications allant de 4 cœurs / 8 Go à 32 cœurs / 256 Go. Sélectionnez la spécification et la quantité de nœuds en fonction de votre TPS (points de mesure/seconde).
Lorsque Product Type est défini sur Lindorm, la spécification minimale pour LindormTSDB est de 4 cœurs / 16 Go.
Spécifications recommandées (cluster à 3 nœuds) :
TPS < 1,9 M : 4 cœurs / 16 Go par nœud.
TPS < 3,9 M : 8 cœurs / 32 Go par nœud.
TPS < 7,8 M : 16 cœurs / 64 Go par nœud.
TPS < 11 M : 32 cœurs / 128 Go par nœud.
Ces recommandations supposent des performances optimales de traitement des données. La capacité réelle dépend de votre modèle métier, de la taille des lots et de la concurrence. Pour plus d'informations, consultez les rubriques Résultats des tests d'écriture et Résultats des tests de requête.