¿Cuánto afecta el modelo de datos a la escalabilidad y el rendimiento en la llamada base de datos "NoSQL"?

Nunca se puede hablar sobre la llamada base de datos "NoSQL" sin traer el teorema CAP (Consistencia, Disponibilidad, Partición: elija dos). Si tiene que elegir, por ejemplo, entre MongoDB (Partición, Consistencia) y CouchDB (Disponibilidad, Partición), lo primero que debe pensar es "¿Necesito datos correctos o necesito acceso todo el tiempo?".

Esas nuevas bases de datos fueron hechas para ser particionadas. Pero, ¿y si no lo hago ? ¿Qué sucede si creo que es genial tener una clave / valor, columna, documento, cualquier base de datos en lugar de una relacional, y simplemente crear una instancia de servidor y nunca compartirla? En ese caso, ¿no tendría disponibilidad y consistencia? MongoDB no necesitaría replicar nada, por lo que estaría disponible. Y CouchDB solo tendría una fuente de datos, por lo que sería bastante consistente.

¿Entonces eso significaría que, en ese caso, MongoDB y CouchDB tendrían poca diferencia en términos de uso? Bueno, excepto, por supuesto, el rendimiento, la API y otros, pero eso sería más como elegir entre PostgreSQL y MySQL que tener dos conjuntos de requisitos fundamentalmente diferentes.

Estoy aqui? ¿Puedo cambiar una base de datos AP o CP a una AC al no crear más de una instancia? ¿O hay algo que me estoy perdiendo?

Hagamos la pregunta al revés. ¿Qué sucede si tomo una base de datos relacional, digamos MySQL y la configuro en una configuración maestro / esclavo? No uso transacciones ACID. Si requiero que cualquier escritura se sincronice con el esclavo inmediatamente, ¿no sería eso una base de datos CP? Y qué pasa si lo sincronizo a intervalos predefinidos, y no importa si un cliente lee datos obsoletos de un esclavo. ¿No sería eso una base de datos AP? ¿No significa eso que si dejo de cumplir con ACID todavía puedo usar el modelo relacional para una base de datos particionada?

En esencia: ¿es la escalabilidad sobre lo que está dispuesto a renunciar en el teorema CAP, más que el modelo de datos subyacente? ¿Tener Columna, Documento, Valor clave, lo que sea, da un impulso a la escalabilidad sobre un modelo relacional? ¿Podríamos diseñar una base de datos relacional diseñada desde cero para la tolerancia de partición? (Tal vez ya existe). ¿Podríamos hacer que la base de datos NoSQL sea compatible con ACID?

Lo sentimos, son muchas preguntas, pero he leído mucho sobre la base de datos NoSQL recientemente y me parece que el mayor beneficio de usarlas es que se ajustan mejor a la "forma" de sus datos, en lugar de solo la partición, CAP y renunciar al cumplimiento de ACID. Después de todo, no todos tienen tantos datos que necesitan para particionarlos. ¿Existe un beneficio de rendimiento / escalabilidad al no usar el modelo relacional antes de siquiera pensar en particionar mis datos?

¿Usar una base de datos NoSQL aumenta la escalabilidad incluso si no está compartiendo datos? Bueno, definamos la escalabilidad. Si se refiere a la escalabilidad en lo que respecta a los sistemas de base de datos / backend, ya que tiene una escala vertical y horizontal donde la escala horizontal ES datos de fragmentación, entonces esta se convierte en una pregunta trivial porque la respuesta sería absolutamente no, porque la única opción que le queda es la escala vertical (es decir, obtener un mejor hardware). Sin embargo, si está hablando de escalabilidad en un sentido más amplio que se refiere a la flexibilidad de la aplicación, el valor de los datos, etc. Esa es una pregunta completamente diferente con varias respuestas. Y como mencionó, a menudo se reducirá a lo que está haciendo con los datos y cómo deben almacenarse. Permítanme introducir todo aquí con la afirmación de que en la mayoría de los casos todavía debería estar usando un RDBMS y NoSQL debería llenar el nicho. La siguiente es una descripción de una instancia específica donde una base de datos NoSQL sería más beneficiosa dados los requisitos específicos, y donde podemos ignorar la escala horizontal.

