¿Por qué usar MySQL para un sitio web de diccionario es una mala idea?

Estoy planeando diseñar y configurar una base de datos para almacenar entradas de diccionario (generalmente palabras sueltas) y su significado en otro idioma. Entonces, por ejemplo, la tabla Glosario debe tener entrada y definición y cada registro de la tabla tiene una referencia a la identificación de un registro almacenado en Tag(Cada entrada debe tener una etiqueta o categoría).

Como mis datos tienen una estructura, pensé que usar una base de datos SQL (como MySQL) no es una mala idea; pero la gente dice que MongoDB es mucho mejor para el rendimiento.

En el lado del cliente, la aplicación debe poder proporcionar un cuadro de búsqueda con autocompletado que consume una API REST proporcionada por el back-end. ¿Es seguro usar MySQL en este escenario? ¿o debo usar MongoDB o ElasticSearch de alguna otra solución para esto? Se supone que cientos de registros deben almacenarse y accederse de esta manera.

No puedo decirte por qué es una mala idea. Sin embargo, puedo decirte muchas razones por las que una base de datos relacional es una buena idea.

1. Recuerde que no todos consultan un diccionario para una definición. La mayoría de las veces, se usa un diccionario para encontrar la ortografía correcta. Esto significa que no solo está encontrando una aguja en un pajar , sino que está buscando agujas similares a la descrita por el usuario (si puedo usar un idioma).

   No solo estará haciendo búsquedas de claves principales. Harás búsquedas de palabras clave

2. Las palabras pueden estar relacionadas, ya sea en significado u ortografía ( leer, leer , rojo y caña )

   Siempre que vea la palabra "relacionado" piense "Base de datos relacional"

3. Si necesita velocidad, necesita almacenamiento en caché sobre su base de datos relacional, no un modelo de datos relacionales roto

4. Una base de datos correctamente normalizada acelera las búsquedas y búsquedas de claves principales, ya que simplemente hay menos bits para examinar.

5. Las personas que dicen que las bases de datos normalizadas son más lentas se refieren al 0.1% de los casos en que esto es cierto. En el otro 99.9% de los casos, en realidad no han trabajado con una base de datos realmente normalizada para ver el rendimiento de primera mano, así que ignórelos. He trabajado con una base de datos normalizada. Quiéralo. No quiero volver Y no soy un tipo de base de datos. Soy un chico de C # / JavaScript / HTML / Ruby.

6. Las palabras tienen un origen. De hecho, muchas palabras en el mismo idioma pueden tener el mismo origen, que es otra palabra en un idioma diferente. Por ejemplo, currículum (lo que cargamos en los sitios web de reclutadores para que podamos recibir llamadas telefónicas y correos electrónicos incesantes durante los próximos 7 años) es una palabra francesa.

7. Un diccionario también define qué tipo de palabra es (sustantivo, verbo, adjetivo, etc.). Esto no es solo un fragmento de texto: "sustantivo" también tiene significado. Además, con una base de datos relacional puedes decir cosas como "dame todos los sustantivos para el idioma inglés" y dado que una base de datos normalizada utilizará claves foráneas y las claves foráneas tienen (o deberían tener) índices, la búsqueda será muy fácil.

8. Piensa en cómo se pronuncian las palabras. Especialmente en inglés, muchas palabras tienen la misma pronunciación (vea mi ejemplo anterior con read y reed, o read y red).

   La pronunciación de una palabra es, en sí misma, otra palabra. Una base de datos relacional le permitiría usar claves externas para cualquier pronunciación. Esa información no se duplicará en una base de datos relacional. Se duplica como loco en una base de datos sin SQL.

9. Y ahora hablemos de las versiones en plural y singular de las palabras. :) Piense en "barco" y "barcos". O el hecho mismo de que una palabra es "singular" o "plural".

10. Oh! Y ahora hablemos del tiempo pasado, el tiempo presente, el tiempo futuro y el participio presente (para ser sincero, no sé qué es el "participio presente". Creo que tiene algo que ver con las palabras que terminan en "ing" en Inglés o algo así).

    Busque "correr" y debería ver los otros tiempos: correr, correr, correr

    De hecho, "tiempo" es otra relación en sí misma.

