Servidor Couchbase

Prueba de concepto: Argumentar el paso a lo relacional

Una prueba de concepto puede ser justo lo que necesitas para empezar a evaluar Couchbase.

Hemos estado blogueando mucho sobre el aspecto técnico de pasar de una base de datos relacional como Oracle o SQL Server a Couchbase. Estos son algunos de los recursos y posts que hemos publicado:

Pero en este artículo vamos a hablar más del proceso general que de los detalles técnicos. Verás cinco pasos para crear una prueba de concepto con éxito. Y si alguna vez necesitas ayuda para empezar, puedes hable con un ingeniero de soluciones Couchbase.

Pasos de la prueba de concepto

Estos pasos no son sólo para migrar una aplicación existente a Couchbase, también funcionan igual de bien para crear una nueva aplicación "greenfield" con Couchbase, o incluso aumentar una base de datos existente (en lugar de reemplazarla por completo).

Al crear una Prueba de Concepto, es una buena idea mantener el alcance tan pequeño y simple como sea posible. Algunas preguntas:

  • ¿Probará o refutará lo que necesitas y te ayudará a dar el siguiente paso?
  • ¿Puede lograrse con rapidez? Si lleva demasiado tiempo o no es una prioridad, podría desvanecerse.
  • Pregunta a Miembro del equipo técnico de Couchbase¿se adapta bien a Couchbase? Puedes aprovechar su experiencia para ahorrarte algunos disgustos.

Seleccione un caso de uso y una aplicación

Cuando hablo con la gente sobre Couchbase y NoSQL, les digo que lo único peor que no usar Couchbase es usar Couchbase para lo incorrecto y volverse amargado con las bases de datos de documentos.

Las ventajas de una base de datos distribuida como Couchbase son:

  • Mejor rendimiento
  • Mayor escalabilidad
  • Mayor disponibilidad
  • Mayor agilidad/flexibilidad de los datos
  • Mejora de la gestión operativa

Si tu aplicación puede beneficiarse de alguna de esas características, merece la pena que eches un vistazo a Couchbase. Couchbase puede no ser la mejor opción si necesitas transacciones multi-documento. Pero como mostré en mi post sobre modelado de datosSi puede anidar los datos en lugar de dispersarlos en trozos, puede que no necesite las transacciones multidocumento tanto como cree.

Además, las conversaciones con los clientes de Couchbase nos han llevado a identificar la necesidad de ir más allá de una base de datos tradicional para potenciar interacciones. Marriott lo denomina ratio "look-to-book".

Think about the interaction to transaction ratio in your proof of concept

Si se encuentra en una situación en la que necesita registrar transacciones en su base de datos tradicional, pero desea una base de datos de baja latencia, flexible y escalable para alimentar todas las interacciones que conducen a ella, Couchbase podría ser la opción adecuada para usted.

Algunos de los casos de uso para los que Couchbase ha sido un gran ajuste incluyen:

Definir los criterios de éxito

Una vez que hayas decidido que tienes un caso de uso que sería bueno para Couchbase, necesitas definir qué significa que una prueba de concepto tenga éxito.

Ejemplos de criterios:

  • Mejoras de rendimiento y latencia - Esto podría reducirse a un número, como "latencia de 5 ms en el percentil 95".
  • Facilidad de ampliación - ¿Es fácil escalar ahora? ¿Cuánto tiempo necesita una persona? ¿Cuántos sábados a las 2 de la mañana hay que trabajar para hacer actualizaciones?
  • Ciclos de desarrollo más rápidos - ¿La gestión de esquemas consume mucho tiempo en tus sprints? Una prueba de concepto con Couchbase puede ayudarte a demostrar si un modelo flexible te va a ahorrar tiempo.
  • Mantenimiento y costes

Cualquiera que sea el criterio, es bueno definirlo al principio, para poder trabajar en su consecución. Un objetivo vago como "solo quiero jugar con NoSQL" está bien para un desarrollador individual, pero un criterio de éxito bien definido va a ser fundamental para convencer a los responsables de la toma de decisiones.

Conozca sus datos

