Produção

Otimizando seu Ubuntu Desktop…

http://www.howtoforge.com/the-perfect-desktop-ubuntu-8.04-lts-hardy-heron

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.

Seguem algumas dicas do Dathan Pattishall da Flickr… enjoy it  

–>spread data around: federate users por shards: eles fazem um hash pelo user id para o cluster id

–>innodb não funciona com pks grandes (baseadas em strings): eles tinham uma pk que era uma url (string) e a converteram para um 64-bit number(ID) usando a função conv(substr(md5(url),0,16),16,10)

–>innodb & strings: indexar uma string em innodb ocupa muito espaço, além disso a fragmentação nas páginas prejudica a performance. A solução foi “bufferizar” as escritas - eles usam um deamon java que faz o buffer de até 4000 mensagens (transações) e as aplica serialmente usando uma única thread

–>reduza o uso de grandes strings: coloque dados históricos ou não produção em MyIsam .  A vantagem é que o Myisam mantem os dados usando 1/6 do tamanho do innodb.

Dê uma olhada no Blog do Dathan Pattishall : http://mysqldba.blogspot.com/

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

Está sendo apresentando na MySQl Conference um hardware que promete acabar com os problemas das queries lentas. O que tem esse hardware de especial? Bom, ele tem um chip adicional chamado de “SQL Chip”, além de já vir com o CentOS 5.1 instalado.

O SQL Chip é um dispositivo que pode executar queries em paralelo e ao mesmo tempo acelerar o seu tempo de execução. E como isso é feito diretamente pelo SQL Chip, tira a carga da base e do servidor.

Existem 3 componentes básicos nessa solução de hardware e o que eles proveem respectivamente:

MySQL:

• Conectividade
• Segurança
• Administração

Kickfire Software:

• otimizador
• “column store” e cache
• “transactional engine”

SQL Chip:

• Execução do SQL
• Gerenciamento de memória
• Acelerador de carga

Mais informações no site do fabricante Kickfire.

Agora é esperar pra ver se o hardware vai fazer o que promete e ver o que o mercado irá dizer dele nos próximos meses.

that’s all folks.

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.

Conheça um pouco da rotina de quem trabalha na Google

No prédio de quem define o Capitalismo do século XXI, o almoço é de graça,os sofas estão a disposição para um descanso e até uma quadra de voley de praia para relaxar com os colegas…vejam o vídeo em….

http://www.truetech.com.br/webtvconsole/usuario/webtvconsole.php?

console=30&canal=19&video=652