“Isso é necessário”, disse ela em voz alta, sem se dirigir a ninguém. - Isso é necessário! É exatamente isso que diz: a principal tarefa de uma empresa é obter lucro no interesse dos acionistas. Bem, pense nisso! Eles não têm medo de nada!
Yuliy Dubov, “Mal Menor”
Depois de ver tal manchete, você provavelmente já decidiu que o artigo é uma estupidez ou uma provocação. Mas não tire conclusões precipitadas: funcionários de grandes corporações, especialmente corporações com participação estatal, muitas vezes têm que comparar plataformas diferentes, inclusive plataformas completamente diferentes - por exemplo, as do título.
É claro que ninguém compara SGBDs dessa forma, porque seus pontos fortes e fracos são bem conhecidos. Via de regra, as plataformas que resolvem algum problema de aplicação estão sujeitas a comparação. No artigo mostrarei a metodologia utilizada neste caso, usando o exemplo dos bancos de dados como um assunto familiar aos leitores do Habr em primeira mão. Então,
Motivação
Quando você inicia um projeto educacional ou um projeto de hobby, a motivação para escolher uma plataforma pode ser muito diversa: “esta é a plataforma que conheço melhor”, “estou interessado em entender esta”, “aqui está a melhor documentação” ... No caso de uma empresa comercial, o critério de seleção é o mesmo: quanto terei que pagar e quanto receberei com esse dinheiro.
Naturalmente, você quer pagar menos e ganhar mais. No entanto, você precisa 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 um peso de 40% ao nó “Custo” e 60% ao nó “Oportunidades”.
Nas grandes corporações, geralmente ocorre o oposto - o peso dos custos não cai abaixo de 50%, e talvez mais de 60%. No exemplo do modelo, tudo o que importa é que o peso total dos nós filhos de qualquer nó pai deve ser 100%.
Condições de corte
Site Existem cerca de 500 sistemas de gerenciamento de banco de dados conhecidos. Naturalmente, se você escolher uma plataforma alvo entre tantas opções, poderá acabar com um artigo de revisão, mas não com um projeto comercial. Para reduzir o espaço de escolha, são formulados critérios de corte e, se a plataforma não atender a esses critérios, ela não será considerada.
Os critérios de corte podem estar relacionados com características tecnológicas, por exemplo:
- Garantias ACID;
- modelo de dados relacional;
- Suporte à linguagem SQL (observe que não é o mesmo que o “modelo relacional”);
- possibilidade de escala horizontal.
Pode haver critérios gerais:
- disponibilidade de suporte comercial na Rússia;
- Código aberto;
- disponibilização da plataforma no Cadastro do Ministério das Telecomunicações e Comunicações de Massa;
- presença da plataforma em alguma classificação (por exemplo, na primeira centena da classificação db-engines.com);
- a presença de especialistas no mercado (por exemplo, com base nos resultados da busca pelo nome da plataforma em um currículo no site hh.ru).
Afinal, pode haver critérios específicos da empresa:
- disponibilidade de especialistas na equipe;
- compatibilidade com sistema de monitoramento X ou sistema de backup Y, no qual se baseia todo o suporte...
O mais importante é que exista uma lista de critérios de corte. Caso contrário, definitivamente haverá algum especialista (ou “especialista”) que goza de confiança especial da administração e dirá “por que você não escolheu a plataforma Z, eu sei que é a melhor”.
Estimativa de custo
O custo da solução consiste obviamente no custo das licenças, no custo do suporte e no custo do equipamento.
Se os sistemas forem aproximadamente da mesma classe (por exemplo, Microsoft SQL Server e PostgreSQL), então, para simplificar, 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 for preciso comparar sistemas completamente diferentes (digamos, Oracle vs. Redis), então é óbvio que para uma avaliação correta é necessário fazer o dimensionamento (cálculo da quantidade de equipamentos). Dimensionar um sistema inexistente é uma tarefa muito ingrata, por isso ainda tentam evitar tais comparações. Isso é fácil de fazer: nas condições de corte, são gravadas zero perda de dados e um modelo relacional, ou vice-versa - uma carga de 50 mil transações por segundo.
Para avaliar as licenças, basta solicitar ao fornecedor ou aos seus parceiros o custo de uma licença para um número fixo de núcleos e suporte por um período fixo. Via de regra, as empresas já possuem relacionamentos sólidos com fornecedores de software e, se o departamento de operações de banco de dados não conseguir responder sozinho à questão dos custos, uma carta será suficiente para obter essas informações.
Diferentes fornecedores podem ter diferentes métricas de licenciamento: por número de núcleos, volume de dados ou número de nós. A base standby pode ser gratuita ou licenciada da mesma forma que a principal. Se forem descobertas diferenças nas métricas, você terá que descrever detalhadamente o estande modelo e calcular o custo das licenças do estande.
Um ponto importante para uma comparação correta são as mesmas condições de suporte. Por exemplo, o suporte Oracle custa 22% do preço da licença por ano, mas você não precisa pagar pelo suporte PostgreSQL. É correto comparar assim? Não, porque um erro que não pode ser corrigido sozinho tem consequências completamente diferentes: no primeiro caso, os especialistas de suporte irão ajudá-lo rapidamente a corrigi-lo, mas no segundo caso, existe o risco de atrasar o projeto ou paralisação do finalizado sistema por tempo indeterminado.
Você pode equalizar as condições de cálculo de três maneiras:
- Usar Oracle sem suporte (na realidade isso não acontece).
- Compre suporte para PostgreSQL - por exemplo, do Postgres Professional.
- Leve em consideração os riscos associados à falta de apoio.
Por exemplo, um cálculo de risco pode ser assim: no caso de uma falha fatal no banco de dados, o tempo de inatividade do sistema seria de 1 dia útil. O lucro previsto com a utilização do sistema é de 40 mil milhões de MNT por ano, a taxa de acidentes é estimada em 1/400, portanto o risco de falta de apoio é estimado em aproximadamente 100 milhões de MNT por ano. Obviamente, “lucro planejado” e “frequência estimada de acidentes” são valores virtuais, mas é muito melhor ter um modelo assim do que não ter nenhum.
Na realidade, o sistema pode ser demasiado importante para que o custo de reputação do tempo de inatividade a longo prazo seja inaceitável, pelo que será necessário apoio. Se o tempo de inatividade for permitido, recusar o suporte às vezes pode ser uma boa maneira de economizar dinheiro.
Suponhamos que, após todos os cálculos, o custo de operação da plataforma A por 5 anos seja de 800 milhões de MNT, o custo de operação da plataforma B seja de 650 milhões de MNT e o custo de operação da plataforma C seja de 600 milhões de MNT. A plataforma C, como vencedora, recebe ponto integral pelo preço, enquanto as plataformas A e B recebem um pouco menos, na proporção de quantas vezes forem mais caras. Neste caso – 0.75 e 0.92 pontos, respectivamente.
Avaliação de oportunidade
A avaliação das oportunidades é dividida em vários grupos, cujo número é limitado apenas pela imaginação de quem faz a avaliação. A opção ideal parece ser dividir as capacidades em equipes que utilizarão essas capacidades; em nosso exemplo, são desenvolvedores, administradores e responsáveis pela segurança da informação. Vamos supor que os pesos dessas funções estejam distribuídos como 40:40:20.
As funções de desenvolvimento incluem:
- facilidade de manipulação de dados;
- dimensionamento;
- presença de índices secundários.
A lista de critérios, bem como os seus pesos, são muito subjetivos. Mesmo ao resolver o mesmo problema, essas listas, pesos dos itens e respostas irão variar significativamente dependendo da composição da sua equipe. Por exemplo, o Facebook usa MySQL para armazenar dados, e o Instagram é baseado em Cassandra. É improvável que os desenvolvedores desses aplicativos tenham preenchido essas tabelas. Só podemos imaginar que Mark Zuckerberg escolheu um modelo relacional completo, pagando por isso com a necessidade de fragmentação aplicada, enquanto Kevin Systrom construiu escalonamento usando a plataforma, sacrificando a facilidade de acesso aos dados.
As funções de administração incluem:
- recursos do sistema de backup;
- facilidade de monitoramento;
- facilidade de gerenciamento de capacidade – discos e nós;
- capacidades de replicação de dados.
Observe que as perguntas devem ser formuladas de maneira quantitativa. Você pode até concordar sobre como avaliar uma função específica. Vamos, por exemplo, tentar avaliar as ferramentas de backup usando o exemplo das ferramentas fornecidas com o Oracle DBMS:
Ferramenta
comentário
Avaliação
imp/exp
Fazendo upload e carregando dados
0.1
iniciar/terminar backup
Copiando arquivos
0.3
RMAN
Capacidade de cópia incremental
0.7
ZDLRA
Somente cópia incremental, recuperação mais rápida até o ponto
1.0
Se não existirem critérios de avaliação claros, faz sentido pedir a vários especialistas que atribuam classificações e depois calcular a média delas.
Por fim, listamos simplesmente as funções 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;
- capacidades de auditoria;
- criptografia de dados em disco;
- criptografia durante a transmissão pela rede (TLS);
- proteção de dados do administrador.
Teste de performance
Separadamente, gostaria de alertar contra o uso de resultados de testes de carga que não foram feitos por você como argumentos.
Em primeiro lugar, a estrutura de dados e o perfil de carga das aplicações testadas podem diferir significativamente do problema que você vai resolver. Cerca de 10 a 15 anos atrás, os fornecedores de bancos de dados adoravam exibir os resultados alcançados nos testes TPC, mas agora, ao que parece, ninguém leva esses resultados a sério.
Em segundo lugar, o desempenho do sistema depende fortemente da plataforma para a qual o código foi originalmente escrito e do equipamento em que o teste foi realizado. Já vi muitos testes onde o Oracle foi comparado com o PostgreSQL. Os resultados vão desde a superioridade incondicional de um sistema até a superioridade igualmente incondicional de outro.
E finalmente, em terceiro lugar, você não sabe nada sobre quem fez o teste. Ambas as qualificações são importantes, influenciando a qualidade da configuração do SO e da plataforma, bem como a motivação, que influencia os resultados dos testes mais do que todos os outros fatores combinados.
Se o desempenho for um fator crítico, realize você mesmo o teste, de preferência com a ajuda das pessoas que irão configurar e manter o sistema de produção.
resultado
Por fim, o resultado de todo o trabalho realizado deverá ser uma planilha onde todas as estimativas sejam combinadas, multiplicadas e somadas:
Como você entende, alterando as escalas e ajustando as classificações você pode alcançar qualquer resultado desejado, mas isso é uma história completamente diferente...
Fonte: habr.com