Almacenamiento en la nube, bases de datos y servicios de datos

Un servicio de almacenamiento debe adaptarse a la forma en que una aplicación lee y modifica los datos. Una base de datos que actualiza unos pocos registros, un equipo que edita documentos compartidos y un sitio web que muestra fotos tienen necesidades distintas.

Tres formas de organizar los datos

Un volumen de bloques contiene bloques de tamaño fijo. El sistema operativo lo formatea con un sistema de archivos, igual que formatearía un disco físico. Puede actualizar una pequeña parte de un archivo en su lugar. Esto es adecuado para una base de datos que realiza muchas lecturas y escrituras pequeñas. Un volumen suele prestar servicio a una máquina virtual; compartirlo directamente requiere compatibilidad del disco y software diseñado para el acceso en clúster.

El almacenamiento de archivos proporciona una carpeta compartida a través de una red. NFS es habitual en Linux; SMB es habitual en Windows. Varios clientes pueden abrir el mismo recurso compartido y el bloqueo de archivos coordina el acceso. Una aplicación existente que espera una ruta compartida puede conservar ese patrón sin tener que reescribirse para llamar a una API de objetos.

Qué contiene un objeto

Un objeto contiene sus datos, una clave única y metadatos, como su tipo de contenido. En un contenedor de objetos con espacio de nombres plano, invoices/2026/10/inv-1042.pdf es una clave completa. Las barras agrupan los nombres por prefijo; no crean carpetas de disco ordinarias.

Las aplicaciones suelen cargar objetos con solicitudes PUT y descargarlos con solicitudes GET mediante HTTPS. El acceso a objetos de uso general trata los datos como un objeto: sustituir su contenido suele significar cargar un reemplazo, mientras que un disco de bloques permite pequeñas escrituras en su lugar. Algunos servicios de objetos añaden funciones especializadas para anexar datos o gestionar directorios. Un contenedor de objetos sigue teniendo un modelo de acceso distinto al de un servidor de archivos compartidos.

El almacenamiento de objetos puede guardar imágenes, grabaciones, registros y copias de seguridad en una colección que crece sin aprovisionar un disco para cada aumento. Las clases estándar en línea prestan servicio a sitios web activos y análisis con acceso en milisegundos. La recuperación demorada corresponde a determinadas clases de archivo, no al almacenamiento de objetos en su conjunto.

Elige almacenamiento para una aplicación

Una tienda en línea usa un disco de bloques para su servidor de base de datos porque los registros cambian con frecuencia. Cinco servidores web leen plantillas de páginas comunes de un recurso compartido de archivos NFS. Las fotos de productos y 2 TB de copias de seguridad nocturnas van al almacenamiento de objetos. La misma aplicación puede usar los tres tipos.

El almacenamiento temporal del host, como instance store de AWS, el disco temporal de Azure y Local SSD de Google Cloud, es adecuado para archivos temporales y cachés que pueden volver a crearse. Un fallo del host o eventos del ciclo de vida de la máquina virtual pueden borrarlo. Conserva la única copia de los datos importantes en almacenamiento persistente, que existe independientemente de una máquina virtual en funcionamiento.

Los precios siguen el modelo de almacenamiento. El almacenamiento de objetos suele facturar los GB realmente almacenados, más las solicitudes y transferencias. El almacenamiento en bloques factura la capacidad aprovisionada, incluido el espacio sin usar. El almacenamiento de archivos puede facturar el espacio utilizado, como hace EFS, o la capacidad reservada. Empieza la elección por el patrón de acceso y después compara la factura para ese patrón.

El almacenamiento de objetos separa los datos del servidor que los utiliza. Un contenedor de objetos o contenedor alberga la colección, mientras que cada objeto tiene su propia clave. La ubicación, el acceso y la configuración de recuperación determinan la seguridad con que puede utilizarse esa colección.

Compara los nombres de los proveedores

Una cuenta de almacenamiento de Azure también puede albergar recursos compartidos de archivos, colas y tablas. Los nombres de los contenedores de uso general de S3, los contenedores de Cloud Storage y las cuentas de almacenamiento de Azure utilizan espacios de nombres compartidos, por lo que un nombre usado por otro cliente puede no estar disponible. El nombre también forma parte de la dirección del objeto. Por ejemplo, un blob de Azure puede tener la dirección https://shopmedia.blob.core.windows.net/images/products/lamp-01.jpg.

Un contenedor de S3 pertenece a una región de AWS. Las cuentas de almacenamiento de Azure tienen una región y una opción de redundancia. Cloud Storage ofrece ubicaciones regionales, birregionales y multirregionales. La ubicación afecta a la latencia, el precio y la residencia de los datos, es decir, el área donde se conservan.

Comparte sin exponer la colección

Mantén la colección privada y concede el acceso que necesita la aplicación mediante permisos de identidad y políticas de recursos. Para una descarga temporal, usa una URL prefirmada de S3, una firma de acceso compartido (SAS) de Azure o una URL firmada de Cloud Storage. Un enlace a una factura que caduca en 60 minutos da acceso temporal sin hacer público todo el contenedor. Cualquiera que tenga un enlace firmado válido puede ejercer sus permisos durante ese período.

Los objetos almacenados se cifran de forma predeterminada con claves administradas por el proveedor; las claves administradas por el cliente dan a este más control. HTTPS protege los datos durante la transferencia. El cifrado y los permisos resuelven problemas diferentes: una persona con permiso de lectura válido puede seguir leyendo un objeto cifrado a través del servicio.

Recupera, conserva y carga

El control de versiones conserva versiones anteriores de los objetos para que pueda deshacerse una sobrescritura. Las versiones almacenadas aumentan la factura. Azure y Google Cloud también ofrecen eliminación recuperable, que conserva los datos eliminados durante un período de recuperación. El almacenamiento inmutable, o una escritura y múltiples lecturas (WORM), bloquea los cambios y la eliminación durante la retención. Algunos ejemplos son S3 Object Lock, el almacenamiento de blobs inmutables de Azure y las políticas de retención de Cloud Storage con bloqueo del contenedor.

Las cargas grandes pueden dividirse en partes, cargarse en paralelo y volver a intentarse individualmente. S3 llama a esto carga multiparte; las cargas por bloques de Azure y las cargas compuestas de Google ofrecen métodos relacionados. Una interrupción de la conexión no obliga a reiniciar toda la transferencia grande.

Dimensiona una colección creciente

Un millón de fotos de 3 MB de promedio ocupan 3 000 000 MB, o 3000 GB: 3 TB en unidades decimales. Otras 20 000 fotos al día añaden 60 GB diarios. En 365 días, eso supone otros 21,9 TB. El almacenamiento de objetos admite este crecimiento sin reservar de antemano un disco de tamaño fijo.

En espacios de nombres planos, mover un prefijo que parece una carpeta implica cambiar las claves de los objetos. Las opciones jerárquicas añaden operaciones reales de directorio, entre ellas Azure Data Lake Storage y el espacio de nombres jerárquico de Cloud Storage. Comprueba el espacio de nombres antes de tratar una carpeta mostrada como un directorio.

