Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Selección de una base de datos para una aplicación SaaS
Para muchas aplicaciones SaaS multiusuario, la selección de una base de datos operativa se puede resumir en una elección entre bases de datos relacionales y no relacionales, o una combinación de ambas. Para tomar una decisión, tenga en cuenta estas características y requisitos de datos de aplicaciones de alto nivel:
-
Modelo de datos de la aplicación
-
Patrones de acceso a los datos
-
Requisitos de latencia de base de datos
-
Requisitos de integridad de los datos e integridad transaccional (atomicidad, consistencia, aislamiento y durabilidad, o ACID)
-
Requisitos de disponibilidad y recuperación entre regiones
En la siguiente tabla se enumeran los requisitos y las características de los datos de las aplicaciones y se analizan en el contexto de las ofertas de AWS bases de datos: Aurora compatible con PostgreSQL y Amazon RDS for PostgreSQL (relacional) y Amazon DynamoDB (no relacional). Puede hacer referencia a esta matriz cuando intente decidir entre ofertas de bases de datos operativas relacionales y no relacionales.
| Bases de datos | Requisitos y características de los datos de las aplicaciones SaaS | ||||
|---|---|---|---|---|---|
| Modelo de datos | Patrones de acceso | Requisitos de latencia | Integridad transaccional y de datos | Disponibilidad y recuperación entre regiones | |
Relacional (Compatible con Aurora PostgreSQL y Amazon RDS para PostgreSQL) |
Relacional o altamente normalizado. | No tiene que planificarse minuciosamente de antemano. | Preferiblemente, una mayor tolerancia a la latencia; puede lograr latencias más bajas de forma predeterminada con Aurora e implementando réplicas de lectura, almacenamiento en caché y funciones similares. | De forma predeterminada, se mantiene una alta integridad transaccional y de datos. | En Amazon RDS, puede crear una réplica de lectura para el escalado entre regiones y la conmutación por error. Aurora automatiza principalmente este proceso. |
No relacional (Amazon DynamoDB) |
Suele estar desnormalizado. Estas bases de datos aprovechan los patrones para modelar many-to-manyrelaciones, elementos grandes y datos de series temporales. | Todos los patrones de acceso (consultas) a los datos deben comprenderse a fondo antes de crear un modelo de datos. | Latencia muy baja con opciones como Amazon DynamoDB Accelerator (DAX) que permiten mejorar aún más el rendimiento. | Integridad transaccional opcional a costa del rendimiento. Los problemas de integridad de los datos se trasladan a la aplicación. | Fácil recuperación entre regiones y configuración activo-activa con tablas globales. (El cumplimiento de ACID solo se puede lograr en una sola región). AWS |
Algunas aplicaciones SaaS multiusuario pueden tener modelos de datos únicos o circunstancias especiales que se gestionan mejor con bases de datos no incluidas en la tabla anterior. Por ejemplo, los conjuntos de datos de series temporales, los conjuntos de datos altamente conectados o el mantenimiento de un registro de transacciones centralizado pueden requerir el uso de un tipo de base de datos diferente. El análisis de todas las posibilidades va más allá del alcance de esta guía. Para obtener una lista completa de las ofertas de AWS bases de datos y cómo pueden satisfacer diferentes casos de uso a un alto nivel, consulte la sección de bases de datos del documento técnico Overview of Amazon Web Services.
El resto de esta guía se centra en los servicios de bases de datos AWS relacionales compatibles con PostgreSQL: Amazon RDS y Aurora PostgreSQL. DynamoDB requiere un enfoque diferente para optimizar las aplicaciones de SaaS, lo que va más allá del alcance de esta guía. Para obtener más información sobre DynamoDB, consulte la entrada AWS del blog Cómo particionar datos SaaS agrupados de múltiples
Elegir entre Amazon RDS y Aurora
En la mayoría de los casos, recomendamos utilizar Aurora, compatible con PostgreSQL, en lugar de Amazon RDS for PostgreSQL. En la siguiente tabla se muestran los factores que debe tener en cuenta al decidir entre estas dos opciones.
| Componente DBMS | Amazon RDS para PostgreSQL | Compatible con Aurora PostgreSQL |
|---|---|---|
| Escalabilidad | Retraso de replicación de minutos, máximo de 5 réplicas de lectura | Retraso de replicación inferior a un minuto (normalmente menos de 1 segundo con bases de datos globales), máximo de 15 réplicas de lectura |
| Recuperación tras un bloqueo | Los puntos de control separados por 5 minutos (de forma predeterminada) pueden ralentizar el rendimiento de la base de datos | Recuperación asíncrona con subprocesos paralelos para una recuperación rápida |
| Conmutación por error | 60 a 120 segundos, además del tiempo de recuperación en caso de accidente | Por lo general, unos 30 segundos (incluida la recuperación en caso de accidente) |
| Almacenamiento | Un máximo de 256 000 IOPS | Las IOPS están limitadas únicamente por el tamaño y la capacidad de la instancia Aurora |
| Alta disponibilidad y recuperación ante desastres | Dos zonas de disponibilidad con una instancia en espera y conmutación por error entre regiones para leer copias de seguridad copiadas o réplicas | Tres zonas de disponibilidad de forma predeterminada, conmutación por error entre regiones con bases de datos globales de Aurora y reenvío de escritura para configuraciones activo-activas Regiones de AWS |
| Copia de seguridad | Durante el período de backup, puede afectar al rendimiento | Respaldos incrementales automáticos, sin impacto en el rendimiento |
| Clases de instancias de bases de datos | Consulte la lista de clases de instancias de Amazon RDS | Consulte la lista de clases de instancias de Aurora |
En todas las categorías descritas en la tabla anterior, la compatibilidad con Aurora PostgreSQL suele ser la mejor opción. Sin embargo, Amazon RDS for PostgreSQL podría seguir teniendo sentido para cargas de trabajo pequeñas y medianas, ya que cuenta con una mayor selección de clases de instancias que podrían ofrecer una opción más rentable a expensas del conjunto de funciones más sólido de Aurora.
