This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português
English version:
Disclaimer
Although I have a perfectly clear disclaimer on the right side of the blog, I'd like to start this article by re-enforcing that disclaimer. Everything I'll write here are my own thoughts and in no way represent my employer view or position. It's probable also that the ideas presented here may go against some respectable people's ideas and some established opinions. I'd like to apologize if someone expects something different. Having said this, the ideas presented here are my real belief, based on my work experience, on my readings and many discussions with some very respectable people.
What is a database benchmark?
Database benchmarks are well defined stress tests and usually when we see references to them chances are that it's all about the
TPC council published benchmarks. The TPC council is a non-profit organization whose members are database software vendors, hardware makers, and other IT related organizations. The purpose of the TPC (Transaction Processing Council) is to "
define transaction processing and database benchmarks and
to disseminate objective, verifiable TPC performance data to the
industry".
The TPC has defined several specs for benchmarks. The specs have designations like:
- TPC-C
OLTP benchmark
- TPC-D
Datawarehouse benchmark (deprecated)
- TPC-H
Datawarehouse benchmark (current)
- TPC-DS
Decision support benchmark (new)
- TPC-E
OLTP benchmark created to replace the TPC-C
The benchmark specs are very detailed and include everything that defines the tests. This include the database schema, the queries that are to be run, the several rules that specify what can and can't be used in terms of features, and also what must be used (like referential and check constraints etc.).
The benchmark reports include the measures taken, which are typically specified in number of transactions per time unit (the transactions are well defined in the specs). They also include the total system cost, which should include hardware and software costs including acquisition and support for a well defined period of time (3 years for example)
And these specs have evolved over time, due to several reasons:
- New hardware and software features turned earlier specs useless (like materialized views which killed TPC-D)
- New uses of software made some old specs look a bit outdated, meaning that new specs were created to better match the new reality
Personally I have no reason to assume that TPC was not created with good intentions. But for reasons that will be clarified along this article,
I give no credit to the benchmarks.
They only measure the will of a supplier to win, and how well it can twist the benchmark rules in order to achieve something worth publishing. Please note that although I have some commercial understanding of the market, I'm basically a technician. If you're talking to top management of big companies, they tend to don't understand any technical related argument, and they might, because of that, give some credit to the benchmarks published on TPC.org. But if you're talking to some technically aware person, I believe it's easy to dismantle a benchmark in around 10m (I'll try it for the top TPC-C published as an exercise).
Having said this, running a publishable benchmark represents an enormous technical and economic effort, and I must grant credit to the companies which do it.
The TPC-E mystery...
TCP-E benchmark specification was introduced because TPC-C had a lot of holes that made it unrealistic. You can easily find several opinions stating it's a better benchmark than it's predecessor.
But if you check the results you'll see that only one database vendor, Microsoft, has publish results for this. The mystery is why? Of course, MS supporters say it's because no one can beat them. No one else believes that. Most people who dedicate some time to study this believe that this is a leap frog game and it really depends on the investment. And if it's still done (or was) with TPC-C, a very mature specification, it should be even easier to do with a relatively new benchmark (the tricks are easier to discover and implement while the specs are still new). I've found several references on the Internet speaking about why no one entered the TPC-E "game", but none of them is conclusive (from my perspective). I can leave some references here for your own research:
You can decide for yourself. Personally I think the issue is related to what Mr. Jerry Keesee (IBM Informix database development director) explained in a public webcast (Chat with the labs) on 29 January 2009. More on that later.
But currently for OLTP, the most popular benchmark is TPC-C. TPC-E apparently is being pushed by hardware vendors (including IBM).
Benchmarks and Informix
Informix was a regular leader of benchmarks in the nineties. It used to partner with hardware vendors to achieve several top result in several categories.
The subject of benchmarks is very sensitive within the Informix community. Many people strongly believe that IBM should run official benchmarks using Informix. IBM never did it after acquiring Informix Software Inc. We may understand or not that position, but the reasons were clearly explained by Mr. Jerry Keesee, in a very clear answer to the question "How come IBM doesn't participate in public benchmarks of IDS? Like the TPC.org benchmarks?". The question was asked by a well known (and particularly critical of IBM) participant of the Informix forums at the end of a webcast in 29 January 2009. The reasons presented were:
- IBM has been doing TPC-C benchmarks with DB2 for a very long time. If we do one with Informix only two things can happen and they're both bad for IBM:
- Informix gets a better number, and the competition and analysts would crush us (IBM and DB2)
- Informix gets a worse number, and the competition and analysts would crush us (IBM and Informix)
- We could consider TPC-E, but currently there's only one vendor (MS) who published results on this kind of benchmark. Once we publish one (which would be better in absolute numbers or cost, since no one publishes a benchmark that doesn't show an improvement), we would have entered a very expensive race, because the vendor who is surpassed will probably reply and the leap frog game would start. Jerry prefers to invest on new features and product improvements which directly bring benefits to the customers.
You can't ask for something clearer than this. Meanwhile a
benchmark on MDM (Meter Data Management) was done and published and Informix got a great result but this is not a standard. So it does not satisfy people who really want TPC results.
Very recently you may have noticed that the words "TPC-C" and "Informix" were floating around the social networks and some Informix related sites. That's because Eric Vercelletto decided to pick the TPC-C schema and specifications and run a
non-oficial database stress test. While some people were jumping around in happiness others were criticizing him. My position is much more neutral, and I think most of the people talking about it never took the time to make a deep analysis of a TPC-C benchmark result. The opinions tend to be divided between something like "yeah!!! Informix finally has a TPC-C benchmark. Now we can show the performance Informix can achieve" and "Oh... The result is so low. He used the free version. It's useless". Really, if you want to speak about it, let's spend some time to look at some facts:
- The benchmark run by Eric is not a true TPC-C benchmark. It's not official, it's not audited and yes, the number is very low if you compare it to other official published results (which by the way can't be done for legal and technical reasons)
- Yes, Eric used the Innovator-C edition, which is a cut down version free of costs. It has limits and lacks some features that could help (only 2GB of RAM, no partitioning etc.)
- Eric fought against technical problems with the clients sending the transactions. In fact he put the clients and the database on the same machine. Something you'll never see in a true benchmark
- Eric used 4 hard disks. You can find a published result on TPC.org site with the same number of cores in the database server, that used 200 hard disks. Yes, you read correctly, two hundred hard disks (but for the top results the numbers are on the thousands)
- The same published benchmark used 10 cores for the clients and 4 cores for the database server. Compare that to the troubles Eric had with the client programs
- Eric used 16GB of memory for both the database and the clients. The benchmark I mentioned above used 72GB just for the database server
- Eric mention his system costs less than 900€. The system that run the above mentioned test was priced at more than $200000
- Eric mentions he tried a client server configuration, but he could not reach more than 15-20% CPU use on the database server. This of course means he had great problems in the way the benchmark was being done (either not enough CPU power on the clients or other constraints like disk/memory on the DB server). In any case this would never get published if it was a true benchmark until the problems were fixed (in which case the numbers would rise dramatically)
So, given all this, are you assuming I don't appreciate Eric's work? Not so! Eric was a colleague at Informix Portugal around 1999 when I moved from a "4GL guy" onto an "engine guy" and he helped me on that. I know he's technically skilled and I appreciate his effort and his voluntarism to push this issue. What I'm trying to show is that the real TPC-C benchmarks belong to a completely different league. They use an unrealistic amount of hardware including CPUs, memory, disk, caching, Solid State Disks, and also an incredible human power. Every small detail is carefully analyzed and any bottleneck identified is studied to the limit. This sometimes brings real improvements to the products, but many times just creates a "smart scheme" to "fool" the benchmark rules. More on this later.
What Eric did is completely different and I never saw it being done: Take some commodity hardware like the one small customers may use, employ very little human effort, and try to make a stress test. Is it useful? Yes, but mostly for the person doing it, and eventually because it triggers others to do something similar or just talk about it. Is it comparable to the benchmarks you normally see referenced in press releases? No! You can't even start comparing it.
Another situation where I've seen people doing something similar is the Advanced Datatools promoted "
fastest Informix DBA" challenge, that usually happens at the IIUG conferences. And it's interesting to see that Lester Knutsen will be showing this soon at Mac Tech. See it for yourself:
http://www.youtube.com/watch?v=ScDyRrsI3H4&feature=share
Quick overview of the TPC-C top result
I mentioned earlier that I would go through the top TPC-C result published as of today in TPC.org. This benchmark was run by Oracle with version 11gR2 with RAC and partitioning. It achieved a very respectable result of over 30M tpmC (thirty millions of transactions per minute - type C -). The observations below are taken from the
full benchmark disclosure report Let's see the facts:
- [Page 6] The system cost was roughly $30M (yes, thirty million dollars). Note that this price is not the price list. It includes a discount of $30M (50%).
- [Page 4] It used 27 servers (oracle RAC nodes) for the database, each one with 4 Sparc processors. This means 1728 cores total (16 cores for each processor).
- [Page 4] It used a central storage unit containing over 11000 24GB SSDs (Solid State Disks) and 720 2TB 7.2RPM SAS disks
- [Page 4] Each one of the 27 nodes had 512GB of RAM, for a total of 13.5TB of RAM for the database servers side
- [Appendix B] Most of the tables and indexes were partitioned in at least 27 pieces. Yes... 27, the same number of nodes. The why is explained below
- [Appendix B] 27 UNDO tablespaces were created... yes 27 again.
- [Page 30/TPC-C Spec] Clause 2.4.1.5 of the current TPC-C specs, define that any "New Order" (one of the five transactions) will refer to a "home warehouse" 99% of the times. So if you setup the clients properly, you split them for 27 RAC nodes. And 99% of the "New Order" transactions will use a "home warehouse". This will all be contained in one of the 27 table partitions. Meaning each database node will essentially work with one of the partitions. Now... The "New Order" transaction represented nearly 45% of all the transactions run in this test. The "Payment" transaction represented around 43%. And for this one, 85% of them used a "home warehouse".
- What is the problem with RAC? The cache fusion... or in other words the piece of the system that guarantees data consistency across the nodes... It's a well known bottleneck, and Oracle usually says you don't have to change the application, but the fact is, if you don't, it will not scale. And TPC-C allows the system to be configured in a way that the various nodes act almost (99% of 45% and 85% of 43%) as if they were isolated nodes. So it scales... I bet you can imagine what Oracle would have to do to get a higher number...: Just add nodes and partitions... (change the application and keep the affinity)
- [TPC-C Spec] From the other three transactions ("Stock level", "Order Status" and "Delivery") only one ("Delivery") includes data changes. The other two are read-only.
- From the 3 later bullets you can understand how unrealistic this is, and the tricks used that take full advantage of it. But we still have one strong point about this benchmark: "Ok, I understand they dumped a ton of hardware and used allowed tricks to push the performance numbers... But what about the cost? It's cost per transaction is better than many previous benchmarks!". True! But once again, we must read everything very carefully. If you browse through several of these benchmarks (and this reflects reality) you'll notice that a very significant part of the cost is for software license and maintenance. The specs require the costs to be calculated for a three years period. And surely, all this hardware should raise the software costs, wouldn't it? Err... Yes, but no! Once again, let me explain... The TPC-C specs just require a calculation for 3 years. So what will a smart vendor do? Simply create a license that instead of perpetual is only for 3 years. As you can see here on the Oracle Price list, a processor license of enterprise version would cost you $47500. On the benchmark result [Page 5] you notice that the value is $23750. Then go back to the price list and notice the small letters on page 9. It states that for a 3 Year term license the cost is 50% of the perpetual license. So this cuts the software costs of the benchmark into 50% (without counting the global 50% discount on all prices). In a real situation it would mean a 75% discount on the software, but of course, after the 3 years period you'd need to uninstall the licenses or just buy new ones
- Finally, support. The benchmarks mentions [Page 5] $62100 for Oracle Incident Server Support package per year. This is exactly 27 * $2300 which accordingly to the price list [Page 13] entitles you to web based support. I cannot find any item in the benchmark that would entitle you to upgrade your software as is normal when you pay S&S (Service and Support). Again, accordingly to the price list small lettered footer this would be 22% (per year) of the perpetual licenses.
So, I'm sure the above would not take more than 10m to explain to any customer. And in my perspective it shows the benchmark was twisted (in a fully legal and compliant manner of course) to increase the performance numbers and to decrease the cost. But neither the technical scenario nor the budget reflect a real customer scenario. This is why, in my opinion these benchmarks are worthless. And finally, if you ask me, I really prefer to have the money (and it's a lot) invested in the R&D of the product or in other marketing activities.
Having said this, I really think what Eric has done is an interesting exercise that may allow you to train your performance tunning skills. And I believe (no inside info here) that database vendors may use the schemas and queries to regularly test the software. It may allow them to notice positive or negative performance changes while they introduce new functionality and performance optimizations.
As for the published benchmarks? They exist solely for the purpose of getting headlines and press releases.
Versão Portuguesa:
Termo de responsabilidade
Apesar de ter um termo de (des)responsabilização perfeitamente claro no lado direito do
blog,
gostaria de começar este artigo por reforçar esses mesmos termos. Tudo o
que escreverei aqui são as minhas próprias opiniões e ideias e de forma
nenhuma refletem o ponto de vista ou posição da minha entidade
patronal. É provável que algumas ideias apresentadas aqui vão contra as
ideias de gente muito respeitável e algumas opiniões bem estabelecidas.
Peço desculpa a quem esperasse algo diferente. Tendo dito isto, as
ideias apresentadas são as minhas reais convicções, baseadas na minha
experiência de trabalho, nas minhas leituras e em muitas discussões com
pessoas que respeito muito.
O que é um benchmark de base de dados?
Os
benchmarks de base de dados são testes de
stress e habitualmente quando vemos referências a eles, é provável que se refiram aos
benchmarks publicados pelo
TPC council. O
TPC Council é uma organização sem fins lucrativos cujos membros são fornecedores de bases de dados, fornecedores de
hardware e outras organizações relacionadas com as tecnologias de informação (TI). O propósito do
TPC (Transaction Processing Council) é "
define transaction processing and database benchmarks and
to disseminate objective, verifiable TPC performance data to the
industry". Numa tradução livre seria "definir
benchmarks de bases de dados e processamento transacional e disseminar dados de
permormance objetivos e verificáveis para o mercado". O TPC definiu várias especificações para os
benchmarks. As especificações têm designações como:
- TPC-C
Benchmark de OLTP
- TPC-D
Benchmark de Datawarehouse (descontinuado)
- TPC-H
Benchmark de Datawarehouse (actual)
- TPC-DS
Benchmark de suporte à decisão (novo)
- TPC-E
Benchmark de OLTP criado para substituir o TPC-C
As especificações de um
benchmark são detalhadas e incluem tudo o que define os testes. Isto incluí o modelo de dados, as
queries
que devem ser executadas, as várias regras que limitam o que pode e não
pode ser usado em termos de funcionalidades e também o que tem de ser
usado (como integridade referencial,
check constraints etc.)
Os relatórios de
benchmark incluem as medidas efetuadas, que são tipicamente especificadas em
número de transacções por unidade de tempo (as transações são elas
próprias definidas na especificação). Incluem também o custo total dos
sistemas, contendo o custo do
hardware e
software, nomeadamente custo de aquisição e suporte por um período bem definido (3 anos por exemplo)
Estas especificações evoluíram ao longo do tempo por diversas razões:
- Novas funcionalidades de hardware e software tornaram as especificações antigas inúteis (como as views materializadas que mataram o TPC-D)
- Novas utilizações do software
fazem com que as especificações antigas pareçam ultrapassadas, levando a
novas especificações que pretendem refletir melhor a realidade
Pessoalmente
não tenho razões para assumir que o TPC não tenha sido criado com boas
intenções. Mas pelas razões que irei expôr ao longo deste artigo,
não dou crédito aos
benchmarks.
Estes apenas medem a vontade de um fornecedor em vencer, e quão bem consegue distorcer as regras do benchmark com o objectivo de obter algo que valha a pena publicar.
Note-se que apesar de ter algum entendimento comercial do mercado, sou
basicamente um técnico. Se tiver uma conversa com a gestão de topo de
uma grande empresa, tenderão a não entender qualquer argumento técnico, e
poderão por causa disso dar algum crédito aos
benchmarks publicados em tpc.org. Mas se estiver a falar com alguma pessoa minimamente técnica, acredito que é fácil "desmontar" um
benchmark em cerca de 10m (tentarei fazê-lo como forma de exercício para o resultado TPC-C de topo)
Apesar disto, correr um
benchmark publicável representa um enorme esforço técnico e económico, e nesse sentido tenho de dar crédito ás empresas que o fazem.
O mistério do TPC-E...
A especificação de
benchmark
TCP-E
foi introduzida porque o TPC-C tinha uma série de falhas que o tornavam
irrealista. É fácil encontrar opiniões que afirma que é um melhor
benchmark que o anterior.
Mas
se procurarmos os resultados vemos que apenas um vendedor de base de
dados, a Microsoft, publicou resultados com esta especificação. O
mistério é porquê?. Naturalmente os apoiantes da MS dizem que é porque
ninguém os consegue bater. Mais ninguém acredita nisto. A maioria das
pessoas que dedicaram algum tempo ao estudo destes
benchmarks
afirmam que se tornam numa "corrida de rãs" e que realmente dependem do
investimento. E se ainda é feito (ou era) com o TPC-C, uma especificação
muito madura, deveria ser ainda mais fácil de fazer com um
benchmark relativamente novo (os truques são mais fáceis de descobrir e implementar enquanto os
benchmarks
são novos. Encontrei várias referências na Internet sobre o porquê de
ainda ninguém ter entrado no "jogo" do TPC-E, mas nenhuma absolutamente
conclusiva (na minha perspetiva). Posso deixar algumas referências para
a sua própria pesquisa:
Pode decidir por si mesmo. Pessoalmente penso que o assunto está mais relacionado com o que o Sr. Jerry Keesee (director de desenvolvimento de IBM Informix) explicou num
webcast público (
Chat
with the labs) em 29 de Janeiro de2009. Mais sobre isto adiante
Mas atualmente, para OLTP o
benchmark mais popular é o TPC-C. Aparentemente o TPC-E está a ser publicado por vendedores de
hardware (incluindo a IBM).
Benchmarks e Informix
A Informix era um líder regular dos
benchmarks nos anos noventa. Costumava colaborar com parceiros de
hardware para alcançar vários resultados de topo em diversas categorias.
O tema dos
benchmarks é muito sensível dentro da comunidade internacional de Informix. Muitas pessoas acreditam fortemente que a IBM devia executar
benchmarks
oficiais com o Informix. A IBM nunca o fez desde que adquiriu a
Informix Software Inc. em 2001. Podemos ou não entender essa postura,
mas as razões foram claramente explicadas pelo Sr. Jerry Keesee, numa
resposta muito clara à questão "Como é que a IBM não participa em
benchmarks públicos de Informix? Como os
benchmarks
TPC.org?". A questão foi colocada por um participante muito conhecido
(e particularmente critico da IBM) dos fóruns de Informix, no final de
um
webcast em 29 de Janeiro de 2009. As razões apresentadas foram:
- A IBM tem feito benchmarks
TPC-C com o DB2 desde há longo tempo. Se fôr feito um com Informix
apenas duas coisas podem acontecer, e são ambas más para a IBM:
- O Informix obtém números melhores e a concorrência e os analistas cairiam em cima da IBM (e do DB2)
- O Informix obtém números piores e a concorrência e os analistas cairiam em cima da IBM (e do Informix)
- Poder-se-ia
considerar o TPC-E, mas atualmente apenas existem resultados
publicados de um vendedor de bases de dados (MS). Após a hipotética
publicação de resultados com Informix (que seria necessariamente melhor
sob alguma perspetiva, dado que ninguém publica números piores) dava-se
inicio a uma corrida muito cara, dado que o vendedor ultrapassado
tentaria responder e a "corrida de rãs" começaria. E o Jerry prefere
investir em novas funcionalidades e melhorias do produto que trazem
benefícios diretos aos clientes
Não se pode pedir algo mais claro que isto. Entretanto um
benchmark sobre MDM (Meter Data Management)
foi executado e publicado, tendo o Informix obtido um excelente resultado. Mas não é considerado um
benchmark standard. Portanto não satisfaz quem realmente anseia por um resultado TPC.
Muito recentemente pode ter notado qeu as palavras "TPC-C" e "Informix" andavam a ecoar pelas redes sociais e em alguns
websites
relacionados com Informix. Isto deveu-se ao Eric Vercelletto ter
decidido pegar no modelo de dados TPC-C e nas especificações e ter
executado um
teste de stress de base de dados não oficial.
Enquanto algumas pessoas davam saltos de contentamento outros
criticavam-no. A minha posição é bastante mais neutral, e penso que a
maioria das pessoas que falam sobre o assunto nunca tiraram um tempo
para fazer uma análise profunda de um resultado de um
benchmark TPC-C. As opiniões tendiam a dividir-se entre algo como "Sim!!! Finalmente o Informix tem um
benchmark TPC-C. Agora podemos mostrar a
performance
que o Informix pode atingir" e no extremo oposto "Ehc... O resultado é
muito baixo. Ele usou a versão grátis. É inútil". Haja paciência. Se
alguém quer falar sobre isto, então passemos algum tempo a ver alguns
factos:
- O benchmark executado pelo Eric não é um verdadeiro benchmark
TPC-C. Não é oficial, não é auditado e sim, o número é baixo se o
compararmos com os resultados oficiais publicados (o que por sinal não
se pode fazer devido a questões legais e técnicas)
- Sim, o Eric usou a edição Innovator-C, que é uma versão limitada
e grátis. Tem limites e falta de funcionalidades que poderiam ajudar
(apenas 2GB de RAM, não tem particionamento etc.)
- O Eric lutou
contra problemas técnicos com os clientes que enviam as transações. Na
verdade ele colocou os clientes e a base de dados no mesmo sistema. Algo
que nunca se vê num benchmark oficial
- O Eric usou 4 discos rígidos. Podem encontrar-se benchmarks publicados no TPC.org, com o mesmo número de cores
no servidor de base de dados usado pelo Eric, que usaram 200 discos
rígidos. Sim, leu corretamente, duzentos discos rígidos (mas para os
resultados de topo este número é em milhares)
- O mesmo benchmark que referi acima usou 10 cores para os clientes e 4 cores para o servidor de base de dados. Compare-se isto com os problemas sentidos pelo Eric com os programas cliente
- O Eric usou 16GB de memória para colocar a base de dados e os clientes. O benchmark referido usou 72GB apenas para a base de dados
- O Eric menciona que o custo do sistema é menos de 900€. O sistema onde correu o benchmark referido custava mais de $200000
- O
Eric mencionou que tentou uma configuração cliente/servidor, mas não
conseguiu atingir mais que 15-20% de utilização de CPU no servidor de
base de dados. Isto evidencia grandes problemas na forma como o benchmark
estava a ser feito (ou falta de poder de CPU nos clientes ou outros
constrangimentos no lado da base de dados como disco ou memória). Em
qualquer caso estes números nunca seriam publicados se fosse um
verdadeiro benchmark até que os problemas fossem identificados e resolvidos (situação em que os números subiriam dramaticamente)
Dado tudo isto, se está a assumir que não aprecio o trabalho do Eric,
está enganado. O Eric foi um colega na Informix Portugal por volta de
1999, altura em que passei de "um tipo do 4GL" para "um tipo do motor" e
ele ajudou-me nisso. Sei que é tecnicamente muito bom e aprecio o
esforço e voluntarismo ao pegar neste tema. O que estou a fazer é apenas
tentar mostrar que os verdadeiros
benchmarks TCP-C pertencem a uma categoria completamente diferente. Usam quantidades irreais de
hardware incluindo CPUs, memória, disco,
cache,
solid state disks
e também uma capacidade humana incrível. Todo e qualquer detalhe é
cuidadosamente analisado e estudado até ao limite. Isto por vezes trás
melhorias reais aos produtos, mas outras apenas cria "esquemas" para
"enganar" as regras dos
benchmarks. Mais sobre isto adiante.
O que o Eric fez é completamente diferente e nunca vi isso ser feito antes: Pegar em
hardware banal, semelhante ao que qualquer pequeno cliente pode usar, empregar um mínimo de esforço humano e executar um teste de
stress.
É útil? Sim, mas principalmente para quem o faz, e eventualmente porque
leva outros a fazer algo semelhante ou apenas falar sobre isso. É
comparável com os
benchmarks que normalmente vemos referenciados em notas de imprensa,
blogs, e outros artigos na Internet? Não! Nem podemos começar a comparar.
Uma outra situação onde vi alguém fazer algo semelhante são os concursos
fastest Informix DBA promovidos pela Advanced Datatools que decorrem normalmente durante as conferências do IIUG.
E é interessante verificar que o Lester Knutsen vai mostrar isto brevemente na Mac Tech. Veja por si mesmo:
http://www.youtube.com/watch?v=ScDyRrsI3H4&feature=share
Revisão rápida do resultado TPC-C de topo
Mencionei antes que iria rever o resultado TPC-C de topo conforme publicação actual em TPC.org.
Este
benchmark
foi efetuado pela Oracle com a versão 11gR2 com RAC e particionamento.
Alcançou um resultado muito respeitável de 30M tpmC (trinta milhões de
transações por minuto - tipo C - ). As observações abaixo foram
baseadas no
relatório completo sobre o benchmark Vejamos os factos:
- [Página
6] O sistema custa grosso modo $30M (sim, trinta milhões de dólares).
Note-se que o preço não é o de tabela. Incluí um desconto de $30M (50%)
- [Página
4] Usou 27 servidores (nós de RAC) para a base de dados, cada um com 4
processadores SPARC. Isto traduz-se num total de 1728 cores (16 cores por processador)
- [Página
4] Usou uma unidade central de armazenamento com mais de 11000 24GB
SSDs (Solid State Disks) e 720 discos de 2TB 7.2RPM SAS
- [Página
4] Cada um dos 27 nós de base de dados tinha 512GB de RAM, para um
total de 13.5TB de RAM para o conjunto dos servidores de bases de dados
- [Apendéce
B] A maioria das tabelas e índices foi particionada em pelo menos 27
partições. Sim... 27, o mesmo número de nós. A razão é explicada adiante
- [Apendíce B] Foram criados 27 UNDO tablespaces... sim, novamente 27
- [Página 30/Especificação TPC-C] A cláusula 2.4.1.5 da especificação actual do TPC-C
define que qualquer transacção "New Order" (uma das cinco transações) se deverá referir a um "home warehouse"
em 99% das vezes que é executada. Assim, se configurar os clientes
corretamente, divide-os pelos 27 nós de RAC. E 99% das transações "New
Order" irão usar um "home warehouse", ou seja dados contidos em
apenas uma das 27 partições das tabelas.. Mais... a transação "New
Order" representa 45% de todas as transações de todo o teste. A
transação "Payment" representa cerca de 43%. E para esta, 85% usam um "home warehouse".
- Qual
é o problema com o RAC? O cache fusion... ou por outras palavras o
componente do sistema que garante a consistência da informação entre os
nós... é um ponto de contenção reconhecido, e habitualmente a Oracle diz
que não é necessário mudar a aplicação, mas o facto é que se não o
fizermos não escala. E o TPC-C permite que o sistema seja configurado de
uma forma que os vários nós atuam quase (99% em 45% das transações e
85% noutros 43%) como se fossem nós isolados. E logo escala muito
melhor... Aposto que consegue imaginar o que a Oracle teria de fazer
para obter um número maior... Adicionar nós e partições... (mudar a aplicação e manter a afinidade)
- [Especificação TPC-C] Das restantes três transações ("Stock level",
"Order Status" e "Delivery") apenas uma ("Delivery") incluí alteração de dados. As outras duas são apenas de leitura
- Dos
últimos 3 pontos pode entender-se o quão irrealista isto é e quais os
truques para tirar proveito disso. Mas mesmo assim ainda resta um ponto
muito forte relativamente a este benchmark: "Ok, compreendo que tenham despejado toneladas de hardware e usado todos os truques permitidos para empurrar os números da performance... Mas e sobre o custo? O custo por transação apresentado é menor que muitos benchmarks anteriores!". Verdade. Mas mais uma vez temos de ler tudo com muita atenção. Se folhear alguns destes benchmarks
verificará que uma parte significativa dos custos é para o
licenciamento e manutenção (e isto reflete a realidade). As
especificações requerem que os custos sejam calculados para um período
de três anos. E com certeza que todo este hardware deveria ter feito aumentar os custos de software,
certo?! Err... Sim, mas não! Vamos à explicação. Se a especificação
requer um custo a 3 anos, o que é que um fornecedor esperto fará? Basta
criar uma licença que em vez de perpétua é apenas por 3 anos. Como pode
ver na lista de preços da Oracle,
uma licença de processador da edição Enterprise custaria $47500. No relatório do benchmark
[Página 5] notará que o valor é $23750. Volte agora à lista de preços e
repare nas letras pequenas na página 9. Informa que para uma licença
com termo de 3 anos, o custo será 50% da licença perpétua. Assim isto
corta o custo da base de dados em 50% (não incluindo o desconto global
de 50%). Numa situação real isto significaria um desconto de 75% no software, mas claro que ao fim de 3 anos teria de desinstalar o produto ou simplesmente adquirir novamente as licenças
- Finalmente, o suporte. O benchmark
menciona [Página 5] $62100 para o pacote Oracle Incident Server
Support, por ano. Isto é exatamente 27 * $2300, o que de acordo com a
lista de preços [Página 13] o habilita apenas a suporte via web. Não consigo encontrar em lado nenhum no benchmark algo que o habilitasse a efetuar upgrades de software
como é normal quando se paga S&S (serviço e suporte). Novamente
segundo as letras pequenas no rodapé da lista de preços isto
representaria mais 22% (por ano) da licença perpétua
Portanto,
tenho a certeza que o exposto acima não demorará mais que 10m a
explicar a um cliente. E na minha perspetiva mostra que os
benchmarks são distorcidos (de forma completamente legal e dentro das regras claro) para aumentar os números de
performance
e reduzir os de custo. Mas nem o cenário técnico nem o de orçamento
refletem um cenário real. É por isso que, na minha opinião, estes
benchmarks
são inúteis. Finalmente, se me perguntarem, realmente prefiro ver o
dinheiro (e é muito) investido em I&D do produto ou em outras atividades de
marketing.
Após tudo isto, penso
sinceramente que o Eric fez um exercício interessante que poderá
ajudar-nos a treinar as nossas capacidades de
performance tunning. E acredito (sem informação privilegiada aqui) que os vendedores de bases de dados podem usar os modelos de dados e
queries para testarem regularmente o seu
software. Poderá ajudá-los a detetarem alterações positivas ou negativas na
performance à medida que introduzem novas funcionalidades e otimizações.
Quanto aos
benchmarks publicados? Existem apenas com o propósito de se conseguir cabeçalhos e notas de imprensa
Posts