Después de elegir un tipo de almacenamiento, relaciona su método de acceso y rendimiento con un servicio. Un disco de alto rendimiento y una carpeta compartida pueden almacenar archivos, pero responden a necesidades distintas de las aplicaciones.

Discos y sus copias

Los tipos de disco ofrecen distintos niveles de rendimiento. Los volúmenes basados en discos duros son adecuados para grandes lecturas secuenciales; los SSD, para pequeñas operaciones frecuentes. IOPS significa operaciones de entrada y salida por segundo. Elige tanto la capacidad como el rendimiento, porque un disco grande no es necesariamente el adecuado para una base de datos con mucha actividad.

Un volumen EBS pertenece a una zona de disponibilidad y se conecta a las instancias de esa zona. Los discos administrados de Azure tienen redundancia local de forma predeterminada, con una opción de redundancia de zona. Google ofrece discos zonales y discos regionales replicados entre dos zonas. Estas opciones de ubicación determinan los fallos que puede soportar un disco.

Una instantánea captura un volumen en un momento dado. Las instantáneas de EBS y las estándar de Google son incrementales: después de la primera copia, las posteriores almacenan los bloques modificados. Azure ofrece instantáneas completas e incrementales. Si un volumen contiene 200 GB y cambian 5 GB, una instantánea incremental almacena unos 5 GB de bloques nuevos. Restaurar esa instantánea sigue reconstruyendo el volumen completo, no solo la parte modificada. Puede convertirse en un disco nuevo en otra zona; las instantáneas también pueden copiarse entre regiones.

Archivos compartidos y software compatible

EFS es un sistema de archivos NFS que crece automáticamente para servidores Linux, incluidos los de distintas zonas de disponibilidad. FSx ofrece Windows File Server, Lustre, NetApp ONTAP y OpenZFS. FSx for Windows File Server proporciona SMB e integración con Active Directory; Lustre es adecuado para conjuntos de datos grandes que requieren rapidez en el cómputo de alto rendimiento.

Azure Files ofrece recursos compartidos SMB y NFS para clientes compatibles de Windows, Linux y macOS. Azure NetApp Files atiende cargas de trabajo empresariales exigentes de archivos. Filestore proporciona NFS administrado en Google Cloud; NetApp Volumes ofrece recursos compartidos basados en NetApp. Comprueba que el protocolo y las funciones del sistema de archivos sean los necesarios antes de comparar los precios de capacidad.

Conecta un servidor de archivos local

AWS Storage Gateway es un dispositivo virtual local que conecta interfaces conocidas de archivos, discos o cintas con el almacenamiento de AWS. Guarda en caché local los datos de uso frecuente. Tape Gateway permite que el software de copias de seguridad existente use cintas virtuales. Azure File Sync sincroniza servidores de archivos de Windows con Azure Files; el almacenamiento por niveles en la nube mantiene los archivos de acceso frecuente en la sede y recupera los archivos de acceso menos frecuente cuando se abren.

Para una sucursal con 8 TB de archivos compartidos y un disco local de 2 TB, la asignación por niveles puede mantener cerca los 2 TB de uso frecuente mientras la nube alberga el conjunto completo. Abrir un archivo de acceso menos frecuente depende entonces de la conexión de red.

Eliminar una máquina virtual no siempre elimina sus discos de datos; un disco sin conectar puede seguir generando cargos. La protección de las instantáneas también depende de la ubicación y del aislamiento de la cuenta. Las instantáneas de EBS y Azure permanecen en la región de origen salvo que se copien. Las instantáneas estándar de Google usan de forma predeterminada el área multirregional más cercana. Una copia de recuperación aislada protege frente a una cuenta de origen comprometida.

Un nivel de almacenamiento cambia lo que pagas por conservar y recuperar objetos. Los niveles de acceso frecuente cobran más por el almacenamiento y menos por el acceso. Los niveles más fríos reducen la tarifa de almacenamiento, pero pueden añadir cargos de recuperación, duraciones mínimas y demoras de restauración.

Compara las clases según las necesidades de acceso

S3 Standard-IA y One Zone-IA tienen mínimos de 30 días. Glacier Instant Retrieval y Flexible Retrieval tienen mínimos de 90 días; Deep Archive tiene 180 días. Flexible Retrieval tarda de minutos a horas en restaurar. La recuperación estándar de Deep Archive se completa en 12 horas y la masiva en 48 horas. S3 Express One Zone ofrece acceso rápido dentro de una sola zona.

El nivel cool de Azure tiene un mínimo de 30 días, cold de 90 días y archive de 180 días. Hot, cool y cold proporcionan acceso en milisegundos. Archive debe rehidratarse a un nivel en línea, lo que puede tardar hasta 15 horas. Una cuenta de almacenamiento establece un nivel en línea predeterminado; cada blob puede tener su propio nivel.

Cloud Storage Standard no tiene mínimo; Nearline tiene 30 días, Coldline 90 y Archive 365. Google Archive permanece en línea, con acceso en milisegundos y cargos de recuperación. La palabra «archivo» por sí sola no indica cuánto tardará una lectura.

La duración mínima es un compromiso de facturación

Eliminar un blob cool de Azure después de 21 días deja 9 días facturables de su mínimo de 30 días. Eliminar un blob de archivo después de 45 días deja 135 días de su mínimo de 180 días. Un objeto de Cloud Storage Archive eliminado después de 100 días deja 265 días. Salir de una clase antes de tiempo también puede generar este cargo.

Calcula la factura total

Usa tarifas de ejemplo de 0,020 u.m. por GB·mes para almacenamiento de acceso frecuente y 0,002 u.m. para archivo, más 0,02 u.m. por GB recuperado del archivo. Para 50 000 GB conservados durante 12 meses:

• El almacenamiento de acceso frecuente cuesta 12 000 u.m..
• El almacenamiento de archivo cuesta 1200 u.m..
• Leer todo el archivo una vez añade 1000 u.m., lo que suma 2200 u.m. en total.
• Leerlo cada mes añade 12 000 u.m., lo que suma 13 200 u.m. en total.

La tarifa de almacenamiento más barata pierde su ventaja cuando las lecturas son frecuentes. Una estimación completa también incluye cargos por solicitudes, eliminación anticipada y salida de datos, el cargo por los datos que salen de la nube. Las cargas por internet suelen ser gratis; las descargas suelen facturarse.

Deja que los patrones de acceso determinen los cambios

S3 Intelligent-Tiering mueve automáticamente los objetos sin usar después de 30 y 90 días y los devuelve al acceder a ellos; cobra cargos de supervisión, pero no de recuperación. Smart tier de Azure mueve los datos entre hot, cool y cold según el uso. Autoclass de Cloud Storage gestiona las clases de un contenedor de objetos. Para calendarios fijos basados en la antigüedad, las reglas de ciclo de vida ofrecen un control explícito.

Las clases de una sola zona sacrifican protección frente a fallos a cambio de costo o rendimiento. S3 One Zone-IA es adecuado para datos secundarios o que puedan volver a crearse, porque la pérdida de esa zona puede hacer que se pierdan los datos.

