Produção

Tive a oportunidade de participar, juntamente com o Etevaldo, da OSCON neste ano.

Minha idéia agora é organizar as anatoções, fazer posts específicos sobre dois temas e, em seguida, havendo interesse nos posts, organizar alguma apresentação com o pessoal para discutirmos o assunto.

O primeiro tema será sobre “cloud computing”, referenciando duas palestras que assisti, uma da rightscale e outra do nytimes. Ambas mto boas.

O segundo tema será sobre XMPP e como este protoloco está sendo utilizado em aplicações que necessitam de “streaming” de mensagens. Referenciarei as palestras do Flickr e da Jive que assisti.

Outros tutorias e palestras que mereceram destaque na minha opinião:

- Palestra sobre MySQL e memcache, que apesar de nada de muito novo, indicou que a criação de UDF´s do MySQL pode facilitar o uso do memcache. Esta é a forma como o Facebook faz e talvez valesse a pena entender melhor as vantagens.

- Palestra sobre o Dtrace, uma ferramenta muito interessante para debug de aplicação, mas que até o momnento não funciona em Linux, apenas Solaris. A previsão nada oficial é final deste ano.

- Palestra sobre a nova engine do MySQL, Maria, e seu relacionamento com o MyISAM.

- Palestra sobre o Puppet e seu funcionamento para gerencia de configuração

Minha idéia é fazer um só post sobre estas palestras, mas sem aprofundar muito.

Para pegar as apresentações é só acessar a página do evento. Contudo, nem todos os palestrantes colocaram as apresentações no site ainda, mas a do Flickr já está lá “Beyond REST? Building Data Services with XMPP PubSub”

Achei tbm dois posts do cara do Nytimes no seu blog que na verdade correspondem ao que apresentou:
http://open.blogs.nytimes.com/2007/11/01/self-service-prorated-super-computing-fun/
http://open.blogs.nytimes.com/2008/05/21/the-new-york-times-archives-amazon-web-services-timesmachine/
Volto ainda esta semana (espero) com posts mais interessantes.

Em junho deste ano, ocorreu o 4.o RedHat Summit 2008. A redhat disponibilizou gratuitamente algumas palestras. São bem interessantes, e uma que me chamou muita atenção foi a palestra do CTO & VT Brian Stevens - RedHat Engineering, sobre os projetos opensources em destaque na redhat, como o gerenciador bastante amigável de nuvens computacionais(cloud computing) oVirt em cima do KVM, presente a algum tempo no kernel, a opção de rodar o fedora 9 inteiramente pelo pendrive - incluindo os arquivos criados pelo usuário - possibilitando literalmente mover seu desktop entre hosts, a integração entre MRG Grid (RHEL) e o projeto OpenSource Condor para alto throughput computacional - com o objetivo de fazer exatamente o que a Amazon faz atualmente com o EC2.

Está é apenas uma das palestras disponibilizadas. Seguem o link:

RedHat Summit: http://www.redhat.com/promo/summit/2008/

Sem dúvida nenhuma o melhor Keynote no MySQL Conf, foi o keynote com os representantes de alguns big players da internet, que responderam a várias perguntas relacionadas aos seus ambientes com que diz respeito ao MySQL, entre eles Facebook e Youtube. Só não publiquei antes esse material, pois tive que garimpar essa info por ai até achar o blog do cara que estava digitando em real time todo o debate.

Segue abaixo o resumo dos números, que por sinal são MUITO interessantes:

Moderador do painel: Kaj Arno
Lista dos participantes ordenada pelo Alexa ranking:
1317. Monty Taylor (MySQL)
905. Matt Ingerenthron (Sun)
39. John Allspaw (Flickr)
13. Farhan Mashraqi (Fotolog)
9. Domas Mituzas (Wkipedia)
6. Jeff Rotheschild (Facebook)
2. Paul Tuckfield (YouTube)
p.s.: 3 entre os top 10 do Alexa.

