Arquitectónicamente, ¿cuál es la mejor manera de convertir un motor de base de datos de instancia única a distribuida?

Dos cosas a considerar aquí:

Un archivo JSON no es más que un archivo de texto plano, especialmente si observa el “nivel de archivo físico”. Es solo en el nivel de la aplicación donde el código JSON comienza a derivar su estructura jerárquica. Por lo tanto, debe distribuir el archivo en sí (la replicación / partición tiene ventajas y desventajas) o su nivel de aplicación divide los datos por jerarquía (es decir, está implementando una partición de tamaño variable en un nivel superior).

¿Cuál es el motivo de la distribución? ¿Es para dividir la carga de trabajo de modo que se puedan realizar múltiples consultas / modificaciones simultáneamente a través de diferentes servidores? ¿O es para mantener múltiples copias de trabajo de los mismos datos? ¿O algo mas?

Primero, ignorando un enfoque híbrido: veamos la replicación. Esto significa que las modificaciones deben enviarse a todos los servidores. Esto a su vez significa que podría haber inconsistencias entre los servidores, ya que dicha distribución no es algo instantáneo. Esto causa problemas de versión, ya que cada servidor puede estar trabajando con una versión diferente de cualquier dato a la vez. Un método para evitarlo sería bloquear ciertas operaciones mientras se realiza dicha actualización, pero esto suele ser una muy mala idea para la concurrencia.

Segundo, particionamiento: ¿Dónde definir tales límites? En una tienda de tablas, puede elegir entre el tipo de datos (es decir, la columna) o el grupo de datos (es decir, las filas). Y esto funciona más fácilmente a nivel físico solo si se utilizan datos de longitud fija, especialmente si se dividen en filas.

Pero dado que sus datos son un archivo de texto plano sin formato con su estructura solo definida a nivel de aplicación, es muy difícil acceder a estos puntos sin analizar realmente la estructura de nivel de aplicación. Es posible dividir toda la estructura en archivos separados, por ejemplo, la agrupación de primer nivel en el archivo JSON puede dividirse en archivos separados.

La división en cualquier forma de partición de longitud fija es muy problemática en el mejor de los casos, a menos que cambie toda la estructura de base de datos en una variante de longitud fija, lo que normalmente no es posible para tales campos de longitud variable en estructuras jerárquicas. E implementar esto utilizando dicha estructura de capa de aplicación sería más adecuado para tenerlo también a nivel de aplicación, especialmente debido a la longitud variable impuesta por estructuras como JSON. Esto también significa que terminará con un límite impuesto por los datos sobre el número de nodos de distribución, que no se escala fácilmente a más, a menos que también comience a particionar en un nivel posterior. Además, la distribución impone un conjunto fijo de grupos permitidos en cada uno de estos niveles divididos; esto no es impuesto por JSON, por lo que deberá imponerlo en un nivel de aplicación de su propia creación.

Entonces ambas ideas son menos que ideales. La replicación aún ayudaría, ya que las consultas se pueden distribuir fácilmente, pero pueden hacer que las modificaciones sean mucho más lentas, sin mencionar que está desperdiciando mucho espacio al duplicar datos. La partición es difícil de lograr a menos que lo haga a nivel de aplicación y defina diferentes rutas a diferentes jerarquías.

Un enfoque híbrido en realidad no ayuda con esos aspectos negativos. En efecto, simplemente agregaría problemas de versión / bloqueo en la partición y aún requeriría que se dividiera a nivel de aplicación.

Mi temor es que su elección de estructura de datos no se preste bien a la distribución. Es decir, JSON no debe usarse de esta manera. Esto tiende a ser debido a la nueva palabra de moda de “noSQL” como si fuera algo “nuevo”. Especialmente la idea “no estructurada” de noSQL se parece más al enfoque de archivo plano utilizado en los mainframes de los años 60 que al enfoque estructurado en bases de datos de tipo SQL desde los años 70. Es decir, el nivel físico más bajo no tiene conocimiento de la estructura de los datos y, por lo tanto, no puede hacer tal división y replicación por sí solo. En casi todos los casos de distribución noSQL, se realiza a través de la replicación únicamente como una forma de respaldo en lugar de concurrencia.

Si observa las bases noSQL diseñadas específicamente para la distribución concurrente, todas utilizan un almacén de datos de longitud fija más estructurado en lugar de archivos planos no estructurados de longitud variable basados ​​como Json / XML / s-expr / etc. Como ejemplo, observe uno de los más comunes: NoSQL distribuido: Cassandra que básicamente implementa una tienda “sin tipo” estructurada en la parte superior de una tienda de tablas estructuradas. Es decir, implementa noSQL sobre SQL para permitir los beneficios de los datos estructurados para permitir una partición y una replicación más fáciles y más eficientes.

Dependería de los datos que se supone que almacenará la base de datos y el propósito de los datos.

Un archivo de propósito general (digamos un archivo de texto) como la estructura de datos sería bueno para la distribución. Según el tamaño de los datos o algún otro parámetro, distribuya los datos.

O una tienda de columnas. Por ejemplo, distribuir según la letra inicial de cada atributo de columna.

Si se trata de un almacén de filas, puede tener varias instancias, cada una con todas las tablas, pero digamos que instancia1 contendrá los datos hasta la fila 50. Instancia2 de 51-100 y así sucesivamente. Y luego master db puede contener los índices de cada columna asignada con la instancia. Así, master db sabrá qué instancia buscar.

Estas son solo algunas de las sugerencias, pero el principio subyacente (según mi opinión) se basa en el formato en el que se deben almacenar los datos.

La mejor manera de mover datos de un motor a otro y retener todos los beneficios del nuevo motor de base de datos es volver a transmitir los datos a la nueva base de datos. De esta manera, todos los índices / particiones / clústeres / cubos se crean correctamente desde cero y están en su estado óptimo y / o equilibrado. Esto también evita tener que entender las estructuras de archivos físicos de la base de datos subyacente.