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.
Uso de bases de datos personalizadas
Descripción general de
Uno de los aspectos más costosos de la puesta en marcha de cargas de trabajo basadas en Microsoft es el uso de licencias de bases de datos comerciales, como SQL Server. Las empresas suelen estandarizar SQL Server como la plataforma de base de datos preferida y esto queda arraigado en la cultura de desarrollo de la organización. Los desarrolladores suelen elegir un modelo relacional basado en SQL Server, independientemente del caso de uso. Los motivos pueden ser:
-
La empresa ya tiene and/or licencias de instancias de SQL Server disponibles.
-
Los equipos se han acostumbrado al modelo de programación SQL mediante el uso de bibliotecas compartidas y la lógica empresarial. ORMs
-
La gerencia no conoce las alternativas.
-
Los desarrolladores no conocen las alternativas.
Las bases de datos personalizadas pueden adaptarse a los patrones de acceso a los datos de su caso de uso. Cada vez más empresas adoptan estas bases de datos conforme avanzan hacia arquitecturas modernas (como los microservicios) y el alcance de cada aplicación se vuelve más limitado.
Una base de datos personalizada no excluye un modelo relacional ni requiere un modelo NoSQL (no relacional). De hecho, una base de datos relacional se considera personalizada cuando se selecciona en respuesta a las necesidades específicas de una carga de trabajo. El uso de bases de datos personalizadas puede ayudar a los equipos a reducir los costos asociados a sus aplicaciones .NET y, al mismo tiempo, obtener las ventajas estándar de la nube, como la escalabilidad, la resiliencia y la reducción del trabajo pesado que no aporta valor.
La siguiente tabla muestra las bases de datos especialmente diseñadas que ofrece. AWS
| Base de datos | Tipo | Características |
|---|---|---|
| Amazon Aurora PostgreSQL o Amazon Aurora MySQL | Relacional | Casos de uso en los que los datos tienen una estructura fija Las bases de datos relacionales mantienen de forma natural la coherencia de datos en las transacciones ACID. |
| Amazon DynamoDB |
Par clave-valor | Base de datos NoSQL que almacena datos mediante una estructura de datos de tabla hash. Almacenamiento y recuperación de datos no estructurados de alto rendimiento. Algunos casos de uso son los perfiles de usuario, el estado de la sesión y los datos del carrito de compras. |
| Amazon ElastiCache |
En memoria | Base de datos NoSQL de alto rendimiento que almacena datos no estructurados en la memoria con un tiempo de acceso inferior a un milisegundo. Se utiliza para datos efímeros a los que se accede con frecuencia, como sesiones de usuario, y como capa de almacenamiento en caché delante de otros almacenes de datos más lentos. Incluye soporte para ElastiCache (Redis OSS) y ElastiCache (Memcached) |
| Amazon MemoryDB |
En memoria con durabilidad | Base de datos personalizada compatible con Redis con almacenamiento duradero. |
| Amazon Timestream |
Serie temporal | Base de datos diseñada para la ingesta de datos de alto rendimiento en orden temporal. Algunos casos de uso son las aplicaciones de Internet de las cosas (IoT) y el almacenamiento de métricas o datos de telemetría. |
| Amazon DocumentDB |
Documento | Base de datos NoSQL que almacena datos sin una estructura prescrita ni relaciones forzadas con otros datos. Suele utilizarse para las cargas de trabajo con muchas solicitudes de lectura, como los catálogos de productos. |
| Amazon Neptune |
Gráfico | Base de datos NoSQL que contiene datos y una representación de las conexiones entre los elementos de datos. Algunos casos de uso son la detección de fraudes, los motores de recomendación y las aplicaciones de redes sociales. |
| Amazon Keyspaces |
Columna ancha | Base de datos distribuida de alto rendimiento basada en Apache Cassandra. Algunos casos de uso son las aplicaciones de IoT, el procesamiento de eventos y las aplicaciones de juegos. |
Uno de los principales impulsores de la adopción de bases de datos personalizadas es la eliminación de las licencias comerciales. Sin embargo, la capacidad de escalado automático de bases de datos como DynamoDB (lo que abarca el modo bajo demanda
AWS ofrece Babelfish para Aurora PostgreSQL
Al elegir una base de datos relacional personalizada para sus aplicaciones, es importante retener las mismas características (o funcionalmente equivalentes) que necesita. Esta recomendación aborda las bases de datos personalizadas como almacén de datos principal para las aplicaciones. Ciertas aplicaciones, como el almacenamiento en caché, se tratan en otras recomendaciones.
Impacto del costo
Si bien es poco probable que la adopción de bases de datos diseñadas específicamente para las cargas de trabajo de.NET afecte directamente a la computación, puede influir consumption/cost directamente en el costo de los servicios de bases de datos que consumen las aplicaciones.NET. De hecho, el ahorro de costos puede ser un objetivo secundario si se compara con los beneficios adicionales de agilidad, escalabilidad, resiliencia y durabilidad de los datos.
En esta guía no se explica el proceso completo de elección de una base de datos personalizada para las aplicaciones ni de rediseño de una estrategia de datos para utilizarlas de forma eficaz. Para obtener más información, consulte Purpose-built databases
En las tablas siguientes se muestran varios ejemplos de cómo la sustitución de SQL Server por una base de datos personalizada puede alterar los costos de las aplicaciones. Tenga en cuenta que se trata simplemente de estimaciones aproximadas. Se requieren valores de referencia y la optimización de las cargas de trabajo reales para calcular el costo de producción exacto.
Estas son algunas estimaciones de bases de datos personalizadas que incluyen computación bajo demanda y SSD de 100 GB para bases de datos de instancia única en us-east-1. Los costos asociados al uso de licencias contemplan la licencia de SQL Server más la garantía del software.
En la siguiente tabla se muestran los costos estimados de los ejemplos de bases de datos comerciales:
| Motor de base de datos | Modelo de licencia | Tipo instancia/especificaciones | AWS coste de cómputo más almacenamiento | Costo de la licencia | Costo total mensual |
|---|---|---|---|---|---|
| Edición estándar de SQL Server en Amazon EC2 | Licencia incluida | r6i.2xlarge (8 CPU/64 GB de RAM) | 1.345,36$ | 0,00$ | 1.345,36 DÓLARES |
| Edición SQL Server Enterprise en Amazon EC2 | Licencia incluida | r6i.2xlarge (8 CPU/64 GB de RAM) | 2.834,56$ | 0,00$ | 2.834,56 DÓLARES |
| Edición estándar de SQL Server en Amazon EC2 | BYOL | r6i.2xlarge (8 CPU/64 GB de RAM) | 644,56$ | 456,00 DÓLARES | 1.100,56 DÓLARES |
| Edición SQL Server Enterprise en Amazon EC2 | BYOL | r6i.2xlarge (8 CPU/64 GB de RAM) | 644,56$ | 1.750,00 DÓLARES | 2.394,56 DÓLARES |
| Edición Standard de SQL Server en Amazon RDS | db.r6i.2xlarge (8 CPU/64 GB de RAM) | 2.318,30 DÓLARES | 0,00$ | 2.318,30 DÓLARES | |
| Edición Enterprise de SQL Server en Amazon RDS | db.r6i.2xlarge (8 CPU/64 GB de RAM) | 3.750,56 DÓLARES | 0,00$ | 3.750,56 DÓLARES |
En la siguiente tabla se muestran los costos estimados de los ejemplos de bases de datos personalizadas:
| Motor de base de datos | Tipo instancia/especificaciones | AWS coste de cómputo más almacenamiento | Costo de la licencia | Costo total mensual |
|---|---|---|---|---|
| PostgreSQL de Amazon Aurora | r6g.2xlarge (8 CPU/64 GB de RAM) | 855,87 DÓLARES | 0,00$ | 855,87 DÓLARES |
| DynamoDB | Base aprovisionada: 100 WCU/400 RCU | 72,00 DÓLARES | 72,00 DÓLARES | |
| Amazon DocumentDB | db.r6i.2xlarge (8 CPU/64 GB de RAM) | 778,60 DÓLARES | 778,60 DÓLARES |
importante
La tabla se basa en los costos estimados del uso de licencias de SQL Server con Software Assurance durante los tres primeros años de la compra. En el caso de la edición Standard de SQL Server: 4100 USD, paquete de 2 núcleos, 3 años. En el caso de la edición Enterprise de SQL Server: 15 700 USD, paquete de 2 núcleos, 3 años.
Le recomendamos que considere los posibles costos antes de adoptar bases de datos personalizadas. Por ejemplo, el costo de actualizar las aplicaciones para usar una base de datos personalizada varía según la complejidad de la aplicación y de la base de datos de origen. Asegúrese de tener en cuenta el costo total de propiedad al planificar este cambio de arquitectura. Esto incluye refactorizar las aplicaciones, formar al personal en nuevas tecnologías y planificar cuidadosamente el rendimiento y el consumo previstos de cada carga de trabajo. A partir de ahí, puede determinar si la inversión compensa el ahorro de costos. En la mayoría de los casos, el mantenimiento de un end-of-support producto supone un riesgo para la seguridad y la conformidad, y el coste de remediarlo vale la pena tanto el esfuerzo como la inversión inicial.
Recomendaciones de optimización de costos
En lo que respecta a las aplicaciones .NET que acceden a SQL Server, existen bibliotecas que reemplazan las bases de datos relacionales personalizadas. Puede implementar estas bibliotecas en su aplicación para reemplazar una funcionalidad similar de una aplicación de SQL Server.
En la siguiente tabla se muestran algunas bibliotecas que se pueden usar en muchos escenarios comunes.
| Library | Base de datos | Reemplazo de | Marco compatible |
|---|---|---|---|
| Npgsql Entity Framework Core Provider |
PostgreSQL de Amazon Aurora | Entity Framework Core SQL Server Provider | Versiones modernas de .NET |
| Npgsql Entity Framework 6 Provider |
PostgreSQL de Amazon Aurora | Entity Framework 6,0 SQL Server Provider | .NET Framework |
| Npgsql |
PostgreSQL de Amazon Aurora | ADO.NET | .NET .NET Framework/Modern |
| MySQL Entity Framework Core Provider |
Amazon Aurora MySQL | Entity Framework Core SQL Server Provider | Versiones modernas de .NET |
| Pomelo. EntityFrameworkCore. MySql |
Amazon Aurora MySQL | Entity Framework Core SQL Server Provider | Versiones modernas de .NET |
La conexión a Amazon Aurora PostgreSQL con Babelfish
Otras bases de datos personalizadas tienen bibliotecas para acceder a bibliotecas compatibles con .NET que le permiten acceder a bases de datos personalizadas. Entre los ejemplos se incluyen:
-
Uso de bases de datos NoSQL de Amazon DynamoDB (documentación)AWS SDK para .NET
-
MongoDB C# Driver
(documentación de MongoDB) -
.NET (documentación de Timestream)
-
Using a Cassandra .NET Core client driver to access Amazon Keyspaces programmatically (documentación de Amazon Keyspaces)
-
Using .NET to connect to a Neptune DB instance (documentación de Neptune)
Si migra a bases de datos diseñadas específicamente, puede utilizar estas herramientas AWS para facilitar el proceso de migración:
-
AWS Schema Conversion Tool (AWS SCT)
puede ser útil para transformar los esquemas de SQL Server para Amazon Aurora y Amazon DynamoDB. -
AWS Database Migration Service (AWS DMS)
puede ser útil para migrar datos, de forma puntual o continua, de SQL Server a Aurora o DynamoDB. -
Babelfish Compass
puede ser útil para comprobar la compatibilidad de su base de datos de SQL Server para utilizarla con Babelfish para Aurora PostgreSQL.
Recursos adicionales
-
Guidance for migrating SQL Server to Amazon Aurora PostgreSQL
(blog de bases de datos de AWS ) -
Jornada de inmersión en la modernización de las aplicaciones de Babelfish
(Workshop Studio)AWS -
Día de inmersión en .NET
(AWS taller de estudio) -
Cómo empezar a usar Amazon Timestream con
.NET () GitHub -
Bases de datos especialmente diseñadas para aplicaciones de.NET modernas
en (presentación) AWSAWS