Respuesta corta
Sí , puede escribir un punto de referencia significativo de un caso estudiado, si lo hace con cuidado, y comprende que si es relevante para el caso particular, puede no serlo para otros casos. Esto es igualmente cierto cuando se comparan las bases de datos del mismo tipo (base de datos relacional versus otra base de datos relacional) o las bases de datos de diferentes tipos.
No , no puede escribir un punto de referencia que demuestre mágicamente que una base de datos específica es mucho mejor que otra en cada caso, para cada aplicación.
Respuesta larga
Definitivamente es posible decir que "pasar de una base de datos a otra mejoró el rendimiento de nuestro sitio".
Mide el rendimiento de la base de datos anterior a través de perfiles o estadísticas de tiempo de ejecución mediante la recopilación de información suficiente sobre las consultas y la rapidez con que son.
Mueve la aplicación a la nueva base de datos.
Tú haces las mismas medidas.
Usted compara.
Por ejemplo, si la lista completa de 3 182 432 productos cargados en 2.834 s. en una base de datos antigua y se carga en 0.920 s. en una nueva base de datos, dado que en ambos casos, la aplicación tiene un caché vacío, es una victoria: la nueva base de datos mejoró el rendimiento de su sitio con respecto a esta consulta.
Ahora, como cualquier medida de rendimiento, está sesgada:
De acuerdo, la nueva consulta es más rápida. Pero espere, su DBA no sabía cómo usar la base de datos que tenía antes , por lo que la consulta que carga todos los productos no está optimizada . Si lo reescribe así, podría cargar esos productos en 0.855 s. en lugar de 2.834.
Ok, tienes un mejor resultado. Pero, ¿no cree que es injusto comparar una base de datos con datos nuevos que se han vaciado a una base de datos de 10 años para la cual se ejecutó el último plan de mantenimiento hace tres años? Por cierto, ¿no cree que debería haber actualizado el producto de la base de datos al menos una vez durante los últimos cuatro años?
Algunas consultas son más rápidas. Algunos son mas lentos. ¿Cómo calcula el resultado promedio para saber que obtuvo un rendimiento general al pasar a la nueva base de datos? Ok, el tiempo de carga de los 3 182 432 productos es más rápido. Pero, ¿importa si la consulta se ejecuta en el sitio web solo en casos excepcionales cuando un administrador realiza una tarea específica que realizó solo dos veces en los últimos diez años? Por otro lado, ejecutar todas las consultas en la página de inicio para un usuario nuevo desperdicia 0.281 s. con la nueva base de datos, cuando era 0.207 s. con la vieja base de datos. Este resultado es mucho más importante, especialmente porque esas consultas no se pueden almacenar en caché durante mucho tiempo, y se ejecutan decenas de miles de veces por día.
Ambas bases de datos deben probarse en los mismos servidores , mismo hardware, misma estructura. Por ejemplo, no puede probar una base de datos en un solo disco duro y la otra en un RAID1 de dos SSD. Cuando migra un proyecto grande a una nueva base de datos, existe la posibilidad de que aloje la nueva base de datos en otros cientos de servidores en rack recién implementados, cuando la base de datos anterior aún permanezca en las máquinas anteriores.
Para resumir, puede comparar las consultas de la base de datos de una aplicación y obtener métricas precisas . Pero entonces, tienes que dar un significado a los números. En este estado, es tentador decir que ganó rendimiento en el sitio: de lo contrario, la gerencia se enfadaría al saber que ha gastado miles de dólares y meses de trabajo solo para hacer las cosas más lentas.
El error más terrible es sacar esas conclusiones de los puntos de referencia y concluir alguna estupidez como "Microsoft SQL Server es tres veces más rápido que Oracle": decir esto es como decir que "Java es mejor que PHP". Define mejor. ¿Mejor en qué casos? ¿Para qué tipo de aplicaciones? ¿Para qué equipo de desarrolladores?
Cuanto más interpretas y generalizas, más la cosa se vuelve irrelevante y sin sentido.
La consulta select [...]que puede encontrar en la revisión # 832 en el archivo ProductFactory.cs, línea 117, se ejecuta en menos de 0.5 s. con la nueva base de datos cuando se prueba bajo las condiciones especificadas en el anexo M de requisitos no funcionales, caso 3. Esto permite pasar el requisito no funcional 527 (ver página 80, revisión 9). El mismo requisito no se cumplió con la base de datos anterior, cuando los resultados de la prueba estaban en el rango de 0.9..1.3 s. en las mismas condiciones
es significativo para un desarrollador y lo suficientemente preciso como para saber qué se probó, cómo y cuáles fueron los resultados. Esto responde a tu pregunta número 2.
Lamentablemente, no tiene ningún sentido para la administración. En lugar:
La migración de nuestro producto de MySQL a la versión más reciente de Microsoft SQL Server mejoró el rendimiento general de nuestro producto en cinco, reduciendo al mismo tiempo los costos en dos y la huella ambiental en tres. Creemos que la migración de todas nuestras aplicaciones a Microsoft SQL Server el próximo año dará mejores resultados y aumentará nuestra competitividad en el mercado.
es un jibber-jabber de marketing puro y, técnicamente, no significa nada, pero sorprendentemente tiene un valor para los departamentos de gestión y marketing.
Finalmente, ¿podemos comparar diferentes tipos de bases de datos? Yo diría que es totalmente posible. Digamos que tengo un sitio web que aloja fotos grandes. Esas fotos se almacenan en varbinary(max)Microsoft SQL Server 2005 (por lo que no puedo usar filestream). Me preocupa el rendimiento al cargar esas fotos, por lo que decido almacenar las fotos como archivos en su lugar, usando el sistema de archivos como mi nueva base de datos. Primero, esos archivos se almacenan en la misma máquina que la base de datos. Perfilo la nueva solución y obtengo el resultado que muestra que, en mi caso, los archivos se cargan un 4% más rápido desde el sistema de archivos que desde Microsoft SQL Server. El punto de referencia es muy claro. Ahora puedo pensar en implementar un servidor dedicado optimizado para el almacenamiento directo de archivos, en lugar de usar el servidor optimizado para Microsoft SQL Server.