Compartir vía

Criterios para elegir un almacén de datos

  • Artículo

En este artículo se describen los criterios de comparación que puede utilizar para evaluar un almacén de datos. El objetivo es ayudarle a determinar qué tipos de almacenamientos de datos pueden cumplir los requisitos de la solución.

Consideraciones generales

Tenga en cuenta estas consideraciones al realizar la selección.

Requisitos funcionales

  • Formato de datos: ¿qué tipo de datos pretende almacenar? Los tipos comunes son los datos transaccionales, objetos JSON, telemetría, índices de búsqueda o archivos sin formato.
  • Tamaño de los datos: ¿de qué tamaño son las entidades que necesita almacenar? ¿Estas entidades deben conservarse como un único documento o se pueden dividir entre varios documentos, tablas y colecciones?
  • Escala y estructura: ¿cuál es la cantidad total de capacidad de almacenamiento que necesita? ¿Prevé realizar particiones de los datos?
  • Relaciones de datos: ¿los datos deben admitir relaciones de uno a varios o de muchos a muchos? ¿Son las relaciones en sí una parte importante de los datos? ¿Necesita unir o combinar datos de otra forma desde dentro del mismo conjunto de datos o desde conjuntos de datos externos?
  • Modelo de coherencia: ¿qué importancia tiene para que las actualizaciones realizada en un nodo aparezcan en otros nodos, antes de que se puedan realizar más cambios? ¿Puede aceptar una coherencia definitiva? ¿Necesita garantías ACID para las transacciones?
  • Flexibilidad de esquemas: ¿qué tipo de esquemas se aplicará a los datos? ¿Usará un esquema fijo, un enfoque de esquema basado en escritura o un enfoque de esquema basado en lectura?
  • Simultaneidad: ¿qué tipo de mecanismo de simultaneidad desea usar al actualizar y sincronizar los datos? ¿La aplicación realizará varias actualizaciones que puedan entrar en conflicto? Si es así, puede requerir el bloqueo de registros y el control de simultaneidad pesimista. Como alternativa, ¿puede admitir controles de simultaneidad pesimista? En su caso, ¿basta con un control de simultaneidad sencillo basado en marcas de tiempo o necesita la funcionalidad agregada del control de simultaneidad de varias versiones?
  • Movimiento de datos: ¿la solución deberá realizar las tareas ETL para mover datos a otros almacenes o almacenamientos de datos?
  • Ciclo de vida de datos: ¿los datos son de solo una escritura o de varias lecturas? ¿Pueden moverse a un almacenamiento de acceso esporádico o en frío?
  • Otras característicad admitidas: ¿necesita otras características específicas, como la validación del esquema, agregaciones, indexación, búsqueda de texto completo, MapReduce u otras funcionalidades de consulta?

Requisitos no funcionales

  • Rendimiento y escalabilidad: ¿cuáles son los requisitos de rendimiento de los datos? ¿Tiene requisitos específicos para la velocidad de ingesta de datos y la velocidad de procesamiento de datos? ¿Cuáles son los tiempos de respuesta aceptables para realizar consultas y agregaciones de datos una vez ingeridos? ¿Cuánto necesitará escalar verticalmente el tamaño del almacén de datos? ¿La carta de trabajo es más de lectura intensiva o de escritura intensiva?
  • Confiabilidad: ¿qué acuerdo general de nivel de servicio necesita admitir? ¿Qué nivel de tolerancia a errores es necesario proporcionar para los consumidores de datos? ¿Qué tipo de funcionalidades de copia de seguridad y restauración necesita?
  • Replicación: ¿necesitará que los datos se distribuyan entre varias réplicas o regiones? ¿Qué tipo de funcionalidad de replicación de datos necesita?
  • Límites: ¿los límites de un almacén de datos particular admiten los requisitos de escalado, el número de conexiones y el rendimiento?

Administración y costo

  • Servicios administrados: cuando sea posible, utilice un servicio de datos administrado, a menos que necesite funcionalidades específicas que solo se puedan encontrar en un almacén de datos hospedado en infraestructura como servicio (IaaS).
  • Disponibilidad de región: si se trata de servicios administrados, ¿el servicio se encuentra disponible en todas las regiones de Azure? ¿La solución debe hospedarse en determinadas regiones de Azure?
  • Portabilidad: ¿los datos deben migrarse a centros de datos externos, locales o a otros entornos de hospedaje en la nube?
  • Licencias: ¿tiene preferencia por un propietario frente al tipo de licencia de OSS? ¿Existen otras restricciones externas del tipo de licencia que puede usar?
  • Coste total: ¿cuál es el costo total de usar el servicio en la solución? ¿Cuántas instancias necesitará ejecutar para satisfacer los requisitos de tiempo de actividad y rendimiento? Tenga en cuenta los costos de las operaciones en este cálculo. Una razón para preferir servicios administrados es el menor costo operativo.
  • Rentabilidad: ¿puede crear una partición de los datos para almacenarlos con más rentabilidad? Por ejemplo, ¿puede mover objetos grandes de una base de datos relacional cara a un almacén de objetos?

Seguridad

  • Seguridad: ¿qué tipo de cifrado necesita? ¿Necesita cifrado en reposo? ¿Qué mecanismo de autenticación desea usar para conectarse a los datos?
  • Auditoría: ¿qué tipo de registro de auditoría necesita generar?
  • Requisitos de red: ¿necesita restringir o administrar el acceso a los datos desde otros recursos de red? ¿Necesita que los datos solo sean accesibles desde dentro del entorno de Azure? ¿Los datos deben ser accesibles desde subredes o direcciones IP específicas? ¿Deben ser accesibles desde aplicaciones o servicios hospedados en centros de datos locales o en otros centros de datos externos?

DevOps

  • Conjunto de aptitudes: ¿hay lenguajes de programación, sistemas operativos u otra tecnología que su equipo domine? ¿Hay otros con los que a su equipo le resultaría difícil trabajar?
  • Clientes: ¿existe una buena compatibilidad del cliente con los lenguajes de desarrollo?

Pasos siguientes