Os 4 melhores bancos de dados de código aberto que você deve considerar para seu próximo projeto

MongoDB MongoDB é um banco de dados NoSQL orientado a documentos perfeito para armazenar dados de sites, gerenciamento de conteúdo e armazenamento em cache. Há uma lista de razões pelas quais este banco de dados é tão popular: mongodb – É altamente flexível e escalável. É também altamente expansível de acordo com o crescimento de dados – MongoDB é ágil e orientado ao desempenho. Aspectos como a alta disponibilidade através de WANs e LANs, suporte completo a index, fácil replicação, escalonamento horizontal e queries ricas baseadas em documentos impulsionam ainda mais seu desempenho – MongoDB é feito basicamente para atender a uma variedade de aplicações – MongoDB permite aos usuários trabalhar facilmente com diversos conjuntos de dados (data sets) graças a seu modelo de dados flexível – Baixa curva de aprendizado – MongoDB pode lidar com queries complexas, mas não está preparado para lidar com workloads tipo queries de relatório (reporting style queries) – A simplicidade por si só torna este banco de dados excelente para aqueles que querem começar um novo projeto

Couchbase

Levou um tempo até o Couchbase tornar-se um banco de dados completo, mas, agora que tornou-se mais conhecido do público, pode acabar ofuscando o MongoDB. Suas vantagens: couchbase– Se você deseja um armazenamento operacional de dados altamente escalável, Couchbase é uma boa escolha, pois é possível integrá-lo ao Hadoop – O servidor Couchbase é um banco de dados NoSQL de código aberto, distribuído e orientado a documentos que garante queries em ritmo acelerado, por um lado, e também um mecanismo de query separado para a execução de queries similares ao SQL – É ótimo para dispositivos móveis e de Internet das Coisas, uma vez que está equipado para permitir sincronização nativa no dispositivo e no lado do servidor – Para aplicativos interativos escaláveis, o Couchbase Server oferece gerenciamento de dados de baixa latência – Com Couchbase o usuário tem um modelo de dados altamente flexível e esquemas muito dinâmicos – Possui uma linguagem de query muito poderosa – É conhecido por possuir uma baixa latência excepcional – A arquitetura do próprio banco de dados garante que os workloads sejam distribuídos uniformemente sobre os nós do cluster – O recurso de replicação é built-in e inicia-se automaticamente – Couchbase é uma boa escolha se o gerenciamento simples é o objetivo do usuário – Todos os tipos de operações podem ser realizadas enquanto o sistema permanece online

OrientDB

Velocidade e flexibilidade não são tão comuns entre os produtos de serviços de gerenciamento de banco de dados, e é por esse motivo que o OrientDB nasceu. Ele é único no sentido de oferecer o melhor dos dois mundos: banco de dados de documentos e dados de grafos. orientdb_logo_2x11 – É o primeiro do seu tipo (open source, banco de dados NoSQL multi-modelo) para combinar de forma única as vantagens dos grafos com documentação flexível – Também suporta relacionamentos. Isso significa que o OrientDB funciona bem com estratégias de Big Data – Oferece flexibilidade sem precedentes, o que significa que o usuário não precisa implementar vários produtos – Configuração zero e suporte a arquitetura multi-master – Oferece confiabilidade infalível – OrientDB é ideal para a nuvem no compartilhamento entre centenas de servidores – É fácil de aprender, fácil de usar e fácil de instalar. O OrientDB está escrito inteiramente em Java

Cassandra

Cassandra é basicamente um projeto da Apache Software Foundation. É particularmente conhecido pelo armazenamento de dados altamente descentralizado, com um alto nível de tolerância a falhas e nenhuma falha de instâncias. Cassandra é ideal para aplicativos que não podem se dar ao “luxo” de perder dados. 2000px-Cassandra_logo.svg– A simplicidade é o melhor argumento de venda do Cassandra. É conhecida tanto pela simplicidade de desenvolvimento como pela simplicidade operacional – Cassandra é particularmente conhecida por sua facilidade de gerenciamento para escalonar – Possui o suporte de vários centros de dados – Oferece facilidade incomparável de escalonamento – Outro grande benefício do Cassandra é o desempenho previsível de query – Pode-se facilmente aprender o core do Cassandra em não mais que três ou quatro horas Todos os bancos de dados mencionados acima contemplam uma abordagem simples e oferecem a quantidade ideal de simplicidade para iniciantes. Ritmo, desempenho, confiabilidade, flexibilidade e alta facilidade de uso são apenas algumas das razões pelas quais qualquer um desses quatro exemplos é uma ótima escolha. Curtiu o conteúdo? Então, caso você queira entender mais sobre NoSQL e Persistência Poliglota, assista ao vídeo com o CEO da Propus Data Science, Carlos Eurico do Canto. ]]>