Tabelão com as perguntas e respostas dos participantes:

Mais algumas perguntas extras interessantes:

Number of times re-architected ?

• MySQL: 2 - 1 time slave, 1 time memcached
• Sun: site depend (many times over the year)
• Flickr: Ummm…2.5 (various clusters federated)
• Fotolog: many cached replacements (about to do one change now)
• Wiped: Never (Spaghetti)
• Facebook: Every Tuesday, continual
• Youtube: Pretty continual, 2-3 times (replication, sharding, federation)

What happens if server fails ? what actions you will generally take ..

• Flickr: All of our 7 are federated, pairs of servers, we can loose any one side of shard, we can loose boxes.. traffic goes to either side of shard, now it goes to one, and we will get another one (very transparent to user) .. for offline, sites are affected
• Wikipedia: Users shout at them on IRC then they moderate fixed in seconds
• Facebook: one of 1800-1900 will always fail, just operate well, minor impact, with data going away for a while…we restore from binlog and start the server quickly, promote slave to master and number of ways
• Fotolog: we simply mount the snapshots to different servers and get
• Youtube: SAN etc, very important data.. recover the server, mirrored disk …mirrored hard drive is crucial

Any recommendation of scaling technology that you wanted to bring

• Fotolog: UltraSPARC-T1 (excellent master, multi threaded) and UltraSPARC-T2 for slave (single threaded)
• Wikipedia: good n/w switch
• Facebook: cheap switch, we dont use SAN, neatly partitioned, they scale independently and fail independently
• MySQL: cluster very sad

Server virtualization ?

• nobody uses at this time
• ETL cluster, we may run more than one in the future (facebook)

Anything to worry at present ?

• Facebook: app design is the key to use resources, data center power supply and consumption
• Fotolog: Google has to approve it for our power (cut app servers by 1/2 by moving from php to java)
• Youtube: not at all

Any reco, lessons to DBA

• better you know what the systems are, then you can
• performance, scaling taking it serious
• nothing more permanent than temp solutions (if u don’t know when u will fail, then u will )
• architect properly in start, schema, cost of serving data
• 10 mts biggest architectural change
• memory, resource

Essa foi a integra completa do painel, as respostas estão escritas como foram faladas pelos participantes.

Posso dizer que esse foi um belo resumo prático do que pudemos ver na conferência. Isso também nos dá uma visão muito mais real do uso do MySQL em outras empresas ao redor do mundo.

that’s all folks.

Finalmente achei alguem q usa MYSQL CLUSTER na vida real! E adivinhem, são brasileiros !! (êta povo pra inventar moda!! rs)
Digo isso porque todos as grandes empresas que usam Mysql, NÃO usam cluster: facebook, wikipedia, flickr, Fotolog, Ytube e … MYSQL

A Paggo inovou no mercado de crédito, com uma solução via celular que substitiui o cartão de crédito. A gol ja está usando esse sistema de pagamento, onde no lugar do número do cartão, você coloca o número do telefone.
Números atuais da Paggo: 1.000.000 de clientes, 25.000.000 de reais/mês, 1000 transações/hora … e crescendo… 24×7

Principais motivações da Paggo na escolha da arquitetura: Agile, low cost, rapid growth

Eles possuem 2 datacenters em SP, replicando de um para outro via master-master, usando solução de cluster em cada datacenter. Maior base : 30gb

Feedback: encontraram muuuitos bugs usando cluster! Pediram consultoria da Mysql, hoje a situação é estável mas eles usam a versão 6.x (que é alpha!!!)
Além disso o cluster tem limitações: não tem fks, não trabalha bem com transações grandes , subqueries e joins nem pensar .

Para que tudo funcione bem é imprescindível deixar no cluster só a informação principal por isso os dados historicos ficam fora do cluster - eles possum um slave somente para relatórios, usando MyIsam.

