ForHosting KIT · Utilidades de desarrollo

Calcule el almacenamiento para retener registros

Convierta el volumen diario de registros y el periodo de retención en el almacenamiento que necesita: 250 GB al día durante 30 días son 7.500 GB sin comprimir, y con una proporción de 0,4 se quedan en 3.000 GB, es decir, 3 TB. Gratis en su navegador.

  • Gratis
  • Funciona en su navegador
  • Sin registro
  • Sus datos no salen de su equipo
Úselo desde WebAPIEmailTelegramApp pronto
Si escribe
Volumen diario promedio (GB)
250
Días de retención
30
Relación de compresión
0,4
Obtiene
Almacenamiento bruto (GB)
7 500
Almacenamiento estimado (GB)
3 000
Almacenamiento estimado (TB)
3
Almacenamiento ahorrado (GB)
4 500

La calculadora de almacenamiento para retención de registros convierte el volumen diario ingerido y una política de conservación en una cifra práctica de capacidad. Introduzca el volumen bruto medio generado cada día, indique cuántos días deben estar disponibles los datos y, si procede, aplique la proporción de tamaño almacenado prevista tras la compresión. El resultado muestra la capacidad bruta, la capacidad estimada en gigabytes y terabytes, y el ahorro previsto, para que los equipos de infraestructura, seguridad y finanzas trabajen con una cifra común durante la planificación inicial.

Parta de un volumen diario representativo

Utilice el volumen bruto medio producido durante un periodo que refleje el funcionamiento habitual, expresado en gigabytes decimales. Un único día excepcionalmente tranquilo reducirá artificialmente el requisito, mientras que un pico durante un lanzamiento puede exagerar la demanda estable; por ello, una media semanal o mensual suele ser una mejor base de planificación. Incluya todas las fuentes cubiertas por la política de retención: eventos de aplicaciones, telemetría de infraestructura, registros de auditoría, fuentes de seguridad y cualquier flujo replicado que se almacene por separado.

La calculadora multiplica esta cantidad diaria por el periodo de retención para obtener el almacenamiento bruto. No deduce crecimiento, réplicas, índices, sobrecarga del sistema de archivos ni margen de seguridad. Esos factores dependen de la plataforma de registro y deben añadirse después de obtener la base.

Si prevé que el volumen aumentará, ejecute otro escenario con la cifra diaria proyectada en vez de ocultar el crecimiento dentro de la proporción de compresión. Mantener separadas las hipótesis de ingesta, retención y sobrecarga facilita revisar, actualizar y explicar la estimación durante las conversaciones de capacidad o presupuesto.

Interprete de forma coherente la proporción de compresión

La proporción de compresión opcional es un multiplicador del tamaño almacenado, no una expresión como «tres a uno». Introduzca 0.4 cuando espere que los datos comprimidos ocupen el 40 por ciento de su tamaño bruto; esto equivale a ahorrar un 60 por ciento de almacenamiento. Omita el campo para utilizar 1, que representa la ausencia de compresión y mantiene la capacidad almacenada estimada igual al requisito bruto.

Las proporciones deben ser mayores que cero y no superar uno, porque esta calculadora modela compresión, no expansión. Siempre que sea posible, base el valor en mediciones de registros representativos. El texto repetitivo puede comprimirse mucho, mientras que los valores cifrados, trazas de pila, identificadores o contenidos ya comprimidos pueden ofrecer un resultado menos favorable.

Compruebe también si su plataforma mide la compresión antes o después de indexar, ya que los índices y metadatos pueden aumentar considerablemente el uso físico. El ahorro devuelto es simplemente la capacidad bruta menos la comprimida, por lo que los revisores pueden ver exactamente qué parte de la estimación depende de esta hipótesis.

Convierta la base en un plan de capacidad implantable

Considere el resultado calculado como la base de almacenamiento de datos para el periodo de retención elegido. El resultado en gigabytes resulta útil para entornos pequeños y comparaciones directas con la ingesta diaria, mientras que los terabytes decimales facilitan comentar estimaciones mayores. El dimensionamiento de producción suele exigir provisiones adicionales para réplicas, índices consultables, metadatos, espacio temporal de fusión, instantáneas, copias de recuperación ante desastres y margen para picos de tráfico.

Aplique esos multiplicadores específicos de la plataforma de forma explícita después de este cálculo para que permanezcan visibles. Por ejemplo, un clúster de búsqueda replicado puede necesitar varias veces la capacidad física base aunque los datos lógicos retenidos no hayan cambiado. Compare varias ejecuciones para evaluar una retención más corta, un filtrado mejor o una mejora de compresión medida antes de comprometer el gasto.

El periodo debe ser un número entero positivo de días; se rechazan cero y los valores negativos porque no describen una necesidad de retención. Revise la estimación cuando cambien la ingesta o las normas y valide las compras finales con métricas observadas de la plataforma.

Dimensionar un nuevo clúster de registros

Calcule la base de almacenamiento lógico antes de añadir réplicas, sobrecarga de indexación, instantáneas y margen operativo.

Comparar políticas de retención

Pruebe distintos números de días para mostrar cómo los cambios de política afectan a la capacidad y al presupuesto de infraestructura.

Evaluar hipótesis de compresión

Compare proporciones medidas de tamaño almacenado y cuantifique la capacidad ahorrada al comprimir el mismo flujo bruto.

¿Qué significa una proporción de compresión de 0.4?

Significa que los registros almacenados ocuparán aproximadamente el 40% de su tamaño bruto, con un ahorro estimado del 60%.

¿Qué ocurre si omito la proporción de compresión?

La calculadora utiliza 1, por lo que el almacenamiento estimado equivale al volumen diario bruto multiplicado por los días de retención.

¿La estimación incluye réplicas e índices?

No. Solo estima los datos retenidos; añada por separado réplicas, índices, metadatos, instantáneas y margen propios de su plataforma.

¿Qué volumen diario debo introducir?

El volumen bruto medio de un periodo normal, mejor un promedio semanal o mensual, en gigabytes decimales. Un día tranquilo subestima la necesidad y un pico de lanzamiento la exagera. Incluya todas las fuentes que cubre la política de retención, como auditoría y seguridad.

¿Cómo elijo una proporción de compresión realista?

Mídala con registros representativos siempre que pueda. El texto repetitivo suele comprimirse mucho, mientras que valores cifrados, trazas de pila, identificadores o datos ya comprimidos se reducen bastante menos, así que una proporción prestada puede falsear la estimación.

Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.

POSThttps://api.kit.forhosting.com/dev/log-retention-storage-estimate

¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.

curl -X POST https://api.kit.forhosting.com/dev/log-retention-storage-estimate \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"average_daily_volume_gb":250,"retention_days":30}'
{
  "average_daily_volume_gb": 250,
  "retention_days": 30
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.log_retention_storage_estimate",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.

Por solicitud$0.002

Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.

HTTPCódigoSignificado
401unauthorizedAPI key ausente o inválida.
402insufficient_balanceEl saldo no cubre el precio de la tarea.
404unknown_typeEl tipo de tarea no existe.
429rate_limitedDemasiadas peticiones. Use el webhook en vez de sondear.
¿Cuánto cuesta?

Cuesta $0.002 por solicitud de API y también puede ejecutarse gratis en su navegador desde esta página.

¿El periodo de retención puede ser cero o negativo?

No. Los días de retención deben formar un entero positivo; los valores no válidos devuelven un error invalid_input.

Ver la documentación completa del KIT →