Moving from SQL Server to Couchbase Part 2: Data Migration

En esta serie de entradas de blog, voy a exponer las consideraciones a tener en cuenta al pasar a una base de datos de documentos cuando se tiene una experiencia relacional. En concreto, Microsoft SQL Server en comparación con Servidor Couchbase.

En tres partes, voy a cubrir:

Modelización de datos
Los datos en sí (esta entrada del blog)
Aplicaciones que utilizan los datos

El objetivo es establecer algunas directrices generales que pueda aplicar a la planificación y el diseño de su aplicación.

Si quieres seguirme, he creado una aplicación que demuestra Couchbase y SQL Server lado a lado. Obtenga el código fuente en GitHuby asegúrese de descargar una versión preliminar para desarrolladores de Couchbase Server.

Tipos de datos en JSON frente a SQL

Couchbase (y muchas otras bases de datos de documentos) usan objetos JSON para los datos. JSON es un formato potente y legible por humanos para almacenar datos. Cuando se compara con los tipos de datos en tablas relacionales, hay algunas similitudes, y hay algunas diferencias importantes.

Todos los datos JSON se componen de 6 tipos: cadena, número, booleano, matriz, objeto y nulo. Hay muchos tipos de tipos de datos disponibles en SQL Server. Empecemos con una tabla que es una especie de traducción "literal", y trabajemos a partir de ahí.

Servidor SQL	JSON
nvarchar, varchar, text	cadena
int, float, decimal, doble	número
bit	booleano
null	null
Campos XML/hierarchyid	matriz / objeto

Servidor SQL

JSON

nvarchar, varchar, text

cadena

int, float, decimal, doble

número

bit

booleano

null

Campos XML/hierarchyid

matriz / objeto

Es importante entender cómo funciona JSON. He enumerado algunas diferencias de alto nivel entre los tipos de datos JSON y los tipos de datos SQL Server. Asumiendo que ya entiendes los tipos de datos SQL, puede que quieras pasar algún tiempo aprendiendo más sobre JSON y los tipos de datos JSON.

A cadena en SQL Server suele definirse mediante una longitud. nvarchar(50) o nvarchar(MAX) por ejemplo. En JSON, no es necesario definir una longitud. Basta con utilizar una cadena.

A número en SQL Server varía mucho en función de para qué se utilice. El sitio número en JSON es flexible, ya que puede almacenar números enteros, decimales o de coma flotante. En circunstancias especiales, como si necesitas una precisión específica o almacenar números muy grandes, es posible que desees almacenar un número como una cadena en su lugar.

A booleano en JSON es verdadero/falso. En SQL Server, es más o menos equivalente: un bit que representa verdadero/falso.

En JSON, cualquier valor puede ser null. En SQL Server, esto se establece campo por campo. Si un campo en SQL Server no está configurado como "nullable", se aplicará. En un documento JSON, no hay tal aplicación.

JSON no tiene fecha tipo de datos. A menudo, las fechas se almacenan como marcas de tiempo UNIX, pero también se pueden utilizar representaciones de cadenas u otros formatos para las fechas. El lenguaje de consulta N1QL dispone de diversas funciones de fechapor lo que si desea utilizar N1QL en fechas, puede utilizar esas funciones para planificar su almacenamiento de fechas en consecuencia.

En SQL Server, existe un geografía tipo de datos. En Couchbase, se admite el formato GeoJSON.

Hay algunos otros tipos de datos especializados en SQL Server, incluyendo hierarchyid, y xml. Típicamente, éstos serían desenrollados en objetos JSON y/o referenciados por clave (como se explora en parte 1 de esta serie de blogs sobre modelado de datos). Todavía puede almacenar XML/JSON dentro de una cadena si lo desea, pero si lo hace, entonces no puede utilizar toda la potencia de N1QL en esos campos.

Migración y traducción de datos

Dependiendo de tu organización y tu equipo, puede que tengas que traer a gente de múltiples roles para asegurar una migración exitosa. Si tienes un DBA, ese DBA tendrá que saber cómo ejecutar y administrar Couchbase tan bien como SQL Server. Si eres DevOps, o tienes un equipo DevOps, es importante involucrarlos desde el principio, para que sean conscientes de lo que estás haciendo y puedan ayudarte a coordinar tus esfuerzos. Pasar a una base de datos de documentos no significa que ya no es necesario que participen los DBA, Ops o DevOps. Si es posible, estas funciones también deben participar en el modelado de datos, para que puedan aportar información y comprender lo que está sucediendo.

Después de haber diseñado su modelo con parte 1 sobre modelado de datospuedes empezar a mover datos a Couchbase.

Para una migración ingenua (de 1 fila a 1 documento), puede escribir un programa muy sencillo que recorra las tablas, columnas y valores de una base de datos relacional y genere los documentos correspondientes. Una herramienta como Dapper manejaría todas las traducciones de tipos de datos dentro de C# y las introduciría en el SDK .NET de Couchbase.