MongoDB 4.0 – Transacional com garantias de integridade ACID

Diagrama de atualizações do MongoDB. A versão 4.0 será lançada no verão 2018 (USA).[/caption]   Como os documentos podem reunir dados relacionados que seriam modelados em diversas tabelas  num esquema relacional, as operações atômicas de documentos únicos do MongoDB já fornecem semânticas de transações que atendem às necessidades de integridade de dados da maioria das aplicações. Mas as transações de documentos múltiplos tornarão mais fácil do que nunca os desenvolvedores abordar uma gama completa de casos de uso. Com o MongoDB 4.0, você poderá confiar na integridade transacional, independentemente de como você o modelo dos seus dados A disponibilização de transações é o resultado de um esforço de engenharia de vários anos, iniciado há mais de 3 anos com a integração do mecanismo de armazenamento WiredTiger quando foram estabelecidas as bases  – desde a camada de armazenamento em si, até o protocolo de replicação, para a arquitetura em sharding. Você pode ler o artigo original escrito por Eliot Horowitz acessando o link  MongoDB Drops ACID. Eliot Horowitz é o CTO e co-fundador da MongoDB Inc,  ]]>

AWS implementa migração de bancos de dados MongoDB para DynamoDB

O provedor de infraestrutura de nuvem pública Amazon Web Services (AWS) anunciou hoje um aprimoramento do Database Migration Service (DMS). O DMS agora suporta a migração de bancos de dados NoSQL em geral, informa a AWS em uma postagem no blog oficial. A partir de agora será possível mover os bancos de dados mantidos no banco de dados NoSQL MongoDB no próprio serviço proprietário do DynamicDB gerenciado pela AWS com a ajuda do DMS. Atualmente, o DMS pode trabalhar com bancos de dados Oracle, Microsoft SQL Server, MySQL, Amazon Aurora, PostgreSQL e SAP ASE. A AWS introduziu o DMS e a ferramenta Schema Conversion Tool em 2015. Em dezembro, o CEO da AWS, Andy Jassy, anunciou que o DMS havia realizado 16.000 migrações em 2016. “No total, já foram mais de 22.000 migrações”, conforme revelou Jassy em um tweet no mês passado. Em fevereiro, a AWS anunciou que a ferramenta Schema Conversion poderia levar dados de data warehouses da Oracle e Teradata e prepará-los para serem aproveitados pelo serviço de armazenamento de dados do Redshift da AWS. O MongoDB já foi uma tecnologia muito conhecida entre os desenvolvedores. A empresa de mesmo nome oferece uma versão gerenciada do banco de dados hospedado na AWS. Agora, a AWS será capaz de obter receitas onde as organizações antes usavam o banco de dados MongoDB em seus datacenters on-premise. Em outras palavras, a AWS agora está desafiando seu próprio cliente, e não é a primeira vez que isso acontece. Clique aqui para acessar a documentação de migração do MongoDB para o DynamoDB. Fonte: VentureBeat  ]]>

Construindo aplicativos com engines de armazenamento MongoDB plugáveis (Parte 2)

No post anterior, foram descritas a arquitetura e características das engines de armazenamento MongoDB plugáveis. Neste post, será detalhado como selecionar qual engine de armazenamento usar, e como mesclar e combinar engines de armazenamento em um replica set.

Como selecionar qual engine de armazenamento usar

Workloads WiredTiger

