¿El fragmentación no es tan popular o más difícil con las bases de datos relacionales / SQL?

Con el fin de admitir uniones relacionales, el fragmentación en mundos de datos relacionales distribuidos generalmente se implementa a nivel de aplicación o “política”, ya que las uniones entre instancias son generalmente muy caras y lentas.

Un ejemplo simple sería que los usuarios cuyos nombres comienzan con ‘A’ van a la Instancia 1, aquellos con ‘B’, van a la instancia 2, etc. Todos los datos asociados con cada grupo de usuarios vivirían en instancias separadas, con el idea de que durante las operaciones de producción normales, no es necesario ejecutar consultas entre instancias.

La mayoría de las bases de datos NoSQL esencialmente omiten todo el concepto de uniones y almacenan todos los datos asociados con una cosa en particular en un documento. Dado que todos los datos que necesita están en un documento en particular, puede particionar en función de uno de los atributos principales de sus documentos, y utilizando esta Shard Key, puede saber en qué instancia de su mundo de datos se encuentra el documento que le interesa.

Este modelo de datos funciona muy bien para ciertos tipos de aplicaciones, pero no tanto para aplicaciones donde los datos son básicamente tabulares y la unión es una rutina. Entonces, en mundos de datos muy grandes, a menudo terminas con un híbrido de bases de datos NoSQL y SQL.

Pero vale la pena saber que es muy importante elegir cuidadosamente las claves de fragmentos tanto en las implementaciones NoSQL relacionales distribuidas como en las de instancias múltiples.

Las bases de datos relacionales generalmente no tienen un mecanismo para fragmentar.

Sharding se refiere a una práctica de almacenamiento de datos en la que los grupos de datos se mantienen en sistemas separados. Por ejemplo, puede optar por mantener los datos de la mitad de sus usuarios en una base de datos y mantener los datos de la otra mitad en una base de datos separada almacenada en una máquina separada.

El objetivo del fragmentación es reducir el trabajo que cada máquina tiene que hacer. Muchas bases de datos NoSQL tienen fragmentos integrados y es transparente para el software que accede a los datos. El software tiene un punto final para alcanzar los datos y no sabe a qué base de datos está accediendo realmente.

La mayoría de las bases de datos relacionales no tienen esta capacidad incorporada (quizás ninguna de ellas sí). Si el software quiere compartir en dos bases de datos relacionales, tiene que hacer un seguimiento de las conexiones a cada base de datos por separado.

Las principales bases de datos relacionales tienen opciones de configuración maestro-esclavo para que muchas bases de datos separadas puedan mantenerse sincronizadas. En estas configuraciones, cada base de datos tiene una copia completa de los datos, no solo una parte de ellos. El software todavía tiene la tarea de decidir a qué base de datos acceder, pero cualquiera que elija, la base de datos tendrá el conjunto de datos completo.

Lea sobre Teradata. Si bien estoy de acuerdo con otras respuestas sobre popularidad y DBMS genérico, la tecnología Teradata de los años 80 implementó métodos de fragmentación física para admitir DBs a gran escala (el tamaño “terabyte” que implica el nombre) en un momento en que unos cientos de megabytes eran grandes datos comerciales. historias. Después de rebotar desde AT&T, NCR. etc., todavía se encuentran en dominios analíticos de alta gama. Buena tecnología y un verdadero innovador de DB.

Sharding es una forma de particionamiento, y la mayoría de los DBMS tienen particionamiento. Lo interesante de los fragmentos es el uso en varias máquinas para el escalado horizontal. El escalado horizontal en DBMS relacionales es difícil. Solo unos pocos lo hacen bien, y son comerciales y a la gente no le gusta pagar por eso, por lo que se conformarán con la semántica más relajada de bases de datos distribuidas fragmentadas y eventualmente consistentes que no realizan transacciones, o se une muy bien.

Hay un campo de desarrollo rico en este momento tratando de poner SQL suficientemente decente encima de los motores de almacenamiento de datos más débiles.