Distribución de la base de datos

Question

¿Cuáles son las posibilidades de distribuir datos de forma selectiva?

Explico mi pregunta con un ejemplo. Considere una base de datos central que contiene todos los datos. Esta base de datos se encuentra en una determinada ubicación geográfica.

La aplicación A necesita un subconjunto de la información presente en la base de datos central. Además, la aplicación A puede estar ubicada en una ubicación geográfica diferente (y tal vez muy lejos) de la que se encuentra la base de datos central.

lo tanto, pensé en crear una nueva base de datos en el mismo lugar de aplicación A que contendría un subconjunto de información de la base de datos central.

¿Qué tecnología/producto me permite implementar tal configuración?

Gracias

Answer 1

Look para database replication. SQL Server puede hacer esto con seguridad, otros (Oracle, MySQL, ...) deberían tenerlo también.

La idea es que la otra ubicación mantenga una copia (subconjunto). Las actualizaciones se intercambian incrementalmente. La forma de tratar los conflictos depende de tu aplicación.

Answer 2

La mayoría de los principales software de base de datos como MySQL y SQL Server pueden hacer el trabajo, pero no es un buen modelo. Con el crecimiento de la demanda (tráfico y usuarios), no sólo va a crear una carga en el servidor de base de datos central (que podría servir a otras aplicaciones), pero también va a abusar de su ancho de banda de red para transferir datos entre el base de datos lejana y el servidor de aplicaciones.

Un modelo mejor es mantener sus datos cerca del servidor de aplicaciones, y utilizar la base de datos muy alejada solo con fines de copia de seguridad y recuperación. Puede usar una SAN FC \ IP (o cualquier otra arquitectura de red de almacenamiento ) como su modelo de red de almacenamiento, según las necesidades de sus aplicaciones.

Answer 3

Una pregunta grande que no se tuvieron en cuenta si es de aplicación A necesita acceso de sólo lectura a los datos o si tiene que ser de lectura y escritura.

El concepto inmediata que viene a la mente al leer sus requisitos es sharding. En MySQL, esto se puede lograr con partitioning. Dicho esto, antes de saltar a las particiones, asegúrese de leer en su pros and cons. Hay instancias en las que el particionamiento puede ralentizar las cosas si sus índices no están bien elegidos, o su esquema de partición no está bien pensado.

Si sus necesidades son de solo lectura, entonces esta debería ser una solución bastante simple. Puede usar MySQL en un contexto maestro-esclavo y usar la aplicación A de un esclavo. Si necesita leer-escribir, esto se vuelve mucho más complejo.

Dependiendo de sus necesidades de escritura, puede dividir sus lecturas en su esclavo y sus grabaciones en el maestro, pero eso agrega complejidad a la estructura de su código (necesita lidiar con múltiples conexiones a múltiples dbs). La ventaja de este tipo de diseño es que no necesita tener una infraestructura de BD compleja.

Por otro lado, puede mantener su código como está, y utilizar una replicación Master-Master en MySQL.Aunque oficialmente no es compatible con Oracle, mucha gente ha tenido éxito en esto. Una búsqueda rápida en Google le encontrará una gran lista de blogs, howtos, etc. Solo tenga en cuenta que su código debe estar escrito correctamente para soportar esto (por ejemplo, no puede usar campos de auto incremento para PKs, etc.).

Si tiene efectivo para gastar, entonces puede ver algunas de las ofertas más comerciales. Oracle DB y SQL Server lo admiten.

También puede usar la replicación de datos basada en bloques, como DRDB(and Mysql DRDB) para manejar la replicación entre los nodos, pero el problema que siempre encontrará es qué sucede si falla el enlace entre los dos nodos.

El problema más importante que encontrará es cómo manejar las actualizaciones conflictivas en 2 nodos DB diferentes. Si sus datos son geográficamente dependientes, puede que esto no sea un problema para usted.

En resumen, este no es un problema fácil (o económico) de resolver.

Answer 4

Es importante abordar la posibilidad de conflictos en la fase de diseño siempre que hable de replicar bases de datos.

Pasando de eso, Sybase Replication Server de SAP le permitirá hacer justamente eso, ya sea con bases de datos de Sybase o de terceros.

En el mundo de Sybase esto se llama con frecuencia un entorno enrollable corporativa. Puede haber múltiples bases de datos geográficamente separadas, cada una con un subconjunto de datos sobre los que tienen control primario. En el HQ, hay un servidor que contiene todos los diversos subconjuntos en un repositorio. Puede optar por replicar tablas completas, o replicar en función de los valores en filas/columnas individuales.

Esto mantiene las bases de datos en un estado poco coherente. Las tasas de transacción, la separación geográfica y la latencia que puede ser inherente a la red afectarán la rapidez con que las actualizaciones se mueven de una base de datos a otra. Si una conexión de red está temporalmente inactiva, Sybase Replication Server pondrá en cola la transacción y la enviará tan pronto como vuelva a aparecer el enlace, pero la estabilidad y la estabilidad del sistema de replicación se verán afectadas por la estabilidad de la conexión de red.

Una vez más, como otros han dicho que no es barato, pero es relativamente sencillo de implementar y mantener.

Descargo de responsabilidad: He trabajado para Sybase, y sigo siendo parte de la familia de compañías SAP.