O WiredTiger será o engine de armazenamento preferencial para a maioria das workloads. A concorrência do WiredTiger e a excelente transferência de leitura e escrita são bem adequadas para aplicações que exigem alta performance, tais como:
  • Aplicativos IoT: sensor de ingestão de dados e análise
  • Gerenciamento de dados do cliente e aplicativos sociais: atualiza todas as interações e engajamento do usuário de vários fluxos de atividade
  • Catálogos de produtos, gerenciamento de conteúdo e análise em tempo real
Para a maioria das workloads, é recomendado o uso do WiredTiger. No decorrer deste artigo serão analisadas situações em que outros engines de armazenamento possam ser aplicáveis.

Workloads criptografados

O Encrypted Storage Engine é ideal para ser usado por instituições regulamentadas como as das áreas de finanças, varejo, saúde, educação e governo. Organizações que precisam criar aplicativos compatíveis com iniciativas regulatórias podem usar o Encrypted Storage Engine com recursos de segurança nativos do MongoDB, como controles de acesso, autenticação, autorização e auditoria para atingir a conformidade. Antes do MongoDB 3.2, os principais métodos para fornecer criptografia em repouso eram usar aplicativos de terceiros que criptografavam arquivos no aplicativo, no sistema de arquivos, ou em nível de disco. Esses métodos funcionam bem com MongoDB, mas tendem a adicionar um custo extra: a complexidade e a sobrecarga. O Encrypted Storage Engine acrescenta aproximadamente 15% de sobrecarga em comparação com o WiredTiger, uma vez que ciclos de CPU disponíveis são alocados para o processo de criptografia/descriptografia – embora o impacto real dependa do data set e do workload. Isso ainda é significativamente menos em comparação com a disco de terceiros ou criptografia de sistema de arquivos, onde os usuários têm notado 25% ou mais de sobrecarga. O Encrypted Storage Engine, combinado com recursos de segurança nativos do MongoDB, como autenticação, autorização e auditoria, proporciona uma solução de segurança de ponta a ponta para proteger os dados com o menor impacto de desempenho.

Workloads In-Memory

As vantagens da computação em memória são bem conhecidas. Os dados podem ser acessados na RAM cerca de 100.000 vezes mais rapidamente do que recuperados do disco, entregando desempenho em ordens de grandeza maiores para aplicações mais exigentes. Com os valores de RAM em declínio e novas tecnologias como memória 3D não-volátil no horizonte, os ganhos em desempenho podem agora ser consumados com a melhoria e aprimoramento de economia como nunca antes. Não só o acesso rápido é importante, mas o acesso previsível, ou latência, é essencial para certas aplicações modernas. Por exemplo, aplicações financeiras comerciais precisam responder rapidamente às condições flutuação de mercado na medida em que os dados fluem através dos sistemas de negociação. A latência imprevisível de valores extremos pode significar a diferença entre ganhar ou perder milhões de dólares. Enquanto o WiredTiger será mais do que capaz para a maioria dos casos de uso, aplicações que requerem latência previsível se beneficiarão do In-Memory Storage Engine. As empresas podem aproveitar o poder das capacidades centrais do MongoDB – linguagem query expressiva, índices primários e secundários, escalabilidade, alta disponibilidade – com os benefícios da latência previsível do In-Memory Storage Engine. Alguns exemplos de quando usá-lo: Na área financeira 
  • Aplicações de transação algorítmica que são altamente sensíveis à latência previsível; como quando picos de latência de elevados volumes de tráfego podem sobrecarregar um sistema de negociação e fazer com que as transações sejam perdidas ou exigir a retransmissão.
  • Sistemas de monitoramento em tempo real que detectam anomalias, tais como fraudes
  • Aplicações que requerem latência previsível para o processamento de ordens de negócio, autorizações de cartão de crédito e outras transações de alto volume.
Na área governamental
  • Aplicações de analytics e de sensores de gerenciamento de dados interessadas em eventos correlacionados espacialmente e temporalmente que precisam ser contextualizados com fontes em tempo real (tempo, redes sociais, tráfego etc).
  • Detecção de ameaças de segurança
No e-commerce/varejo
  • Dados da sessão de perfis de clientes durante uma compra
  • Cache de busca por produtos
  • Recomendações personalizadas em tempo real
Em jogos online
  • Cache de dados do jogador
