O Lindorm é um banco de dados multimodelo nativo da nuvem que consolida tabelas largas, séries temporais, pesquisa e armazenamento de arquivos em um único serviço. Oferece compatibilidade de API com Apache HBase, Apache Cassandra, OpenTSDB, Apache Solr e Hadoop Distributed File System (HDFS), o que permite migrar cargas de trabalho existentes sem reescrever o código da aplicação.
Este tópico compara o Lindorm com os bancos de dados de código aberto que ele substitui.
Lindorm vs. Apache HBase and Apache Cassandra
O LindormTable é o mecanismo de tabelas largas para dados semiestruturados e estruturados. Suporta a API do HBase, Cassandra Query Language (CQL), Phoenix SQL e Java Database Connectivity (JDBC) padrão, todos operando sobre o mesmo conjunto de dados. Os dados gravados pela API do HBase ficam imediatamente disponíveis para consulta via CQL, sem necessidade de sincronização.
| Recurso | Lindorm | Apache HBase | Apache Cassandra | |
|---|---|---|---|---|
Recursos principais | Modelos de dados | Tabelas largas, séries temporais, pesquisa e arquivos em um único serviço | Apenas tabelas largas | Apenas tabelas largas |
| APIs | API do HBase, CQL e Phoenix SQL com interoperabilidade de dados entre protocolos | API do HBase e Phoenix SQL | Apenas CQL | |
| SQL | JDBC padrão; Phoenix SQL integrado com maior estabilidade e desempenho que o Phoenix de código aberto | Requer componente Phoenix externo | Apenas dialeto SQL simples | |
| Tipos de dados | Vários tipos de dados. Consulte Tipos de dados. | Apenas BYTE[] | Vários tipos de dados | |
| Time-to-live (TTL) | Granularidade de tabela, coluna e célula | Granularidade de tabela e célula | Apenas granularidade de tabela | |
| Consistência | Consistência forte e eventual | Consistência forte | Consistência forte | |
| Índices secundários globais | Integrado; não requer componentes externos | Requer componentes externos; configuração complexa | Suportado | |
| Pesquisa de texto completo e consultas multidimensionais | Integrado via LindormSearch. Consulte Visão geral. | Não suportado | Não suportado | |
Desempenho | Throughput | 7 vezes superior ao do Apache HBase de código aberto. Consulte Analisar resultados de benchmark. | Linha de base | Sem dados disponíveis |
| Latência P99 | 1/10 da latência do Apache HBase de código aberto. Consulte Analisar resultados de benchmark. | Alta latência de cauda | Alta latência de cauda | |
Custo | Custo de armazenamento | Até 80% menor que discos em nuvem autogerenciados; as especificações de armazenamento incluem Performance, Standard e Capacity | Discos locais ou em nuvem autogerenciados; sem dimensionamento elástico | Discos locais ou em nuvem autogerenciados; sem dimensionamento elástico |
| Separação de computação e armazenamento | Suportada; dimensione armazenamento e computação independentemente | Não suportada | Não suportada | |
| Compressão de dados | Algoritmo otimizado integrado; taxa de compressão superior a 10:1, mais de 50% maior que a do Snappy | Snappy, LZ4 e LZO; menor taxa de compressão | Snappy e LZ4; menor taxa de compressão | |
| Codificação adaptativa | Suportada; permite consultas rápidas sem decodificação | Codificação DIFF; compressão moderada, dados codificados não recuperáveis | Não suportada | |
| Separação de dados quentes e frios | Armazenamento em camadas automático; reduz o custo de armazenamento em 80% e melhora o desempenho de consultas de dados quentes em 15%. Consulte Visão geral. | Não suportada | Não suportada | |
Extensibilidade e elasticidade | Mínimo de nós |
Não aplicável. |
Pelo menos 3 nós | Pelo menos 3 nós |
| Escalabilidade | Escala para milhares de nós | Escala para milhares de nós | Aproximadamente 100 nós antes de gargalo de desempenho | |
Confiabilidade | Redundância ativa-ativa | Suportada; inclui failover automático e implantação em cluster duplo. Implante o Lindorm junto com uma instância autogerenciada de HBase ou Cassandra no modo primário/secundário. | Sem suporte a failover | Suportada, mas requer três réplicas |
| Consistência forte multirregional | Suportada; possibilita recuperação de desastres no nível de data center | Não suportada | Não suportada | |
| Backup e restauração | Faz backup de mais de 100 TB no Object Storage Service (OSS); objetivo de tempo de recuperação (RTO) inferior a 30 minutos; suporta backup sob demanda e restauração point-in-time. Consulte Ativar backup e restauração de dados. | Suporte limitado | Suporte limitado | |
| Georredundância ativa | Suportada; implante em várias regiões e unidades com sincronização de dados configurável | Não suportada | Suporte moderado | |
Multilocação e segurança | Autenticação e listas de controle de acesso (ACLs) | Autenticação por nome de usuário/senha e ACLs | Não suportado | Suportado |
| Isolamento de recursos | Isolamento físico de recursos entre locatários via grupos de recursos | Não suportado | Não suportado | |
| Gerenciamento de cotas | Cotas globais de solicitação e armazenamento por locatário | Sem suporte a multilocação | Não suportado | |
| Criptografia em repouso | Suportada via Key Management Service (KMS); criptografa todos os dados e logs | Suporte limitado | Não suportada | |
| Lista de bloqueios de chamada de procedimento remoto (RPC) | Suportada; limite de taxa para chamadas RPC específicas | Não suportada | Não suportada | |
| Auditoria | Não suportada | Não suportada | Não suportada | |
Recursos avançados | Lixeira de tabelas | Tabelas excluídas são movidas para a lixeira para recuperação | Não suportado | Não suportado |
| Divisão em cascata | Regiões divididas continuamente sem aguardar compactação | Não suportado | Não suportado | |
| TTL discreto | Retém dados em vários intervalos de tempo em uma única tabela | Não suportado | Não suportado | |
O&M e diagnósticos | Ferramentas de operações e manutenção (O&M) | Gerenciamento de cluster baseado em GUI para tabelas, namespaces, grupos de recursos e ACLs. Consulte Fazer login no sistema de gerenciamento de cluster. | Apenas HBase Shell | Apenas ferramentas CLI; sem GUI |
| Consultas de dados baseadas em SQL | Execute consultas SQL em uma interface gráfica. Consulte Consulta de dados. Também suporta HBase Shell e cqlsh. | Apenas HBase Shell | Apenas cqlsh | |
Ecossistema | Migração de dados | Migração online, entre versões e automatizada de qualquer versão do HBase ou Cassandra; sem alterações no código da aplicação. Consulte Visão geral. | Apenas migração offline | Apenas migração offline |
| Sincronização de dados do MySQL | Sincronização completa e incremental do MySQL via Lindorm Tunnel Service (LTS). Consulte Visão geral. | Sem ferramentas dedicadas; sem sincronização incremental online | Sem ferramentas dedicadas; sem sincronização incremental online | |
| Integração com Apache Spark | Integração profunda: sincronização incremental, análise Spark SQL e gravação de resultados de volta no Lindorm | Integração manual que exige esforço significativo de desenvolvimento | Integração manual que exige esforço significativo de desenvolvimento | |
| Integração com MaxCompute | Arquivamento incremental de dados do Lindorm para o MaxCompute | Integração manual que exige esforço significativo de desenvolvimento | Integração manual que exige esforço significativo de desenvolvimento | |
| Integração com Simple Log Service (SLS) | Assine dados em tempo real do SLS e importe para o Lindorm. Consulte Visão geral. | Integração manual que exige esforço significativo de desenvolvimento | Integração manual que exige esforço significativo de desenvolvimento | |
Capacidades do serviço | SLA | 99,9% para implantação em cluster único; 99,99% para implantação em cluster duplo | Nenhum SLA fornecido | Nenhum SLA fornecido |
| Custos de O&M | Totalmente gerenciado; sem necessidade de administração de banco de dados | Altos custos de O&M | Altos custos de O&M | |
| Suporte técnico | Equipe especializada incluindo membros e committers do Apache Project Management Committee (PMC) | Sem suporte dedicado | Sem suporte dedicado | |
| Histórico em produção | Dezenas de milhares de instâncias suportando cargas de trabalho do Alibaba Group em nove edições do Tmall Double 11 Shopping Festival | Nenhum | Nenhum | |
Lindorm vs. OpenTSDB
O LindormTSDB é um mecanismo de séries temporais totalmente gerenciado e de alto desempenho, compatível com os protocolos do OpenTSDB. Utiliza indexação, modelos de dados e agregação em streaming desenvolvidos pela Alibaba Cloud para oferecer capacidades que, no OpenTSDB, exigiriam construção própria sobre o HBase.
| Recurso | LindormTSDB | OpenTSDB | |
|---|---|---|---|
O&M e gerenciamento | Disponibilidade do serviço | 99,9% | Autogerenciado; provisione e configure clusters com todas as dependências para garantir a disponibilidade |
| Confiabilidade dos dados | 99,9999% | Autogerenciado; a confiabilidade depende da sua configuração de HBase e infraestrutura | |
| Custo de infraestrutura | Sem hardware ou software para implantar; faturamento conforme o uso real | Requer servidores de banco de dados dedicados | |
| Manutenção | Totalmente gerenciado | Requer administradores de banco de dados (DBAs) dedicados | |
| Implantação e dimensionamento | Ativação instantânea; dimensionamento elástico | Requer aquisição de hardware, hospedagem em data center e implantação manual de máquinas | |
| Gerenciamento de dependências | Livre de O&M | Requer gerenciamento de AsyncHBase, HBase e dependências relacionadas | |
| Ajuste de parâmetros | Pré-configurado com base nas melhores práticas | Requer configuração manual de valores de salt, contagens de conexão, modos de flush e configurações de compactação | |
| Criação de tabelas | Gerenciada automaticamente; transparente para os usuários | Requer O&M manual para criação estática de tabelas | |
| Monitoramento e alertas | Monitoramento integrado em todos os processos | Requer ferramentas de terceiros | |
Recursos | Modelos de dados | Valor múltiplo e valor único | Apenas valor único |
| SDK | SDK para Java | Sem SDK para consultas | |
| Tipos de dados | Numérico, booleano e string | Apenas numérico | |
| Consultas SQL | Suportadas | Não suportadas | |
| Suporte a caracteres chineses | Letras e caracteres chineses | Apenas letras | |
| Parâmetro Tags | Opcional | Obrigatório | |
| Máximo de chaves de tag | 16 | 8 | |
| Integração com ecossistema | Integração perfeita com Apache Flink e IoT Platform | Limitada; sem integração nativa com serviços da Alibaba Cloud | |
| Compressão de dados | Algoritmo de compressão dedicado para séries temporais; alta taxa de compressão | Algoritmos de compressão de uso geral; menor taxa de compressão | |
Estabilidade | Isolamento de leitura/gravação | Pools de threads separados para leituras e gravações; desempenho estável sob cargas mistas | Caminhos de leitura e gravação acoplados; exaustão de conexões pode causar falhas |
| Agregação | Agregação em streaming com gerenciamento de memória refinado | Agregação em memória; risco de exceções OutOfMemory | |
Lindorm vs. Elasticsearch and Apache Solr
O LindormSearch é um mecanismo de pesquisa distribuído compatível com a API padrão do Apache Solr. Integra-se ao LindormTable e ao LindormTSDB para fornecer armazenamento e recuperação unificados em vários modelos de dados dentro de um único serviço.
| Recurso | LindormSearch | Elasticsearch de código aberto | Apache Solr | |
|---|---|---|---|---|
Recursos principais | Modelos de dados | Tabelas largas, séries temporais, pesquisa e arquivos; armazena perfeitamente índices de outros mecanismos do Lindorm | Apenas pesquisa | Apenas pesquisa |
| APIs | CQL, Phoenix SQL e API do Solr | API do Elasticsearch | API do Solr | |
| TTL | Granularidade de tabela e coluna | Apenas granularidade de tabela | Apenas granularidade de tabela | |
| Armazenamento e recuperação unificados | Integrado ao LindormTable e LindormTSDB para consultas entre modelos | Não suportado | Não suportado | |
Desempenho e custo | Throughput | 130%–200% do Apache Solr | Sem dados disponíveis | Linha de base |
| Custo de armazenamento | Até 80% menor que discos em nuvem autogerenciados; as especificações de armazenamento incluem Performance, Standard e Capacity | Discos locais ou em nuvem autogerenciados; sem dimensionamento elástico | Discos locais ou em nuvem autogerenciados; sem dimensionamento elástico | |
| Separação de computação e armazenamento | Suportada; dimensione armazenamento e computação independentemente | Não suportada | Não suportada | |
| Compressão de dados | Algoritmo otimizado integrado; taxa de compressão superior a 10:1, mais de 50% maior que a do Snappy | Não suportada | Não suportada | |
| Separação de dados quentes e frios | Fragmentação automática baseada em tempo; mídia econômica para dados frios | Não suportada | Não suportada | |
Elasticidade | Escalabilidade de armazenamento | Alta; desacople o armazenamento da computação e escale vertical ou horizontalmente com poucos cliques; o armazenamento escala em segundos, a computação em minutos | Baixa; requer migração de dados antes do scale-out; o scale-out leva horas | Baixa; requer migração de dados antes do scale-out; o scale-out leva horas |
| Réplicas somente leitura | Cada shard suporta uma primária e várias réplicas somente leitura; adicione réplicas em segundos | Suportado, mas requer migração de dados; leva horas | Suportado, mas requer migração de dados; leva horas | |
Ecossistema | Migração de dados | Migração online e automatizada do Apache Solr ou Elasticsearch de código aberto; sem alterações no código da aplicação. Consulte Visão geral. | Apenas migração offline | Apenas migração offline |
| Sincronização de dados do MySQL | Sincronização completa e incremental do MySQL via LTS. Consulte Visão geral. | Sem ferramentas dedicadas; sem sincronização incremental online | Sem ferramentas dedicadas; sem sincronização incremental online | |
| Integração com Apache Spark | Integração profunda: análise Spark SQL, sincronização incremental e gravação de resultados de volta no Lindorm | Integração manual que exige esforço significativo de desenvolvimento | Integração manual que exige esforço significativo de desenvolvimento | |
| Integração com MaxCompute | Arquivamento incremental de dados do Lindorm para o MaxCompute | Integração manual que exige esforço significativo de desenvolvimento | Integração manual que exige esforço significativo de desenvolvimento | |
| Integração com SLS | Assine dados em tempo real do SLS e importe para o Lindorm. Consulte Visão geral. | Integração manual que exige esforço significativo de desenvolvimento | Integração manual que exige esforço significativo de desenvolvimento | |
Capacidades do serviço | SLA | 99,9% para implantação em cluster único; 99,99% para implantação em cluster duplo | Nenhum SLA fornecido | Nenhum SLA fornecido |
| Custos de O&M | Totalmente gerenciado | Sem dados disponíveis | Sem dados disponíveis | |
| Suporte técnico | Equipe especializada incluindo membros e committers do Apache PMC | Sem suporte dedicado | Sem suporte dedicado | |
| Histórico em produção | Dezenas de milhares de instâncias suportando cargas de trabalho do Alibaba Group em nove edições do Tmall Double 11 Shopping Festival | Nenhum | Nenhum | |
Lindorm vs. HDFS
O LindormDFS é um mecanismo de armazenamento de arquivos nativo da nuvem compatível com os protocolos do Hadoop Distributed File System (HDFS). Desacopla o armazenamento da computação, permitindo dimensionamento elástico e armazenamento em camadas sem a complexidade operacional do HDFS autogerenciado.
| Recurso | LindormDFS | HDFS de código aberto | |
|---|---|---|---|
Compatibilidade com HDFS | Compatibilidade com protocolo HDFS | Suportada | Suportada |
| APIs básicas de leitura/gravação | Totalmente suportadas | Totalmente suportadas | |
| APIs avançadas de gerenciamento | Totalmente suportadas | Totalmente suportadas | |
Custo | Preço unitário de armazenamento (os preços reais na página de compra prevalecem) |
A partir de 0.019 USD/GB/mês |
A partir de 0.023 USD/GB/mês |
| Dimensionamento de armazenamento | Dimensionamento online suave sem tamanho mínimo de etapa | Alto custo mínimo por etapa de dimensionamento; tamanhos de etapa grandes | |
| Separação de computação e armazenamento | Suportada; armazenamento e computação escalam independentemente | Não suportada; armazenamento e computação são coimplantados | |
| Separação de dados quentes e frios | Armazenamento em camadas automático; dados quentes e frios armazenados em mídias diferentes | Não suportada | |
Extensibilidade | Máximo de nós | Sem limite | 0–1.000 |
| Capacidade de armazenamento | 0–1 EB | 0–10 PB | |
| Máximo de arquivos | Centenas de bilhões | Dezenas de milhões | |
| Ecossistema | Integra-se ao ecossistema de dados da Alibaba Cloud e a ecossistemas de big data de código aberto, incluindo Apache Hadoop e Apache Spark | Integra-se a ecossistemas de big data de código aberto, incluindo Apache Hadoop e Apache Spark | |
| Manutenção | Livre de O&M; operação simples | Serviço com estado; requer manutenção complexa | |