Tome por ejemplo la idea de que está creando un sistema de almacenamiento de archivos en la nube similar a Google Drive, Dropbox o Box, pero en lugar de utilizar un sistema de archivos real, decide que sería más beneficioso para usted virtualizar el sistema de archivos. Ahora tiene un problema porque su modelo de datos es repentinamente la estructura de árbol que va a ser terriblemente ineficiente en un RDBMS (a pesar de que así es como se indexa todo). Porque ahora tiene una tabla de 3 columnas con Nombre, Usuario y Principal. El usuario es una clave foránea para una tabla de usuarios y Parent es una clave foránea autorreferenciable que puede anularse (anulable porque el directorio raíz no puede tener un padre). Entonces, ¿cuál es la clave principal? En este caso, es una clave compuesta en todas las columnas ... Lo que de repente convierte a Parent en nuestro peor enemigo.

Ahora, en cambio, piense en cómo lo pondría en alguna forma de almacén de documentos En lugar de combatir los datos, puede trabajar con ellos y almacenarlos como la estructura de árbol, lo que a su vez disminuirá su tiempo de desarrollo y disminuirá los costos de mantenimiento. Si está disminuyendo los costos, ¿eso no permite un tipo diferente de escalabilidad? Además, en este caso, está creando el sistema correctamente desde cero, lo que debería dar más flexibilidad a la aplicación misma. Actualmente estoy ejecutando esto en un solo servidor usando MongoDB, lo que, como explicaste, me da un modelo disponible y consistente que no es muy diferente a mirar la diferencia de MySQL o Postgres.

Con MongoDB, al menos, puede definir con cuántos servidores necesita comunicarse para que una consulta tenga éxito, así que sí, puede convertirla en un modelo consistente y disponible si le dice a todas las consultas que se comuniquen con todas las instancias del servidor.

Así que creo que tiene el derecho de hacerlo porque hay un gran beneficio en cómo se almacenan los datos. Hay cosas que no encajan bien en un modelo relacional que encajan bien en otros modelos (como otro breve ejemplo, Amazon usa alguna forma de base de datos Graph para su motor de recomendación de productos).

¿Entendí correctamente tu pregunta?

Editar: ¿más datos ralentizarán las cosas? Si. ¿Cuánto ralentizará las cosas? Sinceramente, no tengo suficiente experiencia para dar una respuesta adecuada. Clave / valor: esencialmente una tabla de búsqueda con grandes cantidades de datos asociados con la clave de búsqueda. Esto va a ser realmente muy rápido porque solo puedes buscar las cosas con la tecla. Columna / Familia: esencialmente una tienda de clave / valor mucho más estructurada. Solo puede consultar en función de la columna, por lo que esto también debería ser muy rápido. Documento: esquema de estilo de agregación. Aquí querrá agregar datos similares juntos. La desnormalización está bien y se espera para este tipo de base de datos. Dependiendo de si está haciendo muchas escrituras o lecturas, puede organizar sus datos para que se distribuyan en múltiples fragmentos para distribuir las escrituras o las lecturas (tenga en cuenta que puede crear un enfoque híbrido que sea bueno para ambos, pero en general para usted necesita elegir la optimización para uno u otro) Gráfico: La fortaleza de este es que puede crear y destruir relaciones realmente rápido. Si tiene algunos datos en los que tiene relaciones que necesitan cambiar entre datos (piense en alguna forma de motor de recomendación), debe usar esto.

La forma en que almacene datos en cualquiera de estas bases de datos influirá en el rendimiento (similar al hecho de que si almacena datos incorrectamente en algunos RDBMS, influirá en el rendimiento). Entonces, para aclarar esto: necesita saber qué sistema de base de datos debe usar y cómo almacenar datos en ese sistema de base de datos.