Em telecomunicações
  • Processamento em tempo real e cache de informações de clientes e planos de dados
  • Monitoramento do uso da rede para milhões de usuários e execução de ações em tempo real, tais como faturamento
  • Gerenciamento de sessões de usuário em tempo real para criar experiências personalizadas em qualquer dispositivo móvel
 

Workloads MMAPv1

Embora o WiredTiger seja mais adequado para a maioria das workloads de aplicativos, existem certas situações em que os usuários podem preferir permanecer no MMAPv1: Workloads legados: Organizações que tem se atualizado para os últimos lançamentos do MongoDB (3.0 e 3.2) e não querem requalificar suas aplicações com uma nova engine de armazenamento podem preferir permanecer com o MMAPv1. Versão downgrade: O processo de atualização do MMAP/MMAPv1 para o WiredTiger é um simples upgrade “drop in” binário compatível, mas uma vez atualizado para o MongoDB 3.0 ou 3.2 os usuários não podem fazer o downgrade para uma versão inferior a 2.6.8. Isso deve ser levado em conta por usuários que desejam permanecer na versão 2.6. Houve muitos recursos adicionais incluídos no MongoDB desde a versão 2.6, portanto, é altamente recomendável atualizar para a versão 3.2.

Casos de uso de engines de armazenamento mistas

A arquitetura de armazenamento flexível do MongoDB fornece uma opção poderosa para otimizar o banco de dados. As engines de armazenamento podem ser mescladas e combinadas em um único cluster MongoDB para atender às diversas necessidades de aplicação para os dados. Os usuários podem avaliar diferentes engines de armazenamento sem afetar as implementações e também podem migrar facilmente e atualizar para uma nova engine de armazenamento seguindo o processo de atualização sequencial. Para simplificar este processo ainda mais, os usuários podem utilizar o Ops manager ou Cloud manager para atualizar a versão do cluster MongoDB através de um clique de botão. Embora existam muitas configurações mistas de armazenamento possíveis, estes são alguns exemplos de configurações mistas de engine de armazenamento com as engines In-memory e WiredTiger. [caption id="attachment_608" align="aligncenter" width="916"]ecommerce-app-mongodb Figura 10: Aplicação de e-commerce com engines de armazenamento mistas.[/caption] Uma vez que o In-Memory Storage Engine não persiste dados como um nó independente, ele pode ser usado com outra engine de armazenamento para persistir os dados em uma configuração mista de engine de armazenamento. A aplicação eCommerce na Figura 10 utiliza dois clusters fragmentados com três nós (um primário, dois secundários) em cada cluster. O replica set com o In-Memory engine como o nó principal fornece acesso de baixa latência e alta taxa de transferência de dados ao usuário temporário, tais como informações de sessão, itens do carrinho de compras e recomendações. O catálogo de produtos da aplicação é armazenado no cluster fragmentado com WiredTiger como o nó primário. Para pesquisas de produto pode-se usar o cache em memória do WiredTiger para acesso de baixa latência. Se os requisitos de armazenamento de dados do catálogo do produto exceder a capacidade de memória do servidor, os dados podem ser armazenados e recuperados do disco. Esta abordagem em camadas permite que os dados “quentes” sejam acessados e modificados de forma rápida e em tempo real, enquanto há persistência de dados “frios” no disco. A configuração na Figura 11 demonstra como preservar as capacidades de baixa latência em um cluster após o failover. Definir priority=1 no nó In-Memory secundário irá resultar em failover automático para o secundário, e eliminará a necessidade de repopular por completo o primário quando voltar online. Além disso, se os dados temporários necessitam de persistência, então um nó secundário WiredTiger pode ser configurado para atuar como uma réplica, proporcionando elevada disponibilidade e durabilidade de disco. [caption id="attachment_609" align="aligncenter" width="481"]mixed-storage-mongodb Figura 11: Engines de armazenamento mistas, com WiredTiger secundário oculto.[/caption] Para proporcionar ainda maior disponibilidade e durabilidade, 5 nós de replica set com 2 nós In-Memory e 3 nós WiredTiger podem ser usados. Na Figura 12, a engine In-Memory é o nó principal, com quatro nós secundários. Se ocorrer uma falha no primeiro, o nó secundário In-Memory irá passar por failover automático como o nó primário, e não haverá necessidade de repopular o cache. Se o novo nó primário In-Memory também falhar, então o replica set elegerá um nó WiredTiger como primário. Isso reduz qualquer interrupção no funcionamento, já que os clientes ainda serão capazes de escrever sem interrupção para o novo nó primário WiredTiger. [caption id="attachment_610" align="aligncenter" width="453"]mixed-storage-mongodb-5-node Figura 12: Engines de armazenamento mistas com replica set de 5 nós[/caption]   Além disso, uma abordagem mista da engine de armazenamento é ideal para uma arquitetura de microserviço. Em uma arquitetura de microserviço, um banco de dados compartilhado entre os serviços pode afetar vários serviços e desacelerar o desenvolvimento. Ao desvincular o banco de dados e selecionar as engines de armazenamento adequadas para workloads específicos, as empresas podem melhorar o desempenho e desenvolver recursos para serviços individuais rapidamente.

