"Bueno, esto es necesario", dijo en voz alta sin dirigirse a nadie. - Bueno, esto es necesario! Por lo tanto, está escrito directamente: la tarea principal de la empresa es obtener ganancias en interés de los accionistas. Bueno, tu piensas! ¡No tienen miedo a nada!
Julius Dubov, "El mal menor"
Al ver ese titular, probablemente ya haya decidido que el artículo es estupidez o 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 las completamente diferentes, por ejemplo, como las del título.
Por supuesto, nadie compara DBMS así, porque sus fortalezas y debilidades son bien conocidas. Como regla general, las plataformas que resuelven un problema aplicado están sujetas a comparación. En el artículo, mostraré la técnica que se utiliza al mismo tiempo, utilizando el ejemplo de las bases de datos como un tema que, según los rumores, no es familiar para los lectores de Habr. Entonces,
Motivación
Cuando comienza un proyecto educativo o un proyecto de pasatiempos, la motivación para elegir una plataforma puede ser muy diversa: "Conozco mejor esta plataforma", "Estoy interesado en comprender esta", "aquí está la mejor documentación" ... En el caso de una empresa comercial, el criterio de selección es uno: cuánto tendré que pagar y qué obtendré por este dinero.
Naturalmente, desea pagar menos y obtener más. Sin embargo, es necesario decidir cuál es más importante: pagar menos o recibir 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 le asignamos al nodo "Costo" un peso del 40% y al nodo "Oportunidades" - 60%.
En las grandes corporaciones, lo contrario suele ser el caso: el peso del valor no cae por debajo del 50%, y tal vez más del 60%. En el ejemplo del modelo, solo es importante que el peso total de los nodos secundarios de cualquier nodo primario sea del 100%.
Condiciones de corte
El sitio db-engines.com conoce unos 500 sistemas de gestión de bases de datos. Naturalmente, si elige una plataforma objetivo de tantas opciones, puede terminar con un artículo de revisión, pero no un proyecto comercial. Para reducir el espacio de elección, se formulan criterios de corte, y si la plataforma no cumple con estos criterios, entonces no se considera.
Los criterios de corte pueden relacionarse con características tecnológicas, por ejemplo:
- ACID garantiza;
- modelo de datos relacionales;
- Soporte de lenguaje SQL (nota, esto no es lo mismo que "modelo relacional");
- La posibilidad de escala 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 de Masa;
- la presencia de la plataforma en alguna calificación (por ejemplo, en los primeros cien de la calificación db-engines.com);
- disponibilidad de expertos en el mercado (por ejemplo, en función de los resultados de la búsqueda del nombre de la plataforma en el currículum del 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 con el sistema de respaldo Y, en el cual todo el mantenimiento está vinculado ...
Lo más importante es tener una lista de criterios de corte. De lo contrario, definitivamente habrá algún experto (o "experto") que disfrute de la confianza especial de la administración, que dirá "por qué no eligió 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 de mantenimiento 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 equipo 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 el dimensionamiento (cálculo de la cantidad de equipo). El dimensionamiento de un sistema inexistente es una tarea muy ingrata, por lo que aún intentan evitar esa comparación. Es fácil hacer esto: cero pérdida de datos y un modelo relacional se escriben en condiciones de recorte, o viceversa, una carga de 50 mil transacciones por segundo.
Para evaluar las licencias, es suficiente pedirle al vendedor o sus socios el costo de una licencia para un número fijo de núcleos y soporte por un período fijo. 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 de costos por sí sola, entonces una carta es suficiente para recibir esta información.
Diferentes proveedores pueden tener diferentes métricas de licencia: por la cantidad de núcleos, la cantidad de datos o la cantidad de nodos. La base de datos en espera puede ser gratuita o puede tener licencia de la misma manera que la principal. Si solo se encuentran algunas diferencias en las métricas, tendrá que describir en detalle el soporte del modelo y calcular el costo de las licencias para el soporte.
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, y el soporte de PostgreSQL no cuesta nada. ¿Es correcto comparar? No, porque un error que no se puede eliminar por nuestra cuenta tiene consecuencias completamente diferentes: en el primer caso, los especialistas de soporte ayudarán rápidamente a solucionarlo, y en el segundo caso, existe el riesgo de retraso del proyecto o tiempo de inactividad del sistema terminado por un período indefinido.
Hay tres formas de igualar las condiciones de cálculo:
- Use Oracle sin soporte (en realidad, esto no sucede).
- Compre soporte PostgreSQL, por ejemplo, de Postgres Professional.
- Incluya los riesgos asociados con la falta de apoyo.
Por ejemplo, el cálculo de riesgos puede verse así: en caso de una falla fatal de la base de datos, el tiempo de inactividad del sistema será de 1 día hábil. El beneficio previsto del uso del sistema es de 40 mil millones de tugriks mongoles por año, la frecuencia de accidentes se estima en 1/400, por lo tanto, el riesgo de falta de apoyo se estima en unos 100 millones de tugriks mongoles por año. Obviamente, la "ganancia planificada" y la "tasa de accidentes estimada" 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 por un tiempo de inactividad prolongado serán inaceptables, por lo que se necesitará apoyo. Si se permite el tiempo de inactividad, dejar el soporte a veces puede ser una buena manera de ahorrar dinero.
Supongamos que después de todos los cálculos, el costo de la plataforma operativa A durante 5 años resultó ser de 800 millones de tugriks mongoles, el costo de la plataforma operativa B - 650 millones de tugriks, y el costo de la plataforma operativa C - 600 millones de tugriks. La plataforma C, como ganadora, recibe un punto de peso completo por el costo, y las plataformas A y B, 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 oportunidad
La evaluación de oportunidades se divide en muchos grupos, cuyo número está limitado solo por la imaginación de la persona que realiza la evaluación. La mejor opción parece ser la división de capacidades en equipos que utilizarán estas capacidades; en nuestro ejemplo, se trata de desarrolladores, administradores y oficiales 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;
- La presencia de índices secundarios.
La lista de criterios, como sus pesos, es muy subjetiva. Incluso al resolver el mismo problema, estas listas, ponderaciones de elementos y respuestas diferirán significativamente dependiendo de la composición de su equipo. Por ejemplo, Facebook usa MySQL para almacenar datos, e Instagram está construido sobre Cassandra. Es poco probable que los desarrolladores de estas aplicaciones llenen tales tablas. Uno solo puede adivinar que Mark Zuckerberg eligió un modelo relacional completo, pagándolo con la necesidad de aplicar fragmentos, mientras que Kevin Systrom estableció la escala mediante la plataforma, sacrificando la conveniencia del acceso a datos.
Las funciones de administración incluyen:
- capacidades del sistema de respaldo;
- facilidad de monitoreo;
- conveniencia de la gestión de capacidad: discos y nodos;
- capacidades de replicación de datos.
Tenga en cuenta que la redacción de las preguntas debe ser cuantificable. Incluso puede 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 | Un comentario | Evaluación |
|---|---|---|
| imp / exp | Cargar y descargar datos | 0.1 |
| comenzar / finalizar copia de seguridad | Copiando documentos | 0,3 |
| RMAN | Capacidad de copia incremental | 0.7 |
| ZDLRA | Copia incremental solamente, recuperación más rápida al punto | 1.0 |
Si no hay criterios de evaluación claros, tiene sentido pedirles a varios expertos que proporcionen calificaciones y luego promediarlas.
Finalmente, enumeremos las características de seguridad de la información:
- disponibilidad de políticas de administración de contraseñas;
- la capacidad de conectar herramientas de autenticación externas (LDAP, Kerberos);
- modelo a seguir de acceso;
- ;
- ;
- (TLS);
- .
Por separado, me gustaría advertir contra el uso de los resultados de cualquier prueba de carga que no haya hecho usted como argumento.
Primero, la estructura de datos y el perfil de carga de las aplicaciones bajo prueba pueden diferir significativamente de la tarea que va a resolver. Hace unos 10-15 años, a los proveedores de bases de datos les encantaba hacer alarde de los resultados de referencia de TPC, pero ahora nadie parece tomar en serio estos resultados.
En segundo lugar, el rendimiento del sistema depende en gran medida de la plataforma para la que se escribió originalmente el código y de qué hardware se realizó la prueba. He visto muchos puntos de referencia comparar Oracle con PostgreSQL. Los resultados van desde la superioridad incondicional de un sistema hasta la superioridad igualmente incondicional de otro.
Y finalmente, en tercer lugar, no sabes nada sobre quién realizó la prueba. Ambas calificaciones, que afectan la calidad del sistema operativo y la personalización de la plataforma, son importantes, así como la motivación, que afecta 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 especialistas 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 todas las estimaciones se unen, se multiplican y se resumen:
como entiendes, cambiando los pesos y ajustando las estimaciones, puedes lograr cualquier resultado deseado, pero esta es una historia completamente diferente ...