nabihaali - Fotolia
Los tres errores más comunes de NoSQL que usted no quiere cometer
Aquí hay tres errores comunes que las organizaciones todavía están haciendo cuando se trata de NoSQL –y cómo evitarlos
Al igual que muchas tecnologías emergentes, NoSQL ha pasado por un ciclo de éxito que vio la implementación generalizada seguida de resultados decididamente mixtos. La mentalidad de cargo y de culto que tenía a todo el mundo abordando del tren de las bases de datos no relacionales sin duda ha dado lugar a ciertas vergonzosas regresiones de alto perfil. No hay una parte que tenga toda la culpa. Los vendedores presentaron su solución como la bala de plata para arreglar todos los problemas mientras que los desarrolladores con grandes sueños para el futuro hablaron sobre la creciente necesidad de mayor escalabilidad de bases de datos para atraer dólares de los inversores.
Ciertamente, los dueños de negocios pueden ser perdonados por esperar que una solución indolora a los problemas de bases de datos estuviera al fin a la mano. Pero ahora que la primera generación ha alcanzado su punto máximo y la solución está empezando a madurar, ha llegado el tiempo para reagruparse y revisar las lecciones aprendidas durante la última década. Aquí hay tres errores comunes que las organizaciones todavía están haciendo cuando se trata de NoSQL –y cómo evitarlos.
1. NoSQL es sobre algo más que la escalabilidad
Eric Redmond, autor de Siete bases de datos en siete semanas, dice que el error más común que la gente comete es equiparar NoSQL con una escala web. Redmond dice que se ha convertido en casi una broma dentro de la comunidad de base de datos. Es una suposición comprensible. Después de todo, los progenitores de las bases de datos no relacionales de hoy eran compañías como Google y Amazon que se enfocaban en la manera de abordar los problemas de escalabilidad masiva en un entorno web. Incluso el nombre Mongo proviene de huMONGOus –una referencia al volumen de datos y de tráfico que se esperaba que manejara esta popular base de datos de almacenamiento de documentos.
Pero pensando en NoSQL sólo desde el punto de vista de la escalabilidad puede conducir a decisiones pobres. Incluso una organización más pequeña puede beneficiarse de las soluciones NoSQL si se trata en su mayoría con datos de medios sociales que están mejor representados en gráficos. O bien, una organización más grande con una gran cantidad d datos todavía podría necesitar depender principalmente de SQL para consultas sofisticadas. Es realmente más sobre el caso de uso y requisitos no funcionales que sólo la escala de los datos.
Conclusión clave: No se deje absorber por la próxima gran cosa. Ponga las necesidades y realidades del negocio en primer lugar. Hacer una copia de la infraestructura de Google no hará que su empresa sea el próximo Google.
2. Los desarrolladores necesitan evolucionar
Ann Kelly y Dan McCreary, coautores de Dando sentido a NoSQL, señalan otro gran error. En un proyecto web reciente, de alto perfil, un equipo de integración mal seleccionado generó un enorme problema. "El cliente trajo una base de datos NoSQL muy robusta, de gran alcance, y madura, MarkLogic. A continuación, se contrató a un integrador que sólo tenía programadores de Java y sólo estaban familiarizados con bases de datos relacionales. Gastaron aproximadamente entre 30-40 millones de dólares construyendo código que no necesitaba escribirse y que será eliminado." La página web en cuestión es, por supuesto, el notorio healthcare.gov.
Dan dice que este no es el primer proyecto NoSQL donde esto ha sucedido, y no será el último. Un equipo que no tiene experiencia en la escritura de código para bases de datos no relacionales es muy probable que tenga problemas similares. Cuando los desarrolladores utilizan un proceso viejo con la nueva tecnología, es fácil sobre-desarrollar. Basarse en las clases UML y Java para crear código elaborado simplemente no es necesario en el mundo racionalizado del almacenamiento de documentos.
Conclusión clave: Cuando los documentos se asignen directamente a los objetos, el código puede ser magro y con una fuerte orientación. Si el código está proliferando, investigue las herramientas, la metodología, y la mentalidad del equipo para determinar el verdadero problema.
3. La distribución es difícil, incluso cuando se hace más fácil por NoSQL
Eric Redmond está de acuerdo en que no hay sustituto para el conocimiento y la experiencia, ya sea en la implementación o la administración en curso. "Cuando se está hablando de gran escala, la base de datos no es el problema. El problema es en la comprensión de cómo manejarlo operativamente. Puede instalar Couch [de Apache] y ejecutar un montón de consultas en una máquina. Pero una vez que intente distribuirlo a través de múltiples máquinas, se convierte en un sistema distribuido y es un ámbito totalmente diferente. Usted tendría que ser un talentoso administrador de sistemas y un operador talentoso. El hecho de que se puede escribir una consulta que rápidamente se ejecuta en la máquina de desarrollo local, a menudo no influye en lo bien que va a escalar horizontalmente a través de cientos de máquinas."
Afortunadamente, Redmond dice que algunas de las bases de datos NoSQL están diseñadas para ayudar a evitar que los desarrolladores se den un tiro en el pie. Couch es un ejemplo, ya que utiliza automáticamente MapReduce con el supuesto de que el usuario está haciendo una consulta contra muchos servidores. Riak es otro ejemplo. Para aquellos que dicen que encuentran difícil de usar Riak, Redmond tiene algunas malas noticias. "Es difícil de utilizar porque la escritura de consultas en un entorno distribuido es difícil."
Conclusión clave: Elija una base de datos NoSQL que haga cumplir las mejores prácticas. Además, recuerde que un almacén de valor clave es uno de los patrones generales más simples que son fácilmente escalables.
