Desde la perspectiva del desarrollador, puedo decir que casi todos los motores tradicionales de bases de datos tradicionales solo pueden escalar y escalar es una idea posterior.
En los últimos años, con la necesidad de una mayor escalabilidad y sistemas de alta disponibilidad, se han realizado esfuerzos para que las bases de datos existentes se escalen. Pero debido a que los diseños se ven obstaculizados por el código heredado, en gran medida se atornilla en lugar de ser fundamental para el diseño. Encontrará esto si intenta escalar la mayoría de los motores de bases de datos conocidos. Agregar servidores esclavos puede ser bastante difícil de configurar y notará que viene con limitaciones significativas, algunas de las cuales pueden requerir volver a ajustar las tablas de su base de datos.
Por ejemplo, la mayoría de ellos son diseños maestro / (multi-) esclavo en lugar de diseños multimaestro. En otras palabras, es posible que solo tenga un servidor completo sentado allí y que no pueda procesar consultas. Algunos lo hacen, pero con limitaciones ... por ejemplo, solo lectura de diseño de esclavos múltiples. Por lo tanto, es posible que tenga un servidor que tome escrituras y todos los demás proporcionen datos de solo lectura. Notarás que cuando configuras estos sistemas, no siempre es un proceso sencillo y es difícil que funcione bien. En muchos casos, se siente como un perno adicional.
Por otro lado, hay algunos motores de bases de datos más nuevos que se están desarrollando con concurrencia y diseño multimaestro desde el principio. NOSQL y NewSQL son la nueva clase de diseño.
¡Entonces parece que la mejor manera de obtener un mejor rendimiento de un servidor SQL tradicional es escalar! Mientras que con NOSQL y NewSQL es tanto escalable como escalable.
La razón por la cual los sistemas RDBMS tradicionales están estrechamente acoplados es porque todos necesitan una vista consistente de los mismos datos. Cuando tiene varios servidores que aceptan actualizaciones a los mismos datos de diferentes clientes, ¿en cuál confía? Cualquier método que intente garantizar que los datos sean consistentes a través de algún tipo de mecanismo de bloqueo requiere la cooperación de otros servidores que perjudiquen el rendimiento o afecten la calidad de los datos, ya que los datos leídos de un cliente pueden estar desactualizados. Y los servidores deben decidir entre ellos qué datos son más recientes al escribir en el mismo registro. Como puede ver, es un problema complejo que se vuelve más complejo por el hecho de que la carga de trabajo se distribuye entre los servidores y no solo entre procesos o subprocesos donde el acceso a los datos aún es bastante rápido.