¿Cuáles son algunos límites aproximados de rendimiento (lectura/s, escritura/s) para un único servidor de base de datos (sin arquitectura maestro-esclavo), suponiendo almacenamiento en disco? ¿Cuántas lecturas, escrituras, según el tipo de disco? (SSD vs no SSD), suponiendo operaciones simples (seleccione una fila por clave principal, actualice una fila, indexada correctamente). Supongo que este límite depende de la búsqueda/escritura del disco.
EDITAR: Mi pregunta es más sobre obtener métricas aproximadas de la cantidad de operaciones que admite una base de datos: para poder saber, por ejemplo, si una nueva función que activa 300 inserciones/s puede admitirse sin escalar con servidores adicionales.
Respuesta1
Puedes leer muchos resultados de pruebas comparativas.aquícomo si el sitio web fuera una fuente confiable.
Respuesta2
¿Puedo ser tan atrevido como para sugerirle que lo pruebe para obtener la respuesta a su propia consulta? Si tienes windows ejecutaSSIO.exeen su cuadro de desarrollo para probar el rendimiento del disco y comprender cómo funciona sin hacer nada.
Luego, ejecute el monitor de rendimiento (suponiendo que esté en MS-SQL TKProf, tal vez en Oracle; no use mysql u otros, lo siento, habrá una herramienta similar). Ejecute su consulta y observe cuántas lecturas/escrituras y cuánta CPU se necesitó para realizar él. Luego puede comparar los números de SSIO y Performance Monitor y escalar los requisitos de hardware para manejar la cantidad de usuarios/frecuencia que necesitará esta actualización según su equipo actual.
Dicho esto, 300 filas es una cantidad muy pequeña de filas que se deben cambiar para cualquier SQL Server razonable, incluso en discos bastante lentos. A menos que haya índices compuestos masivos o blobs, etc. Tengo procesos en vivo mientras el usuario observa una consulta que crea 1,5 millones de filas que se ejecutan en fracciones de segundo en un hardware relativamente modesto.
Respuesta3
Túno poderjuzgue sin comparar su aplicación y cárguela.
Todo se reduce a niveles de RAID, velocidades de eje, tamaño de las transacciones (no sólo "inserciones"), activadores, claves externas, hyperthreading, otras aplicaciones en el servidor, RAM en el servidor, cómo están organizados los discos (volúmenes separados para tempdb, uno por DB t-log, MDF, etc.), nivel de paquete de servicio, configuración de caché del controlador RAID, CPU Ls + caché L3, número de núcleos, diseño de esquema, código...
La ampliación es más fácil que la ampliación: agrega gastos generales si federa servidores o particiona tablas. Más barato añadir RAM y más husillos.
Un buen artículo esTPS de 35k de Paul Nielson. Carga al menos 100 veces mayor que las 300 aproximadamente.