Exemplo em PHP

O memcached pode ser acessado de muitas linguagens de alto nível, como C/C++, Java, Python, PHP, e até .NET. Abaixo, um exemplo em PHP.
Antes do memcache, uma página poderia ter uma consulta do seguinte tipo:

<?php
// A query SQL está abreviada, apenas como exemplo
// Digamos que essa consulte demore cerca de 1 segundo
// para ser completada
$sql = "SELECT * FROM tabela INNER JOIN ......";
$res = pg_query($sql);
$arr = pg_fetch_all($res); // array com todos os resultados
?>

Com esse código, a cada acesso na página, teremos uma consulta de 1 segundo feita ao banco de dados. Muitas vezes, a consulta será exatamente a mesma. Modificando a consulta para uso do memcached, teríamos algo assim:

<?php
// Conecta ao memcached
$mc = new Memcache;
$mc->addServer('ip.do.servidor');
 
$sql = "SELECT * FROM tabela INNER JOIN ......";
$cache = $mc->get(md5($sql)); // Usamos o md5() da query como chave
 
if ($cache === false) {
    // Resultado não está no cache
    $res = pg_query($sql);
    $arr = pg_fetch_all($res);
    $mc->set(md5($sql), $arr);
}
else {
    $arr = $cache;
}
?>

Pelo exemplo acima, temos algumas modificações. Primeiramente conectamos ao memcached. A chamada a addServer() pode ser feita múltiplas vezes, caso existam vários memcached rodando em máquinas separadas. Pode ser dado um “peso” pra cada servidor também, de acordo com a memória disponível em cada um.
Logo em seguida, é feita a verificação no memcached se o resultado da consulta já está lá. Como chave, usei o hash md5 da consulta, pra gerar uma identificação única. O método get() pode retornar false, caso a chave não esteja no memcached, ou retornar o objeto que foi guardado.
A checagem é simples. Se o get() retornou false, então o sistema faz a consulta como já fazia antes, e no fim guarda o resultado no memcached, pra agilizar as próximas consultas. E caso não tenha retornado false, temos já o resultado da consulta diretamente. Ao fim do bloco if, teremos, de uma forma ou de outra, o resultado da consulta em $arr.
A diferença é que rodando a consulta no banco, o tempo será de cerca de 1 segundo (tempo que estimamos para a execução da consulta), e pegando o resultado direto do memcached, a consulta demorará algo da ordem de milissegundos para ser completada.

Problemas

Um dos problemas clássicos em qualquer abordagem que use cache é como saber se as informações em cache ainda estão atuais. Com o memcached, isso não é diferente. Existem algumas formas de se lidar com o problema.
A primeira delas, mais simples, e que pode ser usada livremente caso não seja de suma importância que os dados estejam atuais, é mexer no tempo em que a informação ficará no cache. O tempo pode ser especificado na chamada ao método set(), da seguinte forma:

<?php
$mc->set(md5($sql), $arr, MEMCACHE_COMPRESSED, 60);
?>

Temos neste exemplo todos os parâmetros para a chamada de set(): a chave, o objeto a ser guardado, uma flag (pode ser usado MEMCACHE_COMPRESSED, que indica que o objeto será comprimido para ocupar menos espaço, ou 0 pra indicar que deve ser guardado sem compressão), e por último o tempo de vida do objeto, no caso, 60 segundos.
Ou seja, caso não haja problema das informações permanecerem desatualizadas por 60 segundos no máximo, essa abordagem pode ser usada.
Caso a informação tenha que estar sempre atualizada, a forma de tratamento terá que ser outra. O memcached possui método para apagar o objeto associado a uma chave. Tendo a chave, basta usar:

<?php
$mc->delete('chave');
?>

e a entrada que existia no memcached para aquela chave será invalidada.
A idéia, nesse segundo caso, é justamente localizar no código todos os pontos que modificam o banco de dados de forma que possa alterar o resultado da consulta feita, e adicionar código para invalidar o cache nesses pontos. Assim, quando for feita a consulta no memcached, caso alguma informação tenha sido modificada, a entrada correspondente no memcached já terá sido apagada, e a chamada a get() retornará false naturalmente.
É claro que essa segunda abordagem dá muito mais trabalho, por isso a sugestão de se usar a primeira delas nos casos em que pode ser usada. Lembre-se que em um site com 100 acessos por segundo, um tempo de vida de 60 segundos evitará 5999 consultas ao banco (a primeira será feita e guardada).