Como cubrí en el Post sobre modelado de datos JSONEs importante que entiendas tus datos antes de empezar a escribir código. Tienes que entender lo que vas a modelar y cómo tiene que funcionar tu aplicación.

Migrar de una base de datos relacional a una documental no va a ser un ejercicio puramente mecánico. Si tiene previsto migrar datos, es mejor que empiece por pensar en el aspecto que tendrían independientemente de cómo estén almacenados actualmente. Dibuja un concepto en una pizarra sin utilizar "tablas" ni "documentos".

Identificar los patrones de acceso

También traté este tema en mi Post sobre modelado de datos JSON. Couchbase es muy flexible en la forma en que puede almacenar datos. Pero el acceso a los datos también es flexible. El diseño de tu modelo debe tener eso en cuenta.

En esa entrada de blog, expuse algunas reglas generales para los documentos anidados/separados. A un nivel superior, puedes empezar pensando en el acceso a los datos de esta manera:

  • Clave/valor - La habilidad de obtener/cambiar un documento basado en su clave. Este es el método más rápido y de menor latencia disponible en Couchbase.
  • Consulta N1QL - N1QL es SQL para datos JSON, disponible en Couchbase. Puede consultar datos de cualquier forma que puedas imaginar. Y lo que es más importante, puedes consultar datos basándote en algo otros que su llave.
  • Búsqueda de texto completo - Cuando se necesita realizar una consulta basada en texto con conocimiento de idiomas. Es ideal, por ejemplo, para búsquedas dirigidas por el usuario.
  • Map/Reduce - Escribir una función pura para calcular los resultados de la consulta por adelantado. N1QL le está quitando mucha carga de trabajo a M/R, pero sigue siendo bueno para algunos tipos especializados de agregación.
  • Geoespacial - Consulta de documentos a partir de información geográfica o de localización.
  • Análisis/informes - Couchbase Analytics (actualmente en previsualizar) puede proporcionarle un acceso no operativo muy indexado a sus datos. Puede ejecutar informes complejos sin afectar a los usuarios cotidianos.

Revisar la arquitectura

Al final de su prueba de concepto, puede medir sus resultados en función de los criterios que creó al principio.

Puede ser una buena idea iterar sobre esta prueba de concepto: puedes aplicar lo que has aprendido en cada iteración posterior. Si mantienes las iteraciones cortas, puedes aprender lo que has aplicado más rápido. Esto no sólo es cierto para Couchbase, por cierto, ¡sino para cualquier cosa!

Por último, si tu prueba de concepto es un éxito (y sé que lo será), es hora de prepararse para la producción. Tómate tu tiempo para revisar la arquitectura, las decisiones que has tomado, lo que ha funcionado bien, lo que no ha funcionado bien, etcétera. Cuanto más documentes, mejor le irá al resto del equipo y de la organización en el próximo proyecto.

Resumen

Crear una prueba de concepto con estos cinco pasos te ayudará a tener éxito. Lo único que queda por hacer es empezar:

Comparte este artículo
Recibe actualizaciones del blog de Couchbase en tu bandeja de entrada
Este campo es obligatorio.

Autor

Publicado por Matthew Groves

A Matthew D. Groves le encanta programar. No importa si se trata de C#, jQuery o PHP: enviará pull requests para cualquier cosa. Lleva codificando profesionalmente desde que escribió una aplicación de punto de venta en QuickBASIC para la pizzería de sus padres, allá por los años noventa. Actualmente trabaja como Director de Marketing de Producto para Couchbase. Su tiempo libre lo pasa con su familia, viendo a los Reds y participando en la comunidad de desarrolladores. Es autor de AOP in .NET, Pro Microservices in .NET, autor de Pluralsight y MVP de Microsoft.

Deja un comentario

¿Listo para empezar con Couchbase Capella?

Empezar a construir

Consulte nuestro portal para desarrolladores para explorar NoSQL, buscar recursos y empezar con tutoriales.

Utilizar Capella gratis

Ponte manos a la obra con Couchbase en unos pocos clics. Capella DBaaS es la forma más fácil y rápida de empezar.

Póngase en contacto

¿Quieres saber más sobre las ofertas de Couchbase? Permítanos ayudarle.