Los datos suelen ser menos útiles a medida que envejecen. Una política de ciclo de vida aplica ese patrón a cada objeto nuevo, para que las personas no tengan que recordar cada traslado o eliminación.

Una regla tiene tres partes

Un filtro identifica objetos, como claves que empiezan por logs/ u objetos con una etiqueta determinada. Una condición indica cuándo se aplica la regla, por ejemplo, los días desde la creación o, en Azure, desde el último acceso. Una acción cambia el nivel de almacenamiento o elimina el objeto. Los servicios son S3 Lifecycle, administración del ciclo de vida de Azure Blob Storage y Cloud Storage Object Lifecycle Management.

Para registros de aplicaciones que se necesitan con frecuencia durante un mes y se conservan durante siete años, muévelos a un nivel de acceso infrecuente el día 30 y a un nivel de archivo el día 90. El nivel de acceso infrecuente conserva cada registro durante 60 días, lo que supera su mínimo de 30 días. Configura la eliminación después del período completo de retención en años naturales: siete años pueden incluir dos días bisiestos, por lo que 2557 días evita la eliminación anticipada. Una regla simple de 2555 días puede quedarse corta.

Cuenta el tiempo de permanencia en cada nivel

La antigüedad del objeto y su tiempo en un nivel son diferentes. Si un objeto entra en un nivel con un mínimo de 90 días el día 30 y sale el día 60, su permanencia es de solo 30 días:

Quedan 60 días del mínimo sin usar, que pueden facturarse. Cuenta el intervalo entre transiciones antes de evaluar el costo de una política. Cada transición también tiene el costo de una solicitud. Algunas clases más frías tienen tamaños mínimos de objeto facturable, como 128 KB en S3 Standard-IA, por lo que mover objetos diminutos puede ahorrar poco o costar más.

Versiones y retención protegida

Las reglas de ciclo de vida pueden eliminar versiones no actuales después de un intervalo elegido, conservar un número limitado de versiones anteriores y limpiar cargas multiparte incompletas. Sin esas reglas, las versiones y las partes abandonadas pueden seguir consumiendo almacenamiento de pago.

Un bloqueo de retención activo o una retención legal impide que el ciclo de vida elimine datos protegidos. Para facturas conservadas durante diez años naturales, un plan las mueve al archivo después de un año y programa su eliminación después de 3653 días, teniendo en cuenta hasta tres días bisiestos. Un bloqueo en modo de cumplimiento impide la eliminación anticipada incluso por parte de los administradores. La regla de ciclo de vida gestiona la antigüedad; el bloqueo garantiza la protección.

La recuperación es una operación independiente

La rehidratación de prioridad alta de Azure suele tardar menos de una hora para blobs de menos de 10 GB, a un precio mayor. Las reglas de ciclo de vida de Azure no pueden rehidratar un blob archivado; restaurarlo requiere una solicitud aparte. Planifica una restauración antes de prometer una entrega urgente desde un archivo sin conexión.

Las acciones de ciclo de vida se ejecutan en segundo plano, normalmente uno o dos días después de cumplirse la condición. Usa la política para aplicar la retención de forma coherente a toda la colección y ten en cuenta ese tiempo de procesamiento al planificar las operaciones.

Los datos pueden sobrevivir a una interrupción y seguir siendo inaccesibles durante ella. Por eso, la protección del almacenamiento tiene dos medidas distintas: durabilidad y disponibilidad.

Interpreta correctamente los porcentajes

La durabilidad describe la protección frente a la pérdida de datos durante un año. S3 Standard está diseñado para una durabilidad del 99,999999999 %, llamada once nueves. La proporción de pérdida es de uno entre 100 mil millones por objeto y año. Para 10 millones de objetos, la pérdida anual esperada es de 0,0001 objetos: un promedio de uno cada 10 000 años. Es una medida estadística de diseño, no un calendario de pérdida de objetos.

La disponibilidad describe la proporción de tiempo durante la cual se puede acceder a los datos. Un mes de 30 días tiene 43 200 minutos. Con una disponibilidad del 99,9 %, la proporción de tiempo no disponible es del 0,1 %, o 43,2 minutos. Con el 99,99 %, es de 4,32 minutos; con el 99 %, de 432 minutos, o 7,2 horas. La disponibilidad de diseño de S3 Standard es del 99,99 %. Un SLA es un compromiso contractual, a menudo respaldado por créditos; su cifra puede diferir del objetivo de diseño.

Ajusta las copias al fallo

Varias copias dentro de un centro de datos protegen frente a fallos de hardware. Las copias entre zonas de disponibilidad protegen frente a una interrupción de un centro de datos. Las copias en una segunda región hacen frente a un desastre regional, según dónde y cómo se realice la replicación.

La replicación síncrona confirma una escritura después de que las copias requeridas acusen recibo. Algunos sistemas requieren todas las copias designadas; otros usan una mayoría, o cuórum. La replicación asíncrona confirma en la copia principal y envía los cambios después. Si se pierde la principal, pueden perderse los cambios que aún estén en tránsito. Ese retraso de replicación debe mantenerse dentro del RPO de la empresa, la cantidad máxima aceptable de pérdida de datos recientes medida en tiempo.

Interpreta la redundancia de Azure

LRS ofrece al menos once nueves de durabilidad, ZRS doce y las opciones con redundancia geográfica dieciséis. GRS tiene seis copias en total. Los datos secundarios ordinarios de GRS/GZRS no están disponibles para lectura hasta la conmutación por error; RA-GRS y RA-GZRS añaden acceso de lectura a la copia secundaria. Una región replicada no es necesariamente un reemplazo activo inmediato.

La mayoría de las clases de S3 abarcan al menos tres zonas; las clases One Zone no. La replicación de S3 puede copiar objetos a otro contenedor en la misma región o en otra. Los contenedores regionales de Cloud Storage abarcan zonas, los birregionales usan dos regiones elegidas y los multirregionales usan un área más amplia. La replicación turbo opcional tiene como objetivo copiar los datos nuevos en 15 minutos en el almacenamiento birregional.

La residencia de los datos también se aplica a las copias secundarias. Si se exige que permanezcan en un solo país, comprueba la ubicación de la segunda región. La replicación también puede trasladar sobrescrituras o eliminaciones no deseadas, según el servicio y la configuración. Proporciona copias resistentes del estado actual; las versiones protegidas y las copias de seguridad permiten recuperarse de un estado incorrecto.

Una copia de seguridad es una copia recuperable que se conserva para casos de eliminación, corrupción, ataque o pérdida de una sede. Un plan útil de copias de seguridad parte de lo que la empresa puede perder y de cuánto tiempo puede permanecer sin servicio.

Establece dos objetivos diferentes

Una copia de seguridad cada 24 horas puede dejar sin protección casi 24 horas de cambios si el fallo ocurre justo antes de la siguiente copia. Cumple un RPO de 24 horas, pero no uno de 1 hora. Las copias cada hora o una replicación continua suficientemente actualizada permiten cumplir el objetivo más corto.

