"Esto es necesario", dijo en voz alta, sin dirigirse a nadie. - ¡Esto es necesario! Esto es exactamente lo que dice: la principal tarea de una empresa es obtener beneficios en interés de los accionistas. ¡Bueno, piensalo! ¡No le tienen miedo a nada!
Yuliy Dubov, “El mal menor”
Habiendo visto un titular así, probablemente ya haya decidido que el artículo es una estupidez o una provocación. Pero no se apresure a sacar conclusiones: los empleados de las grandes corporaciones, especialmente las corporaciones con participación estatal, a menudo tienen que comparar diferentes plataformas, incluidas plataformas completamente diferentes, por ejemplo, las que aparecen en el título.
Por supuesto, nadie compara los DBMS de esta manera, porque sus fortalezas y debilidades son bien conocidas. Como regla general, las plataformas que resuelven algún problema de aplicación están sujetas a comparación. En el artículo mostraré la metodología que se utiliza en este caso, utilizando el ejemplo de las bases de datos como un tema que los lectores de Habr conocen de primera mano. Entonces,
Motivación
Cuando inicias un proyecto educativo o un proyecto de hobby, la motivación para elegir una plataforma puede ser muy diversa: “esta plataforma la conozco mejor”, “me interesa entender ésta”, “aquí tienes la mejor documentación”. En el caso de una empresa comercial, el criterio de selección es el mismo: cuánto tendré que pagar y qué recibiré por ese dinero.
Naturalmente, usted quiere pagar menos y obtener más. Sin embargo, debe decidir qué es más importante: pagar menos u obtener más, y asignar un peso a cada nodo. Supongamos que una solución de alta calidad es más importante para nosotros que una barata, y asignamos un peso del 40% al nodo “Costo” y del 60% al nodo “Oportunidades”.
En las grandes corporaciones suele ocurrir lo contrario: el peso del coste no cae por debajo del 50%, y tal vez más del 60%. En el ejemplo del modelo, lo único importante es que el peso total de los nodos secundarios de cualquier nodo principal debe ser del 100%.
Condiciones de corte
Sitio Se conocen alrededor de 500 sistemas de gestión de bases de datos. Naturalmente, si elige una plataforma de destino entre tantas opciones, puede terminar con un artículo de revisión, pero no con un proyecto comercial. Para reducir el espacio de elección, se formulan criterios de corte y, si la plataforma no cumple con estos criterios, no se considera.
Los criterios de corte pueden estar relacionados con características tecnológicas, por ejemplo:
- Garantías del ÁCIDO;
- modelo de datos relacionales;
- Soporte de lenguaje SQL (tenga en cuenta que esto no es lo mismo que el “modelo relacional”);
- Posibilidad de escalado horizontal.
Puede haber criterios generales:
- disponibilidad de soporte comercial en Rusia;
- fuente abierta;
- disponibilidad de la plataforma en el Registro del Ministerio de Telecomunicaciones y Comunicaciones Masivas;
- presencia de la plataforma en alguna clasificación (por ejemplo, en los primeros cien de la clasificación de db-engines.com);
- la presencia de expertos en el mercado (por ejemplo, según los resultados de buscar el nombre de la plataforma en un currículum en el sitio web hh.ru).
Después de todo, puede haber criterios específicos de la empresa:
- disponibilidad de especialistas en el personal;
- compatibilidad con el sistema de monitoreo X o el sistema de respaldo Y, en el cual se basa todo el soporte...
Lo más importante es que exista una lista de criterios de corte. De lo contrario, seguramente habrá algún experto (o “experto”) que goce de una confianza especial por parte de la dirección y le dirá: “¿Por qué no elegiste la plataforma Z? Sé que es la mejor”.
Costo estimado
El costo de la solución obviamente consiste en el costo de las licencias, el costo del soporte y el costo del equipo.
Si los sistemas son aproximadamente de la misma clase (por ejemplo, Microsoft SQL Server y PostgreSQL), entonces, por simplicidad, podemos suponer que la cantidad de equipos para ambas soluciones será aproximadamente la misma. Esto le permitirá no evaluar el equipo, ahorrando así mucho tiempo y esfuerzo. Si tiene que comparar sistemas completamente diferentes (por ejemplo, Oracle versus Redis), entonces es obvio que para una evaluación correcta es necesario realizar un dimensionamiento (cálculo de la cantidad de equipo). Dimensionar un sistema inexistente es una tarea muy ingrata, por lo que todavía intentan evitar este tipo de comparaciones. Esto es fácil de hacer: en las condiciones de corte, se escribe un modelo relacional y una pérdida de datos cero, o viceversa: una carga de 50 mil transacciones por segundo.
Para evaluar las licencias, basta con preguntar al proveedor o a sus socios el coste de una licencia para un número fijo de núcleos y soporte durante un período determinado. Como regla general, las empresas ya tienen relaciones sólidas con los proveedores de software, y si el departamento de operaciones de la base de datos no puede responder la pregunta sobre el costo por sí solo, entonces una carta es suficiente para obtener esta información.
Los diferentes proveedores pueden tener diferentes métricas de licencia: por número de núcleos, volumen de datos o número de nodos. La base de reserva puede ser gratuita o se puede licenciar de la misma forma que la principal. Si se descubren diferencias en las métricas, deberá describir el stand modelo en detalle y calcular el costo de las licencias para el stand.
Un punto importante para una comparación correcta son las mismas condiciones de soporte. Por ejemplo, el soporte de Oracle cuesta el 22% del precio de la licencia por año, pero no tiene que pagar por el soporte de PostgreSQL. ¿Es correcto comparar así? No, porque un error que no puede solucionar usted mismo tiene consecuencias completamente diferentes: en el primer caso, los especialistas de soporte le ayudarán rápidamente a solucionarlo, pero en el segundo caso, existe el riesgo de retrasar el proyecto o de inactividad del producto terminado. sistema por tiempo indefinido.
Puede igualar las condiciones de cálculo de tres formas:
- Utilice Oracle sin soporte (en realidad esto no sucede).
- Compre soporte para PostgreSQL, por ejemplo, de Postgres Professional.
- Tenga en cuenta los riesgos asociados a la falta de apoyo.
Por ejemplo, un cálculo de riesgo podría verse así: en caso de una falla fatal en la base de datos, el tiempo de inactividad del sistema sería de 1 día hábil. El beneficio previsto por el uso del sistema es de 40 mil millones de MNT por año, la tasa de accidentes se estima en 1/400, por lo que el riesgo de falta de apoyo se estima en aproximadamente 100 millones de MNT por año. Obviamente, el “beneficio planificado” y la “frecuencia estimada de accidentes” son valores virtuales, pero es mucho mejor tener un modelo de este tipo que no tener ninguno.
En realidad, el sistema puede ser demasiado importante como para que el costo reputacional del tiempo de inactividad a largo plazo sea inaceptable, por lo que se necesitará apoyo. Si se permite un tiempo de inactividad, rechazar el soporte técnico a veces puede ser una buena forma de ahorrar dinero.
Supongamos que después de todos los cálculos, el costo de operar la plataforma A durante 5 años resulta ser de 800 millones de MNT, el costo de operar la plataforma B es de 650 millones de MNT y el costo de operar la plataforma C es de 600 millones de MNT. La plataforma C, como ganadora, recibe un punto completo por el precio, mientras que las plataformas A y B reciben un poco menos, en proporción a cuántas veces son más caras. En este caso, 0.75 y 0.92 puntos, respectivamente.
Evaluación de la oportunidad
La evaluación de oportunidades se divide en muchos grupos, cuyo número está limitado únicamente por la imaginación de quien realiza la evaluación. La opción óptima parece ser dividir las capacidades en equipos que las utilizarán; en nuestro ejemplo, se trata de desarrolladores, administradores y responsables de seguridad de la información. Supongamos que los pesos de estas funciones se distribuyen como 40:40:20.
Las funciones de desarrollo incluyen:
- facilidad de manipulación de datos;
- escalada;
- Presencia de índices secundarios.
La lista de criterios, así como sus ponderaciones, son muy subjetivas. Incluso cuando se resuelve el mismo problema, estas listas, pesos de elementos y respuestas variarán significativamente según la composición de su equipo. Por ejemplo, Facebook usa MySQL para almacenar datos e Instagram se basa en Cassandra. Es poco probable que los desarrolladores de estas aplicaciones completaran dichas tablas. Uno solo puede suponer que Mark Zuckerberg eligió un modelo relacional completo, pagándolo con la necesidad de fragmentación aplicada, mientras que Kevin Systrom construyó el escalamiento usando la plataforma, sacrificando la facilidad de acceso a los datos.
Las funciones de administración incluyen:
- capacidades del sistema de respaldo;
- facilidad de seguimiento;
- facilidad de gestión de la capacidad – discos y nodos;
- Capacidades de replicación de datos.
Tenga en cuenta que las preguntas deben redactarse de forma cuantitativa. Incluso pueden ponerse de acuerdo sobre cómo evaluar una función en particular. Intentemos, por ejemplo, calificar las herramientas de respaldo usando el ejemplo de las herramientas suministradas con Oracle DBMS:
Herramienta
comentario
Evaluación
diablillo/exp
Subiendo y cargando datos
0.1
iniciar/finalizar copia de seguridad
Copiando documentos
0.3
RMÁN
Capacidad de copia incremental
0.7
ZDLRA
Sólo copia incremental, recuperación más rápida hasta el punto
1.0
Si no existen criterios de evaluación claros, tiene sentido pedir a varios expertos que den calificaciones y luego promediarlas.
Finalmente, simplemente enumeramos las funciones de seguridad de la información:
- disponibilidad de políticas de gestión de contraseñas;
- la capacidad de conectar herramientas de autenticación externas (LDAP, Kerberos);
- modelo de acceso;
- capacidades de auditoría;
- cifrado de datos en disco;
- cifrado durante la transmisión a través de la red (TLS);
- protección de datos por parte del administrador.
Pruebas de rendimiento
Por otra parte, me gustaría advertirle contra el uso como argumentos de los resultados de cualquier prueba de carga que no haya realizado usted.
En primer lugar, la estructura de datos y el perfil de carga de las aplicaciones que se prueban pueden diferir significativamente del problema que se va a resolver. Hace unos 10 o 15 años, a los proveedores de bases de datos les encantaba hacer alarde de los resultados obtenidos en las pruebas TPC, pero ahora parece que nadie se toma en serio estos resultados.
En segundo lugar, el rendimiento del sistema depende en gran medida de para qué plataforma se escribió originalmente el código y en qué equipo se realizó la prueba. He visto muchas pruebas en las que se comparó Oracle con PostgreSQL. Los resultados van desde la superioridad incondicional de un sistema hasta la superioridad igualmente incondicional de otro.
Y por último, en tercer lugar, no sabes nada sobre quién hizo la prueba. Ambas cualificaciones son importantes e influyen en la calidad de la configuración del sistema operativo y la plataforma, así como en la motivación, que influye en los resultados de las pruebas más que todos los demás factores combinados.
Si el rendimiento es un factor crítico, realice la prueba usted mismo, preferiblemente con la ayuda de las personas que configurarán y mantendrán el sistema de producción.
resultado
Finalmente, el resultado de todo el trabajo realizado debe ser una hoja de cálculo donde se combinen, multipliquen y sumen todas las estimaciones:
Como comprenderás, cambiando las escalas y ajustando las calificaciones puedes lograr cualquier resultado deseado, pero esa es una historia completamente diferente...
Fuente: habr.com