Mais informações

O site do projeto tem um Wiki que responde a maior parte das dúvidas que se pode ter, em relação a instalação e ao uso.
No caso do PHP, as funções são bem documentadas na parte do manual sobre memcache.
Eu uso em produção o memcached, com 2 servidores, um com 768mb de memória disponíveis para o memcached e outro com 256mb. Dei pesos 3 e 1 respectivamente, para que um objeto tenha 3 vezes mais chance de cair no primeiro servidor. A configuração está bastante satisfatória, e o banco de dados agradece.

Artigos relacionados

• Evitando SQL injection em PHP
• Otimização: imagens inline
• Otimização de sites, parte 3 – Cache
• Otimização de sites, parte 2 – Compressão
• Otimização em PHP, parte 1: Minify
• Problemas com acentuação?
• O limite de 4 (ou 3?) Gb de memória

Antes de mostrar os problemas que são normalmente encontrados, um pouco de história pra descobrirmos porque existem várias codificações, e que elas não estão aí só pra atrapalhar a nossa vida.

A muito, muito tempo atrás…

Todos sabemos que os computadores manipulam bits, e que para facilitar a nossa vida, os agrupam em bytes, que são conjuntos de 8 bits. Como cada bit pode valer 0 ou 1, temos, para um byte, 256 combinações diferentes. Logo, 1 byte tem a capacidade de armazenar um número de 0 a 255.

Como os computadores no passado operavam na língua inglesa, foi adotado o padrão ASCII (lê-se ásqui). Este padrão de codificação define 128 caracteres, sendo alguns de controle e outros tantos para codificar letras, números e alguns sinais.

Como só são necessários 128 valores para representar toda a gama de caracteres pela codificação ASCII, ficamos com a metade da capacidade de armazenamento do nosso byte sem uso. Chamamos este formato de codificação também de 7-bit, pois precisamos de apenas 7 bits para codificar 128 valores.

Entram em cena as extensões

Conforme foi sendo necessário se colocar caracteres e símbolos extras, como por exemplo, letras gregas e caracteres internacionais (cê-cedilha, a-com-til, etc), resolveu-se o problema da forma mais simples possível.

Como temos a metade do byte inutilizada, porque não usar estes 128 valores que estão “sobrando” para armazenar outros caracteres? Pois foi exatamente isto que foi feito. Definiram símbolos que seriam adicionados neste espaço, e nasceram as “tabelas ascii estendidas”, ou seja, são completamente compatíveis com o padrão ASCII (pois os primeiros 128 valores não mudam).

O grande problema desta solução está no fato de que no mundo inteiro, existem muito mais que 128 caracteres e símbolos. Daí, cada região passou a trabalhar com sua própria tabela ASCII estendida. No ocidente, se usa a codificação ISO8859-1, que possui caracteres latinos, letras gregas. É usado em boa parte do mundo (Americas, Oceania, Europa ocidental e boa parte da Africa).

Outras regiões usam outras codificações, como por exemplo o KOI8-R, usado na Rússia. Esta codificação possui todo o alfabeto cirílico, utilizado naquela região.

Uma tremenda confusão

Com dezenas de codificações, muitos problemas passaram a ocorrer. Se tentar ler um documento codificado em ISO8859-1 usando outra tabela ASCII estendida que não seja a ISO8859-1, qualquer caractere que esteja na área estendida da tabela (acima dos 128 primeiros caracteres) irá aparecer trocado por outro. E como o computador não tem como saber qual é a codificação correta de um documento sem analisá-lo semanticamente (temos apenas uma grande seqüência de valores de 0 a 255), temos um grande problema formado.

Outro problema sério é a impossibilidade de se exibir um documento com caracteres de várias línguas diferentes, sem implementar algum tipo de gambiarra.

Unicode: seus problemas acabaram!

No meio disso tudo, nasce o Unicode, para resolver de vez todos os problemas relacionados a codificação de caracteres. A idéia é simples: ao invés de usar apenas 1 byte pra armazenar todos os caracteres, símbolos, figuras, etc (o que é logicamente impossível), porque não utilizar mais de 1 byte?

A codificação UTF-8 armazena caracteres em seqüências que variam de 1 a 4 bytes, mas mantendo a compatibilidade com o ASCII. Os primeiros 128 valores são idênticos.