La velocidad de recuperación es independiente. Si restaurar 3 TB tarda 6 horas y el RTO es de 4 horas, el plan no cumple el objetivo aunque la copia contenga todos los registros necesarios. Un proceso de restauración más rápido o un sistema en espera en caliente puede reducir el tiempo de recuperación.

Aplica políticas a varios recursos

AWS Backup centraliza las políticas de copias de seguridad para recursos como EBS, RDS, DynamoDB, EFS, FSx y S3. Azure Backup cubre recursos como máquinas virtuales, discos administrados, Azure Files, blobs y SQL Server en máquinas virtuales. Google Cloud ofrece Backup and DR Service. Las políticas establecen la frecuencia, la retención y las copias a otras regiones o cuentas.

Las bases de datos administradas también realizan copias de seguridad y conservan registros de transacciones. RDS, Azure SQL Database y Cloud SQL admiten la restauración a un momento dado elegido dentro del período de retención. La retención de RDS puede ser de hasta 35 días. Los registros permiten recuperar datos entre las horas de las copias, por ejemplo, justo antes de una actualización accidental.

Aísla una copia de recuperación

La regla 3-2-1 orienta la planificación de copias de seguridad: tres copias, en dos tipos de almacenamiento, con una fuera de la sede. En la nube, otra región ayuda ante la pérdida de una sede y una cuenta independiente ayuda a aislar el acceso. La retención bloqueada añade protección frente a un atacante que elimine la copia de seguridad: AWS Backup Vault Lock, los almacenes inmutables de Azure Backup y los almacenes de copias de seguridad de Google con retención obligatoria proporcionan este control.

Una copia diaria fuera de la sede no cumple un RPO de cuatro horas para un desastre regional. Puede tener un retraso de casi un día incluso cuando las instantáneas locales se realizan cada cuatro horas.

Para un recurso compartido de archivos de 3 TB con un RPO de cuatro horas y un RTO de ocho horas, realiza instantáneas cada cuatro horas para la recuperación local y crea una copia recuperable en otra región al menos cada cuatro horas. Conserva las instantáneas recientes durante siete días y el historial de recuperación diario durante 90 días. Prueba una restauración completa cada trimestre y mide si termina en ocho horas.

Servicios de recuperación y archivos históricos

AWS Elastic Disaster Recovery y Azure Site Recovery replican servidores para que puedan arrancar en otro lugar con objetivos de recuperación cortos, a menudo de minutos, por un costo adicional. Se ocupan de recuperar un sistema funcional, además de conservar archivos antiguos.

Un archivo histórico conserva registros inactivos para su uso o retención a largo plazo. Una copia de seguridad permite recuperar un sistema actual con un historial que se renueva. Un archivo de bajo costo puede ser útil para almacenar copias, pero su demora de recuperación debe ajustarse al plan de recuperación. Las pruebas de restauración comprueban tanto si los datos funcionan como cuánto tarda realmente la recuperación.

Una base de datos relacional almacena hechos relacionados en tablas. Un servicio administrado ejecuta la plataforma de base de datos por ti, mientras que tu equipo sigue siendo responsable del funcionamiento de sus datos y consultas.

Interpreta tablas y claves

Una tabla contiene filas para los registros y columnas para los atributos. Su esquema define esas columnas y sus tipos de datos. Una clave primaria identifica de forma única una fila. Una clave foránea hace referencia a la clave primaria de otra tabla y conecta registros entre tablas.

Supón que customers contiene a Ana con el identificador de cliente 1 y país Brasil, y a Kofi con el identificador 2 y país Ghana. La tabla orders contiene los pedidos 501 y 503 del cliente 2, con totales de 80 y 45, y el pedido 502 del cliente 1, con un total de 120. SQL lee y modifica los datos:

SELECT name FROM customers WHERE country = 'Ghana';

Esto devuelve Kofi. La unión mediante customer_id conecta a Kofi con los pedidos 501 y 503, cuyo total es 125. No es necesario repetir el nombre del cliente en cada pedido.

Mantén unida una transacción

Una transacción agrupa cambios en una unidad. Las propiedades ACID describen sus garantías:

• Atomicidad: todos los pasos tienen éxito o ninguno lo tiene.
• Consistencia: los datos confirmados cumplen las reglas definidas.
• Aislamiento: se impide que las transacciones simultáneas interfieran de las formas que prohíbe el nivel de aislamiento.
• Durabilidad: un cambio confirmado sobrevive a un fallo.

Una transferencia de 50 carga una cuenta y abona otra. Si el segundo cambio falla, la atomicidad también deshace el primero. Por eso las bases de datos relacionales son adecuadas para pedidos, inventario y pagos: los cambios relacionados pueden confirmarse juntos.

Elige quién administra la plataforma

Un servicio administrado de PostgreSQL proporciona mantenimiento automático de la plataforma a una aplicación nueva. Una base de datos heredada que necesita una versión antigua del motor y un complemento del sistema operativo puede necesitar una máquina virtual. Un servicio administrado no significa que el proveedor elija tu esquema, corrija las consultas lentas o conceda acceso a los usuarios adecuados. Tu equipo también selecciona el tamaño, la región y la configuración de disponibilidad.

Distingue las copias adicionales

Una réplica en espera en otra zona permite la conmutación por error si falla la principal. Algunos ejemplos son RDS Multi-AZ, Azure SQL Database con redundancia de zona y la alta disponibilidad de Cloud SQL. La conmutación por error puede interrumpir brevemente el servicio; no supone cero tiempo de inactividad.

Una réplica de lectura distribuye el tráfico de lectura y puede situarse en otra región. Suele recibir cambios de forma asíncrona, por lo que puede mostrar un valor anterior justo después de una escritura. No es lo mismo que una réplica en espera para la conmutación por error o una copia de seguridad histórica.

El escalado vertical añade procesadores o memoria, a menudo con una breve interrupción. Las réplicas de lectura amplían la capacidad para el tráfico de lectura, mientras que el crecimiento automático del almacenamiento añade capacidad de disco. Las copias de seguridad y los registros de transacciones permiten restaurar a un momento dado después de un cambio perjudicial que las réplicas pueden haber copiado ya.

Empieza la elección de una base de datos por la aplicación: su motor, las funciones requeridas y la escala. Conservar el mismo motor suele evitar cambios de código. Un motor compatible en la nube puede ofrecer un comportamiento de almacenamiento y escalado diferente sin ser idéntico al original.

Compara los principales servicios

Amazon RDS admite MySQL, PostgreSQL, MariaDB, Oracle, SQL Server e IBM Db2. Aurora es un motor independiente de AWS compatible con MySQL o PostgreSQL. Almacena seis copias entre tres zonas de disponibilidad, aumenta el almacenamiento automáticamente y ofrece Aurora Serverless para demandas cambiantes de cómputo.

Azure SQL Database usa el motor de SQL Server y ofrece opciones sin servidor y Hyperscale. SQL Managed Instance admite casi todo el comportamiento de SQL Server a nivel de instancia, útil para bases de datos existentes que dependen de funciones como los trabajos de SQL Server Agent. Azure Database for PostgreSQL y Azure Database for MySQL ejecutan sus motores de código abierto como servidores flexibles administrados. SQL Server on Azure Virtual Machines proporciona control total del sistema operativo, con mantenimiento administrado por el cliente.

