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

¿El uso de una base de datos NoSQL le da un impulso a la escalabilidad incluso si no está fragmentando datos? Pues vamos a definir la escalabilidad. Si se refiere a la escalabilidad como a los sistemas de base de datos / backend, en el sentido de que tiene una escala vertical y horizontal en la que la escala horizontal ES datos de fragmentación, esto se convierte en una pregunta trivial porque entonces la respuesta sería absolutamente no, porque la única opción que queda Es escalamiento vertical (es decir, mejor hardware). Sin embargo, si está hablando de escalabilidad en un sentido más amplio en relación con la flexibilidad de la aplicación, el valor de los datos, etc. Entonces, 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 prefaciar todo aquí con la afirmación de que, en la mayoría de los casos, aún debe utilizar un RDBMS y NoSQL debe llenar los nichos. La siguiente es una descripción de una instancia específica en la que una base de datos NoSQL sería más beneficiosa en función de los requisitos específicos, y en la que 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 usar 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 de repente la estructura de árbol que será horriblemente ineficiente en un RDBMS (a pesar de que así es como se indexa todo). Porque ahora tienes una tabla de 3 columnas con Nombre, Usuario y Padre. El usuario es una clave foránea para una tabla de usuarios y Parent es una clave foránea anulable que hace referencia automática (es 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 lugar de eso, piensa en cómo lo pondrías en algún tipo de almacén de documentos. En lugar de luchar contra los datos, puede trabajar con ellos y almacenarlos como la estructura de árbol, lo que a su vez disminuirá el tiempo de desarrollo y disminuirá los costos de mantenimiento. Si está reduciendo los costos, ¿eso no permite un tipo de escalabilidad diferente? Además, en este caso, está creando el sistema correctamente desde el principio, lo que debería dar más flexibilidad a la aplicación en sí. Actualmente estoy ejecutando esto en un solo servidor utilizando MongoDB, que, como explicaste, me da un modelo disponible y consistente que no es muy diferente a mirar la diferencia de MySQL o Postgres.

Al menos con MongoDB, puedes definir con cuántos servidores necesitas comunicarte para que una consulta tenga éxito, así que sí, puedes convertirlo en un modelo consistente y disponible si le dices a todas las consultas que se comuniquen con todas las instancias del servidor.

Por lo tanto, creo que usted tiene el derecho de hacerlo porque existe un gran beneficio en la forma en que se almacenan los datos. Hay cosas que no encajan bien en un modelo relacional que encaja bien en otros modelos (como otro breve ejemplo, Amazon usa alguna forma de base de datos gráfica para su motor de recomendaciones para productos).

¿Entendí correctamente tu pregunta?

Editar: ¿Más datos retrasarán las cosas? Sí. ¿Cuánto retrasará las cosas? Sinceramente, no tengo la experiencia suficiente 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 cosas por la clave. Columna / familia: Esencialmente una tienda de clave / valor mucho más estructurada. Solo puede realizar consultas basadas en la columna y, por lo tanto, 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 Necesito elegir optimización para uno u otro) Gráfico: la fortaleza de este es que puede crear y destruir relaciones muy rápidamente. 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 almacena los datos en cualquiera de estas bases de datos influirá en el rendimiento (similar al hecho de que si almacena datos de forma incorrecta en algunos RDBMS, influirá en el rendimiento). Esperemos que sea más claro: debe saber qué sistema de base de datos debe usar y cómo almacenar los datos en ese sistema de base de datos.