– Não é possível, – ela disse em voz alta, sem se dirigir a ninguém. – Não é possível! Está claramente escrito – a principal tarefa da sociedade é a obtenção de lucros em benefício dos acionistas. Pensem bem! Não têm medo de nada!
Yuli Dubov, "O Menor Mal"
Ao ver esse título, você provavelmente já decidiu que o artigo é ou uma besteira ou uma provocação. Mas não se precipite nas conclusões: os funcionários de grandes corporações, especialmente aquelas com participação do governo, frequentemente precisam comparar diferentes plataformas, incluindo algumas bastante distintas – como aquelas mencionadas no título.
Claro que ninguém compara SGBDs, pois seus pontos fortes e fracos são bem conhecidos. Normalmente, as plataformas comparadas são aquelas que resolvem alguma tarefa aplicada. Neste artigo, mostrarei a metodologia utilizada, tomando como exemplo bancos de dados, um assunto familiar para os leitores do Habr. Então,
Motivação
Quando você começa um projeto de estudo ou um projeto de hobby, a motivação para escolher uma plataforma pode ser bastante variada: "eu conheço melhor esta plataforma", "é interessante entender esta", "aqui está a melhor documentação"… No caso de uma empresa comercial, o critério de escolha é único: quanto terei que pagar e o que receberei por esse dinheiro.
Naturalmente, você quer pagar menos e receber mais. No entanto, é necessário decidir o que é mais importante – pagar menos ou receber mais, e atribuir um peso a cada nó. Suponha que valorize mais uma solução de qualidade do que uma barata, atribuindo um peso de 40% ao nó "Custo" e 60% ao nó "Recursos".
Em grandes corporações, normalmente é o contrário – o peso do custo não cai abaixo de 50%, e pode até ser acima de 60%. No exemplo modelo, o que importa é que o peso total dos nós filhos de qualquer nó pai deve ser 100%.
Critérios de exclusão
Site conhece cerca de 500 sistemas de gestão de bancos de dados. Naturalmente, ao escolher uma plataforma-alvo entre tantas opções, pode resultar em um artigo de revisão, mas não em um projeto comercial. Para reduzir o espaço de escolha, são formulados critérios de exclusão, e se uma plataforma não atender a esses critérios, ela não é considerada.
Os critérios de exclusão podem estar relacionados a características tecnológicas, como:
- garantias ACID;
- modelo relacional de dados;
- suporte à linguagem SQL (note que isso não é o mesmo que "modelo relacional");
- capacidade de escalabilidade horizontal.
Podem haver critérios gerais:
- existência de suporte comercial na Rússia;
- código aberto;
- plataforma listada no Registro do Ministério das Comunicações;
- plataforma em alguma classificação (por exemplo, entre os cem primeiros da classificação db-engines.com);
- existência de especialistas no mercado (por exemplo, pelos resultados da busca do nome da plataforma em currículos no site hh.ru).
Por fim, podem existir critérios específicos da empresa:
- existência de especialistas na equipe;
- compatibilidade com o sistema de monitoramento X ou com o sistema de backup Y, no qual todo o suporte está vinculado…
O mais importante é que a lista de critérios de exclusão exista. Caso contrário, sempre haverá algum especialista (ou "especialista") que goza de especial confiança da gestão, que dirá: "Por que vocês não escolheram a plataforma Z? Eu sei que ela é a melhor."
Avaliação de custos
O custo da solução é evidentemente formado pelo custo das licenças, custo do suporte e custo do hardware.
Se os sistemas forem aproximadamente da mesma classe (por exemplo, Microsoft SQL Server e PostgreSQL), então, para simplificar, pode-se considerar que o número de hardware para ambas as soluções será aproximadamente igual. Isso permitirá não avaliar o hardware, economizando assim muito tempo e esforço. No entanto, se for necessário comparar sistemas completamente diferentes (por exemplo, Oracle vs. Redis), é evidente que, para uma avaliação correta, é necessário fazer um sizing (cálculo da quantidade de hardware). O sizing de um sistema inexistente é uma tarefa bastante ingrata, portanto, tentam-se evitar tais comparações. Fazer isso é simples: nos critérios de exclusão são mencionadas a perda de dados zero e o modelo relacional ou, alternativamente, a carga de 50 mil transações por segundo.
Para avaliar as licenças, basta solicitar ao fornecedor ou seus parceiros o preço da licença para um número fixo de núcleos e suporte por um período determinado. Normalmente, as empresas já estabeleceram relações sólidas com os fornecedores de software, e se o departamento de operações de banco de dados não puder responder à pergunta sobre o preço por conta própria, uma única carta é suficiente para obter essa informação.
Os diferentes fornecedores podem ter diferentes métricas de licenciamento: por número de núcleos, volume de dados ou número de nós. Um banco de dados standby pode ser gratuito ou licenciado da mesma forma que o principal. Se forem detectadas algumas diferenças nas métricas, será necessário descrever detalhadamente o estande de modelo e calcular o custo das licenças para o estande.
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 valor da licença por ano, enquanto o suporte do PostgreSQL pode não ter custo. É correto comparar assim? Não, porque os efeitos de um erro que não pode ser corrigido por esforço próprio são completamente diferentes: no primeiro caso, os especialistas em suporte ajudarão rapidamente a solucioná-lo, enquanto no segundo caso existe o risco de atraso no projeto ou paralisação do sistema concluído por um período indefinido.
É possível igualar as condições de cálculo de três maneiras:
- Usar Oracle sem suporte (na prática, isso nunca acontece).
- Comprar suporte para PostgreSQL – por exemplo, da empresa Postgres Professional.
- Incluir no cálculo os riscos associados à falta de suporte.
Por exemplo, o cálculo dos riscos pode ser assim: em caso de falha irreparável do banco de dados, a paralisação do sistema será de 1 dia útil. O lucro previsto com a utilização do sistema é de 40 bilhões de tugriks mongóis por ano, e a frequência de falhas é estimada em 1/400, portanto, o risco da ausência de suporte é avaliado em aproximadamente 100 milhões de tugriks mongóis por ano. É evidente que o "lucro previsto" e a "frequência estimada de falhas" são quantidades virtuais, mas é muito melhor ter esse modelo do que não ter nenhum.
Na verdade, o sistema pode ser muito importante, e as perdas reputacionais de uma paralisação prolongada seriam inaceitáveis, por isso o suporte será necessário. No entanto, se a paralisação for permitida, a falta de suporte pode às vezes ser uma boa maneira de economizar.
Suponha que, após todos os cálculos, o custo de operação da plataforma A durante 5 anos foi de 800 milhões de tugriks mongóis, o custo da plataforma B foi de 650 milhões de tugriks, e o custo da plataforma C foi de 600 milhões de tugriks. A plataforma C, como vencedora, recebe uma pontuação total pelo custo, enquanto as plataformas A e B recebem pontuações um pouco menores, proporcionalmente ao quanto elas são mais caras. Neste caso, 0.75 e 0.92 pontos, respectivamente.
Avaliação de capacidades
A avaliação de capacidades é dividida em vários grupos, cujo número é limitado apenas pela imaginação de quem faz a avaliação. O ideal parece ser dividir as capacidades por equipes que utilizarão essas capacidades; no nosso exemplo, estas são desenvolvedores, administradores e oficiais de segurança da informação. Suponha 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;
- escalabilidade;
- existência de índices secundários.
A lista de critérios, assim como seus pesos, é bastante subjetiva. Mesmo ao resolver a mesma tarefa, essas listas, os pesos dos itens e as respostas variarão significativamente dependendo da composição da sua equipe. Por exemplo, o Facebook utiliza MySQL para armazenamento de dados, enquanto o Instagram é construído sobre Cassandra. É improvável que os desenvolvedores dessas aplicações tenham preenchido tais tabelas. Pode-se apenas especular que Mark Zuckerberg escolheu um modelo relacional completo, pagando por isso com a necessidade de sharding aplicado, enquanto Kevin Systrom incorporou a escalabilidade por meio da plataforma, sacrificando a conveniência de acesso aos dados.
As funções de administração incluem:
- capacidades do sistema de backup;
- facilidade de monitoramento;
- facilidade de gerenciamento de recursos – discos e nós;
- capacidades de replicação de dados.
Observe que as formulações das perguntas devem permitir uma avaliação quantitativa. Podemos até acordar sobre como avaliar cada função. Vamos, por exemplo, tentar classificar as ferramentas de backup com base nas ferramentas fornecidas com o SGBD Oracle:
A ferramenta
Comentário
Avaliação
imp/exp
Exportação e importação de dados
0.1
Início/fim do backup
Cópia de arquivos
0.3
RMAN
Capacidade de cópia incremental
0.7
ZDLRA
Somente cópia incremental, recuperação mais rápida para um ponto específico
1.0
Se não houver critérios claros de avaliação, faz sentido pedir a vários especialistas que atribuam notas e, em seguida, calcular a média.
Finalmente, vamos listar as funções de segurança da informação:
- existência de políticas de gerenciamento de senhas;
- capacidade de conectar-se a meios de autenticação externos (LDAP, Kerberos);
- modelo de acesso baseado em funções;
- capacidades de auditoria;
- criptografia de dados em disco;
- criptografia durante a transmissão pela rede (TLS);
- proteção de dados contra o administrador.
Testes de desempenho
Gostaria de alertar separadamente sobre o uso, como argumentos, de resultados de quaisquer testes de carga realizados por terceiros.
Primeiro, a estrutura dos dados e o perfil de carga das aplicações em teste podem diferir significativamente da tarefa que você pretende resolver. Há cerca de 10 a 15 anos, os fabricantes de bancos de dados gostavam de exibir resultados alcançados em testes TPC, mas agora parece que ninguém leva 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 no hardware em que o teste foi realizado. Eu já vi muitos testes em que o Oracle foi comparado com o PostgreSQL. Os resultados variam de uma superioridade absoluta de um sistema a uma igualmente absoluta superioridade de outro.
E, por fim, em terceiro lugar, você não sabe nada sobre quem conduziu o teste. A qualificação é importante, pois afeta a qualidade da configuração do sistema operacional e da plataforma, assim como a motivação, que influencia os resultados do teste mais do que todos os outros fatores juntos.
Se o desempenho for um fator criticamente importante, realize o teste você mesmo, preferencialmente com a participação de especialistas que irão configurar e manter o sistema de produção.
Resultado
Finalmente, o resultado de todo o trabalho deve ser uma planilha onde todas as notas estão compiladas, multiplicadas e somadas:
Como você entende, alterando os pesos e ajustando as notas, é possível alcançar qualquer resultado desejado, mas essa é uma história completamente diferente...
Fonte: habr.com
