Migración de SQL a NoSQL Databases
Pasos para migrar datos de una base de datos relacional a NoSQL
El uso de una base de datos relacional en sus aplicaciones .NET tiene algunas limitaciones, como su incapacidad para manejar más carga sin reemplazar el hardware existente (ampliación) y su incapacidad para actualizar su modelo de datos rígido, es decir, filas y columnas. Si se enfrenta a estos desafíos, es posible que ya haya decidido cambiar su base de datos a NoSQL. Si aún no está convencido, puede que desee leer ¿Por qué NoSQL?
Teniendo en cuenta el caso de que no tiene opciones para escalar su capa de base de datos y ha elegido mover sus datos a NoSQL, la abrumadora tarea de la migración podría estar impidiéndole dar este salto.
Si bien la migración es una gran tarea, si se divide en pasos, se puede abordar de una manera muy organizada para facilitarle la vida. Este documento técnico está aquí para ayudarlo a organizar su proceso de migración en 6 pasos lógicos.
Si sigue estos sencillos pasos, seguramente lo ayudarán en su proceso de migración. Este trabajo considera que usted ya conoce los conceptos básicos sobre las características de NosDB, una red NoSQL Base de datos de documentos. Si no es así, diríjase a la página web del NDN Collective . A continuación les presento los detalles del mencionado proceso.
Paso 1: identificar el alcance
El primer paso y el más importante es comprender su modelo de negocio y el esquema de la base de datos. También deberá comprender completamente cómo su aplicación accede a estos datos y el flujo de datos hacia y desde su base de datos. Esto ayuda a identificar dos piezas clave de información:
- La parte del esquema de su base de datos a la que se accede más (lecturas, escrituras o ambas)
- Datos que se agrupan, es decir, siempre se accede a ellos juntos para lecturas y escrituras.
Tener esta información lo ayuda a identificar decisiones clave en los pasos restantes. Por lo tanto, este es también el paso más crucial.
Paso 2: identificar NoSQL Requisitos de instalación
Una vez que haya terminado de comprender su modelo de negocio y el flujo de datos, estará en buena forma para tomar algunas decisiones aproximadas sobre cómo implementar su NoSQL clúster, en función de los requisitos de su empresa. Por ejemplo, anotar la cantidad actual de aplicaciones en ejecución, la cantidad de usuarios y la tasa de acceso son algunas métricas importantes. Observar qué parte de sus datos es altamente confidencial, es decir, necesita tener una copia de seguridad a toda costa, también lo ayuda a decidir la estrategia de implementación de los nodos de réplica.
Desde un NoSQL database es una base de datos distribuida, puede aprovechar la naturaleza distribuida a su favor e implementarla según los requisitos de su negocio. La mayor ventaja que obtiene, además de la escalabilidad, es distribuir/implementar su NosDB fragmentos de clúster en diferentes ubicaciones GEO. Esto le permite implementar fragmentos cerca de la ubicación geográfica de su aplicación y evitar viajes de red costosos. Y aumenta el rendimiento de la aplicación.
Solo recuerde que todo lo que estamos haciendo aquí es esbozar los requisitos. Definitivamente revisaremos estas configuraciones después de identificar, crear y optimizar nuestras colecciones.
Paso 3: Convierta y optimice las colecciones JSON
Ahora que tiene los requisitos básicos de su clúster de implementación, su "boceto" dictará sus estrategias de optimización.
Convertir tablas en colecciones
Primero, simplemente convierta las tablas de la base de datos relacional en colecciones y convierta sus columnas en atributos. Este es el normalizado datos provenientes de una base de datos relacional.
Desnormalice los datos incrustando documentos
A continuación, necesitas desnormalizar tablas aisladas, es decir, tablas que no significan nada a menos que se correlacionen con otra tabla. En términos relacionales, las tablas aisladas son mesas de unión. Por ejemplo, Detalles del pedido en una base de datos Northwind tiene más sentido cuando se menciona con referencia a una orden. Por lo tanto, la elección correcta sería incrustar los detalles del pedido dentro del Ordenar documentos.
Convertir relaciones
Ahora, lo que te queda son esas colecciones que contienen documentos que tienen sus respectivas mesas de unión incrustado dentro de ellos. Pero, ¿qué sucede con las relaciones de muchos a muchos, de uno a muchos y otras? Aquí es donde su conocimiento sobre los datos agrupados de forma natural y los datos a los que se accede en conjunto resulta útil.
En Ejemplo de migración de la base de datos NorthWind, la Local y Ordenar las tablas están relacionadas, pero no siempre se accede a ellas juntas. Por lo tanto, no tiene sentido incrustar el Objeto de cliente dentro de Documento de pedido. Además, incrustar el Documento de cliente duplicará datos innecesariamente, lo que queremos evitar en la medida de lo posible. En caso contrario un solo cambio en el perfil del Cliente requerirá que la aplicación realice el cambio en todos los Pedido.Cliente documentos. Un coste de cálculo innecesario.
Por otro lado, la aplicación siempre requiere Categorías cada vez que se recupera el Producto; por lo tanto, este es un buen candidato para la incrustación. Y no olvide que la belleza de los documentos JSON es que también pueden admitir matrices y matrices de documentos JSON para enriquecer sus objetos.
Modelo híbrido: lo mejor de la normalización y la desnormalización
Desde un NoSQL El esquema se basa en el flujo de datos de la aplicación, si una colección tiene la ventaja de mantenerla tanto incrustada como no incrustada, entonces adopte el modelo híbrido.
En la base de datos de ejemplo Northwind, a la que se hace referencia en la página anterior, este fenómeno se puede ver en el Categoría y Producto mesas. El escenario es que cada vez que un Producto se accede, la aplicación necesita saber su Categoría. Pero la aplicación también necesita averiguar Productos by Categoría.
Si Categoría se mantuvo en una tabla separada, una sola búsqueda de producto significaría dos llamadas a la base de datos, una para buscar el Producto y el otro para ir a buscar el respectivo Categoría, por lo tanto, el costo adicional de la red. Si solo el Categoría estaba incrustado, luego, para averiguar todas las categorías, tendría que ejecutar la siguiente instrucción SQL:
SELECT DISTINCT product.Category.CategoryName FROM Products;Una consulta SQL simple pero no muy eficiente, ¿verdad? Así que la respuesta es mantener el Categoría documento en una colección separada, pero incruste solo la parte que necesariamente requiere el Producto. Esto se llama un Modelo híbrido.
Por ejemplo, en nuestro escenario, cuando la aplicación obtiene el documento del Producto, solo requiere conocer el Categoría Nombre y Categoría Descripción. Por lo tanto, es completamente innecesario incrustar el Categoría Imagen en cada documento del Producto. De hecho, si se duplica, requerirá mucho almacenamiento innecesario y aumentará el tamaño del documento, lo que impondrá un viaje de red costoso.
Este es un caso de uso perfecto de un Modelo Híbrido, por lo que las colecciones quedarían conformadas de la siguiente manera:
"Product" {
"name": "string",
"category": {
"name": "string",
"description": "string",
}
}y almacenando Categoría también por separado:
"Category" {
"name": "string",
"description": "string",
"picture": byte[]
}
}Decida su estrategia de distribución
Lo siguiente que debe decidir es la posible estrategia de distribución de sus colecciones. El boceto inicial de sus requisitos de configuración afecta directamente esto.
Tienes tres opciones para tu estrategia de distribución:
- Distribución basada en rango: Esta estrategia le permite definir cómo se distribuyen los datos entre los nodos según los rangos especificados para cada fragmento. Por ejemplo, si su NosDB el clúster está distribuido GEO con un fragmento en Nueva York y otro en Londres, entonces los datos generados y requeridos por las aplicaciones existentes en Nueva York deberían estar en la misma ubicación GEO, optimizando así los costos de la red. Esta estrategia se usa principalmente en clústeres distribuidos GEO, pero también tiene otros casos de uso.
- Distribución basada en hash: Hashing le permite distribuir datos entre fragmentos de manera uniforme, por lo que también distribuye la carga de manera uniforme. Esta estrategia no es la mejor opción para un clúster distribuido GEO, pero es ideal para NosDB clústeres dentro de un único centro de datos.
- Colección fragmentada única (Dishabilitar distribución): Esto deshabilita completamente la distribución en una colección. Use esta opción si su conjunto de datos es pequeño o desea específicamente que esté en una sola máquina.
Después de decidir su estrategia de distribución, es posible que desee revisar la optimización de su colección y su estrategia de implementación para ver si se pueden optimizar aún más. Un par de iteraciones suelen ser suficientes para llegar a una decisión.
Paso 4: Migrar datos
Finalmente, después de una intensa lluvia de ideas, aquí viene la parte relativamente fácil, es decir, migrar datos de la base de datos relacional a la NoSQL database.
Primero cree sus objetos .NET que representen sus colecciones y documentos JSON. ¡Sí! no se necesita ORM para insertar datos ya que la API .NET convierte automáticamente sus objetos .NET en documentos JSON. (Solo una nota, sin embargo, también puede optar por usar la integración ADO.NET que se envía junto con NosDB).
A continuación, acceda a su base de datos relacional y rellene estos objetos .NET e insértelos en el NoSQL database. También puede usar CLR Triggers y CLR UDF proporcionados por NosDB para ayudar a su migración.
Una vez que haya migrado sus datos, ahora es el momento de migrar su aplicación para adoptar los datos en términos de colecciones y documentos. Sin NosDB no tiene la opción de usar ADO.NET o CLR Triggers & UDF, pero aún puede usar la API.
Paso 5: Migrar aplicación
Hay varias formas de migrar su aplicación .NET en funcionamiento a NosDB. NosDB admite operaciones SQL como SELECCIONAR, INSERTAR, ACTUALIZAR y ELIMINAR. El uso de operaciones SQL reduce en gran medida la curva de aprendizaje para migrar su aplicación, es decir, puede usar la sintaxis a la que está acostumbrado. Incluso puede administrar el clúster de la base de datos en NosDB utilizando SQL.
NosDB admite SQL con todas las múltiples formas en que se puede acceder a la base de datos, a saber:
- API de .NET
- ADO.NET
- LINQ
- API de Java
- REST API
También puede usar la API del lado del servidor para mejorar el rendimiento de su aplicación, aprovechando el poder de distribución mediante el uso de marcos como MapReduce. Si no estás usando NosDB solo tiene la opción de llamar a la API directamente. SQL y ADO.NET solo son proporcionados por NosDB.
Paso 6: validar la migración
Después de la migración, la validación es el último paso de todo el proceso: verifique todas sus pruebas, valide los datos migrados y su aplicación. Este paso depende completamente de usted y de sus procesos comerciales. Banco el recién incorporado NoSQL database. Verifique los límites de la configuración de clúster actual (aunque puede escalar cuando lo desee) y equípese con las herramientas adecuadas como NosDB Management Studio para administrar y monitorear todo el clúster desde una sola ubicación.
¡Eso es todo! Si sigues estos pasos podrás organizar tu migración de una base de datos relacional a una NoSQL database en un proceso lógico de 6 pasos.