Por que usar o MySQL para um site de dicionário é uma má idéia?

55

Estou planejando criar e configurar um banco de dados para armazenar entradas de dicionário (geralmente palavras únicas) e seu significado em outro idioma. Portanto, por exemplo, o glossário da tabela deve ter entrada e definição e cada registro da tabela tem uma referência ao ID de um registro armazenado Tag(Cada entrada deve ter uma tag ou categoria).

Como meus dados têm uma estrutura, pensei que usar um banco de dados SQL (como MySQL) não é uma má idéia; mas as pessoas dizem que o MongoDB é muito melhor para o desempenho.

No lado do cliente, o aplicativo deve poder fornecer uma caixa de pesquisa com preenchimento automático, que consome uma API REST fornecida pelo back-end. É seguro usar o MySQL nesse cenário? ou devo usar o MongoDB ou o ElasticSearch de qualquer outra solução para isso? Centenas de milhares de registros devem ser armazenados e acessados dessa maneira.

— Aziz Az
fonte

79

As pessoas que estão dizendo as coisas não fizeram muita pesquisa sobre isso. O idioma com o maior vocabulário, o inglês, possui menos de um milhão de palavras distintas. Isso está dentro do domínio dos recursos de desempenho de um banco de dados relacional.

— TheCatWhisperer

25

Não vejo nada aqui que me faça pensar que o MySQL não funcionaria bem para isso. O desempenho em uma pesquisa simples não seria um problema e, se você precisar seguir esse caminho, terá uma pesquisa de texto completo.

— GrandmasterB

46

Quanto a "MongoDB é muito melhor para desempenho" - como uma declaração não modificada, sem esclarecimento de escopo, isso é um absurdo. Por exemplo, consulte As ferramentas de linha de comando podem ser 235x mais rápidas que o seu Hadoop Cluster (que encontrei em um link na Crise da obesidade no site ).

— Curinga

82

Estou tão cansado de pessoas que dizem que os bancos de dados relacionais são ruins e o MongoDB é melhor porque é mais rápido. É como dizer que os carros são ruins e que devemos usar aviões porque eles viajam mais rápido. Meu conselho é ignorar conselhos como este.

— Brandon

13

@Brandon O triste é que as reivindicações "NoSQL são muito mais rápidas" geralmente se resumem a uma explicação teórica de por que elas deveriam ser muito melhores, mas na prática isso nem se aplica a muitos cenários do mundo real. Veja, por exemplo, aqui . Seu conjunto de benchmark usado é de código aberto e também está disponível no github. Inferno O CERN gerencia seu PB de dados com um OracleDB muito bem.

— Voo

95

Não sei dizer por que é uma má ideia. Eu posso lhe dizer várias razões pelas quais um banco de dados relacional é uma boa ideia.

Lembre-se de que nem todo mundo consulta um dicionário para uma definição. Mais vezes, um dicionário é usado para encontrar a ortografia correta. Isso significa que você não está apenas encontrando uma agulha no palheiro , mas procurando agulhas semelhantes às descritas pelo usuário (se é que posso usar um idioma).

Você não fará apenas pesquisas de chave primária. Você fará pesquisas de palavras-chave
As palavras podem estar relacionadas, tanto em significado quanto em ortografia ( leitura, leitura , vermelho e palheta )

Sempre que você vir a palavra "relacionado", pense em "Banco de Dados Relacional"
Se você precisar de velocidade, precisará armazenar em cache o banco de dados relacional, não um modelo de dados relacionais quebrado
Um banco de dados normalizado adequadamente acelera as pesquisas e pesquisas com a chave primária, pois há apenas menos bits para filtrar.
As pessoas que dizem que os bancos de dados normalizados são mais lentos estão se referindo aos 0,1% dos casos em que isso é verdade. Nos outros 99,9% dos casos, eles realmente não trabalharam com um banco de dados verdadeiramente normalizado para ver o desempenho em primeira mão, então ignore-os. Eu trabalhei com um banco de dados normalizado. Adoro. Não quero voltar. E eu não sou um cara de banco de dados. Eu sou um cara de C # / JavaScript / HTML / Ruby.
As palavras têm uma origem. De fato, muitas palavras no mesmo idioma podem ter a mesma origem, que é outra palavra em um idioma diferente. Por exemplo, currículo (o que enviamos para sites de recrutadores para que possamos receber telefonemas e e-mails incessantes pelos próximos 7 anos) é uma palavra em francês.
Um dicionário também define que tipo de palavra é (substantivo, verbo, adjetivo ect). Este não é apenas um pedaço de texto: "substantivo" também tem significado. Além disso, com um banco de dados relacional, você pode dizer coisas como "me dê todos os substantivos para o idioma inglês" e, como um banco de dados normalizado utilizará chaves estrangeiras, e as chaves estrangeiras têm (ou deveriam ter) índices, a pesquisa será rápida.
Pense em como as palavras são pronunciadas. Especialmente em inglês, muitas palavras têm a mesma pronúncia (veja meu exemplo acima com read e reed, ou read e red).

