Mnesia: vantagens e diferenças

Quais são as vantagens do Mnesia em relação às principais implementações de bancos de dados SQL e como elas diferem para elas?

Posso usar o banco de dados para armazenar grandes quantidades de dados sem degradação perceptível no desempenho?

Desculpe por chegar atrasado à festa. :) Aqui está a minha resposta, com base no uso do Mnesia desde 1996 e em várias outras tecnologias de banco de dados desde 1988.

Mnesia e MySQL são realmente bestas diferentes, e qual é a melhor depende muito de como você pretende usá-lo.

Se o seu aplicativo estiver escrito em Erlang, o Mnesia permitirá que você armazene os dados no mesmo espaço de memória do seu aplicativo, o que significa que você pode buscar um único objeto de dados tão rapidamente quanto alguns microssegundos. Isso não é possível no MySQL, pois seu aplicativo e o banco de dados serão separados na memória. A razão pela qual o Mnesia pode fazer isso e ainda ser robusto é que Erlang implementa a 'proteção' da memória no nível do idioma.

No geral, os bancos de dados SQL tendem a favorecer a taxa de transferência sobre a latência e, quando se trata de latência, o Mnesia + Erlang geralmente é excelente. Você precisa decidir qual é o mais importante para você. Como diz a documentação (acima), os aplicativos de destino da Mnesia eram aplicativos de comutação de telecomunicações, onde os requisitos de tempo de resposta para, por exemplo, uma configuração de chamada, eram de aproximadamente 20 ms. Essencialmente, isso significava que você poderia ler do banco de dados apenas se os dados estivessem na memória compartilhada, mas evitaria gravar no armazenamento persistente com base na configuração por chamada. OTOH, esses aplicativos praticamente não precisam de suporte a consultas ad-hoc e não usam conjuntos de dados muito grandes. Algum trabalho foi feito para estender a adequação do Mnesia a outros domínios, mas isso não é uma prioridade para a equipe de desenvolvimento do Erlang / OTP. Mnesia é o que é e é provável que continue assim.

No link acima, onde Mnesia e MySQL são comparados em termos de velocidade, é preciso lembrar que está no eJabberd, que roda em um único servidor se for MySQL e executa um banco de dados totalmente replicado se for Mnesia - e grandes clusters de eJabberd podem ter até 10 ou mais nós erlang (e, portanto, 10 ou mais réplicas de Mnesia). Do ponto de vista da redundância, isso é bastante ridículo e caro, e o Mnesia de maneira alguma o obriga a fazê-lo. Obviamente, ele fornece leituras rápidas em cada nó, mas as gravações serão muito caras. Várias comparações que li acabaram comparando Mnesia distribuído com um MySQL de nó único; se a redundância não é necessária para o MySQL, também não deve ser necessária para o Mnesia. Mnesia é bastante flexível ao permitir que você escolha padrões de replicação, e a localização dos dados é transparente para o aplicativo.

Mnesia também não se limita a 2 GB por tabela (embora uma opção de armazenamento específica seja). O maior banco de dados de Mnesia que eu conheço tem cerca de 600 GB de dados em disco (RAM + 64 bits) - embora eu não recomende isso. Qualquer coisa de até 10 a 20 GB deve estar perfeitamente bem com o hardware moderno, mas pule inteiramente o disc_only_copies e use disc_copies - compre mais RAM, se necessário. Eu pensaria duas vezes antes de usar o suporte de sharding (mnesia_frag) - funciona, mas raramente vale a pena.

Talvez a maior diferença entre o Mnesia e o MySQL seja o próprio SQL: o Mnesia realmente não tem funcionalidade comparável; O QLC oferece algum suporte para consultas ad-hoc, mas não está na mesma liga que o SQL, nem o nível de otimização de consultas. Em ferramentas e provisionamento, o MySQL também é superior e, se você precisar de análises, não há dúvida de qual escolher (por exemplo, NÃO Mnésia).

A melhor maneira de visualizar o Mnesia é como uma extensão do idioma Erlang. Ele coloca os dados na ponta dos dedos e é excelente para pequenos conjuntos de dados em que a estrutura de dados e os padrões de acesso são bem conhecidos. Para esse propósito, usar o MySQL é tão desconfortável quanto usar o Mnesia para as coisas em que o MySQL funciona melhor.

A maioria dos aplicativos se enquadra em algum ponto intermediário, e é aqui que se torna uma chamada de julgamento. Você pode acabar usando os dois ...

A partir da documentação :

Mnesia é um sistema de gerenciamento de banco de dados distribuído, apropriado para aplicativos de telecomunicações e outros aplicativos Erlang que exigem operação contínua e propriedades leves em tempo real. É uma seção da Open Telecom Platform (OTP), que é uma plataforma de sistema de controle para a construção de aplicativos de telecomunicações.

