Quais são as vantagens de executar o NoSQL (ex MongoDB) sobre MySQL, PostGRE SQL ou MSSQL no Drupal? As vantagens são obtidas com o simples uso do armazenamento ou alguma configuração do Drupal precisa ser alterada?
Esta é uma pergunta à qual Károly Négyesi daria uma resposta "autorizada". Ele certamente conhece a vantagem de usar o MongoDB com o Drupal.
Kiamlaluno
Leia minha mente .. muito interessado em outras opções se houver benefícios substanciais e, é claro, os profissionais vêm com contras.
18711 Kevin
Respostas:
13
O MongoDB pode ser usado para armazenar a maioria ou todas as suas entidades em um armazenamento rápido e orientado a documentos. Esse tipo de armazenamento é bem melhor do que o armazenamento padrão baseado em SQL que temos no núcleo Drupal (que é baseado no esquema "uma tabela por campo").
No estado atual do Drupal 7, você teria:
A tabela base da entidade armazenada no SQL (ou seja, a tabela de usuários, a tabela de nós etc.)
Todos os campos armazenados no SQL
As propriedades das entidades de suas tabelas base duplicadas no MongoDB
Isso permite consultas rápidas sobre as entidades no MongoDB e a capacidade de adicionar índices complexos aos quais nenhum banco de dados SQL Opensource suporta (incluindo índices entre tabelas). Ao mesmo tempo, você não perde a interoperabilidade porque a tabela base da entidade ainda está armazenada no SQL e, portanto, pode ser unida por módulos que ainda são apenas SQL (como Flag).
Esse tipo de consulta rápida está disponível graças ao mecanismo EntityFieldQuery, uma maneira de criar consultas sobre entidades, suas propriedades e seus campos de maneira abstrata. A implementação padrão no núcleo converte essas consultas para SQL, mas o módulo MongoDB possui uma implementação completa que pode atender diretamente a essas consultas do MongoDB.
Graças ao back-end EntityFieldQuery para Views , você pode aproveitar facilmente esse poder usando as ferramentas às quais está acostumado. A única desvantagem é que os relacionamentos não são suportados (mas, na prática, você raramente precisa deles de qualquer maneira - e isso pode ser contornado ao inserir dados adicionais no objeto da entidade e adicionar a exposição deles como propriedades adicionais da entidade).
Em poucas palavras, assim que o desempenho da consulta é um problema no seu projeto, o que acontece assim que você tem um conjunto de dados significativo (digamos, começando em alguns décimos de milhares de entidades em um determinado tipo de entidade), o MongoDB é um ganho líquido por pouquíssimas desvantagens. Altamente recomendado.
Damien Tournoud: Se você tiver problemas de desempenho com apenas alguns décimos de milhares de entradas, provavelmente há um problema subjacente (configuração do DBMS, consultas mal escritas, pode ser qualquer coisa). Se o esquema SQL subjacente for bom o suficiente, você não precisa se preocupar antes de um milhão de entradas em uma única tabela (mas os campos podem crescer rapidamente se você considerar revisões e campos com vários valores provavelmente).
314 Pierre
Meu argumento é exatamente: nosso esquema é normalizado e, como conseqüência, apresenta desempenho de consulta muito baixo. Para melhorar o desempenho da consulta, você precisa desnormalizar o esquema. A principal vantagem de usar o MongoDB no nosso caso é que é algum tipo de "mecanismo de desnormalização automática".
Damien Tournoud
E, claro, o MongoDB é ótimo aqui, porque é um banco de dados orientado a documentos. Armazenar documentos complexos, como entidades no armazenamento SQL, é simplesmente estúpido. É nossa implementação padrão, mas isso não significa que você deve usá-lo :)
Damien Tournoud
@ Pierre: Damien falou sobre alguns décimos mil entidades , o que pode ser uma coisa completamente diferente das linhas da tabela. Por exemplo, você pode ter 10 ou mais campos nessa entidade e, em seguida, 10 tabelas adicionais que precisam ser consultadas com uma consulta separada toda vez que uma entidade é carregada. E o MongoDB pode substituir essas tabelas adicionais, não a tabela base da entidade.
Berdir 18/03/11
2
Nenhum módulo deve esperar que os campos estejam no MySQL. A única maneira de consultar os campos no Drupal 7 é EntityFieldQuery. Abra um bug no módulo se estiver consultando diretamente as tabelas de campos. Não conheço nenhum desses módulos no momento.
Damien Tournoud
7
O MongoDB e similares são projetados para armazenar dados estruturados (hierárquicos) de uma maneira relativamente flexível.
Por exemplo Drupal 7, ao usar field_sql_storage, cada campo obtém suas próprias tabelas. Quando você anexa 10 campos a um tipo de conteúdo, você acaba com 10 tabelas no seu banco de dados. Quando você carrega esse nó, field_sql_storageexecutará uma consulta por campo e por nó (ou vários nós, ao usar node_load_multiple).
Ao usar mongodb_field_storage , você pode armazenar todos os campos de um nó em um único documento e obter uma única consulta.
Você também pode armazenar outras coisas, como watchdog, sessões, cache, blocos no MongoDB .
Você ainda precisa do MySQL, no entanto, o MongoDB não o substitui (apenas para partes específicas).
Outra vantagem é que, com o MongoDB , é mais fácil escalar, você pode adicionar muitos servidores a um cluster para compartilhar os dados entre eles.
Oi Berdir! Você sabe que, se eu deixar o MongoDB em um projeto existente para testar o desempenho, eu ativaria e desabilitaria o módulo sem consequências? Quero experimentar o mongo, mas e se não funcionar ou algo assim? É seguro tentar? (Eu sei que você não pode garantir isso, mas eu pergunto o que acontece na maioria dos casos)
Beto Aveiga
1
Bem, para começar, você não pode simplesmente soltá-lo. Cada campo configurou qual back-end de armazenamento que ele usa. Você precisará alterar / recriar seus campos, recriar suas visualizações (pois elas precisam usar o back-end efq_views ), talvez suas próprias consultas, se você escreveu consultas diretas nas tabelas de dados do campo. Pode ser mais fácil recriar a mesma estrutura em uma nova instalação para uma comparação inicial.
Berdir
Obrigado Berdir! Eu tentei o MongoDB há alguns dias atrás, mas não havia um ganho perceptível no desempenho, mas também não estava ciente das coisas / mudanças que você está me dizendo agora. Eu pensei que "o MongoDB deveria fazer a diferença em sites maiores". Vou tentar o MongoDB novamente.
Beto Aveiga
5
Os profissionais vêm com contras.
O Drupal como um todo não pode ser alternado para o MongoDb, portanto você terá que suportar dois bancos de dados e garantir que eles funcionem bem juntos.
Muitos módulos não poderão trabalhar com o mongodb, assim você perderá a interoperabilidade.
A menos que você tenha uma necessidade premente (como parte do seu sistema não está lidando com o número de solicitações / ou quantidade de dados), eu não trocaria. E mesmo quando você começa a se aproximar dos limites, lance o hardware para o problema ou ajuste antes de mudar.
Eu pensei que tinha respondido isso antes, há quase uma duplicata no SO
Respostas:
O MongoDB pode ser usado para armazenar a maioria ou todas as suas entidades em um armazenamento rápido e orientado a documentos. Esse tipo de armazenamento é bem melhor do que o armazenamento padrão baseado em SQL que temos no núcleo Drupal (que é baseado no esquema "uma tabela por campo").
No estado atual do Drupal 7, você teria:
Isso permite consultas rápidas sobre as entidades no MongoDB e a capacidade de adicionar índices complexos aos quais nenhum banco de dados SQL Opensource suporta (incluindo índices entre tabelas). Ao mesmo tempo, você não perde a interoperabilidade porque a tabela base da entidade ainda está armazenada no SQL e, portanto, pode ser unida por módulos que ainda são apenas SQL (como Flag).
Esse tipo de consulta rápida está disponível graças ao mecanismo EntityFieldQuery, uma maneira de criar consultas sobre entidades, suas propriedades e seus campos de maneira abstrata. A implementação padrão no núcleo converte essas consultas para SQL, mas o módulo MongoDB possui uma implementação completa que pode atender diretamente a essas consultas do MongoDB.
Graças ao back-end EntityFieldQuery para Views , você pode aproveitar facilmente esse poder usando as ferramentas às quais está acostumado. A única desvantagem é que os relacionamentos não são suportados (mas, na prática, você raramente precisa deles de qualquer maneira - e isso pode ser contornado ao inserir dados adicionais no objeto da entidade e adicionar a exposição deles como propriedades adicionais da entidade).
Em poucas palavras, assim que o desempenho da consulta é um problema no seu projeto, o que acontece assim que você tem um conjunto de dados significativo (digamos, começando em alguns décimos de milhares de entidades em um determinado tipo de entidade), o MongoDB é um ganho líquido por pouquíssimas desvantagens. Altamente recomendado.
fonte
O MongoDB e similares são projetados para armazenar dados estruturados (hierárquicos) de uma maneira relativamente flexível.
Por exemplo
Drupal 7, ao usarfield_sql_storage, cada campo obtém suas próprias tabelas. Quando você anexa 10 campos a um tipo de conteúdo, você acaba com 10 tabelas no seu banco de dados. Quando você carrega esse nó,field_sql_storageexecutará uma consulta por campo e por nó (ou vários nós, ao usarnode_load_multiple).Ao usar mongodb_field_storage , você pode armazenar todos os campos de um nó em um único documento e obter uma única consulta.
Você também pode armazenar outras coisas, como watchdog, sessões, cache, blocos no MongoDB .
Você ainda precisa do MySQL, no entanto, o MongoDB não o substitui (apenas para partes específicas).
Outra vantagem é que, com o MongoDB , é mais fácil escalar, você pode adicionar muitos servidores a um cluster para compartilhar os dados entre eles.
fonte
Os profissionais vêm com contras.
O Drupal como um todo não pode ser alternado para o MongoDb, portanto você terá que suportar dois bancos de dados e garantir que eles funcionem bem juntos.
Muitos módulos não poderão trabalhar com o mongodb, assim você perderá a interoperabilidade.
A menos que você tenha uma necessidade premente (como parte do seu sistema não está lidando com o número de solicitações / ou quantidade de dados), eu não trocaria. E mesmo quando você começa a se aproximar dos limites, lance o hardware para o problema ou ajuste antes de mudar.
Eu pensei que tinha respondido isso antes, há quase uma duplicata no SO
fonte