"Isto é necesario", dixo en voz alta, sen dirixirse a ninguén. - Isto é necesario! Isto é exactamente o que di: a principal tarefa dunha empresa é obter beneficios en interese dos accionistas. Ben, pensa niso! Non teñen medo a nada!
Yuliy Dubov, "Mal menor"
Despois de ver tal titular, probablemente xa decidiches que o artigo é unha estupidez ou unha provocación. Pero non se apresure a sacar conclusións: os empregados das grandes corporacións, especialmente as corporacións con participación estatal, moitas veces teñen que comparar diferentes plataformas, incluídas as completamente diferentes, por exemplo, as do título.
Por suposto, ninguén compara os DBMS deste xeito, porque os seus puntos fortes e débiles son ben coñecidos. Como regra xeral, as plataformas que resolven algún problema de aplicación están suxeitas a comparación. No artigo mostrarei a metodoloxía que se emprega neste caso, utilizando o exemplo das bases de datos como un tema que lles resulta familiar aos lectores de Habr de primeira man. Entón,
Motivación
Cando se inicia un proxecto educativo ou un proxecto de afección, a motivación para elixir unha plataforma pode ser moi diversa: “esta é a plataforma que mellor coñezo”, “interésame entender esta”, “aquí está a mellor documentación” ... No caso dunha empresa comercial, o criterio de selección é o mesmo: canto terei que pagar e que conseguirei por estes cartos.
Por suposto, quere pagar menos e obter máis. Non obstante, debes decidir o que é máis importante: pagar menos ou conseguir máis, e asignar un peso a cada nodo. Supoñamos que unha solución de alta calidade é máis importante para nós que unha barata, e asignamos un peso do 40% ao nodo "Custo" e do 60% ao nodo "Oportunidades".
Nas grandes corporacións adoita ser verdade o contrario: o peso do custo non cae por debaixo do 50%, e quizais máis do 60%. No exemplo do modelo, o único que é importante é que o peso total dos nodos fillos de calquera nodo pai debe ser do 100%.
Condicións de corte
Sitio web Coñécense uns 500 sistemas de xestión de bases de datos. Por suposto, se escolle unha plataforma de destino entre tantas opcións, pode acabar cun artigo de revisión, pero non un proxecto comercial. Para reducir o espazo de elección, formúlanse criterios de corte e, se a plataforma non cumpre estes criterios, non se considera.
Os criterios de corte poden estar relacionados con características tecnolóxicas, por exemplo:
- garantías ACID;
- modelo de datos relacionais;
- Soporte de linguaxe SQL (teña en conta que este non é o mesmo que o "modelo relacional");
- posibilidade de escalado horizontal.
Pode haber criterios xerais:
- dispoñibilidade de apoio comercial en Rusia;
- código aberto;
- dispoñibilidade da plataforma no Rexistro do Ministerio de Telecomunicacións e Comunicacións de masas;
- presenza da plataforma nalgunha clasificación (por exemplo, no primeiro cento da clasificación db-engines.com);
- a presenza de expertos no mercado (por exemplo, en función dos resultados da busca do nome da plataforma nun currículo no sitio web hh.ru).
Despois de todo, pode haber criterios específicos da empresa:
- dispoñibilidade de especialistas no persoal;
- compatibilidade co sistema de monitorización X ou sistema de copia de seguridade Y, no que se basea todo o soporte...
O máis importante é que haxa unha lista de criterios de corte. En caso contrario, definitivamente haberá algún experto (ou "experto") que goce dunha confianza especial da dirección que dirá "por que non escolleches a plataforma Z, sei que é a mellor".
Estimación de custos
O custo da solución consiste obviamente no custo das licenzas, o custo do soporte e o custo dos equipos.
Se os sistemas son aproximadamente da mesma clase (por exemplo, Microsoft SQL Server e PostgreSQL), entón, para simplificar, podemos supoñer que a cantidade de equipos para ambas as solucións será aproximadamente a mesma. Isto permitirache non avaliar o equipo, aforrando así moito tempo e esforzo. Se tes que comparar sistemas completamente diferentes (por exemplo, Oracle vs. Redis), entón é obvio que para unha correcta avaliación é necesario facer un dimensionamento (cálculo da cantidade de equipos). Dimensionar un sistema inexistente é unha tarefa moi ingrata, polo que aínda intentan evitar tales comparacións. Isto é fácil de facer: nas condicións de corte, escríbense cero perda de datos e un modelo relacional, ou viceversa: unha carga de 50 mil transaccións por segundo.
Para avaliar as licenzas, abonda con pedir ao vendedor ou aos seus socios o custo dunha licenza para un número fixo de núcleos e soporte durante un período determinado. Como regra xeral, as empresas xa teñen fortes relacións cos provedores de software, e se o departamento de operacións de base de datos non pode responder a pregunta dos custos por si só, unha carta é suficiente para obter esta información.
Os diferentes provedores poden ter diferentes métricas de licenza: por número de núcleos, volume de datos ou número de nodos. A base de espera pode ser gratuíta, ou pode ter licenza do mesmo xeito que a principal. Se se descubren diferenzas nas métricas, terás que describir detalladamente o modelo de stand e calcular o custo das licenzas para o stand.
Un punto importante para unha comparación correcta son as mesmas condicións de soporte. Por exemplo, o soporte de Oracle custa o 22% do prezo da licenza ao ano, pero non tes que pagar polo soporte de PostgreSQL. É correcto comparar así? Non, porque un erro que non se pode corrixir por conta propia ten consecuencias completamente diferentes: no primeiro caso, os especialistas de soporte axudarano rapidamente a solucionalo, pero no segundo caso, existe o risco de atrasar o proxecto ou o tempo de inactividade do acabado. sistema por un período indefinido.
Podes igualar as condicións de cálculo de tres xeitos:
- Use Oracle sen soporte (en realidade isto non ocorre).
- Compre soporte para PostgreSQL, por exemplo, de Postgres Professional.
- Teña en conta os riscos asociados á falta de apoio.
Por exemplo, un cálculo de risco pode verse así: en caso de falla fatal da base de datos, o tempo de inactividade do sistema sería de 1 día hábil. O beneficio proxectado polo uso do sistema é de 40 millóns de MNT ao ano, a taxa de accidentes estímase en 1/400, polo que o risco de falta de apoio estímase en aproximadamente 100 millóns de MNT ao ano. Obviamente, o "beneficio planificado" e a "frecuencia estimada de accidentes" son valores virtuais, pero é moito mellor ter tal modelo que non ter ningún.
En realidade, o sistema pode ser demasiado importante para que o custo reputacional do tempo de inactividade a longo prazo sexa inaceptable, polo que será necesario soporte. Se se permite o tempo de inactividade, rexeitar a asistencia ás veces pode ser unha boa forma de aforrar diñeiro.
Supoñamos que despois de todos os cálculos, o custo da plataforma operativa A durante 5 anos resulta ser de 800 millóns de MNT, o custo da plataforma operativa B é de 650 millóns de MNT e o custo da plataforma operativa C é de 600 millóns de MNT. A plataforma C, como gañadora, recibe un punto completo polo prezo, mentres que as plataformas A e B reciben algo menos, en proporción a cantas veces son máis caras. Neste caso – 0.75 e 0.92 puntos, respectivamente.
Avaliación de oportunidades
A avaliación das oportunidades divídese en moitos grupos, cuxo número só está limitado pola imaxinación da persoa que realiza a avaliación. A opción óptima parece ser dividir as capacidades en equipos que utilizarán estas capacidades; no noso exemplo, estes son desenvolvedores, administradores e oficiais de seguridade da información. Supoñamos que os pesos destas funcións están distribuídos como 40:40:20.
As funcións de desenvolvemento inclúen:
- facilidade de manipulación de datos;
- escalado;
- presenza de índices secundarios.
A lista de criterios, así como os seus pesos, son moi subxectivos. Mesmo ao resolver o mesmo problema, estas listas, pesos dos elementos e respostas variarán significativamente dependendo da composición do teu equipo. Por exemplo, Facebook usa MySQL para almacenar datos e Instagram está construído sobre Cassandra. É improbable que os desenvolvedores destas aplicacións cubriran tales táboas. Só se pode adiviñar que Mark Zuckerberg escolleu un modelo relacional completo, pagándoo coa necesidade de sharding aplicado, mentres Kevin Systrom construíu a escala usando a plataforma, sacrificando a facilidade de acceso aos datos.
As funcións administrativas inclúen:
- capacidades do sistema de copia de seguridade;
- facilidade de seguimento;
- facilidade de xestión da capacidade: discos e nós;
- capacidades de replicación de datos.
Teña en conta que as preguntas deben formularse de forma cuantitativa. Incluso podes poñerte de acordo sobre como avaliar unha función en particular. Imos, por exemplo, tentar valorar as ferramentas de copia de seguridade usando o exemplo das ferramentas que se proporcionan co DBMS de Oracle:
Ferramenta
Comentario
Avaliación
imp/exp
Cargando e cargando datos
0.1
comezar/finalizar a copia de seguridade
Copiando ficheiros
0.3
RMAN
Capacidade de copia incremental
0.7
ZDLRA
Só copia incremental, recuperación máis rápida ata o punto
1.0
Se non hai uns criterios de avaliación claros, ten sentido pedirlle a varios expertos que dean valoracións e despois promedian.
Finalmente, simplemente enumeramos as funcións de seguridade da información:
- dispoñibilidade de políticas de xestión de contrasinais;
- a capacidade de conectar ferramentas de autenticación externas (LDAP, Kerberos);
- modelo de acceso;
- capacidades de auditoría;
- cifrado de datos no disco;
- cifrado durante a transmisión pola rede (TLS);
- protección de datos do administrador.
Probas de rendemento
Por separado, gustaríame advertir contra o uso dos resultados das probas de carga que non fixeras ti como argumentos.
En primeiro lugar, a estrutura de datos e o perfil de carga das aplicacións que se están a probar poden diferir significativamente do problema que vai resolver. Hai uns 10-15 anos, aos vendedores de bases de datos encantáballes facer gala dos resultados acadados nas probas TPC, pero agora, ao parecer, ninguén se toma estes resultados en serio.
En segundo lugar, o rendemento do sistema depende en gran medida da plataforma para a que se escribiu orixinalmente o código e do equipo que se realizou a proba. Vin moitas probas onde se comparou Oracle con PostgreSQL. Os resultados van dende a superioridade incondicional dun sistema ata a superioridade igualmente incondicional doutro.
E por último, en terceiro lugar, non sabes nada de quen fixo a proba. Ambas as cualificacións son importantes, xa que inflúen na calidade da configuración do SO e da plataforma, así como na motivación, que inflúe nos resultados das probas máis que todos os demais factores xuntos.
Se o rendemento é un factor crítico, realiza a proba ti mesmo, preferiblemente coa axuda das persoas que configurarán e manterán o sistema de produción.
Resultado
Finalmente, o resultado de todo o traballo realizado debería ser unha folla de cálculo onde se combinen, multipliquen e sumen todas as estimacións:
Como entendes, cambiando as escalas e axustando as valoracións podes conseguir o resultado desexado, pero esa é unha historia completamente diferente...
Fonte: www.habr.com