Cloud SQL ejecuta MySQL, PostgreSQL y SQL Server. AlloyDB for PostgreSQL proporciona un servicio compatible con PostgreSQL optimizado para cargas de trabajo exigentes, incluidas consultas analíticas. Spanner distribuye datos relacionales globalmente, escala horizontalmente y mantiene la consistencia fuerte entre regiones. Las configuraciones multirregionales ofrecen un SLA de hasta el 99,999 % de disponibilidad.

Elige según la función que importa

Una empresa minorista regional que usa MySQL puede utilizar RDS for MySQL, Azure Database for MySQL o Cloud SQL for MySQL. Una aplicación SQL Server que depende de trabajos a nivel de instancia necesita un servicio compatible con instancias, como SQL Managed Instance; verifica que el destino elegido admita cada función específica. Una aplicación PostgreSQL exigente puede considerar Aurora PostgreSQL o AlloyDB.

La replicación global no tiene un único comportamiento. Aurora Global Database tiene una región principal de escritura y regiones secundarias asíncronas para lecturas locales y recuperación ante desastres. Spanner permite transacciones distribuidas globalmente con consistencia fuerte. Una aplicación pequeña de una sola región normalmente no necesita esa complejidad global.

Si la carga de trabajo es impredecible o suele estar inactiva, una opción sin servidor puede ajustar la capacidad. Si la aplicación requiere acceso al sistema operativo, selecciona una máquina virtual. «Administrado» y «sin servidor» describen opciones operativas; no hacen que todas las funciones de los motores sean intercambiables.

Incluye las licencias y el uso en la factura

Los motores comerciales como Oracle, SQL Server y Db2 requieren una licencia incluida o un acuerdo válido de uso de licencias propias, llamado BYOL. La Ventaja híbrida de Azure puede reutilizar licencias elegibles de SQL Server. Los motores de código abierto como MySQL y PostgreSQL no tienen cargo de licencia del motor.

Los cargos habituales incluyen cómputo, GB·mes de almacenamiento, almacenamiento adicional de copias de seguridad, datos transferidos hacia fuera y, a veces, operaciones de entrada y salida. Los cargos sin servidor dependen de la capacidad utilizada a lo largo del tiempo. Compara el servicio completo y el acuerdo de licencia, no solo la cifra de cómputo por hora.

Las bases de datos NoSQL organizan los datos en torno a patrones de acceso concretos. «No solo SQL» abarca varios modelos, no un sustituto para todas las bases de datos relacionales. Elige un modelo según las preguntas que plantea la aplicación y las garantías que necesitan sus respuestas.

Relaciona el modelo con la pregunta

Un almacén clave-valor recupera rápidamente cart:58213 mediante su clave conocida. Ofrece menos formas de buscar atributos arbitrarios. Un documento agrupa campos relacionados y los documentos pueden tener estructuras diferentes:

{"orderId":"A-1042","customer":{"name":"Ana"},"items":[{"sku":"LAMP-01","qty":2},{"sku":"BULB-07","qty":4}]}

La aplicación puede leer este pedido y sus artículos juntos. La flexibilidad de la estructura no elimina la necesidad de estructura: la aplicación sigue necesitando campos utilizables y claves elegidas cuidadosamente. Algunos servicios también aplican reglas de validación.

Los almacenes de columnas anchas gestionan enormes volúmenes de escritura, como lecturas de millones de sensores. Los almacenes de grafos representan explícitamente las relaciones como aristas entre nodos. Rastrear conexiones entre cuentas es un problema de grafos, mientras que encontrar repetidamente una cuenta por su identificador es una búsqueda por clave.

Usa la memoria para lecturas repetidas

Un almacén en memoria mantiene los datos en RAM para un acceso muy rápido, a menudo inferior a un milisegundo. Un patrón habitual es la caché lateral: comprueba la caché; si hay un fallo de caché, lee la base de datos y guarda una copia en la caché con un tiempo de caducidad.

Para una búsqueda en caché de 1 ms y una consulta a la base de datos de 50 ms, con una tasa de aciertos del 90 %, un acierto cuesta 1 ms y un fallo cuesta 51 ms. El promedio es:

El fallo incluye la búsqueda sin éxito en la caché. Los datos almacenados en caché pueden caducar o expulsarse, por lo que una caché ordinaria no debería contener la única copia de referencia. Los servicios de bases de datos duraderas en memoria son una opción distinta.

Elige la consistencia de forma deliberada

Con consistencia fuerte, una lectura devuelve la última escritura confirmada. La consistencia eventual permite que una réplica muestre brevemente un valor anterior mientras se pone al día con las actualizaciones. Esto puede favorecer una menor latencia, un menor costo o una mejor disponibilidad durante algunos fallos. El comportamiento requerido depende de la tarea: un saldo recién actualizado y un contador de recomendaciones pueden tener necesidades distintas.

DynamoDB ofrece lecturas con consistencia eventual y fuerte para las operaciones admitidas. Cosmos DB ofrece cinco niveles de consistencia. NoSQL no significa «sin transacciones»: muchos servicios admiten transacciones, aunque el alcance admitido varía.

Las bases de datos relacionales son adecuadas para relaciones complejas, uniones y transacciones entre varias filas. NoSQL es adecuado para una escala muy grande, registros flexibles y patrones de acceso conocidos. Una aplicación puede mantener los pedidos en un almacén relacional, los perfiles en uno documental y las lecturas repetidas de productos en una caché.

Los servicios NoSQL en la nube ofrecen distintos modelos y opciones operativas. Identifica primero si la carga de trabajo necesita documentos, conexiones, datos de columnas anchas o una caché, y después compara la compatibilidad y los cargos de capacidad.

Reconoce las familias de servicios

La tabla agrupa los servicios por finalidad; no significa que tengan API idénticas. DynamoDB es un servicio sin servidor, admite acceso clave-valor y documental y ofrece tablas globales entre regiones. DocumentDB busca la compatibilidad con MongoDB. Keyspaces es compatible con Cassandra y Neptune almacena grafos.

Cosmos DB se distribuye globalmente y ofrece las API NoSQL, MongoDB, Cassandra, Gremlin y Table. Una cuenta usa una API. También ofrece cinco niveles de consistencia. Azure Table Storage es un servicio clave-valor independiente y sencillo dentro de una cuenta de almacenamiento. Compartir una interfaz Table no le proporciona todas las funciones de distribución global y consistencia de Cosmos DB.

Firestore es una base de datos documental sin servidor con actualizaciones en tiempo real y compatibilidad con dispositivos sin conexión. Bigtable gestiona grandes cargas de trabajo de columnas anchas y baja latencia, y admite la API de HBase. Los historiales de sensores y la personalización a gran escala son usos habituales.

La caché y la memoria duradera son distintas

ElastiCache admite Valkey, Redis OSS y Memcached. Memorystore ofrece Valkey, Redis y Memcached, mientras que Azure Managed Redis proporciona caché administrada con Redis. Las consultas de productos que se repiten con frecuencia pueden usar estas cachés para evitar lecturas repetidas de la base de datos.

