– ¡Es increíble! – dijo en voz alta, sin dirigirse a nadie. – ¡Es increíble! Así de directo está escrito: la tarea principal de la sociedad es obtener beneficios en interés de los accionistas. ¡Piensen en eso! ¡No temen a nada!
Yuliy Dubov, "El mal menor"
Al ver tal título, seguramente ya han decidido que el artículo es una tontería o una provocación. Pero no se apresuren a sacar conclusiones: a los empleados de grandes corporaciones, especialmente de aquellas con participación estatal, a menudo les toca comparar diferentes plataformas, incluyendo algunas totalmente distintas, como las que se mencionan en el título.
Por supuesto, nadie compara bases de datos, ya que se conocen bien sus fortalezas y debilidades. Por lo general, se comparan plataformas que resuelven alguna tarea práctica. En el artículo mostraré la metodología que se utiliza en este caso, tomando como ejemplo bases de datos como un tema que los lectores de Habr conocen bien. Así que,
Motivación
Cuando inician un proyecto de aprendizaje o un proyecto personal, la motivación para elegir una plataforma puede ser muy diversa: «conozco mejor esta plataforma», «me interesa entender esta», «aquí está la mejor documentación»... En el caso de una empresa comercial, el criterio de elección es uno: cuánto hay que pagar y qué obtendré por ese dinero.
Por supuesto, se desea pagar menos y obtener más. Sin embargo, es necesario decidir qué es más importante: pagar menos o obtener más, y asignar un peso a cada nodo. Supongamos que nos importa más una solución de calidad que una económica, y le asignamos al nodo "Costo" un peso del 40%, mientras que al nodo "Características" un 60%.
En grandes corporaciones, por lo general, todo es al revés: el peso del costo no baja del 50%, y puede ser incluso mayor del 60%. En el ejemplo modelado, lo importante es que el peso total de los nodos secundarios de cualquier nodo padre debe ser del 100%.
Criterios de exclusión
El sitio web conoce alrededor de 500 sistemas de gestión de bases de datos. Por supuesto, al elegir una plataforma objetivo entre tal cantidad de opciones, podría resultar un artículo de revisión, pero no un proyecto comercial. Para reducir el espacio de selección, se formulan criterios de exclusión, y si la plataforma no cumple con esos criterios, no se considera.
Los criterios de exclusión pueden referirse a características tecnológicas, por ejemplo:
- garantías ACID;
- modelo relacional de datos;
- soporte para el lenguaje SQL (tenga en cuenta que no es lo mismo que «modelo relacional»);
- capacidad de escalado horizontal.
Puede haber criterios generales:
- existencia de soporte comercial en Rusia;
- código abierto;
- existencia de la plataforma en el Registro del Ministerio de Comunicaciones;
- existencia de la plataforma en algún ranking (por ejemplo, en el top 100 del ranking db-engines.com);
- existencia de expertos en el mercado (por ejemplo, según los resultados de búsqueda del nombre de la plataforma en currículos en el sitio hh.ru).
Finalmente, puede haber criterios específicos de la empresa:
- existencia de especialistas en el personal;
- compatibilidad con el sistema de monitoreo X o con el sistema de respaldo Y, en el que depende todo el soporte…
Lo más importante es que haya una lista de criterios de exclusión. De lo contrario, seguramente habrá algún experto (o «experto») que goce de la particular confianza de la dirección, que dirá «¿por qué no eligieron la plataforma Z? Sé que es la mejor».
Evaluación de costos
El costo de la solución se compone, evidentemente, del costo de las licencias, el costo del soporte y el costo del hardware.
Si los sistemas son aproximadamente de la misma clase (por ejemplo, Microsoft SQL Server y PostgreSQL), para simplificar se puede considerar que la cantidad de hardware para ambas soluciones será aproximadamente la misma. Esto permitirá no evaluar el hardware, ahorrando así mucho tiempo y esfuerzo. Sin embargo, si se trata de comparar sistemas completamente diferentes (digamos, Oracle frente a Redis), es evidente que para una evaluación correcta es necesario hacer un sizing (cálculo de la cantidad de hardware). Hacer el sizing de un sistema inexistente es una tarea bastante ingrata, por lo que se evita en la medida de lo posible tal comparación. Es sencillo: en las condiciones de exclusión se indican pérdida de datos nula y modelo relacional o, por el contrario, carga de 50 000 transacciones por segundo.
Para evaluar las licencias, basta con solicitar al proveedor o a sus socios el costo de la licencia para un número fijo de núcleos y soporte durante un periodo determinado. Por lo general, las empresas ya han establecido relaciones sólidas con los proveedores de software, y si el departamento de explotación de bases de datos no puede responder a la pregunta sobre el costo por sí mismo, obtener esta información requiere solo un correo electrónico.
Diferentes proveedores pueden tener métricas de licenciamiento distintas: según el número de núcleos, el volumen de datos o la cantidad de nodos. La base de datos en espera puede ser gratuita o puede licenciarse al mismo precio que la principal. Si se descubren algunas diferencias en las métricas, habrá que describir detalladamente el modelo de stand y calcular el costo de las licencias para el stand.
Un punto importante para una comparación correcta son las condiciones de soporte iguales. Por ejemplo, el soporte de Oracle cuesta el 22% del costo de la licencia por año, mientras que no se paga por el soporte de PostgreSQL. ¿Es correcto comparar así? No, porque las consecuencias de un error que no puede ser solucionado por los propios medios son completamente diferentes: en el primer caso, los especialistas de soporte ayudan a solucionar el problema rápidamente, mientras que en el segundo caso existe el riesgo de retrasar el proyecto o de que el sistema terminado esté inactivo durante un tiempo indeterminado.
Se pueden igualar las condiciones de cálculo de tres maneras:
- Usar Oracle sin soporte (en realidad, esto no sucede).
- Comprar soporte para PostgreSQL, por ejemplo, de la empresa Postgres Professional.
- Incluir en el cálculo los riesgos asociados con la falta de soporte.
Por ejemplo, el cálculo de riesgos puede ser así: en caso de una falla irremediable de la base de datos, el tiempo de inactividad del sistema será de 1 día laboral. La ganancia planificada por el uso del sistema es de 40 mil millones de tugrik mongoles al año, la frecuencia de fallos se estima en 1/400, así que el riesgo de no tener soporte se evalúa aproximadamente en 100 millones de tugrik mongoles al año. Es evidente que la "ganancia planificada" y la "frecuencia estimada de fallos" son cantidades virtuales, pero es mucho mejor tener un modelo así que no tener ninguno.
En realidad, el sistema puede ser demasiado importante, y las pérdidas de reputación debido a un tiempo de inactividad prolongado resultarían inaceptables, por lo que se requerirá soporte. Sin embargo, si se permite el tiempo de inactividad, a veces renunciar al soporte puede ser una buena manera de ahorrar.
Supongamos que, después de todos los cálculos, el costo de operación de la plataforma A durante 5 años resultó ser de 800 millones de tugrik mongoles, el costo de operación de la plataforma B fue de 650 millones de tugrik, y el costo de operación de la plataforma C fue de 600 millones de tugrik. La plataforma C, como ganadora, recibe un punto completo por su costo, mientras que las plataformas A y B obtienen un poco menos, en proporción a cuánto más caras son. En este caso, obtienen 0.75 y 0.92 puntos, respectivamente.
Evaluación de capacidades
La evaluación de capacidades se divide en múltiples grupos, cuyo número está limitado solo por la imaginación de quien evalúa. La opción óptima parece ser dividir las capacidades según los equipos que las utilizarán; en nuestro ejemplo, serían los desarrolladores, administradores y funcionarios de seguridad de la información. Supongamos que los pesos de estas funciones se distribuyen como 40:40:20.
Las funciones de desarrollo pueden incluir:
- facilidad para manipular datos;
- escalabilidad;
- presencia de índices secundarios.
La lista de criterios, así como sus pesos, es muy subjetiva. Incluso al resolver la misma tarea, estas listas, los pesos de los puntos y las respuestas variarán significativamente según la composición de su equipo. Por ejemplo, Facebook utiliza MySQL para almacenar datos, mientras que Instagram se basa en Cassandra. Es poco probable que los desarrolladores de estas aplicaciones hayan completado tales tablas. Solo podemos suponer que Mark Zuckerberg eligió un modelo relacional completo, pagando por ello la necesidad de ‘sharding’ aplicado, mientras que Kevin Systrom priorizó la escalabilidad mediante los recursos de la plataforma, sacrificando la facilidad de acceso a los datos.
Las funciones de administración incluyen:
- capacidades del sistema de backup;
- facilidad de monitoreo;
- facilidad de gestión de recursos: discos y nodos;
- capacidades de replicación de datos.
Tenga en cuenta que la formulación de las preguntas debe permitir una evaluación cuantitativa. Incluso se puede acordar cómo evaluar cada función. Por ejemplo, intentemos calificar las herramientas de copia de seguridad utilizando los herramientas proporcionadas con la base de datos Oracle:
Herramienta
Comentario
Evaluación
imp/exp
Exportación e importación de datos
0.1
copia de seguridad de inicio/final
Copia de archivos
0.3
RMAN
Capacidad de copia de seguridad incremental
0.7
ZDLRA
Solo copia de seguridad incremental, recuperación más rápida al punto
1.0
Si no hay criterios claros de evaluación, tiene sentido pedir a varios expertos que emitan calificaciones y luego promediarlas.
Finalmente, enumeremos las funciones de seguridad de la información:
- existencia de políticas de gestión de contraseñas;
- capacidad de conectar herramientas de autenticación externas (LDAP, Kerberos);
- modelo de acceso basado en roles;
- capacidades de auditoría;
- cifrado de datos en disco;
- cifrado durante la transmisión por red (TLS);
- protección de datos contra el administrador.
Prueba de rendimiento
Me gustaría advertir especialmente sobre el uso de resultados de pruebas de carga realizadas por otros como argumentos.
En primer lugar, la estructura de datos y el perfil de carga de las aplicaciones que se están probando pueden diferir significativamente de la tarea que planea resolver. Hace 10 o 15 años, los fabricantes de bases de datos solían presumir de los resultados obtenidos en las pruebas TPC, pero ahora parece que nadie toma esos resultados en serio.
En segundo lugar, el rendimiento del sistema depende en gran medida de la plataforma para la que se escribió originalmente el código y del hardware utilizado para realizar la prueba. He visto muchas pruebas donde Oracle se comparaba con PostgreSQL. Los resultados varían desde la superioridad indiscutible de un sistema hasta la igual superioridad del otro.
Y finalmente, en tercer lugar, no sabe nada sobre quién realizó la prueba. Es importante la calificación, que influye en la calidad de la configuración del sistema operativo y la plataforma, así como la motivación, que influye en los resultados de la prueba más que todos los demás factores juntos.
Si el rendimiento es un factor crítico, realice la prueba usted mismo, preferiblemente con la participación de especialistas que configurarán y mantendrán el sistema industrial.
Resultado
Finalmente, el resultado de todo el trabajo realizado debe ser una hoja de cálculo en la que se consolidan, multiplican y suman todas las calificaciones:
Como ustedes entenderán, al cambiar los pesos y ajustar las calificaciones se puede lograr cualquier resultado requerido, pero esa es otra historia…
Fuente: habr.com