Sin embargo, los datos completamente planos son relativamente infrecuentes, por lo que, para modelos más complejos, es probable que tenga que escribir código para migrar del antiguo modelo relacional al nuevo modelo documental.

He aquí algunas cosas que conviene tener en cuenta al escribir código de migración (de cualquier tipo, pero especialmente de relacional a no relacional):

Dedique tiempo suficiente a la planificación. Durante la migración, puede que descubra que necesita replantearse su modelo. Tendrá que hacer pruebas y ajustes, y es mejor disponer de tiempo extra que cometer errores con las prisas. La migración de datos es un ciclo iterativo: migrar una tabla, ver si funciona, hacer ajustes y seguir iterando. Es posible que tenga que repetir este ciclo varias veces.
Pruebe su migración utilizando datos reales. Los datos pueden estar llenos de sorpresas. Puede que piense que el campo NVARCHAR sólo contiene representaciones de cadenas de números, pero puede que haya algunas filas anómalas que contengan palabras. Utilice una copia de los datos reales para probar y verificar su migración.
Prepárese para ejecutar la migración varias veces. Tenga un plan para limpiar una migración fallida y empezar de nuevo. Puede tratarse de un simple DELETE FROM cubo en N1QL, o podría ser una serie de limpiezas más matizadas y específicas. Si lo planificas desde el principio, será más fácil. Automatiza tu migración para que sea menos dolorosa.
¿ETL o ELT? Extraer-Transformar-Cargar, o Extraer-Cargar-Transformar. ¿Cuándo vas a hacer una transformación? Cuando pones datos en Couchbase, la flexibilidad de JSON te permite transferir in situ después de carga si lo desea.

Ejemplo de migración ETL

Escribí una aplicación de consola de migración muy simple usando C#, Entity Framework y el SDK .NET de Couchbase. Migra tanto el carrito de la compra como los ejemplos de redes sociales de la entrada anterior. La aplicación El código fuente está disponible en GitHub.

Esta aplicación va a realizar la transformación, por lo que se trata de un enfoque ETL. Este enfoque utiliza Entity Framework para mapear tablas relacionales a clases C#, que luego se insertan en documentos. El modelo de datos para Couchbase puede ser mejor representado por clases C# que por tablas relacionales (como se demostró en la entrada anterior del blog), por lo que este enfoque tiene menor fricción.

Voy a utilizar C# para escribir un programa de migración, pero la automatización es lo importante, no la herramienta específica. Esto va a ser esencialmente "tirar" el código después de la migración se ha completado. Mi enfoque C# no hace ningún tipo de procesamiento por lotes, y probablemente no es muy adecuado para grandes cantidades de datos, por lo que podría ser una buena idea utilizar una herramienta como Talend y/o un enfoque ELT para datos a muy gran escala/Empresa.

He creado un ShoppingCartMigrator y una clase SocialMediaMigrator clase. Sólo voy a cubrir el carrito de la compra en este post. Le paso un Couchbase cubo y Entity Framework contexto que utilicé en la última entrada del blog. (En su lugar, puede pasar un archivo NHibernate sesión o un simple DbConnection aquí, según sus preferencias).

public class ShoppingCartMigrator
{
    readonly IBucket _bucket;
    readonly SqlToCbContext _context;

    public ShoppingCartMigrator(IBucket bucket, SqlToCbContext context)
    {
        _bucket = bucket;
        _context = context;
    }
}

público clase ShoppingCartMigrator