11. El inglés no hace mucho esto, pero el género es otra cosa que define una palabra. Idiomas como el español tienen sufijos que definen si el sujeto del sustantivo es masculino o femenino. Si necesita completar los espacios en blanco para una oración, el género es extremadamente importante en muchos idiomas.

    Dado que no siempre puede confiar en las convenciones del lenguaje para determinar el género (en español, las palabras que terminan en "o" son masculino / masculino, pero eso no es cierto para todas las palabras), necesita un valor de identificación: masculino o femenino. Esta es otra relación que una base de datos normalizada maneja con gracia incluso en millones de registros.

Con todas las reglas retorcidas y las relaciones entre las palabras, e incluso diferentes idiomas, me resulta difícil imaginar este almacén de datos como un "almacén de documentos" como lo proporciona una solución sin SQL. Hay tantas y una gran variedad de relaciones entre las palabras y sus componentes que una base de datos relacional es la única solución sensata.

Si va con la tienda de valores clave (que le ofrece un modelo de programación más empobrecido) y resulta que necesita más estructura (en su caso, por ejemplo, agregar un tercer idioma), o necesita hacer consultas más complejas que involucren uniones , pasará mucho tiempo reorganizando sus claves, desnormalizando sus datos y / o recorriendo todos los datos para encontrar lo que necesita.

Si comienza con una base de datos relacional, puede trabajar a través del diseño, el código de su aplicación y probar concentrándose más en el modelo de datos naturales para su aplicación, en lugar de calzarlo en la forma de valor clave.

Una vez que la aplicación se establece, puede trabajar en el rendimiento, midiendo varias opciones. Hay bastantes trucos de rendimiento para hacer en SQL antes de tener que cambiar de tecnología. Habrás aprendido mucho sobre tu aplicación y estarás en una posición mucho mejor para decidir si la relación te está perjudicando y si el valor-clave funcionará para tu modelo de datos.

Si resulta que el valor clave es exactamente lo que necesita su aplicación, puede cambiar sin haber desperdiciado una inversión significativa en el modelo relacional, mientras que al revés podría terminar perdiendo el tiempo haciendo que el modelo de valor clave haga cosas que son trivial en el modelo relacional.

Considere la base de datos relacional como un acelerador para diseñar, escribir y poner en funcionamiento su aplicación, ante los requisitos siempre cambiantes a medida que aprende más sobre su dominio y usuarios.

Cuando tenga millones de usuarios, seguramente necesitará refactorizar el diseño de todos modos, incluso si ha elegido un valor-clave para comenzar.

Para una base de datos tan pequeña, probablemente no habrá mucha diferencia en el rendimiento. Un RDBMS estándar no es una idea terrible aquí porque presumiblemente, debería haber muchas más lecturas que escrituras de una entrada determinada. El rendimiento no parece ser el principal impulsor de esto. El almacenamiento en caché en la capa de aplicación también mitiga tales preocupaciones.

La otra consideración es la replicación y la resistencia. Las bases de datos relacionales tienden a diseñarse en torno a una sola instancia. Debería leer el teorema CAP y considerar lo que más le importa.

Estas bases de datos NoSQL siempre parecen una buena idea desde el principio, pero se le garantizará tener problemas cuando comience a tratar casos extremos (por ejemplo, donde las palabras clave deben buscarse por su valor (o parte de), por ejemplo).

Sería una opción más segura ir con una base de datos relacional desde el principio y luego desnormalizar más tarde. MySQL es increíble para este tipo de propósito (bases de datos relacionales simples con búsqueda basada en texto), no hay demasiados casos de uso en los que encuentre dificultades con este tipo de datos. Solo asegúrese de tener sus índices configurados correctamente y verá que funcionará a un nivel comparable (o mejor al hacer una búsqueda de texto) a una base de datos NoSQL, y le dará la flexibilidad para modificar la lógica de su aplicación sin ser vinculado a una estructura de datos concreta.

A medida que encuentre el uso más común de sus datos (y si alguna vez encuentra que no satisface sus necesidades de rendimiento), puede proceder a desnormalizar los datos enviando a un formato establecido que se puede cargar (y recuperar) Un esquema NoSQL.