Conclusão

O MongoDB é o banco de dados de última geração usado pelas mais diversas e sofisticadas organizações no mundo, de startups de ponta a grandes empresas, para criar aplicações em uma fração de custo de bancos de dados legados como nunca antes. Com APIs de engine de armazenamento plugáveis, o MongoDB continua a inovar e fornecer aos usuários a capacidade de escolher as engines de armazenamento ideais para suas cargas de trabalho. Agora, as empresas têm em mãos um ecossistema ainda mais rico de opções de armazenamento para resolver novas classes de casos de uso com um único framework de banco de dados. Fonte: Dzone.com ]]>

Construindo aplicativos com engines de armazenamento MongoDB plugáveis (Parte 1)

Com os usuários criando aplicativos data-driven (ou “controlados por dados”) cada vez mais complexos, já não há uma tecnologia de armazenamento de banco de dados “one size fits all” capaz de alimentar todo o tipo de aplicativo construído para as empresas. Os aplicativos modernos precisam suportar uma variedade de cargas de trabalho com diferentes padrões de acesso e perfis de preço/desempenho – desde apps de baixa latência, leitura e escrita in-memory a analytics em tempo real e arquivos comprimidos altamente “ativos”. Através da utilização de engines de armazenamento plugáveis, o MongoDB pode ser estendido com novas capacidades, e configurado para uso otimizado de arquiteturas de hardware específicas. Essa abordagem reduz significativamente a complexidade entre o operacional e o desenvolvedor quando comparada à execução de múltiplas tecnologias de banco de dados. As engines de armazenamento podem ser mescladas no mesmo replica set ou sharded cluster. Os usuários também podem usar a mesma linguagem de consulta do MongoDB, o modelo de dados, a escala, a segurança e ferramentas operacionais em diferentes aplicativos, cada um alimentado por diversas engines de armazenamento MongoDB conectáveis. storageenginemongodb O MongoDB 3.2 vem com 4 engines de armazenamento suportadas que podem ser otimizadas para cargas de trabalho específicas:

  • A engine de armazenamento padrão WiredTiger (WiredTiger Storage Engine). Para a maioria das aplicações, o controle de concorrência granular do WiredTiger e a compressão nativa proverão o melhor desempenho e eficiência de um armazenamento completo.
  • A engine de armazenamento encriptada (Encrypted Storage Engine), que protege dados altamente sensíveis, sem o desempenho ou a sobrecarga de gerenciamento de criptografia de sistema de arquivos separados. A Encrypted Storage EMecanismo de Armazenamento CriptografadoMecanismo de Armazenamento Criptografadongine baseia-se no WiredTiger e assim ao longo deste post, declarações relativas ao WiredTiger também se aplicam ao Encrypted storage engine. Essa engine é parte do MongoDB Advanced Enterprise.  
  • A engine de armazenamento in-memory (In-Memory Storage Engine) para aplicativos que possuem SLAs extremamente rigorosos para baixa latência consistente e previsível, embora não exija a durabilidade do disco para os dados. Esta engine é parte do MongoDB Advanced Enterprise.
  • A engine MMAPv1, uma versão melhorada da engine de armazenamento usada nos lançamentos MongoDB pré-3.x. O MMAPv1 é a engine de armazenamento padrão no MongoDB 3.0.
