Llegamos a ustedes gracias a:



Reportajes y análisis

Cómo elegir una base de datos para su aplicación

[02/12/2019] Elegir la base de datos "correcta" puede ser a menudo crítico para el éxito de una aplicación. En lugar de seguir el consejo de los proveedores o utilizar una base de datos porque ya la tiene, es útil considerar el propósito fundamental y los requisitos del almacén de datos.

Estas son las preguntas más importantes que se deben hacer cuando se elige una base de datos:

  • ¿Cuántos datos espera almacenar cuando la aplicación esté madura?
  • ¿Cuántos usuarios espera atender simultáneamente en hora punta?
  • ¿Qué disponibilidad, escalabilidad, latencia, rendimiento y consistencia de datos necesita su aplicación?
  • ¿Con qué frecuencia cambiarán los esquemas de su base de datos?
  • ¿Cuál es la distribución geográfica de su población de usuarios?
  • ¿Cuál es la "forma" natural de sus datos?
  • ¿Su aplicación necesita procesamiento de transacciones en línea (OLTP), consultas analíticas (OLAP) o ambas?
  • ¿Qué proporción de lecturas y escrituras espera en la producción?
  • ¿Necesita consultas geográficas y/o consultas de texto completo?
  • ¿Cuáles son sus lenguajes de programación preferidos?
  • ¿Tiene un presupuesto? En caso afirmativo, ¿cubrirá las licencias y los contratos de apoyo?
  • ¿Existen restricciones legales para el almacenamiento de datos?

Expandiremos esas preguntas y sus implicaciones.

¿Cuánta información almacenará?

Si su estimación está en gigabytes o menos, entonces casi cualquier base de datos manejará sus datos, y las bases de datos en memoria son completamente factibles. Todavía hay muchas opciones de base de datos para manejar datos en el rango de terabytes (miles de gigabytes).

Si su respuesta está en petabytes (millones de gigabytes) o más, solo unas pocas bases de datos le servirán bien, y necesita estar preparado para los costos significativos de almacenamiento de datos, ya sea en gastos de capital para el almacenamiento local o en gastos operativos para el almacenamiento en nube. A esa escala, es posible que desee un almacenamiento por niveles para que las consultas sobre datos "en vivo" puedan ejecutarse en memoria o contra las unidades SSD locales para obtener velocidad, mientras que el conjunto de datos completo reside en discos giratorios para ahorrar.

¿Cuántos usuarios simultáneos?

Estimar la carga de muchos usuarios simultáneos es a menudo tratado como un ejercicio de dimensionamiento del servidor, que debe realizarse justo antes de instalar su base de datos de producción. Desafortunadamente, muchas bases de datos no pueden manejar miles de usuarios que consultan terabytes o petabytes de datos, debido a problemas de escalamiento.

La estimación de usuarios simultáneos es mucho más fácil para una base de datos utilizada por los empleados, que para una base de datos pública. Para esto último, es posible que necesite tener la opción de escalar a varios servidores para cargas inesperadas o estacionales. Desafortunadamente, no todas las bases de datos soportan el escalado horizontal sin necesidad de realizar manualmente el sharding de las tablas grandes.

¿Cuáles son sus requisitos de '-ilidad'?

En esta categoría incluyo disponibilidad, escalabilidad, latencia, rendimiento y consistencia de datos, aunque no todos los términos terminan en "-ilidad".

La disponibilidad es a menudo un criterio clave para las bases de datos transaccionales. Aunque no todas las aplicaciones necesitan funcionar las 24 horas del día, los 7 días de la semana, con una disponibilidad del 99,999%, algunas sí. Unas pocas bases de datos en nube ofrecen una disponibilidad de "cinco nueves", siempre y cuando se ejecuten en múltiples zonas de disponibilidad. Las bases de datos locales pueden configurarse normalmente para una alta disponibilidad fuera de los períodos de mantenimiento programados, especialmente si puede permitirse configurar un par de servidores activos-activos.

