Cette rubrique compare Lindorm aux autres bases de données open source.
Informations générales
Lindorm est compatible avec plusieurs API standard, telles qu'Apache HBase, S3, TSDB, HDFS et Apache Solr. Il prend en charge divers modèles de données, notamment les modèles de table large, de séries temporelles, d'objets, de texte, de file d'attente et spatiaux. Lindorm est idéal pour le stockage et l'analyse de types de données variés tels que les journaux, les factures et les tags, offrant des performances élevées à faible coût.
Cette rubrique compare Lindorm à des alternatives open source comme Apache HBase, OpenTSDB, Elasticsearch, Apache Solr et HDFS. La comparaison porte sur les fonctionnalités principales, les performances et le coût afin de vous aider à comprendre les avantages de Lindorm.
Comparaison des fonctionnalités
Lindorm vs. Apache HBase
LindormTable est un moteur de stockage distribué conçu pour des volumes massifs de données structurées et semi-structurées. Il est compatible avec les API standard open source, y compris Apache HBase et Phoenix (SQL). Le tableau suivant compare LindormTable à Apache HBase.
|
Fonctionnalité |
Lindorm |
Apache HBase |
|
|
Fonctionnalités principales |
Modèle de données |
Prend en charge plusieurs modèles de données, tels que la table large, les séries temporelles, la recherche et les fichiers. Le modèle de table large prend en charge plusieurs endpoints et API. |
Table large uniquement |
|
Accès API |
Prend en charge l'API HBase et Phoenix SQL. Les données sont interopérables entre différents endpoints. |
API HBase ou Phoenix SQL |
|
|
SQL |
Conforme JDBC et compatible avec Phoenix, offrant une stabilité et des performances supérieures. |
Nécessite une prise en charge externe pour Phoenix. |
|
|
Type de données |
Prend en charge un ensemble riche de types de données. Pour plus d'informations, consultez Types de données. |
Prend en charge uniquement |
|
|
TTL |
Fournit un TTL de niveau entreprise aux niveaux table, ligne et cellule. |
Prend en charge le TTL au niveau de la table et de la cellule. |
|
|
Cohérence forte |
Prend en charge plusieurs niveaux de cohérence, y compris la cohérence forte et la cohérence à terme. |
Prise en charge |
|
|
Index secondaire global |
Fournit un index secondaire global intégré. Cette fonctionnalité permet des requêtes transparentes, offre des performances élevées et autorise la redondance à la demande des colonnes non indexées. |
Nécessite une configuration complexe de composants externes. |
|
|
Récupération multidimensionnelle |
S'intègre parfaitement à LindormSearch pour fournir un accès unifié au stockage massif de données, aux requêtes multidimensionnelles et à la recherche en texte intégral. Pour plus d'informations, consultez Présentation de l'index de recherche. |
Non pris en charge |
|
|
Performances |
Débit |
Offre jusqu'à 7 fois le débit d'un nœud Apache HBase unique. Pour plus d'informations, consultez Analyse des résultats des tests. |
Sans objet |
|
Pics de latence des requêtes |
Réduit la latence P99 à un dixième de celle d'Apache HBase. Pour plus d'informations, consultez Analyse des résultats des tests. |
Pics de latence fréquents |
|
|
Coût |
Coût de stockage |
Propose plusieurs types de stockage, tels que Performance, Standard et Capacity, réduisant les coûts jusqu'à 80 % par rapport aux instances autogérées sur disques cloud. |
Basé sur des disques cloud ou locaux autogérés, qui sont coûteux et peu élastiques. |
|
Séparation du calcul et du stockage |
Oui. Les ressources de stockage et de calcul évoluent indépendamment. |
Non |
|
|
Compression des données |
Utilise un algorithme de compression intégré profondément optimisé pour atteindre un taux de compression supérieur à 10:1, soit plus de 50 % supérieur à Snappy. |
Prend en charge Snappy, LZ4 et LZO, mais les taux de compression sont faibles. |
|
|
Encodage |
Utilise un encodage adaptatif conscient du type de données pour un taux de compression élevé. Cela permet des recherches rapides sans décodage. |
Prend en charge DIFF avec une compression modérée. Les données encodées ne peuvent pas être recherchées. |
|
|
Séparation des données chaudes et froides |
Hiérarchise automatiquement les données. Les données froides sont déplacées vers un stockage économique à haute compression pour réduire les coûts de 80 %, tout en améliorant les performances d'accès aux données chaudes de 15 %. Pour plus d'informations, consultez Séparation des données chaudes et froides. |
Non pris en charge |
|
|
Évolutivité et élasticité |
Échelle minimale |
Sans objet. |
Au moins 3 nœuds |
|
Évolutivité |
Hautement évolutif. Prend en charge la mise à l'échelle horizontale jusqu'à des milliers de nœuds. |
Hautement évolutif. Prend en charge la mise à l'échelle horizontale jusqu'à des milliers de nœuds. |
|
|
Fiabilité |
Redondance actif-actif |
Fournit des capacités avancées telles que le basculement automatisé de reprise après sinistre et les requêtes simultanées sur deux clusters. Prend en charge la construction d'une architecture primaire/de secours hybride avec un cluster Apache HBase autogéré. |
Ce n'est pas une fonctionnalité produit. Le basculement n'est pas pris en charge. |
|
Cohérence forte inter-zone de disponibilité |
Prend en charge le déploiement inter-zones de disponibilité (AZ), garantissant une récupération automatique et une forte cohérence des données en cas de panne au niveau de la zone. |
Non pris en charge |
|
|
Sauvegarde et restauration |
Prend en charge la sauvegarde de jeux de données supérieurs à 100 To vers OSS. Fournit des fonctionnalités avancées telles que la sauvegarde à la demande, la récupération à un instant donné (PITR) et un objectif de temps de récupération (RTO) indépendant de la taille des données inférieur à 30 minutes. Pour plus d'informations, consultez Activer la sauvegarde et la restauration. |
Prise en charge, mais avec des capacités limitées. |
|
|
Redondance géographique active |
Prise en charge. Permet le déploiement sur plusieurs régions géographiques et unités avec synchronisation des données à la demande. |
Non pris en charge |
|
|
Multi-location et sécurité |
Authentification et ACL |
Prend en charge l'authentification par nom d'utilisateur et mot de passe ainsi que les listes de contrôle d'accès (ACL). Pour plus d'informations, consultez Gérer les utilisateurs. |
Non pris en charge |
|
Isolation des ressources |
Fournit des groupes de ressources pour permettre l'isolation physique des ressources entre les locataires. |
Non pris en charge |
|
|
Quota |
Prend en charge les quotas globaux pour les locataires, y compris les requêtes et le stockage. |
Ne prend pas en charge la multi-location. |
|
|
Chiffrement au repos |
Prise en charge. Les clés sont gérées par KMS et toutes les données et tous les journaux sont chiffrés. |
Prise en charge, mais avec des capacités limitées. |
|
|
Liste noire RPC |
Prend en charge une liste noire RPC pour restreindre certains appels. |
Non pris en charge |
|
|
Audit |
Actuellement non pris en charge. |
Non pris en charge |
|
|
Fonctionnalités avancées |
Corbeille de table |
Lindorm déplace les tables supprimées vers une corbeille, où elles peuvent être restaurées pour éviter la perte accidentelle de données. |
Non pris en charge |
|
Fractionnement en cascade |
Les régions peuvent être fractionnées successivement sans attendre la fin de la compaction, améliorant considérablement l'évolutivité et l'équilibrage de charge. |
Non pris en charge |
|
|
TTL discret |
Permet de conserver les données de plusieurs périodes non contiguës. |
Non pris en charge |
|
|
Opérations et diagnostics |
Outils O&M |
Fournit un outil de gestion de cluster basé sur une interface graphique pour gérer les tables, les namespaces, les groupes et les ACL. Pour plus d'informations, consultez Se connecter au système de gestion de cluster. |
HBase Shell |
|
Requête de données |
Prend en charge les requêtes SQL interactives dans le système de gestion de cluster basé sur une interface graphique. Pour plus d'informations, consultez Data Query. Il prend également en charge des outils open source comme HBase Shell et CQLsh. |
HBase Shell |
|
|
Écosystème |
Migration de données |
Prend en charge la migration en ligne, inter-version, automatisée et efficace depuis diverses versions d'Apache HBase. Le processus de migration n'a aucun impact sur vos applications et ne nécessite aucune modification de code. Pour plus d'informations, consultez Lindorm Tunnel Service. |
Seule la migration hors ligne est prise en charge. |
|
Synchronisation des données MySQL |
Prend en charge l'importation complète et la synchronisation incrémentielle des données MySQL vers Lindorm en utilisant Lindorm Tunnel Service. |
Nécessite des outils tiers. Ne prend pas en charge la synchronisation incrémentielle en ligne. |
|
|
Analyse Spark |
Offre une intégration profonde et productisée. Vous pouvez synchroniser de manière incrémentielle les données Lindorm vers Spark, les analyser avec Spark SQL et écrire les résultats dans Lindorm. |
Non optimisé. L'intégration des données nécessite des efforts de développement importants. |
|
|
MaxCompute |
Fournit une intégration productisée pour archiver de manière incrémentielle les données Lindorm vers MaxCompute. |
L'intégration des données nécessite des efforts de développement importants. |
|
|
Log Service |
Prend en charge l'abonnement en temps réel aux données de Log Service vers Lindorm en utilisant Lindorm Tunnel Service. |
L'intégration des données nécessite des efforts de développement importants. |
|
|
Service et support |
SLA de disponibilité |
Garanti par un SLA. Offre une disponibilité de 99,95 % pour une instance mono-zone et de 99 975 % pour une instance multi-zone. |
Non fourni |
|
Coût opérationnel |
Un service entièrement géré qui élimine le besoin d'opérations de base de données complexes. |
Coût opérationnel élevé |
|
|
Équipe technique |
Une équipe d'experts composée de membres du comité de gestion de projet Apache (PMC) et de contributeurs (Committers) fournit un support technique. |
Non fourni |
|
|
Expérience éprouvée |
Éprouvé à grande échelle avec des dizaines de milliers d'instances déployées, prenant en charge le Festival mondial du shopping 11,11 d'Alibaba depuis neuf ans. |
Sans objet |
|
Lindorm vs. OpenTSDB
Lindorm TSDB est un moteur de base de données de séries temporelles performant, économique et fiable. Il fournit des opérations de lecture/écriture efficaces, un taux de compression de données élevé et une agrégation de données de séries temporelles. LindormTSDB est hautement compatible avec le protocole OpenTSDB et offre de puissantes capacités de séries temporelles en utilisant des technologies propriétaires pour l'indexation, la modélisation des données et l'agrégation de flux. Le tableau suivant compare LindormTSDB à OpenTSDB.
|
Fonctionnalité |
LindormTSDB |
OpenTSDB |
|
|
Opérations et gestion |
Disponibilité du service |
99,9 % |
Nécessite de construire et de gérer des clusters et des dépendances pour assurer la disponibilité. |
|
Fiabilité des données |
99,9999 % |
Nécessite de construire et de gérer des clusters et des dépendances pour assurer la fiabilité. |
|
|
Investissement matériel et logiciel |
Aucun investissement matériel ou logiciel. Paiement à l'utilisation. |
Coût relativement élevé pour les serveurs de base de données. |
|
|
Coût de maintenance |
Service géré |
Nécessite des administrateurs de base de données (DBA) dédiés, entraînant des coûts de main-d'œuvre élevés. |
|
|
Déploiement et mise à l'échelle |
Fournit une activation instantanée, un déploiement rapide et une mise à l'échelle élastique. |
Nécessite un achat de matériel long, un hébergement en centre de données et un déploiement de machines. |
|
|
Dépendances |
Sans O&M |
Dépend d'AsyncHBase et HBase, ce qui entraîne des coûts opérationnels élevés. |
|
|
Réglage des paramètres |
Utilise des paramètres par défaut basés sur les meilleures pratiques. |
Nécessite un réglage manuel des paramètres tels que SALT, le nombre de connexions, la vidange synchrone et la compaction. |
|
|
Instructions de création de table |
La création de table est gérée par le service et transparente pour les utilisateurs. |
Nécessite que le personnel O&M écrive des instructions statiques de création de table. |
|
|
Surveillance et alertes |
Fournit un pipeline complet d'auto-surveillance. |
Nécessite des outils externes pour la configuration. |
|
|
Fonctionnalités |
Modèle de données |
Prend en charge les modèles de données multivalues et monovalues. |
Prend en charge uniquement le modèle de données monovalue. |
|
SDK |
Java SDK |
Le SDK open source ne prend pas en charge les requêtes. |
|
|
Variété des types de données |
Prend en charge plusieurs types de données, tels que numérique, booléen et chaîne. |
Prend en charge uniquement les types numériques. |
|
|
Capacité de requête SQL |
Prend en charge SQL pour les requêtes analytiques. |
Non pris en charge |
|
|
Prise en charge des caractères chinois |
Prend en charge les caractères anglais et chinois. |
Prend en charge uniquement les caractères anglais. |
|
|
Exigence de tag |
Les tags sont facultatifs. |
Les tags sont obligatoires. |
|
|
Nombre de clés de tag |
Jusqu'à 16 |
Jusqu'à 8 |
|
|
Intégration |
Offre un écosystème riche avec une intégration transparente avec Flink et IoT Platform. |
En tant que produit open source, ses capacités d'intégration avec les services cloud sont limitées. |
|
|
Coût de stockage |
Compression des données |
Utilise un algorithme de compression spécialisé pour les données de séries temporelles, atteignant un taux de compression élevé. |
Utilise un algorithme de compression généraliste, résultant en un taux de compression faible. |
|
Stabilité |
Lectures de données |
Sépare les pools de threads de lecture et d'écriture pour une gestion facile des connexions et des performances stables en lecture/écriture. |
Couple les opérations de lecture et d'écriture, ce qui peut entraîner un épuisement des connexions et un taux élevé d'échecs de lecture/écriture. |
|
Agrégateur |
Utilise l'agrégation de flux avec une gestion fine de la mémoire pour un meilleur contrôle. |
Utilise l'agrégation matérialisée en mémoire, ce qui peut facilement entraîner des erreurs de manque de mémoire (OOM). |
|
LindormSearch vs. Elasticsearch et Solr
Lindorm Search est un moteur de recherche et de stockage distribué conçu pour des ensembles de données massifs. Il est compatible avec l'API standard Apache Solr. Le tableau suivant compare LindormSearch à Elasticsearch et Apache Solr.
|
Fonctionnalité |
LindormSearch |
Elasticsearch |
Apache Solr |
|
|
Fonctionnalités principales |
Modèle de données |
Prend en charge plusieurs modèles de données, tels que la table large, les séries temporelles, la recherche et les fichiers. Le moteur de recherche peut servir de magasin d'index pour d'autres moteurs de manière transparente. |
Recherche uniquement |
Recherche uniquement |
|
Accès API |
Prend en charge Phoenix SQL et l'API Solr. |
API ES |
API Solr |
|
|
TTL |
Fournit un TTL de niveau entreprise à plusieurs granularités, telles que la table et la ligne. |
Seul le TTL au niveau de la table est pris en charge. |
Seul le TTL au niveau de la table est pris en charge. |
|
|
Stockage et récupération unifiés |
S'intègre parfaitement à LindormTable et LindormTSDB pour fournir un stockage et une récupération multimodales unifiés. |
Sans objet |
Sans objet |
|
|
Performances et coût |
Débit |
Offre 130 % à 200 % du débit d'un nœud Apache Solr unique. |
Sans objet |
Sans objet |
|
Coût de stockage |
Propose plusieurs types de stockage, tels que Performance, Standard et Capacity. Réduit les coûts de stockage jusqu'à 80 % par rapport aux instances autogérées sur disques cloud. |
Basé sur des disques cloud ou locaux autogérés, qui sont coûteux et peu élastiques. |
Basé sur des disques cloud ou locaux autogérés, qui sont coûteux et peu élastiques. |
|
|
Séparation du calcul et du stockage |
Oui. Les ressources de stockage et de calcul évoluent indépendamment. |
Non |
Non |
|
|
Compression des données |
Utilise un algorithme de compression intégré profondément optimisé pour atteindre un taux de compression supérieur à 10:1, soit plus de 50 % supérieur à Snappy. |
Sans objet |
Sans objet |
|
|
Séparation des données chaudes et froides |
Sépare automatiquement les données en tables basées sur un attribut temporel. Les données froides utilisent un stockage économique à haute compression pour réduire les coûts, tandis que les performances d'accès aux données chaudes sont améliorées. |
Non pris en charge |
Non pris en charge |
|
|
Élasticité |
Élasticité du stockage |
Élevée. Découple le stockage du calcul et prend en charge la mise à l'échelle en un clic. La mise à l'échelle du stockage prend effet en quelques secondes et celle du calcul en quelques minutes. |
Faible. La mise à l'échelle horizontale nécessite une migration de données et prend des heures. |
Faible. La mise à l'échelle horizontale nécessite une migration de données et prend des heures. |
|
Un seul rédacteur, plusieurs lecteurs |
Les shards de données prennent en charge un modèle à un seul rédacteur et plusieurs lecteurs. Les réplicas de lecture peuvent être mis à l'échelle horizontalement en ligne, les changements prenant effet en quelques secondes. |
Pris en charge, mais l'ajout de réplicas de lecture nécessite une migration de données et prend des heures. |
Pris en charge, mais l'ajout de réplicas de lecture nécessite une migration de données et prend des heures. |
|
|
Écosystème |
Migration de données |
Prend en charge la migration de données en ligne, automatisée et efficace depuis des clusters Apache Solr ou Elasticsearch vers Lindorm sans impact sur l'application ni modification de code. Pour plus d'informations, consultez Lindorm Tunnel Service. |
Seule la migration hors ligne est prise en charge. |
Seule la migration hors ligne est prise en charge. |
|
Synchronisation des données MySQL |
Prend en charge l'importation complète et la synchronisation incrémentielle des données MySQL vers Lindorm en utilisant Lindorm Tunnel Service. |
Nécessite des outils tiers. Ne prend pas en charge la synchronisation incrémentielle en ligne. |
Nécessite des outils tiers. Ne prend pas en charge la synchronisation incrémentielle en ligne. |
|
|
Analyse Spark |
Offre une intégration profonde et productisée. Vous pouvez analyser les données Lindorm avec Spark SQL, synchroniser de manière incrémentielle les données Lindorm vers Spark et écrire les résultats d'analyse hors ligne dans Lindorm. |
Non optimisé. L'intégration des données nécessite des efforts de développement importants. |
Non optimisé. L'intégration des données nécessite des efforts de développement importants. |
|
|
Log Service |
Prend en charge l'abonnement en temps réel aux données de Log Service vers Lindorm en utilisant Lindorm Tunnel Service. |
L'intégration des données nécessite des efforts de développement importants. |
L'intégration des données nécessite des efforts de développement importants. |
|
|
Service et support |
SLA de disponibilité |
Garanti par un SLA. Offre une disponibilité de 99,95 % pour une instance mono-zone et de 99 975 % pour une instance multi-zone. |
Non fourni |
Non fourni |
|
Coût opérationnel |
Un service entièrement géré qui élimine le besoin d'opérations de base de données complexes. |
Sans objet |
Sans objet |
|
|
Équipe technique |
Une équipe d'experts composée de membres du comité PMC Apache et de contributeurs (Committers) fournit un support technique. |
Non fourni |
Non fourni |
|
|
Expérience éprouvée |
Éprouvé à grande échelle avec des dizaines de milliers d'instances déployées, prenant en charge le Festival mondial du shopping 11,11 d'Alibaba depuis neuf ans. |
Sans objet |
Sans objet |
|
Lindorm vs. HDFS
Lindorm DFS est un service de stockage de fichiers natif du cloud compatible avec le protocole HDFS. Le tableau suivant compare LindormDFS à HDFS.
|
Fonctionnalité |
LindormDFS |
HDFS |
|
|
Positionnement du produit |
Système de fichiers distribué |
Système de fichiers distribué |
|
|
Compatibilité HDFS |
Protocole de communication HDFS |
Pris en charge |
Pris en charge |
|
API de lecture/écriture de base |
Entièrement pris en charge |
Entièrement pris en charge |
|
|
API de gestion avancée |
Entièrement pris en charge |
Entièrement pris en charge |
|
|
Coût |
Prix du stockage (Le prix réel sur la page d'achat fait foi.) |
À partir de 0 019 USD/Go/mois |
À partir de 0 023 USD/Go/mois |
|
Élasticité du stockage |
Prend en charge la mise à l'échelle en ligne fluide. |
Seuil d'entrée élevé et grands incréments de mise à l'échelle. |
|
|
Séparation du calcul et du stockage |
Pris en charge. Découplé des moteurs de calcul pour une mise à l'échelle indépendante. |
Non pris en charge. Colocalisé avec les moteurs de calcul. |
|
|
Stockage hiérarchisé |
Stockage multi-niveaux avec hiérarchisation intelligente des données. |
Non pris en charge |
|
|
Évolutivité |
Nombre de nœuds |
Sans objet |
0 à 1 000 |
|
Capacité de stockage |
0 à 1 Eo |
0 à 10 Po |
|
|
Nombre de fichiers |
Prend en charge des centaines de milliards de fichiers. |
Des dizaines de millions |
|
|
Écosystème |
Écosystèmes big data open source comme Hadoop et Spark, ainsi que l'écosystème de données Alibaba Cloud. |
Écosystèmes big data open source comme Hadoop et Spark. |
|
|
Facilité d'utilisation |
LindormDFS ne nécessite pas d'O&M et est facile à maintenir. |
Service avec état complexe à maintenir. |
|