Llegamos a ustedes gracias a:



Reportajes y análisis

¿Qué base de datos debo utilizar?

[09/04/2014] Recientemente estuve en Chicago por unas semanas estableciendo la primera oficina satélite para mi compañía. Aunque Silicon Valley puede ser el hogar de los grandes fabricantes de big data, Chicago es el hogar de los usuarios y profesionales del big data. Así que muchas personas aquí comprenden que uno puede ir a una reunión o evento de big data casi todos los días de la semana.
Los eventos de big data ofrecen, casi inevitablemente, una introducción al NoSQL y los motivos por los que ya no puede seguir guardando todo en un RDBMS. Para empezar, gran parte de la audiencia se encuentra en territorio con el que no están familiarizados. Hay varios tipos de bases de datos NoSQL y varios motivos razonables para usarlas en diferentes situaciones para diferentes conjuntos de datos. El marketing sin sentido de la industria tecnológica dice NoSQL = escala, pero en realidad esto es mucho más complicado.
Parte del motivo por el que hay tantos tipos de bases de datos NoSQL radica en el teorema CAP, también conocido como el teorema de Brewer. Éste establece que uno puede ofrecer solo dos de las siguientes tres características: consistencia, disponibilidad y tolerancia a fallas. Los diferentes conjuntos de datos y las diferentes reglas de ejecución ocasionan que uno haga diferentes combinaciones. La complejidad de los datos y la escalabilidad del sistema también entran en juego.
Otra razón para esta divergencia se puede encontrar en la ciencia básica de la computación o inclusive en la matemática básica. Algunos conjuntos de datos pueden ser mapeados fácilmente hasta parejas de valores clave; en esencia, aplanar los datos no hace que éstos sean menos significativo, y no se necesita ninguna reconstrucción de sus relaciones. Por otro lado, hay conjuntos de datos en los que las relaciones con los otros elementos de datos son tan importantes como los elementos de datos en sí mismos.
Las bases de datos relacionales se basan en el álgebra relacional, que es más o menos una consecuencia de la teoría de conjuntos. Las relaciones basadas en la teoría de conjuntos son efectivas para muchos conjuntos de datos; pero en los que se requiere elementos de padre-hijo o de distancia de las relaciones, la teoría de conjuntos no es muy efectiva. Puede que necesite la teoría de las gráficas para diseñar eficientemente una solución de datos.
En otras palabras, las bases de datos relacionales son sobredimensionadas para unos datos que pueden ser usados efectivamente como pares de valores clave, y subdimensionadas para datos que necesitan más contexto. El sobredimensionamiento le costará escalabilidad y el subdimensionamiento le costará rendimiento.
Bases de datos de pares de valores clave
Las bases de datos de pares de valores clave incluyen la versión actual 1.8 de Couchbase y Apache Cassandra. Éstas son altamente escalables, pero no ofrecen ninguna ayuda a los desarrolladores con los conjuntos de datos complejos. Si necesita una tabla hash distribuida y respaldada en disco y puede buscar todo por identidad, éstas (Couchbase y Apache Cassandra) escalarán bien y serán muy rápidas. Sin embargo, si está buscando una clave, para obtener otra clave, para obtener otra clave, para obtener su valor, probablemente tenga un caso más complicado.
Existen varias y diferentes permutaciones de bases de datos de pares de valores clave. Éstas son básicamente distintas combinaciones del teorema CAP y diferentes configuraciones de almacenamiento y uso de memoria. En último término, consigue una especie de tabla hash.
Esto está bien para las listas de partes planas, siempre y cuando no sean compuestas. Esto también está bien para citas de stock, ahora, u otros tipos de listas en las que esa clave tiene significado y es la forma principal en la que verá el valor. Usualmente, éstas se combinan con un índice, y existe una forma de realizar búsquedas contra los valores o generar una lista de claves; pero si necesita mucho de eso, probablemente debería buscar algo más.
Bases de datos de familia de columna / grandes tablas
La mayoría de los almacenes de valor clave (incluyendo Cassandra) ofrecen alguna forma de agrupamiento por columnas y pueden considerar también la familia de columna o la gran tabla. Algunas bases de datos como HBase fueron diseñadas como almacenamiento de familia de columnas desde el principio. Ésta es una forma más avanzada de base de datos de pares de valor clave. Esencialmente, las claves y los valores se hacen compuestos. Piense en esto como un mapa de hash cruzado con un arreglo multidimensional. Básicamente, cada columna contiene una fila de datos.
De acuerdo a Robin Schumacher, vicepresidente de productos de DataStax, que vende una versión certificada de Cassandra. Un caso de uso popular para Cassandra son los datos de series de tiempo, los cuales pueden provenir de sensores, sitios web (por ejemplo, Web logs), datos financieros, etcétera. Los datos típicamente vienen a una alta tasa de velocidad, pueden venir desde múltiples lugares a la vez, se agregan rápidamente y requieren capacidades de escritura rápida, así como lectura de alto rendimiento en fracciones de tiempo.
También puede usar MapReduce en ellas, así que pueden ser buenos almacenamientos analíticos para datos semiestructurados. Son altamente escalables, pero usualmente no son transaccionales. Si las relaciones entre los datos son tan importantes como los datos mismos (como la distancia o los cálculos de rutas), entonces no utilice una base de datos de familia de columnas/grandes tablas.
Bases de datos de documentos
Muchos desarrolladores piensan que las bases de datos de documentos son el Santo Grial, dado que encajan perfectamente con la programación orientada a objetos. Habiendo proveedores de alto vuelo como 10gen (MongoDB), Couchbase y Couch DB de Apache, ahí es donde se genera la mayor parte del ruido.
Frank Weil de Couchbase señala que la compañía se está moviendo de una base de datos de pares de valor clave en versión 1.8 a una base de datos de documentos en 2.0. De acuerdo a él, la base de datos de documentos es una progresión natural. Desde el clustering hasta el acceso a los datos, las bases de datos de documentos y los almacenamientos de valor clave son exactamente lo mismo, excepto en una base de datos de documentos, la base de datos entiende los documentos en el almacenamiento.
El punto dulce para todo eso es donde usted probablemente ya genere documentos JSON. Como señala Max Schireson, presidente de 10gen, usted debería considerar una base de datos de documentos si sus datos son muy complejos para modelarse en una base de datos relacional. Por ejemplo, una seguridad derivada compleja podría ser difícil de almacenar en un formato tradicional. Los registros de salud electrónica ofrecen otro buen ejemplo. Si estuviera considerando usar almacenamiento XML, es una señal fuerte para que considere MongoDB y el uso de JSON/BSON.
Éste es probablemente su almacenamiento operativo -donde los datos son recolectados de los usuarios, sistemas, redes sociales o lo que sea que recolecte. Probablemente esto no sea desde donde está reportando, aunque las bases de datos como MongoDB frecuentemente tienen alguna forma disponible de MapReduce. Aunque, al menos en MongoDB, puede buscar en lo que sea, generalmente no conseguirá un rendimiento aceptable sin un índice.
Bases de datos gráficas
Las bases de datos gráficas tratan menos acerca del volumen de los datos o de la disponibilidad, y más bien tratan más acerca de cómo se relacionan sus datos y qué cálculos está intentando realizar. Según me dijo Philip Rathle, director senior de ingeniería de producto en Neo Technologies (fabricantes de Neo4j), las bases de datos gráficas son especialmente útiles cuando el conjunto de datos está interconectado fundamentalmente y no es tabular. El patrón de acceso a datos primario es transaccional, por ejemplo, OLTP/sistema de grabación vs. batch? teniendo en cuenta que las bases de datos gráficas permiten que las operaciones de relación ocurran transaccionalmente, algo que en el mundo RDBMS necesitaría realizarse en batch.
Esto va en contra de la mayor parte del marketing NoSQL: una razón específica para una base de datos gráfica es que usted necesita una transacción que sea más correcta para sus estructuras de datos de lo que ofrece una base de datos relacional.
Los usos comunes para las bases de datos relacionales incluyen problemas geoespaciales, motores de recomendación, análisis de red/nube, y bioinformática -básicamente, cualquier lugar en que la relación entre los datos sea tan importante como los datos mismos. Ésta también es una tecnología importante en diversas funciones de análisis financiero. Si desea averiguar cuán vulnerable es una compañía ante un poco de malas noticias sobre otra compañía, será crítico calcular cuán directa es la relación. Realizar este tipo de consulta en varias sentencias de SQL demanda mucho código y no será rápido, pero una base de datos gráfica realiza esta tarea de manera excelente.
Realmente no necesita una base de datos gráfica si sus datos son simples o tabulares. Una base de datos gráfica no es tampoco adecuada si está haciendo OLAP o análisis de longitud. Generalmente, las bases de datos gráficas se trabajan en conjunto con un índice para lograr una mejor búsqueda y visualización, pero la parte gráfica tiene que ser transversalizada; por eso, necesita un arreglo en algún nodo inicial.
Ordenándolo todo
Las bases de datos gráficas ofrecen un gran ejemplo de por qué es tan difícil denominar estos nuevos tipos de bases de datos. NuevaBD es mi nombre preferido -excepto que, algunas sean tan o más antiguas que los RDBMS. NoSQL no es un buen nombre porque algunas de ellas soportan SQL, y SQL es realmente ortogonal a las capacidades de estos sistemas.
Finalmente, big data no es precisamente un nombre correcto, porque no necesita grandes conjuntos de datos para aprovechar las bases de datos que encajan en sus datos de manera más natural que las bases de datos relacionales. Norelacionales no termina de usarse porque las bases de datos gráficas son muy relacionales; simplemente rastrean formas diferentes de relaciones que los RDBMS.
En verdad, éstas son el resto de las bases de datos que resuelven el resto de nuestros problemas. El marketing de las décadas pasadas, combinado con las limitaciones de hardware y de ancho de banda, así como con las expectativas más bajas en términos de latencia y volumen, evitaron que algunas de las bases de datos más antiguas alcancen amplia notoriedad como RDBMS.
Simplemente, así como no deberíamos tratar de resolver todos nuestros problemas con un RDBMS, no deberíamos intentar resolver todos nuestros problemas matemáticos con la teoría de conjuntos. Los problemas de datos de hoy se están volviendo complicados: la escalabilidad, el rendimiento (baja latencia) y las necesidades de volumen son mayores. Con la intención de resolver esos problemas, vamos a tener que usar más de una tecnología de base de datos.
Andrew C. Oliver, InfoWorld (EE.UU.)
Andrew C. Oliver es un experto consultor de software. Es muy conocido por haber fundado el proyecto POI, el cual ahora está hospedado en Apache. También fue uno de los primeros desarrolladores en JBoss.