{

sólo lectura IBucket _bucket;

sólo lectura SqlToCbContext _contexto;

público ShoppingCartMigrator(IBucket cubo, SqlToCbContext contexto)

{

_bucket = cubo;

_contexto = contexto;

}

Con esos objetos en su lugar, creé un Vaya a método para realizar la migración, y un Limpieza para eliminar los documentos creados en la migración, si así lo decidiera.

Para el Vaya a dejo que Entity Framework haga el trabajo duro de las uniones y haga un bucle a través de cada carrito de la compra.

public bool Go()
{
    var carts = _context.ShoppingCarts
        .Include(x => x.Items)
        .ToList();
    foreach (var cart in carts)
    {
        var cartDocument = new Document<dynamic>
        {
            Id = cart.Id.ToString(),
            Content = MapCart(cart)
        };
        var result = _bucket.Insert(cartDocument);
        if (!result.Success)
        {
            Console.WriteLine($"There was an error migrating Shopping Cart {cart.Id}");
            return false;
        }
        Console.WriteLine($"Successfully migrated Shopping Cart {cart.Id}");
    }
    return true;
}

público bool Vaya a()

{

var carros = _contexto.Carros de la compra

.Incluya(x => x.Artículos)

.ToList();

foreach (var carro en carros)

{

var cartDocument = nuevo Documento<dinámico>

{

Id = carro.Id.ToString(),

Contenido = MapCart(carro)

};

var resultado = _bucket.Inserte(cartDocument);

si (!resultado.Éxito)

{

Consola.WriteLine($"Se ha producido un error al migrar el carro de la compra {cart.Id}");

devolver falso;

}

Consola.WriteLine($"Migrado con éxito el carro de la compra {cart.Id}");

}

devolver verdadero;

}

He optado por abortar la migración si se produce un solo error. Es posible que no desee hacerlo. Es posible que desee registrar en un archivo en su lugar, y hacer frente a todos los registros que causan errores a la vez.

Para la limpieza, he optado por eliminar todos los documentos que tienen un tipo de "ShoppingCart".

public void Cleanup()
{
    Console.WriteLine("Delete all shopping carts...");
    var result = _bucket.Query<dynamic>("DELETE FROM `sqltocb` WHERE type='ShoppingCart';");
    if (!result.Success)
    {
        Console.WriteLine($"{result.Exception?.Message}");
        Console.WriteLine($"{result.Message}");
    }
}

público void Limpieza()

{

Consola.WriteLine("Borrar todos los carros de la compra...");

var resultado = _bucket.Consulta<dinámico>("DELETE FROM `sqltocb` WHERE type='ShoppingCart';");

si (!resultado.Éxito)

{

Consola.WriteLine($"{resultado.Excepción?.Mensaje}");

Consola.WriteLine($"{resultado.Mensaje}");

}

Este es el enfoque más sencillo. Un enfoque más complejo podría consistir en colocar un campo marcador temporal de "huella digital" en determinados documentos y, a continuación, eliminar los documentos con una determinada huella digital en la limpieza. (Por ejemplo DELETE FROM sqltocb WHERE huella digital = '999cfbc3-186e-4219-ab5d-18ad130a9dc6'). O viceversa: identifique los datos problemáticos para su posterior análisis y elimine el resto. Sólo tiene que asegurarse de limpiar estos campos temporales cuando la migración se haya completado con éxito.

Cuando pruebes esto por ti mismo, puede que quieras ejecutar la aplicación de consola dos veces, sólo para ver la limpieza en acción. El segundo intento dará lugar a errores porque estará intentando crear documentos con claves duplicadas.

¿Y las demás funciones de SQL Server?

No todo en SQL Server tiene una contrapartida directa en Couchbase. En algunos casos, nunca tendrá una contraparte. En algunos casos, habrá un equivalente aproximado. Algunas características llegarán en el futuro, ya que Couchbase está bajo un rápido y activo desarrollo de código abierto, y se están añadiendo nuevas características cuando es apropiado.

También ten en cuenta que las bases de datos de documentos y las bases de datos NoSQL a menudo fuerzan la lógica de negocio fuera de la base de datos en mayor medida que las bases de datos relacionales. Tan bueno como sería si Couchbase Server tuviera todas las características bajo el sol, siempre hay compensaciones. Algunas son de naturaleza técnica, otras son decisiones de diseño de producto. Se podrían hacer concesiones para añadir características de estilo relacional, pero en algún punto de ese viaje, Couchbase deja de ser una base de datos rápida y escalable y empieza a ser "sólo otra" base de datos relacional. Ciertamente hay mucha convergencia en las bases de datos relacionales y no relacionales, y cada año se producen muchos cambios.

Con esto en mente, permanece atento a la última entrada del blog de la serie. Este cubrirá los cambios en la codificación de aplicaciones que vienen con el uso de Couchbase, incluyendo:

SQL/N1QL
Procedimientos almacenados
Niveles de servicio
Disparadores
Vistas
Serialización
Seguridad
Concurrencia
Autonúmero
OR/Ms y ODMs
Transacciones

Resumen

Esta entrada de blog comparó y contrastó las características de datos disponibles en Couchbase Server con SQL Server. Si actualmente utilizas SQL Server y estás considerando añadir una base de datos de documentos a tu proyecto o empezar uno nuevo, estoy aquí para ayudarte.

Echa un vistazo a la Portal para desarrolladores de Couchbase para más detalles.

Póngase en contacto conmigo en matthew.groves@couchbase.comHaga una pregunta en los foros de Couchbaseo envíeme un mensaje a Twitter @mgroves.

Matthew Groves

Platform

Self-Managed

Services

Capabilities

Why Couchbase?

Migrate to Capella

By Use Case

By Industry

By Application Need

Popular Docs

By Developer Role

COMMUNITY

Join the Developer Community

Resource Center

Education

Compare

About

Partnerships

Our Services

Partners: Register a Deal

Ready to register a deal with Couchbase?

Marriott

Todos los mensajes

Paso de SQL Server a Couchbase Parte 2: Migración de datos

Tipos de datos en JSON frente a SQL

Migración y traducción de datos

Ejemplo de migración ETL

¿Y las demás funciones de SQL Server?

Resumen

Autor

Publicado por Matthew Groves

4 Comentarios

Dejar una respuesta Cancelar respuesta