É isso aí, No Pain No Gain !

abs ,
Camila

Vou aproveitar a vinda ao Mysql Conference 2008 para fazer a minha estréia no Blog!

Hoje assisti uma Palestra interessante do Domas Mituzas sobre db design para performance de web applications.

Ele começou dizendo que o mundo web é um mundo diferente do transacional. Nao estamos falando de OLTP e sim OLWP (online web processing).
A web demanda muito mais do ambiente : need data now !! Em relacao ao acesso de dados: menos escrita (em geral inserts) e muitas leituras ( ordered data, range scan, pages)

Aqui vão algumas dicas de como obter melhor performance no Mysql para web applications:

ordering:
- file sorts sao ruins !! procure evitar usando as dicas abaixo …

indexing:
- crie índices para cada query
- use índices compostos
- crie índices para varchar(255) se este for usado no sort

innodb:
- criar indices compostos melhora o tempo de leitura
(para evitar file sorts (neste caso com order by), colocar a coluna do sort no índice pode ajudar
sim, isso aumenta tempo de escrita mas como na web o tempo de leitura é importante, pode valer a pena o sacrifício

query cache:
- não funciona pra grandes aplicações com muitas alteraçoes
- funciona para queries uniformes que não mudam muito

Counts:
-cuidado com counts , é melhor manter o dado calculado

Blobs:
- manter fora da logica da query de pesquisa, apenas fazer o display
- ou seja, leia os blobs em uma segunda query

Paginação:
- bom uso: WHERE id>xxx LIMIT

Character set:
- se possível usar latin 1 (ou outro 8bit charset)
- cuidado com utf8, filesorts ficam mais caros!

Persistent conections:
- “persistent = bad” !!!! (PASMEM, isso tava no slide dele !! vc deve estar se perguntando o que fazer com os pools de conexão, pois é, eu também! - vale a pena testar em nosso ambiente)
“connect is cheap , connection is not” (diferente do Oracle, onde o custo de abrir uma conexão é alto)
o respaldo para o comentário é que as aplicações não usam todas as conexoes e isso gera desperdício de recursos. E como abrir conexões em tese é barato … não precisaria de pool

Bem, essas foram as principais recomendações.

Vale a pena dar uma passada no site do Domas Mituzas: http://dammit.lt/

No primeiro do MySQL Conf assisti duas palestras muito interessantes, uma falando sobre o DRDB e outra do Ask Bjørn Hansen falando sobre performance e escalabilidade em sistemas web.

A palestra sobre o DRDB(Distributed Replicated Block Device) foi interessante pois rolou um hands-on do palestrante ao-vivo e tudo funcionou perfeitamente(os caras enssaiaram bem). Brincadeiras a parte ficou bem claro que o DRDB tem um papel importante no mundo do MySQL e é uma solução altamente viável de alta disponibilidade(HA) para o MySQL. No link(http://www.mysql.com/products/enterprise/drbd.html) tem alguns documentos e outras informações mais detalhadas sobre o uso do DRDB com o MySQL e no site do DRBD você pode encontrar mais informações sobre o uso desse software para outros diferentes tipos de sistemas.

Na segunda parte do dia assisti a palestra do Bjørn Hansen(além de ser uma figura a parte o cara destrói como palestrante). Ele falou muita coisa ligada a escalabilidade e performance de aplicações web e por ser um evento de MySQL citou bastante coisa relacionada também. Estou montando uma apresentação pro techtalk para discutirmos mais detalhadamente o que foi falado de mais revelante, pois tem muita coisa que TEMOS que olhar mais a fundo e começar a seguir, pois está sob nosso alcance e vai ajudar todo mundo e com certeza vamos evoluir muito com isso.

Quero encerrar esse primeiro post do MySQL Conf com uma afirmação:

“O MySQL não vai fazer tudo por você se você não fizer algo por ele.” pensem a respeito…

e um bom dia a todos.