"Bem, isso é necessário", disse ela em voz alta sem se dirigir a ninguém. - Bem, isso é necessário! Por isso, está escrito diretamente - a principal tarefa da empresa é obter lucro no interesse dos acionistas. Bem, você pensa! Eles não têm medo de nada!
Julius Dubov, "O Mal Menor"
Vendo essa manchete, você provavelmente já decidiu que o artigo é estupidez ou provocação. Mas não tire conclusões precipitadas: os funcionários de grandes corporações, especialmente de empresas estatais, muitas vezes precisam comparar plataformas diferentes, incluindo completamente diferentes, por exemplo, como as do título.
Obviamente, ninguém compara DBMS assim, porque seus pontos fortes e fracos são bem conhecidos. Como regra, plataformas que resolvem um problema aplicado estão sujeitas a comparação. No artigo, mostrarei a técnica usada ao mesmo tempo, usando o exemplo de bancos de dados como um assunto que não é por boatos familiar aos leitores de Habr. Assim,
Motivação
Quando você inicia um projeto educacional ou um projeto de hobby, a motivação para escolher uma plataforma pode ser muito diversa: “Conheço melhor essa plataforma”, “Estou interessado em entender esta”, “aqui está a melhor documentação” ... No caso de uma empresa comercial, o critério de seleção é um: quanto terei que pagar e o que vou receber por esse dinheiro.
Naturalmente, você quer pagar menos e obter mais. No entanto, é necessário decidir o que é mais importante - pagar menos ou receber mais e atribuir um peso a cada nó. Vamos supor que uma solução de alta qualidade seja mais importante para nós do que uma solução barata e atribuímos ao nó "Custo" um peso de 40% e o nó "Oportunidades" - 60%.
Nas grandes empresas, geralmente acontece o contrário - o peso do valor não cai abaixo de 50% e talvez mais de 60%. No exemplo do modelo, é importante apenas que o peso total dos nós filhos de qualquer nó pai seja 100%.
Condições de corte
O site db-engines.com conhecia cerca de 500 sistemas de gerenciamento de banco de dados. Naturalmente, se você escolher uma plataforma de destino dentre tantas opções, poderá terminar com um artigo de revisão, mas não com um projeto comercial. Para reduzir o espaço de escolha, os critérios de corte são formulados e, se a plataforma não atender a esses critérios, ela não será considerada.
Os critérios de corte podem estar relacionados a recursos tecnológicos, por exemplo:
- Garantias ACID;
- modelo de dados relacionais;
- Suporte à linguagem SQL (observe que isso não é o mesmo que "modelo relacional");
- a possibilidade de escala horizontal.
Pode haver critérios gerais:
- disponibilidade de suporte comercial na Rússia;
- Código aberto;
- disponibilidade da plataforma no Registro do Ministério das Telecomunicações e Comunicações de Massa;
- a presença da plataforma em alguma classificação (por exemplo, nas primeiras cem da classificação db-engines.com);
- disponibilidade de especialistas no mercado (por exemplo, com base nos resultados da pesquisa do nome da plataforma no currículo no site hh.ru).
Afinal, pode haver critérios específicos da empresa:
- disponibilidade de especialistas na equipe;
- compatibilidade com o sistema de monitoramento X ou com o sistema de backup Y, no qual toda a manutenção está vinculada ...
O mais importante é ter uma lista de critérios de corte. Caso contrário, certamente haverá algum especialista (ou "especialista") que desfruta da confiança especial da gerência, que dirá "por que você não escolheu a plataforma Z, eu sei que é o melhor".
Estimativa de custo
O custo da solução obviamente consiste no custo de licenças, no custo de manutenção e no custo do equipamento.
Se os sistemas são aproximadamente da mesma classe (por exemplo, Microsoft SQL Server e PostgreSQL), por uma questão de simplicidade, podemos assumir que a quantidade de equipamentos para ambas as soluções será aproximadamente a mesma. Isso permitirá que você não avalie o equipamento, economizando muito tempo e esforço. Se você precisar comparar sistemas completamente diferentes (por exemplo, Oracle x Redis), é óbvio que, para uma avaliação correta, é necessário fazer o dimensionamento (cálculo da quantidade de equipamento). O dimensionamento de um sistema inexistente é uma tarefa muito ingrata; portanto, eles ainda tentam evitar essa comparação. É fácil fazer isso: zero perda de dados e um modelo relacional são gravados em condições de recorte, ou vice-versa - uma carga de 50 mil transações por segundo.
Para avaliar licenças, basta solicitar ao fornecedor ou a seus parceiros o custo de uma licença para um número fixo de núcleos e suporte por um período fixo. Como regra, as empresas já têm um forte relacionamento com os fornecedores de software e, se o departamento de operação do banco de dados não puder responder sozinho à questão de custo, basta uma carta para receber essas informações.
Fornecedores diferentes podem ter métricas de licenciamento diferentes: pelo número de núcleos, pela quantidade de dados ou pelo número de nós. O banco de dados em espera pode ser gratuito ou pode ser licenciado da mesma maneira que o principal. Se apenas algumas diferenças nas métricas forem encontradas, você precisará descrever em detalhes o suporte do modelo e calcular o custo das licenças para o suporte.
Um ponto importante para uma comparação correta são as mesmas condições de suporte. Por exemplo, o suporte da Oracle custa 22% do preço da licença por ano, e o suporte do PostgreSQL não custa nada. É correto comparar? Não, porque um erro que não pode ser eliminado por conta própria tem consequências completamente diferentes: no primeiro caso, os especialistas em suporte ajudarão a corrigi-lo rapidamente e, no segundo caso, há o risco de atraso no projeto ou tempo de inatividade do sistema concluído por um período indeterminado.
Existem três maneiras de equalizar as condições de cálculo:
- Use o Oracle sem suporte (na realidade, isso não acontece).
- Compre o suporte ao PostgreSQL - por exemplo, no Postgres Professional.
- Inclua riscos associados à falta de suporte.
Por exemplo, o cálculo de riscos pode ser assim: no caso de uma falha fatal no banco de dados, o tempo de inatividade do sistema será de 1 dia útil. O lucro planejado com o uso do sistema é de 40 bilhões de tugriks mongóis por ano, a frequência de acidentes é estimada em 1/400, portanto, o risco de falta de suporte é estimado em cerca de 100 milhões de tugriks mongóis por ano. Obviamente, “lucro planejado” e “taxa estimada de acidentes” são quantidades virtuais, mas é muito melhor ter um modelo desse tipo do que não ter nenhum.
Na realidade, o sistema pode ser muito importante e as perdas de reputação resultantes de períodos de inatividade prolongados serão inaceitáveis, portanto, será necessário suporte. Se o tempo de inatividade for permitido, a retirada do suporte às vezes pode ser uma boa maneira de economizar dinheiro.
Suponha que, após todos os cálculos, o custo da plataforma operacional A por 5 anos tenha sido 800 milhões de tugriks mongóis, o custo da plataforma operacional B - 650 milhões de tugriks e o custo da plataforma operacional C - 600 milhões de tugriks. A plataforma C, como vencedora, recebe um peso total pelo custo, e as plataformas A e B - um pouco menos, na proporção de quantas vezes são mais caras. Nesse caso - 0,75 e 0,92 pontos, respectivamente.
Avaliação de oportunidade
A avaliação das oportunidades é dividida em muitos grupos, cujo número é limitado apenas pela imaginação da pessoa que faz a avaliação. A melhor opção parece ser a divisão de recursos em equipes que usarão esses recursos; em nosso exemplo, são desenvolvedores, administradores e agentes de segurança da informação. Vamos supor que os pesos dessas funções sejam distribuídos como 40:40:20.
As funções de desenvolvimento incluem:
- facilidade de manipulação de dados;
- escala;
- a presença de índices secundários.
A lista de critérios, como seus pesos, é muito subjetiva. Mesmo ao resolver o mesmo problema, essas listas, pesos e respostas de itens diferem significativamente, dependendo da composição de sua equipe. Por exemplo, o Facebook usa o MySQL para armazenar dados, e o Instagram é construído sobre Cassandra. É improvável que os desenvolvedores desses aplicativos preencham essas tabelas. Pode-se adivinhar que Mark Zuckerberg escolheu um modelo relacional completo, pagando por ele com a necessidade de sharding aplicado, enquanto Kevin Systrom criou a plataforma para escalar, sacrificando a conveniência do acesso a dados.
As funções de administração incluem:
- recursos do sistema de backup;
- facilidade de monitoramento;
- conveniência de gerenciamento de capacidade - discos e nós;
- recursos de replicação de dados.
Observe que o texto das perguntas deve ser quantificável. Você pode até concordar em como avaliar uma função específica. Vamos, por exemplo, tentar classificar as ferramentas de backup usando o exemplo de ferramentas fornecidas com o Oracle DBMS:
| Ferramenta | Um comentário | Avaliação |
|---|---|---|
| imp / exp | Carregar e baixar dados | 0,1 |
| backup inicial / final | Copiando arquivos | 0,3 |
| RMAN | Capacidade de cópia incremental | 0,7 |
| ZDLRA | Apenas cópia incremental, recuperação mais rápida até o ponto | 1.0 |
Se não houver critérios de avaliação claros, faz sentido solicitar a vários especialistas que forneçam notas e depois faça a média delas.
Por fim, vamos apenas listar os recursos de segurança da informação:
- disponibilidade de políticas de gerenciamento de senhas;
- a capacidade de conectar ferramentas de autenticação externas (LDAP, Kerberos);
- modelo de acesso;
- ;
- ;
- (TLS);
- .
Separadamente, gostaria de alertar contra o uso dos resultados de quaisquer testes de carga que não foram feitos por você como argumentos.
Primeiro, a estrutura de dados e o perfil de carga dos aplicativos em teste podem diferir significativamente da tarefa que você resolverá. Cerca de 10 a 15 anos atrás, os fornecedores de bancos de dados adoravam exibir os resultados do benchmark TPC, mas agora ninguém parece levar esses resultados a sério.
Em segundo lugar, o desempenho do sistema depende bastante da plataforma para a qual o código foi originalmente escrito e do hardware em que o teste foi realizado. Eu já vi muitos benchmarks comparar o Oracle com o PostgreSQL. Os resultados variam da superioridade incondicional de um sistema à superioridade igualmente incondicional de outro.
E finalmente, em terceiro lugar, você não sabe nada sobre quem conduziu o teste. Ambas as qualificações, que afetam a qualidade do SO e a personalização da plataforma, são importantes, bem como a motivação, que afeta os resultados dos testes mais do que todos os outros fatores combinados.
Se o desempenho for um fator crítico, faça você mesmo o teste, de preferência com a ajuda de especialistas que irão configurar e manter o sistema de produção.
Resultado
Finalmente, o resultado de todo o trabalho realizado deve ser uma planilha, onde todas as estimativas são reunidas, multiplicadas e resumidas:
como você entende, alterando os pesos e ajustando as estimativas, você pode obter o resultado desejado, mas essa é uma história completamente diferente ...