Amazon MemoryDB está diseñado como una base de datos duradera en memoria. Una caché ordinaria puede expulsar o perder una entrada; la función de MemoryDB como base de datos duradera es diferente. Decide si los datos son una copia reemplazable antes de elegir basándote únicamente en el tiempo de respuesta.

Paga por la tasa de transferencia efectiva reservada o real

Con la capacidad aprovisionada, reserva de antemano una tasa de transferencia efectiva. DynamoDB usa unidades de capacidad de lectura y escritura; Cosmos DB usa unidades de solicitud por segundo, o RU/s. Una demanda predecible y estable puede hacer que esta opción sea económica. Con la capacidad bajo demanda o sin servidor, los cargos dependen de las solicitudes y la capacidad se ajusta a la demanda. El almacenamiento se factura por separado.

Un carrito de compra nuevo con picos impredecibles puede empezar con DynamoDB bajo demanda o Cosmos DB sin servidor. Una aplicación documental móvil que debe funcionar sin conexión encaja con las funciones de Firestore para dispositivos. Un equipo de fraude que rastrea vínculos entre cuentas necesita un servicio de grafos, no solo una búsqueda por clave más rápida.

El servicio independiente Cosmos DB for PostgreSQL está en proceso de retirada; no es otra API de cuenta. Microsoft dirige los nuevos proyectos de PostgreSQL distribuido a Elastic Clusters en Azure Database for PostgreSQL. Comprueba el servicio y la API reales antes de dar por supuesta la compatibilidad de una aplicación existente.

Una carga grande requiere un cálculo antes de elegir una herramienta. Determina cuánta capacidad de red puede usar realmente la migración y después compara ese tiempo con el proceso completo de transferencia sin conexión.

Expresa el tamaño y la velocidad en unidades compatibles

El almacenamiento usa bytes; las redes usan bits por segundo. Un byte contiene 8 bits. Con unidades decimales, 1 GB son mil millones de bytes, 1 TB son 1000 GB y 1 Gbps son mil millones de bits por segundo. Un GiB binario equivale aproximadamente a 1,074 GB, así que comprueba qué unidad muestra una herramienta.

Para 100 TB por un enlace de 1 Gbps, los datos contienen 800 billones de bits. Al dividir por mil millones se obtienen 800 000 segundos, aproximadamente 9,3 días. Con un uso efectivo del 80 %, divide por 0,8 Gbps: 1 000 000 de segundos, aproximadamente 11,6 días. A 100 Mbps, incluso el uso completo tarda unos 93 días. Un enlace de 1 Gbps transfiere como máximo 125 MB/s, o unos 10,8 TB al día, no 1 GB/s.

Relaciona las herramientas en línea con la interfaz

DataSync incluye programación, cifrado y comprobaciones de integridad y puede mover fuentes compatibles de sistemas de archivos u objetos a S3, EFS o FSx. Transfer Family es adecuado para socios que ya envían archivos mediante protocolos de transferencia establecidos. Una copia puntual y una sincronización continua son tareas distintas.

Compara con la transferencia sin conexión

Los dispositivos Azure Data Box proporcionan hasta 120 TB o 525 TB, con Data Box Disk para conjuntos más pequeños. Google Transfer Appliance también mueve datos en hardware enviado físicamente. Incluye el tiempo de pedido, copia, envío y carga por el proveedor; el proceso completo puede tardar entre una y varias semanas. Cifra el dispositivo y verifica los datos resultantes.

AWS Snowball Edge está cerrado a nuevos clientes y su soporte en regiones comerciales termina el 31 de diciembre de 2026. Las opciones actuales de AWS incluyen DataSync y Data Transfer Terminal, una ubicación física reservada donde los clientes llevan unidades para cargas de alta velocidad.

Una sede tiene un enlace de 200 Mbps, con la mitad disponible para la migración. La tasa efectiva es de 100 Mbps. Mover 300 TB tarda 24 millones de segundos, aproximadamente 278 días, lo que hace atractivo un dispositivo sin conexión. Mover 2 TB tarda 160 000 segundos, aproximadamente 1,9 días, por lo que el envío añadiría demora.

Las transferencias repetidas necesitan una ruta continua

AWS Direct Connect, Azure ExpressRoute y Google Cloud Interconnect proporcionan conectividad privada dedicada con una velocidad y una latencia más constantes. Pueden ser adecuados para grandes transferencias continuas. Un dispositivo sin conexión crea una copia inicial, pero no mantiene sincronizados los cambios posteriores.

Incluye en la estimación los cargos del servicio de transferencia y la salida de datos posterior. La entrada de datos por internet suele ser gratis; las descargas de la nube suelen costar por GB. Usa cifrado en tránsito y sumas de verificación o comprobaciones de integridad equivalentes para confirmar que la copia de destino esté completa.

Mover los bytes de una base de datos es solo una parte de la migración. El destino debe comprender el esquema, la aplicación debe funcionar con él y los cambios finales deben llegar antes de que los usuarios pasen al nuevo sistema.

Clasifica lo que cambia

Una migración homogénea conserva el motor, por ejemplo, de PostgreSQL a PostgreSQL administrado. Una migración heterogénea lo cambia, por ejemplo, de Oracle a PostgreSQL. Eso puede requerir la conversión de tipos de datos, esquemas, procedimientos almacenados y código de la aplicación.

Una migración con el mismo motor aún puede necesitar comprobaciones de versión o funciones. Un informe de conversión es útil precisamente porque identifica lo que no se transfiere automáticamente.

Limita el tiempo de inactividad

Una migración sin conexión detiene la aplicación para la exportación, la transferencia y la importación. Una migración en línea comienza con una carga completa mientras el origen permanece en uso. Después, la captura de cambios de datos (CDC) envía los nuevos cambios al destino. La copia inicial por sí sola ya está desactualizada si los usuarios siguieron escribiendo durante ella.

La transición al nuevo sistema requiere una secuencia controlada:

1. Detén las escrituras en el origen.
2. Aplica los cambios capturados restantes y confirma que el destino se ha puesto al día.
3. Convierte el destino en una base de datos independiente cuando sea necesario.
4. Redirige la aplicación y verifica que funcione.

La replicación continua reduce la ventana final; no elimina la necesidad de esa ventana ni de las pruebas. Mantener el origen antiguo en modo de solo lectura durante un período puede proporcionar una opción de respaldo sin permitir escrituras simultáneas incompatibles.

Elige herramientas de detección, conversión y migración

AWS DMS traslada bases de datos y admite replicación continua. AWS SCT y DMS Schema Conversion evalúan y convierten estructuras y código de bases de datos. Application Discovery Service recopila información de servidores; Application Migration Service realoja servidores. Migration Hub hace seguimiento del trabajo y Migration Evaluator ayuda a elaborar la justificación económica.

Azure Migrate detecta, evalúa y migra servidores, bases de datos y aplicaciones web. Azure Database Migration Service gestiona migraciones compatibles de SQL Server, PostgreSQL y MySQL mediante métodos en línea o sin conexión. Data Box transporta grandes copias de datos sin conexión; no realiza la conversión de esquemas.