O MongoDB permite aos usuários mesclar e combinar várias engines de armazenamento em um único cluster MongoDB. Esta flexibilidade fornece uma abordagem simples e confiável para suportar diversas cargas de trabalho. Tradicionalmente, várias tecnologias de banco de dados são necessárias para gerenciar e atender a essas necessidades, com código complexo e de integração personalizada para mover dados entre as tecnologias, e para assegurar o acesso consistente e seguro. Com arquitetura de armazenamento flexível do MongoDB, o banco de dados gerencia automaticamente o movimento dos dados entre tecnologias de engines de armazenamento usando a replicação nativa. Esta abordagem reduz significativamente a complexidade entre o operacional e o desenvolvedor, quando comparada com a execução de várias tecnologias de banco de dados distintas. storageengine-table_mongodb

WiredTiger Storage Engine

A MongoDB adquiriu a WiredTiger em 2014 e, com ela também os especialistas por trás da engine de armazenamento WiredTiger: os co-fundadores Keith Bostic (criador da Sleepycat Software) e Dr. Michael Cahill e seus colegas. Bostic e Cahill foram os arquitetos originais do Berkeley DB, software de gerenciamento de dados incorporados mais amplamente utilizado no mundo, e têm décadas de experiência escrevendo engines de armazenamento de alto desempenho. A WiredTiger aproveita arquiteturas modernas de hardware e algoritmos de software inovadores para fornecer um desempenho líder na indústria às aplicações mais exigentes. O WiredTiger é ideal para uma vasta gama de aplicações operacionais e, portanto, é também a engine de armazenamento padrão do MongoDB. Deve ser o ponto de partida para todas as novas aplicações, com exceção dos casos em que se faz necessário os recursos específicos das engines de armazenamento in-memory ou criptografada. As principais vantagens do WiredTiger incluem: Máximo cache disponível: o WiredTiger maximiza o uso da memória disponível como cache para reduzir os gargalos de I/O. Existem dois caches utilizados: o cache WiredTiger e o cache do sistema de arquivos. O WiredTiger cache armazena dados não comprimidos, fornece desempenho in-memory. O cache do sistema de arquivos armazena dados comprimidos. Quando os dados não são encontrados no cache WiredTiger, o WiredTiger vasculha os dados no cache do sistema de arquivos. Os dados encontrados no cache do sistema de arquivos primeiro passam por um processo de descompressão antes de migrar para o cache do WiredTiger. storageengine-mongodb-3 O cache do WiredTiger executa melhor quando detém o máximo possível do conjunto de trabalho. No entanto, é também importante reservar memória para outros processos que dele necessitam, como o sistema de operação, incluindo o cache de sistema de arquivos. Isto também inclui o próprio MongoDB que, como um todo, consumirá mais memória do que o que está em uso ativo pelo WiredTiger. O MongoDB difere do WiredTiger no tamanho do cache em aproximadamente 60% da RAM. O valor mínimo recomendável para o cache do sistema de arquivos é de 20% da memória disponível. Qualquer coisa menor que isso e o sistema operacional pode ficar limitado de recursos. Alta taxa de transferência (throughput): WiredTiger usa “cópia na escrita” – quando um documento é atualizado o WiredTiger faz uma nova cópia e determina a versão mais recente para retornar ao leitor. Esta abordagem permite que vários clientes modifiquem simultaneamente diferentes documentos em uma coleção, resultando em maior concorrência e throughput. O desempenho ótimo de escrita é alcançado quando um aplicativo está utilizando uma máquina com vários núcleos (quanto mais, melhor), e várias threads estão escrevendo para diferentes documentos. Redução do footprint de armazenamento e melhoria das IOPs de disco: o WiredTiger usa algoritmos de compressão para reduzir a quantidade de dados armazenados em disco. Não só o armazenamento é reduzido, mas o desempenho IOPs é aumentado à medida que menos bits são lidos ou gravados no disco. Alguns tipos de arquivos compactam melhor que outros. Os arquivos de texto são altamente compressíveis, enquanto dados binários podem não ser tão compressíveis, uma vez que já podem ser codificados e comprimidos. O WiredTiger incorre em ciclos de CPU adicionais ao utilizar a compressão, mas os usuários podem configurar esquemas de compressão para otimizar a sobrecarga da CPU x taxa de compressão. O Snappy, que é a engine de compressão padrão, proporciona um bom equilíbrio entre a alta taxa de compressão com baixa sobrecarga da CPU. O Zlib vai conseguir maiores taxas de compressão, mas incorrer em ciclos de CPU adicionais. Compressão (index e journals): O index pode ser comprimido tanto na memória como no disco. O WiredTiger utiliza a compressão de prefixo para comprimir índices, conservando o uso de RAM, bem como liberando IOPs de armazenamento. Journals são compactados por padrão com compressão Snappy. Escalabilidade multi-core: na medida em que fabricantes de CPU encolher litografias e o consumo de energia passa a se tornar um problema, as tendências de processadores mudaram para arquiteturas multi-core, a fim de sustentar a cadência da lei de Moore. O WiredTiger foi projetado com modernas arquiteturas multi-core em mente, e oferece escalabilidade em sistemas multi-core. Programar técnicas, tais como hazard pointers, algoritmos sem bloqueio, e o rápido travamento minimizam a contenção entre threads. As threads podem executar operações sem bloquear umas às outras – resultando em menos contenção de thread, melhor concorrência e maior throughput. Read concern: o WiredTiger permite aos usuários especificar um nível de isolamento para suas leituras. As operações de leitura podem retornar uma visualização dos dados que foram aceitos ou comitados no disco por uma maioria no replica set. Isto fornece uma garantia de que os aplicativos apenas leiam os dados que irão persistir em caso de falha e não serão revertidos quando um novo membro do replica set for promovido a primário. Para mais informações sobre a migração do MMAP/MMAPv1 para WiredTiger, consulte a documentação oficial do MongoDB.