A pronúncia de uma palavra é, por si só, outra palavra. Um banco de dados relacional permitiria o uso de chaves estrangeiras em qualquer pronúncia. Essa informação não será duplicada em um banco de dados relacional. Ele é duplicado como um louco em um banco de dados sem SQL.
E agora vamos falar sobre versões plurais e singulares de palavras. :) Pense em "barco" e "barcos". Ou o próprio fato de uma palavra ser "singular" ou "plural".
Oh! E agora vamos falar sobre o pretérito, o presente, o futuro e o particípio presente (para ser sincero, não sei qual é a porcaria do "particípio presente". Acho que tem algo a ver com as palavras que terminam em "ing" em Inglês ou algo assim).

Procure "correr" e você verá os outros tempos: correu, corre, corre

De fato, "tenso" é outro relacionamento em si.
O inglês não faz muito isso, mas gênero é outra coisa que define uma palavra. Idiomas como o espanhol têm sufixos para definir se o sujeito do substantivo é masculino ou feminino. Se você precisar preencher os espaços em branco de uma frase, o sexo é extremamente importante em vários idiomas.

Como você nem sempre pode confiar nas convenções de idioma para determinar o sexo (em espanhol, as palavras que terminam em "o" são masculinas / masculinas, mas isso não é verdade para todas as palavras), você precisa de um valor de identificação: masculino ou feminino. Esse é outro relacionamento que um banco de dados normalizado manipula normalmente mesmo em milhões de registros.

Com todas as regras distorcidas e relacionamentos entre palavras e até mesmo idiomas diferentes, é difícil para mim imaginar esse repositório de dados como um "repositório de documentos", como uma solução sem SQL. Existem tantas e uma variedade tão grande de relacionamentos entre palavras e seus componentes que um banco de dados relacional é a única solução sensata.

— Greg Burghardt
fonte

7

Para o número 1, a indexação é frequentemente um dos pontos fortes das ofertas não relacionais, não uma fraqueza.

— precisa saber é o seguinte

61

@JimmyJames Não pense por um minuto que os sistemas relacionais não estão usando os mesmos tipos de índices. Muitas dessas técnicas foram pioneiras nesse mundo.

— Blrfl 5/17

14

"Sempre que vir a palavra" relacionado ", pense em" Banco de Dados Relacional "". Eu não concordo O "relacional" no "banco de dados relacional" refere-se às próprias tuplas. Related é um termo muito amplo para esta declaração conter água

— gardenhead

12

Também existem bancos de dados gráficos (o Neo4j vem à mente) que são explicitamente focados em atravessar relacionamentos, em vez de realizar junções tradicionais. Isso pode ser vantajoso, pois muitos dicionários são na verdade teias de palavras; por exemplo, o projeto WordNet usa seu próprio formato de gráfico, em vez de um RDMS tradicional.

— tucuxi

4

Eu diminuí a votação desta resposta apenas para "Sempre que você vir a palavra 'relacionado', pense em 'Banco de Dados Relacional'". Isso é ridículo . Eu amo bancos de dados relacionais, mas o modelo relacional não é apropriado para todos os tipos de relacionamentos. Sua visão dos dados normalizados também está completamente errada. A normalização dos dados otimiza as edições , porque os dados não são duplicados, não pesquisas. (É por isso que os bancos de dados de relatórios não se normalizam. Eles usam técnicas de modelagem dimensional e esquemas em estrela.) Acho que você não sabe do que está falando. As 80 votações confirmam todas as minhas preocupações sobre os conselhos deste site.

— jpmc26

27

Se você utiliza o armazenamento de valores-chave (que oferece um modelo de programação mais empobrecido) e você precisa de mais estrutura (no seu caso, digamos, adicionando um terceiro idioma) ou precisa fazer consultas mais complexas envolvendo junções , você gastará muito tempo reorganizando suas chaves, desnormalizando seus dados e / ou fazendo um loop sobre todos os dados para encontrar o que precisa.

Se você começar com um banco de dados relacional, poderá trabalhar no design, no código do aplicativo e experimentá-lo, concentrando-se mais no modelo de dados naturais do aplicativo, em vez de colocá-lo na forma de valor-chave.

Depois que o aplicativo se acalmar, você poderá trabalhar no desempenho, medindo várias opções. Existem alguns truques de desempenho a serem executados no SQL antes da necessidade de alternar tecnologias. Você aprenderá muito sobre seu aplicativo e estará em uma posição muito melhor para decidir se o relacionamento está prejudicando você e se o valor-chave funcionará para o seu modelo de dados.