Database Migration Service de Google admite migraciones a Cloud SQL o AlloyDB, incluidas migraciones continuas compatibles y conversiones heterogéneas a PostgreSQL. Migration Center detecta activos, los evalúa y estima los costos. Selecciona una ruta de origen a destino compatible, no solo un servicio que tenga «migración» en su nombre.

Resuelve una migración con cambio de motor

Una tienda disponible 24/7 traslada una base de datos Oracle de 2 TB a un destino administrado compatible con PostgreSQL. Evalúa primero la conversión. Crea el destino y convierte el esquema, reescribe los procedimientos señalados para trabajo manual e inicia la carga completa junto con CDC. Prueba la aplicación mientras continúa la replicación. Después, realiza la transición controlada. Una carpeta de archivos exportados en un contenedor de objetos es un recurso útil para la transferencia, pero los usuarios necesitan una base de datos de destino coherente y en funcionamiento.

El sistema que registra las transacciones de hoy tiene una función distinta a la del sistema que explica cinco años de historia empresarial. El análisis combina datos de muchas fuentes sin hacer que las transacciones habituales esperen a que terminen grandes exploraciones de datos.

Reconoce las estructuras de datos y las cargas de trabajo

Los datos estructurados tienen un diseño fijo, como una tabla de ventas. Los datos semiestructurados contienen etiquetas sin una estructura fija de tabla, como JSON o XML. Los datos no estructurados incluyen imágenes, audio y documentos de formato libre.

El OLTP, procesamiento de transacciones en línea, gestiona muchas lecturas y escrituras pequeñas de registros actuales. El OLAP, procesamiento analítico en línea, ejecuta grandes consultas sobre datos históricos. Los informes exigentes en una base de datos de producción pueden ralentizar los pedidos y los pagos, por lo que el análisis suele usar una copia independiente.

Compara el lago, el almacén y la arquitectura combinada

Un almacén combina fuentes en tablas consistentes. Su almacenamiento por columnas puede leer solo las columnas necesarias. Si una tabla de 2 TB tiene 100 columnas del mismo tamaño y una consulta necesita tres, la exploración aproximada es de 60 GB, no de 2 TB.

Un lago conserva archivos sin procesar para exploración, ciencia de datos y aprendizaje automático, incluidos datos cuyo uso posterior se desconoce. Sin un catálogo y responsables, resulta difícil encontrar algo o confiar en ello: es un «pantano de datos». Las arquitecturas de lago y almacén de datos añaden una gestión similar a la de un almacén con formatos como Apache Iceberg y Delta Lake. Un lago y un almacén pueden coexistir porque atienden etapas y necesidades distintas.

Sigue un flujo de datos

Un flujo de datos ingiere datos, los almacena, los transforma, los analiza y presenta los resultados o actúa en función de ellos. Con ETL, la extracción va seguida de la transformación y después de la carga. Con ELT, los datos se cargan primero y se transforman en el destino. Los almacenes en la nube pueden proporcionar la capacidad de procesamiento para ELT.

El procesamiento por lotes gestiona datos recopilados durante un período, como la carga nocturna de ventas. El procesamiento en flujo gestiona los eventos a medida que llegan, y es adecuado para paneles en directo, pagos sospechosos o alertas de sensores. Un informe histórico mensual puede funcionar bien por lotes; una reacción necesaria en segundos requiere procesamiento en flujo.

Mantén los datos utilizables y fiables

La gobernanza establece reglas y procesos para el acceso, la retención, el significado y la calidad. Un catálogo registra qué existe y qué significa. El linaje rastrea de dónde proceden los datos y qué transformaciones los modificaron. Juntos ayudan a un equipo a explicar una cifra en un panel.

Las comprobaciones de calidad abordan la integridad, exactitud, consistencia, actualidad, validez y unicidad. La falta de un código de región perjudica la integridad; los pagos duplicados perjudican la unicidad; un flujo desactualizado perjudica la actualidad. La calidad es útil antes tanto del análisis como de la inteligencia artificial. Los formatos abiertos y las herramientas interoperables facilitan el intercambio y reducen los silos de datos aislados y la dependencia de un proveedor.

Un servicio de análisis tiene un lugar específico en el camino que va de los eventos a las decisiones. Identifica esa función antes de elegir un producto de un proveedor: capturar un flujo, limpiarlo, consultarlo y mostrarlo son operaciones distintas.

Almacenes y consultas sobre archivos

Redshift ofrece almacenes aprovisionados y sin servidor. BigQuery es un servicio sin servidor, separa el almacenamiento del cómputo y ofrece precios de consulta basados en los datos examinados o en la capacidad. Microsoft Fabric combina funciones de almacén de datos y de arquitectura de lago y almacén; Synapse Analytics sigue disponible, aunque Fabric es la opción hacia la que se dirige el desarrollo nuevo.

Athena ejecuta SQL sin servidor sobre archivos de S3; no almacena los datos que consulta. Las tablas externas de BigQuery pueden leer archivos de Cloud Storage, y las tablas de la arquitectura de lago y almacén de Fabric en OneLake tienen un punto de conexión de análisis SQL. Consultar archivos en su ubicación es distinto de cargar otra copia en una base de datos.

Prepara datos y gestiona eventos

AWS Glue transforma datos y mantiene un catálogo que describe su estructura y ubicación. Azure Data Factory crea y programa flujos de datos. Google Dataflow ejecuta procesamiento tanto por lotes como en flujo con Apache Beam.

Para Spark y marcos de macrodatos relacionados, usa Amazon EMR, Azure Databricks o Fabric Spark, y Managed Service for Apache Spark de Google, antes Dataproc. Estos proporcionan marcos de procesamiento; no cumplen la misma función que un panel o un servicio de mensajes.

Para flujos, Amazon Kinesis captura y procesa datos en tiempo real y Data Firehose carga flujos en los destinos. Azure Event Hubs ingiere eventos; Stream Analytics o Fabric Real-Time Intelligence los analiza. Google Pub/Sub transporta mensajes y Dataflow los procesa.

Sigue un evento hasta el panel

Para un panel en directo de una tienda, los eventos de pedidos entran en Kinesis, Event Hubs o Pub/Sub. Las copias sin procesar se guardan en S3, Azure Data Lake Storage o Cloud Storage. Glue, Data Factory o Dataflow limpia los registros. Redshift, Fabric o BigQuery permite el análisis, y Quick Sight, Power BI o Looker muestra los resultados.

Looker puede definir métricas empresariales de forma centralizada para que los equipos usen el mismo significado para medidas como los ingresos. Amazon OpenSearch Service tiene otra función: indexar texto y registros para su búsqueda y análisis.

Reduce los cargos de consultas basados en datos examinados

Con una tarifa de ejemplo de 5 u.m. por TB examinado, leer 2 TB cuesta 10 u.m. Si un formato por columnas como Parquet permite que la consulta lea tres de 100 columnas del mismo tamaño, lee 60 GB, o 0,06 TB, con un costo de 0,30 u.m.. Si los archivos también se dividen en particiones por día y la consulta solo necesita uno de 30 días del mismo tamaño, la exploración baja a 2 GB, con un costo de 0,01 u.m..