Encrypted Storage Engine

A segurança dos dados é algo essencial para muitos executivos devido ao aumento dos ataques, bem como a uma série de violações de dados nos últimos anos, com impacto negativo para várias marcas fortemente consolidadas no mercado. Por exemplo, em 2015, uma grande seguradora de saúde nos EUA foi vítima de uma violação de dados em massa em que os criminosos obtiveram acesso aos dados de mais de 80 milhões de pessoas – o que resultou em um prejuízo estimado em US$ 100 milhões. No final, uma das vulnerabilidades críticas foi o fato dos corretores de saúde não criptografarem os dados sensíveis dos pacientes armazenados em repouso no banco. Juntamente com extensas capacidades de controle de acesso e auditoria do MongoDB, a criptografia é um componente vital na construção de aplicações que estejam em conformidade com as normas HIPAA, FERPA, PCI, SOX, GLBA, ISO 27001 etc. O Encrypted storage engine é baseado no WiredTiger, e, portanto, é projetado para a eficiência operacional e desempenho:
  • Nível de controle de concorrência de documento e compressão
  • Suporte para CPUs equipadas com AES-NI da Intel para a aceleração do processo de criptografia/decriptografia
  • Conforme os documentos são modificados, somente os blocos de armazenamento atualizados precisam ser criptografados, em vez de toda a base de dados.
