2009-03-02 49 views
12

Me preguntaba qué hace al desarrollar una nueva aplicación en términos de estimación del tamaño de la base de datos.Estimación del tamaño de la base de datos

E.g. Estoy planeando lanzar un sitio web, y estoy teniendo dificultades para estimar qué tamaño podría esperar que mi base de datos crezca. No espero que me diga qué tamaño tendrá mi base de datos, pero me gustaría saber si existen principios generales para estimar esto.

E.g. Cuando Jeff desarrolló StackOverflow, (supuestamente) estimó el tamaño y el crecimiento de su base de datos.

Mi dilema es que voy a buscar una solución alojada para mi aplicación web (es sobre el costo en esta etapa), y preferiblemente no quiero dispararme en el pie al no comprar suficiente espacio de SQL Server (cobran una prima para esto).

+0

Escribí una aplicación para automatizar la producción de una hoja de cálculo que estima el tamaño futuro de una base de datos en función del número de filas por tabla. Consulte http://lucid-nonsense.co.uk/?page_id=456 Puede ser útil para usted. –

Respuesta

11

Si tiene un esquema de base de datos, el tamaño es bastante sencillo ... solo se estima filas * avg tamaño de fila para cada tabla * algún factor para índices * algún otro factor para sobrecarga. Dado el precio ridículamente bajo del almacenamiento hoy en día, el dimensionamiento a menudo no es un problema a menos que pretenda tener un sitio con mucho tráfico (o esté construyendo una aplicación para una gran empresa).

Para mis propios ejercicios de tamaño, siempre he creado una hoja de cálculo de Excel lista:

  • Col 1: cada tabla que va a crecer
  • col 2: estimado tamaño de columna en bytes
  • Col 3 : # estimado de filas (por año o máximo, dependiendo de la aplicación)
  • col 4: factor de índice (I siempre establecer este a 2)
  • col 5: factor de sobrecarga (I siempre se establece esta a 1,2)
  • col 6: total de la columna (col 2 X 3 X 4 X 5)

La suma de col 6 (columna total), más el tamaño inicial de la base de datos sin tablas de crecimiento, es su estimación del tamaño. Puedes obtener mucho más científico, pero esta es mi manera rápida y sucia.

+0

+1. una mejor explicación que la mía! –

+0

¡escribe demasiado rápido! eso es casi exactamente lo que dije :) – warren

+0

Gracias por toda su ayuda, muchachos, creo que esto me da un buen lugar para comenzar. –

0

El costo de la estimación es probable que sea más grande que el costo del almacenamiento

La mayoría de los proveedores de alojamiento venden capacidad por el ammount utilizado al final de cada mes, por lo que sólo se deja correr

0

Determinar:

  • el número de visitantes por día, V
  • cómo se crearon muchos registros de cada tipo por visita, N1, N2, N3 ...
  • camisetas que el tamaño de cada tipo de registro, S1, S2, S3 ...

EDIT: se olvidó factor de índice que una buena regla de oro es 2 veces

Crecimiento total por día = 2 * V * (N1 * S1 + S2 + N2 * * N3 + S3 ...)

0

Mis reglas de dedo a seguir son

  • el número de usuarios es lo que espero?
  • ¿qué contenido pueden publicar?
  • ¿Qué tan grande es un registro de usuario?
  • ¿Cuán grande es cada elemento de contenido que un usuario puede agregar?
  • cuánto va a agregar I?
  • ¿cuánto tiempo durarán esos elementos de contenido? ¿Siempre? solo un par de semanas?

Multiplicar el tamaño del registro del usuario multiplicado por el número de usuarios; agregue el número de usuarios por el tamaño del elemento de contenido; multiplicar por dos (para un conveniente factor de dulce de azúcar).

+0

Buena respuesta: los factores de rechazo son la parte más importante del tamaño de la base de datos ... como dijimos cuando era consultor "si el número parece demasiado bajo, solo agregue otro factor de borrado". –

Cuestiones relacionadas