Em particular, o nível muito alto de tolerância a falhas exigido em muitos sistemas ininterruptos, combinado com os requisitos no DBMS para serem executados no mesmo espaço de endereço que o aplicativo, nos levaram a implementar um novo DBMS. chamado Mnesia. O Mnesia é implementado na linguagem de programação Erlang, e muito estreitamente conectado, e fornece a funcionalidade necessária para a implementação de sistemas de telecomunicações tolerantes a falhas. Mnesia é um DBMS distribuído para vários usuários, criado especialmente para aplicativos de telecomunicações industriais escritos na linguagem de programação simbólica Erlang, que também é a linguagem de destino. Mnesia tenta resolver todos os problemas de gerenciamento de dados exigidos para sistemas de telecomunicações típicos e possui vários recursos que normalmente não são encontrados em bancos de dados tradicionais.

Em aplicativos de telecomunicações, existem necessidades diferentes dos recursos fornecidos pelos DBMSs tradicionais. Os aplicativos agora implementados na linguagem Erlang precisam de uma mistura de uma ampla variedade de recursos, que geralmente não são satisfeitos pelos DBMSs tradicionais. O Mnesia foi projetado com requisitos como o seguinte em mente:

Pesquisa rápida de chave / valor em tempo real

Consultas complicadas não em tempo real, principalmente para operação e manutenção

Dados distribuídos devido a aplicativos distribuídos

Alta tolerância a falhas

Re-configuração dinâmica

Objetos complexos

O que diferencia o Mnesia da maioria dos outros DBMSs é que ele foi projetado com os problemas típicos de gerenciamento de dados dos aplicativos de telecomunicações em mente. Portanto, o Mnesia combina muitos conceitos encontrados em bancos de dados tradicionais, como transações e consultas, com conceitos encontrados em sistemas de gerenciamento de dados para aplicativos de telecomunicações, como operações em tempo real muito rápidas, grau configurável de tolerância a falhas (por meio de replicação) e a capacidade de reconfigure o sistema sem pará-lo ou suspendê-lo. A Mnesia também é interessante devido ao seu forte acoplamento à linguagem de programação Erlang, quase transformando o Erlang em uma linguagem de programação de banco de dados. Isso tem muitos benefícios, o principal é que a incompatibilidade de impedância entre o formato de dados usado pelo DBMS e o formato de dados usado pela linguagem de programação,

Mnesia versus MySQL, desempenho :

O ejabberd consome menos recursos computacionais ao usar algum banco de dados * SQL do que ao usar Mnesia interno. Você provavelmente está interessado nesse tópico quando possui muitos usuários simultâneos (mais de 1000, por exemplo). Com poucos usuários simultâneos, o consumo de CPU do ejabberd é insignificante, portanto os administradores de pequenos servidores não se importam em configurar um servidor e banco de dados SQL externos.

CouchDB v. Mnesia, V. MySQL e outros tópicos de Mnesia :

Um insight que me veio à mente imediatamente é que, embora tenha sido óbvio para mim como estruturar os dados para o MySQL, isso é menos para o Mnesia e para o CouchDB ainda não tenho certeza da melhor abordagem ainda. Por enquanto, aqui estão alguns dos pontos mais óbvios:

Um 'registro' possui um campo 'numplays' que obviamente indica quantas vezes foi reproduzido. Isso é bom no MySQL, mas se eu apenas incorporar esse campo em um documento para o CouchDB, receberei uma revisão duplicada completa do documento no banco de dados toda vez que esse número for alterado, o que parece muito ineficiente.

O layout de três tabelas no MySQL de registros, tags e uma tabela de links entre eles (veja o script se isso não estiver claro) é (pelo menos para mim) obviamente a solução certa, mas existem muitas maneiras possíveis de fazer isso no Mnesia e no CouchDB, acho que não tenho as respostas intuitivamente.

Em suma, ele foi projetado para fins muito específicos e parece bem projetado para se adequar ao objetivo. Nenhum banco de dados pode ser abstratamente comparado a outro. Somente através do uso de requisitos é possível induzir elementos de comensurabilidade.

Não, eu não diria que Mnesia é bom para grande quantidade de dados. Você pode optar por usar Ets ou Dets como back-end. Se você escolher Ets, seu banco de dados ficará na memória e muito rápido, mas os dados não serão persistentes. E se você deseja que seus dados sejam persistentes (salvos em disco), é necessário usar o Dets, que tem um limite de 2 GB , para que seu banco de dados não possa conter mais de 2 GB de dados.

Você pode usar um back-end personalizado, por exemplo, o innostore usado no banco de dados Riak NoSQL.

As vantagens do Mnesia é que ele é um banco de dados distribuído, portanto é muito fácil executar sistemas tolerantes a falhas se você tiver mais de um computador. E é muito fácil de usar no Erlang, pois é um banco de dados no idioma e age "como uma função". E também é super rápido se você só precisa de um banco de dados na memória, por exemplo, como um cache.