Se o valor-chave for exatamente o que seu aplicativo precisa, você poderá alternar sem desperdiçar investimentos significativos no modelo relacional, enquanto o contrário pode acabar perdendo tempo fazendo com que o modelo de valor-chave faça coisas que são necessárias. trivial no modelo relacional.

Considere o banco de dados relacional como um acelerador para que seu aplicativo seja projetado, gravado e em funcionamento, diante de requisitos sempre em mudança, à medida que você aprende mais sobre seu domínio e usuários.

Quando você tem milhões de usuários, quase certamente precisará refatorar o design, mesmo que tenha escolhido o valor-chave para começar.

— Erik Eidt
fonte

13

O epílogo neste artigo descreve exatamente um cenário de alteração de requisitos que invalidam um design. Ele descreve um aplicativo (real) como "um caso de uso perfeito para o MongoDB", mas depois descreve como uma mudança relativamente pequena nos requisitos, que seria trivial para implementar em um RDBMS, exigia uma quantidade considerável de trabalho e o teria movido. para um caso de uso que (como explicam as partes anteriores do artigo) não é muito um bom caso de uso do Mongo.

— Derek Elkins

5

O artigo do Sarah MongoDB é exatamente o que passamos com um produto 1.0 que construímos usando-o; por 1.1, estávamos usando o Postgres.

— Joe

@DerekElkins, super referência, thx!

— Erik Eidt

11

"mas depois descreve como uma mudança relativamente pequena nos requisitos, que teria sido trivial para implementar em um RDBMS" Claro, mas o oposto é verdadeiro. Usamos RDBMSs no trabalho e enfrentamos problemas que seriam triviais para resolver no MongoDB. Curiosamente, os requisitos de software nem sempre são mapeados perfeitamente para os recursos das ferramentas que usamos.

— NPSF3000

@ NPSF3000, seria incrível se você pudesse citar uma referência, como um blog ou algum texto que seja elaborado sobre isso!

— Erik Eidt

10

Para um banco de dados tão pequeno, provavelmente não fará muita diferença no desempenho. Um RDBMS padrão não é uma péssima idéia aqui porque, presumivelmente, deve haver muito mais leituras do que gravações de uma determinada entrada. O desempenho não parece ser o principal driver para isso. O armazenamento em cache na camada de aplicativo também atenua essas preocupações.

A outra consideração é replicação e resiliência. Os bancos de dados relacionais tendem a ser projetados em torno de uma única instância. Você deve ler o teorema da PAC e considerar o que mais importa para você.

— JimmyJames
fonte

Como o CAP se aplica a um aplicativo Web relativamente normal? Dependendo do seu kit, é provável que você possa sustentar milhares de conexões de entrada e uma camada de cache de página pode aumentar isso em uma ordem de magnutude. O CAP só começa a se tornar algo que você precisa considerar quando os sistemas distribuídos são a única maneira de atingir seu objetivo.

— Ben

2

A resiliência do Ben é um objetivo por si só. Se um ponto de falha único não for aceitável para um aplicativo, as soluções distribuídas oferecem uma solução. As soluções não RDBMS tendem a ser mais orientadas para isso. Não é simplesmente o volume a considerar. Latência e disponibilidade são preocupações. Se o seu requisito é ter 99,9% de tempo de atividade. Você só pode ficar inativo por cerca de 9 horas por ano e a perda de dados em um banco de dados é catastrófica; portanto, é necessário considerar a replicação / backups / capturas instantâneas. É equivocado pensar que isso necessariamente simplifica as coisas.

— JimmyJames

2

Esses bancos de dados NoSQL sempre soam como uma boa idéia desde o início, mas você terá problemas ao começar a lidar com casos extremos (por exemplo, onde as palavras-chave devem ser pesquisadas pelo valor (ou parte de), por exemplo.

Seria uma opção mais segura usar um banco de dados relacional no início e depois desnormalizar mais tarde. O MySQL é incrível para esse tipo de objetivo (bancos de dados relacionais simples com pesquisa baseada em texto), não há muitos casos de uso nos quais você encontrará problemas com esse tipo de dados. Apenas certifique-se de que seus índices estejam configurados corretamente e você encontrará um desempenho comparável (ou melhor ao fazer uma pesquisa de texto) a um banco de dados NoSQL, e lhe dará a flexibilidade de modificar a lógica do aplicativo sem ser necessário. ligado a uma estrutura de dados concreta.

À medida que você encontra o uso mais comum dos seus dados (e se você achar que não está atendendo às suas necessidades de desempenho), poderá desnormalizar os dados, enviando para um formato definido que possa ser carregado (e recuperado de) um esquema NoSQL.

— joel.cass
fonte