La escalabilidad, especialmente la escalabilidad horizontal, ha sido históricamente mejor para las bases de datos NoSQL que para las bases de datos SQL, pero varias bases de datos SQL se están poniendo al día. La escalabilidad dinámica es mucho más fácil de lograr en la nube. Las bases de datos con buena escalabilidad, pueden manejar muchos usuarios simultáneos mediante la ampliación o la salida hasta que el rendimiento sea suficiente para la carga.

La latencia se refiere tanto al tiempo de respuesta de la base de datos como al tiempo de respuesta de extremo a extremo de la aplicación. Lo ideal es que cada acción del usuario tenga un tiempo de respuesta de menos de un segundo, lo que a menudo se traduce en la necesidad de que la base de datos responda en menos de 100 milisegundos por cada transacción simple. Las consultas analíticas a menudo pueden tardar segundos o minutos. Las aplicaciones pueden preservar el tiempo de respuesta ejecutando consultas complicadas en segundo plano.

El rendimiento de una base de datos OLTP se mide normalmente en transacciones por segundo. Las bases de datos con alto rendimiento pueden soportar muchos usuarios simultáneos.

La consistencia de los datos suele ser "fuerte" para las bases de datos SQL, lo que significa que todas las lecturas devuelven los datos más recientes. La consistencia de los datos puede ser cualquier cosa desde "eventual" hasta "fuerte" para bases de datos NoSQL. La consistencia eventual ofrece una latencia más baja, con el riesgo de leer datos obsoletos.

La consistencia es la "C" en las propiedades ACID requeridas para la validez en caso de errores, particiones de red y fallas de alimentación. Las cuatro propiedades de ACID (por sus siglas en inglés) son Atomicidad, Consistencia, Aislamiento y Durabilidad.

¿Son estables sus esquemas de base de datos?

Si es poco probable que los esquemas de su base de datos cambien significativamente con el tiempo, y desea que la mayoría de los campos tengan tipos consistentes de registro a registro, entonces las bases de datos SQL serían una buena opción para usted. De lo contrario, las bases de datos NoSQL, algunas de las cuales ni siquiera soportan esquemas, podrían ser mejores para su aplicación. Sin embargo, hay excepciones. Por ejemplo, Rockset permite realizar consultas SQL sin imponer un esquema fijo o tipos consistentes a los datos que importa.

Distribución geográfica de los usuarios

Cuando los usuarios de su base de datos están en todo el mundo, la velocidad de la luz impone un límite más bajo en la latencia de la base de datos para los usuarios remotos, a menos que proporcione servidores adicionales en sus regiones. Algunas bases de datos permiten servidores de lectura-escritura distribuidos; otras ofrecen servidores de solo lectura distribuidos, y todas las escrituras se ven obligadas a pasar por un único servidor maestro. La distribución geográfica hace que el equilibrio entre consistencia y latencia sea aún más difícil.

La mayoría de las bases de datos que soportan nodos distribuidos globalmente y consistencia fuerte, usan grupos de consenso para acelerar la escritura sin degradar seriamente la consistencia, típicamente usando los algoritmos Paxos (Lamport, 1990) o Raft (Ongaro y Ousterhout, 2013). Las bases de datos distribuidas NoSQL que son eventualmente consistentes usan típicamente la replicación no consensuada de par a par, lo que puede llevar a conflictos cuando dos réplicas reciben escritos concurrentes en el mismo registro, conflictos que usualmente son resueltos heurísticamente.

Forma de los datos

Las bases de datos SQL almacenan clásicamente datos fuertemente tipados en tablas rectangulares con filas y columnas. Se basan en relaciones definidas entre tablas, utilizan índices para acelerar las consultas seleccionadas y JOINS para consultar varias tablas a la vez. Las bases de datos de documentos suelen almacenar JSON de escritura débil que puede incluir matrices y documentos anidados. Las bases de datos gráficas almacenan vértices y bordes, o triples o cuádruples. Otras categorías de bases de datos NoSQL incluyen almacenes de valores clave y columnares.

A veces los datos se generan en una forma que también funcionará para el análisis; a veces no, y será necesaria una transformación. A veces un tipo de base de datos se construye sobre otra. Por ejemplo, los almacenes de valor clave pueden ser la base de casi cualquier tipo de base de datos.

¿OLTP, OLAP o HTAP?

