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.
Respostas:
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.
fonte
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.
fonte
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ê.
fonte
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.
fonte