Com o Encrypted storage engine, a proteção dos dados em repouso é uma característica integrante da base de dados. O conteúdo do banco de dados em “texto simples” é criptografado usando um algoritmo que leva uma chave de criptografia aleatória como entrada e gera texto cifrado que só pode ser decriptografado com a chave adequada. O Encrypted Storage Engine suporta uma variedade de algoritmos de criptografia da biblioteca OpenSSL. O AES-256 no modo CBC é o padrão, enquanto outras opções incluem AES-256 no modo GCM, bem como o modo FIPS para FIPS-140-2. A criptografia é realizada em nível de página para fornecer o desempenho ideal. Em vez de ter que criptografar/decriptografar o arquivo inteiro ou o banco de dados para cada alteração, apenas as páginas alteradas precisam ser criptografadas ou decriptografadas, resultando em menos sobrecarga e maior desempenho. Além disso, o Encrypted Storage Engine fornece gerenciamento seguro das chaves de criptografia. Cada nó codificado contém uma chave interna do banco de dados que é utilizada para encriptar ou desencriptar os arquivos de dados. A chave interna do banco de dados é envolvida com uma chave mestra externa, que deve ser fornecida ao nó para que este inicialize. Para garantir que as chaves nunca são escritas ou paginadas para o disco em forma não criptografada, o MongoDB usa mecanismos de proteção do sistema operacional, como o VirtualLock e o mlock, para travar o processo de espaço de memória virtual na memória. Há duas maneiras principais de gerenciar a chave mestra: através de uma integração com um dispositivo de gerenciamento de chave de terceiros via Key Management Interoperability Protocol (KMIP) ou do gerenciamento de chaves local através de um keyfile. A maioria dos requisitos regulatórios recomendam que as chaves de encriptação sejam rotacionadas e substituídas por uma nova chave pelo menos uma vez por ano. O MongoDB pode efetuar a rotação da chave sem incorrer em tempo de inatividade através de reinicializações de rolamento do replica set. Ao usar um appliance KMIP, os próprios arquivos do banco de dados não precisam ser recriptografados, evitando assim a sobrecarga de desempenho significativa imposta pela rotação da chave em outros bancos de dados. Apenas a chave mestra é rotacionada, e o armazenamento de chaves do banco de dados interno é recriptografado. Recomenda-se a utilização de um appliance KMIP com o Encrypted Storage Engine.

In-Memory Storage Engine

Em aplicações modernas, diferentes subconjuntos de dados de aplicativos contemplam diferentes requisitos de latência e durabilidade. A opção do In-Memory Storage Engine foi criada para aplicações que possuem SLAs extremamente críticos mesmo em 99º percentis. O In-Memory Storage Engine manterá todos os dados na memória, e não irá escrever nada no disco. Os dados sempre tem que ser populados na inicialização, e nada pode ser assumido na reinicialização, incluindo dados de aplicativo e dados do sistema (ou seja, usuários, permissões, definições de índice, oplog etc). Todos os dados devem se encaixar no tamanho do cache in-memory especificado. O In-Memory Storage Engine combina os benefícios de latência previsíveis de um “in memory cache” com as queries ricas e capacidades analíticas do MongoDB. Ele tem a vantagem de usar exatamente as mesmas APIs que qualquer outro servidor MongoDB para que os aplicativos não precisem de código especial para interagir com o cache, como lidar com a invalidação de cache quando os dados são atualizados. Além disso, um mongod que está configurado no In-Memory storage engine pode ser parte de um replica set e, portanto, pode ter outro nó no mesmo replica set suportado pelo armazenamento persistente rápido. O In-Memory engine é atualmente suportado no MongoDB 3.2.6+. Para métricas de desempenho no In-Memory storage engine, consulte a documentação técnica do MongoDB Pluggable Storage Engine. Para aplicações que exijam latências previsíveis, o In-Memory engine é o mecanismo de armazenamento recomendado, pois fornece baixa latência enquanto também minimiza tail latencies, resultando em alta performance e uma experiência de usuário consistente. Alguns dos principais benefícios do In-Memory Engine:
  • Latência previsível e consistente para aplicações que querem minimizar picos de latência
  • Os aplicativos podem combinar camadas de armazenamento em cache e banco de dados separados em uma única camada – todos acessados e gerenciados com as mesmas APIs, ferramentas operacionais e controles de segurança
  • Redundância de dados com o uso de um nó secundário WiredTiger em um replica set

MMAPv1 Storage Engine

A engine MMAPv1 é uma versão aprimorada da engine de armazenamento usada nos releases MongoDB pré-3.x. Ela utiliza a simultaneidade em nível de coleção e arquivos de memória mapeada para acessar o armazenamento de dados subjacente. O gerenciamento de memória é delegado ao sistema operacional. Isso evita a compressão dos dados coletados, apesar dos journals estarem comprimidos pelo Snappy. Na segunda parte desta série, vamos discutir como selecionar qual engine de armazenamento usar em cada caso. Fonte: DZone.com]]>