Com o Unicode, surgem outros problemas que não irei discutir aqui, como por exemplo, um texto com 20 caracteres não irá ocupar necessariamente 20 bytes, e isto causa problemas de armazenamento em buffers, em disco, em estruturas de dados. Tudo deve estar preparado para receber possivelmente mais que os 20 bytes.

O fato é: Unicode é uma codificação universal, que comporta qualquer caractere existente até o momento (pelo menos até explorarmos o espaço e nos depararmos com algumas raças alienígenas).

De volta ao presente

Todos os problemas relacionados a acentuação hoje em dia decorrem de um erro simples: mistura de codificações. Simples assim.

Se é desejado um sistema completamente em UTF-8, então, todos os seus componentes devem estar operando em UTF-8. No caso de páginas web, os arquivos gerados devem estar em UTF-8, os bancos de dados devem estar preferencialmente em UTF-8, a conexão com os bancos de dados devem estar em UTF-8, e o servidor web deve informar ao navegador de que a página que ele está exibindo é UTF-8. Vou continuar usando o UTF-8 como exemplo, mas tudo isto vale para qualquer outra codificação. É só trocar onde estiver UTF-8 pela codificação que desejar.

As páginas

Os arquivos com o código HTML, ou o que quer que esteja sendo gerado, precisa estar codificado em UTF-8. Se ele não estiver, aparecerão caracteres esquisitos na tela, pois o navegador vai tentar ler a página como UTF-8, e o que vai estar lá não vai ser UTF-8. Acentos e símbolos extras vão ficar truncados.

Gambiarras surgem aqui. Ao invés de se resolver este problema da forma correta (mudando-se a codificação das páginas), muita gente prefere “dar um jeito”. Daí, temos no código chamadas para conversão de codificações, temos tradução de acentos em entidades html (ao invés de se colocar um “Ç”, coloca-se “Ç”). Claro que existem usos válidos para isto, mas o que mais vejo por aí é o uso disso para se contornar o problema e evitar a solução correta.

Banco de dados

Os bancos de dados deveriam preferencialmente estar em UTF-8, mas outras codificações também são possíveis. Isto acontece porque uma conexão feita com o banco pode operar em uma codificação, independente da forma como o banco guarda os dados internamente.

Explico: mesmo o banco de dados guardando tudo como ASCII internamente, se a conexão com o banco é feita em UTF-8, o banco “sabe” que precisa converter todos os dados antes de apresentá-los para a aplicação que os solicitou. O importante, no caso, é que a conexão seja efetuada com a codificação correta.

Cabeçalhos HTTP: importantíssimos!

E por último, de nada adianta tudo estar operando em UTF-8, e o servidor web dizer ao navegador: “aí, a página que vou te mostrar agora tá em ISO8859-1, ok?”. Daí o navegador tenta ler a página como ISO8859-1, e o resultado são vários caracteres duplos onde deveríamos ver acentos.

A forma correta de se fazer isto, é fazer com que o servidor envie o cabeçalho Content-type de forma correta, informando o tipo MIME do dado que está sendo servido, assim como a codificação utilizada.

Por exemplo, para páginas HTML, o servidor poderia enviar o seguinte cabeçalho:

Content-type: text/html; charset=utf-8

Uma gambiarra que se usa muito neste ponto é colocar o seguinte código no HTML:

<meta http-equiv="Content-type" content="text/html; charset=utf-8" />

Esta forma, embora funcione em alguns casos, deve ser evitada, pois o navegador só irá considerá-la se o servidor web não informar a codificação e se o navegador não tiver alguma preferência marcada. Ou seja, depende de fatores externos, e nem sempre será honrada.

Conclusão

Eu, pessoalmente, uso UTF-8 para tudo. Acho que já passou da hora desta codificação ser adotada por todos. Não vejo motivo hoje em dia para se continuar usando o obsoleto ISO8859-1 (também conhecido como “Latin-1″) ou outras codificações, visto que o UTF-8 engloba todas elas.

Tudo isto é independente da linguagem utilizada. No caso, citei a web porque é um campo onde tenho muita familiaridade, mas se aplica em qualquer situação.

E se a experiência contar, depois do dia que passei a usar UTF-8 para tudo, nunca mais tive problemas com acentuação. Só me restam as lembranças deste passado sombrio.

Artigos relacionados

• Otimização de sites com memcached