El ahorro procede de excluir realmente las columnas y particiones innecesarias. El simple hecho de guardar un archivo en un almacén de objetos no garantiza una exploración pequeña. Las reservas de capacidad de BigQuery son una opción de facturación; no hacen que el cliente administre los servidores del almacén.

Los servicios de inteligencia artificial en la nube van desde API listas para usar hasta plataformas para entrenar modelos. La mejor capa de partida depende de la tarea empresarial, los datos y los conocimientos del equipo.

Relaciona las ideas principales

La inteligencia artificial abarca sistemas que realizan tareas como reconocer imágenes o comprender el lenguaje. El aprendizaje automático es un enfoque dentro de la IA: un modelo aprende patrones a partir de datos. El aprendizaje profundo usa redes neuronales de muchas capas. La inteligencia artificial generativa crea contenido como texto, imágenes o código a partir de una instrucción. Un modelo fundacional se entrena con datos amplios para adaptarse a muchas tareas; un modelo de lenguaje grande, o LLM, se centra en el lenguaje.

El entrenamiento produce o ajusta un modelo a partir de datos. La inferencia usa un modelo entrenado con una entrada nueva. Entrenar un modelo pequeño puede necesitar solo un procesador normal; los grandes modelos de aprendizaje profundo suelen necesitar GPU o TPU. Evaluar una compra nueva en busca de fraude es inferencia, aunque el modelo se haya entrenado meses antes.

La clasificación predice una categoría; la regresión predice un número. Estos métodos pueden simplificar reglas complicadas, prever la demanda, personalizar recomendaciones y detectar anomalías. La inteligencia artificial basada en agentes añade planificación y uso de herramientas para que un agente pueda realizar una tarea, como buscar información y llamar a una aplicación.

Elige una capa de servicio

1. Las API preentrenadas gestionan tareas establecidas como la traducción o el reconocimiento de voz sin crear un modelo.
2. Las plataformas generativas proporcionan modelos fundacionales, fundamentación en datos y herramientas para agentes: Amazon Bedrock, Microsoft Foundry y Gemini Enterprise Agent Platform, antes Vertex AI.
3. Las plataformas de aprendizaje automático crean, entrenan e implementan modelos personalizados: SageMaker AI, Azure Machine Learning y Gemini Enterprise Agent Platform. AutoML reduce el código necesario para entrenar con tus datos.
4. El aprendizaje automático dentro de servicios de datos, como BigQuery ML y Redshift ML, permite que los equipos trabajen mediante SQL donde ya se encuentran los datos.

Una empresa minorista que traduce descripciones puede usar una API de traducción. Un asistente de chat que responde a partir de manuales de la empresa puede usar generación aumentada por recuperación (RAG): recuperar fragmentos pertinentes de los manuales y proporcionarlos con cada pregunta. Una previsión de demanda basada en las ventas de la propia empresa puede usar AutoML, aprendizaje automático en bases de datos o una plataforma de aprendizaje automático. Crear desde cero añade esfuerzo cuando un servicio existente ya es adecuado.

Evalúa los datos y los resultados

Los ejemplos de entrenamiento incompletos, desactualizados o sesgados pueden producir resultados deficientes o injustos. Comprueba la integridad, exactitud, consistencia, actualidad, validez y unicidad. La inteligencia artificial responsable también requiere equidad, privacidad, seguridad, transparencia, explicabilidad, supervisión humana y responsabilidad.

Una respuesta generativa convincente puede contener una alucinación, una afirmación fluida pero falsa. Fundamenta los resultados importantes en información fiable y revísalos. El proveedor protege su servicio; el cliente controla los datos proporcionados, el acceso y el uso de los resultados. RAG proporciona evidencia al modelo, pero su presencia por sí sola no garantiza una respuesta correcta.

Muchas tareas habituales de inteligencia artificial ya cuentan con un servicio preentrenado. Una aplicación envía la entrada mediante una API y recibe resultados sin que sus desarrolladores tengan que entrenar primero un modelo.

Relaciona la entrada y el resultado

Los servicios de visión encuentran objetos, escenas y texto en imágenes; Video Intelligence API de Google gestiona el análisis de video. La conversión de voz a texto transcribe audio, mientras que la conversión de texto a voz genera voz a partir de texto escrito. El análisis de texto identifica sentimientos, entidades, frases clave o categorías. La traducción cambia el idioma del texto.

Los servicios de documentos conservan las relaciones dentro de los formularios, como qué fecha corresponde a la etiqueta «Fecha de factura» o qué importe es el total de una tabla. La detección general de texto en imágenes encuentra texto, pero no proporciona la misma comprensión del formulario. Por tanto, un flujo de facturas requiere extracción de documentos, no solo etiquetas de imágenes.

Combina servicios en torno a un proceso empresarial

Un centro de contacto puede transcribir llamadas grabadas, analizar el sentimiento de cada transcripción y mostrar en un panel los temas recurrentes que generan insatisfacción. La transcripción produce las palabras; el análisis de lenguaje interpreta aspectos de esas palabras.

Una aseguradora puede extraer nombres, fechas e importes de reclamaciones con un servicio de documentos y enviar los resultados de baja confianza a una persona. Esa revisión forma parte del proceso: un campo detectado es una predicción, no una garantía de que el valor sea correcto.

Amazon Lex crea chatbots de voz o texto y puede trabajar con Amazon Connect, un centro de contacto en la nube. Amazon Q proporciona asistencia generativa a usuarios empresariales y desarrolladores. Microsoft Foundry y Gemini Enterprise Agent Platform proporcionan herramientas para asistentes conversacionales y agentes. Azure Vision, Speech, Language y las API relacionadas forman parte de Foundry Tools, antes Azure AI services.

Estima el uso antes de estimar el precio

Los servicios pueden cobrar por imagen, minuto de audio, página, carácter traducido o token generado. Cuenta la unidad pertinente y después aplica la tarifa. Usa una tarifa de traducción de ejemplo de 15 u.m. por millón de caracteres. Dos mil descripciones de 500 caracteres cada una contienen un millón de caracteres. Traducirlas a diez idiomas procesa diez millones de caracteres y cuesta 150 u.m.. Contar solo el texto de origen dejaría fuera el procesamiento repetido para cada idioma.

Preentrenado no siempre significa comportamiento fijo. Los vocabularios personalizados de transcripción pueden ayudar con los nombres de productos; las etiquetas de imágenes personalizadas pueden reconocer los productos de una empresa; los clasificadores de documentos personalizados pueden ordenar sus formularios. Estas opciones permiten adaptar un servicio sin un proyecto completo de creación de modelos.

Las imágenes, voces y documentos pueden contener datos personales. Proporciónalos para una finalidad lícita, obtén consentimiento cuando sea necesario y controla el acceso y la retención. Elige el servicio según su tarea y sus necesidades de datos antes de decidir que es necesario un entrenamiento personalizado.