O problema e o objetivo
Comparar Database Engines é uma tarefa complicada e muitas vezes desagradável de se
realizar. Mas como cada aplicação tem requisitos de perfomance e tratamento de dados
diferentes, não podemos ignorar as comparações e assumir que um ou outro banco de dados
é ideal para todo e qualquer tipo de aplicação / requisito.
No caso levarei em consideração uma aplicação que possui um requisito importante
para o bem-estar do cliente: Perfomance (Velocidade de resposta). Bem especificamente
alta perfomance no input de dados.
Os dados de entrada da aplicação, usualmente, são contabilizados na casa de 500 K
até 10 M linhas de entrada. Portanto o objetivo deste comparativo é identificar qual
destas opções é melhor aplicada para atender este requisito.
Este comparativo pode levantar diversas outras questões que conflitam com algumas
premissas como:
- A aplicação não é desenvolvida para atuar com um banco específico (database agnostic)
- É esperado que a aplicação possa atuar em qualquer ambiente (Windows, Linux, Solaris ) , para isso usaremos Java
- Não é cabível a utilização de um banco de dados NoSQL (motivos diversos)
Operação Lightning Fast
Para o comparativo terei algumas premissas que serão aplicadas a todos:
- Obrigatoriamente os dados devem ter origem em uma aplicação dinâmica, ou seja, a fonte de dados NÃO poderá ser um arquivo utilizado com uma operação de Bulk Insert via console ou algo do tipo
- Caso aplicável várias construções de queries poderão ser criadas para atingir o objetivo do comparativo (Single Row Insert, Stored Procedure, Multi Row Insert)
- Não será realizado nenhum tuning complexo no sistema de banco de dados
- A tabela de destino será uma tabela crua, sempre esvaziada no ínicio da rodada do teste e não possuirá nenhum tipo de índice
- Os sistemas de banco de dados estarão instalados em um ambiente virtualizado com VirtualBox na seguinte condição:
Host: CentOS 5.5 – Intel Xeon 2.83 4 Core – 8GB
Guest: Windows XP – 1 Core – 2GB
- Os testes serão realizados com origem em um aplicação Java, sendo executada em uma máquina distinta do servidor de dados, e os tempos sempre serão relativos a execução da transação de inserção
- A latência da rede será negligenciada
Design da base para o teste
Informação utilizada nas queries:
Utilizando um gerador aleatório de dados ASCII (alfanumérico) qualquer serão geradas sequências de 12 caracteres
para preencher cada coluna da tabela.
Ex.: (‘6K4S8G5M7J4O’,’6K5I7N5J0B6R’,’6K4G8P3C3Q0O’,’6K4P7E0A7P8L’,’6K0I2J4F3E3S’,’6K7U3A1J8E6H’,’6K1R6K8U7O3I’,’6K3B7N6M6I2N’,’6K7S7V6M6M1A’,’6K1Y7A3H6D1U’,’6K3F2J1Y7L2V’,’6K6O4R4U2J4P’,’6K0F7K8F1G5K’,’6K3X2B3H3O4H’,’6K0E0P5E0R2F’,’6K4K1X4W5J1C’,’6K0E6W7Q8K6H’,’6K3F8K8G0O4T’,’6K2S3W5Q5S1Y’,’6K4N7X7A4S8J’)
Resultados
De acordo com os resultados mostrados abaixo, concluímos que Mysql e Postrge são os mais velozes na operação de inserção, quanto ao Oracle e SQL Server devido ao comportamento do servidor durante a execução dos testes acredito que possa existir um gargalo no parsing das queries, pois somente neles o processamento do servidor chegou a casa dos 100% de CPU.
Como o objetivo do experimento era identificar os mais lentos e mais rápidos, o Mysql levou a medalha de ouro, mas não quer dizer que um banco é ou não melhor que o outro. No desenvolvimento de software não existe bala de prata, cada recurso é eficaz para solucionar um determinado domínio de problema.
#> sudo make a_sandwich 