Para descifrar los acrónimos anteriores, la cuestión es si su aplicación necesita una base de datos para transacciones, análisis o ambos. Necesitar transacciones rápidas implica velocidad de escritura rápida e índices mínimos. La necesidad de análisis implica una rápida velocidad de lectura y muchos índices. Los sistemas híbridos utilizan varios trucos para soportar ambos requisitos, incluyendo tener una tienda transaccional primaria que alimenta a una tienda de análisis secundaria a través de la replicación.

Relación lectura/escritura

Algunas bases de datos son más rápidas en las lecturas y consultas, y otras son más rápidas en la escritura. La mezcla de lecturas y escrituras que espera de su aplicación es un número útil para incluir en sus criterios de selección de base de datos, y puede guiar sus esfuerzos de benchmarking. La elección óptima del tipo de índice difiere entre aplicaciones de lectura pesada (normalmente un árbol B) y aplicaciones de escritura pesada (a menudo un árbol de fusión estructurado en logs, también conocido como árbol LSM).

Índices y consultas geoespaciales

Si tiene datos geográficos o geométricos y desea realizar consultas eficientes para encontrar objetos dentro de un límite u objetos dentro de una distancia dada de una ubicación, necesita índices diferentes de los que necesitaría para los datos relacionales típicos. Un árbol R es a menudo la opción preferida para los índices geoespaciales, pero hay más de una docena de otras estructuras de datos de índices geoespaciales posibles. Hay un par de docenas de bases de datos que soportan datos espaciales; la mayoría soportan algunos o todos los estándares del Open Geospatial Consortium.

Índices y consultas de texto completo

Del mismo modo, la búsqueda eficiente de texto completo en los campos de texto requiere índices diferentes a los de los datos relacionales o geoespaciales. Normalmente, se construye un índice de lista invertida de palabras tokenizadas, y se busca para evitar hacer un costoso escaneo de tablas.

Lenguajes de programación preferidos

Mientras que la mayoría de las bases de datos soportan APIs para muchos lenguajes de programación, el lenguaje de programación preferido en su aplicación puede a veces influir en su elección de base de datos. Por ejemplo, JSON es el formato de datos natural para JavaScript, por lo que puede elegir una base de datos que soporte el tipo de datos JSON para una aplicación JavaScript.

Limitaciones presupuestarias

Las bases de datos tienen un precio que va de libre a muy caro. Muchas bases de datos tienen versiones gratuitas y de pago, y a veces tienen más de un nivel de oferta de pago, por ejemplo, ofreciendo una versión Enterprise y diferentes tiempos de respuesta de servicio. Además, algunas bases de datos están disponibles en la nube en términos de pago por uso.

Si elige una base de datos gratuita y de código abierto, es posible que tenga que renunciar al soporte de proveedores. Siempre y cuando tenga experiencia en la empresa, eso puede estar bien. Por otro lado, puede ser más productivo para su personal concentrarse en la aplicación, y dejar la administración y el mantenimiento de la base de datos a los vendedores o proveedores de cloud computing.

Restricciones legales

Existen muchas leyes sobre seguridad de datos y privacidad. En la UE, el GDPR tiene implicaciones de gran alcance para la privacidad, la protección de datos y la localización de los datos. En los Estados Unidos, la HIPAA regula la información médica y la GLBA regula la forma en que las instituciones financieras manejan la información privada de los clientes. En California, la nueva CCPA mejora los derechos de privacidad y la protección del consumidor.

Algunas bases de datos son capaces de manejar los datos de una manera que cumple con algunas o todas estas regulaciones, siempre y cuando se sigan las mejores prácticas. Otras bases de datos tienen fallas que hacen que sea muy difícil utilizarlas para obtener información personal identificable, sin importar cuán cuidadoso sea usted.

Honestamente, esa fue una larga lista de factores a considerar al elegir una base de datos, probablemente más de lo que usted preferiría considerar. Sin embargo, vale la pena tratar de responder a todas las preguntas de la mejor manera posible antes de arriesgarse a comprometer su proyecto con lo que resulta ser una base de datos inadecuada o excesivamente costosa.

Puede ver también