Categorias
Desenvolvimento Web Tutoriais

Fulltext Search – Busca Textual com Postgres – Parte 2

Continuando de onde paramos na parte 1, vamos ver um pouco como configurar o mínimo para ter uma busca textual através do Postgres. Se você quer se aprofundar mais nas possibilidades, recomendo os seguintes recursos:

Antes de tudo: você tem uma instalação do Postgres funcionando né? Não? Veja se esse artigo ajuda, quando terminar retome daqui.

Precisamos entender que a busca textual parte de um processamento do texto, fazendo uma análise estrutural e semântica e convertendo nosso texto em um formato padronizado. Esse processamento é dependente do idioma e portanto, uma configuração feita para inglês é diferente de outra para português.

Felizmente o Postgres já vem com suporte básico a várias línguas, incluindo português, mas para uma busca mais flexível (pegando variações de plural/singular ou conjugações de verbo) precisamos incluir arquivos de dicionário.

Nesse gist eu disponibilizei os arquivos de dicionário para português do Brasil (pt-br). Eles foram extraídos do projeto Vero do LibreOffice e convertidos para utf-8. Sabendo da origem dos arquivos, vamos usá-los:

!/bin/bash

# Caminho das extensões do Postgresql, varia de ambiente para ambiente. As vezes, de versão para versão.
# Para descobrir programaticamente, precisa instalar o pacote `postgresql-dev` e então usar o `pg_config --sharedir`
# Lugares possíveis:
# Debian/Ubuntu: /usr/share/postgresql/VERSAO
# Alpine/docker: /usr/local/share/postgresql
PGSHARE=/usr/local/share/postgresql

mkdir -p $PGSHARE/tsearch_data

curl -sSL 'https://gist.github.com/CauanCabral/5ad952e0014c1cf21a87c3731397f078/raw/f525e8d21f6697c68303300713ddb28a4bccf384/pt_br.dict' -o $PGSHARE/tsearch_data/hunspell_pt_br.dict
curl -sSL'https://gist.github.com/CauanCabral/5ad952e0014c1cf21a87c3731397f078/raw/f525e8d21f6697c68303300713ddb28a4bccf384/pt_br.affix' -o $PGSHARE/tsearch_data/hunspell_pt_br.affix

Feito isso, você terá os arquivos de dicionário para pt-br onde o Postgres irá procurar.

O próximo passo é conectar ao banco de dados (pode ser via psql, via adminer ou pgAdmin, o que você preferir). Para evitar qualquer problema nesse primeiro teste, crie um banco de dados próprio para a gente e conecte a ele. Vou chamar aqui de busca_textual.

-- Habilitamos a extensão 'unaccent' para usar na normalização dos dados
CREATE EXTENSION IF NOT EXISTS unaccent SCHEMA public;

-- Criamos nosso dicionário, usando os arquivos que pegamos no gist
CREATE TEXT SEARCH DICTIONARY portuguese_hunspell (
    TEMPLATE = ispell,
    DictFile = hunspell_pt_br,
    AffFile = hunspell_pt_br,
    Stopwords = portuguese);

-- Criamos uma nova configuração tomando como ponto de partida 'portuguese'
CREATE TEXT SEARCH CONFIGURATION pt_br ( COPY = portuguese );

-- Alteramos nossa nova configuração, para usar o dicionário e unaccent
ALTER TEXT SEARCH CONFIGURATION pt_br
    ALTER MAPPING FOR
        asciiword, asciihword, hword_asciipart,
        word, hword, hword_part
WITH portuguese_hunspell, unaccent, portuguese_stem;

Com esses comandos nós criamos uma configuração chamada pt_br que instrui o Postgres a processar um texto fazendo:

  • Quebra do texto usando regras do português
  • Substituição da palavra pela sua forma não conjugada (por exemplo voto vira votar)
  • Remoção dos acentos da palavra

Fundamental destacar que a identificação de uma palavra (token é o termo mais apropriado) só acontece uma vez. Então se o token sendo processado existe no dicionário portuguese_hunspell, ele vai ser salvo e indexado da forma como esse dicionário trabalha ele (desconjugada a palavra). Se ela for acentuada, ela nem chegará a passar pelo filtro/dicionário de desacentuação.

Por exemplo: a palavra razões ao passar por esse dicionário é substituída por razão, por que ela existe no dicionário. Já a palavra inventada jasões passará despercebida nesse dicionário e cairá na regra de desacentuação e será substituída por jasoes.

Então a ordem dos dicionários/filtros na criação da configuração são determinantes para o resultado da sua busca. Se colocar a desacentuação antes do dicionário hunspell. nossos resultados anteriores seriam razoes e jasoes, respectivamente.

Tendo a configuração, agora podemos ver como ela funciona em frases.

Lembra do parágrafo mencionado na parte 1? Execute a query abaixo para ver como ele seria processado em nossa configuração:

SELECT * FROM ts_debug('pt_br', 'Algumas das principais razões da evasão escolar no Brasil atual são a pobreza, a dificuldade de acesso à escola, a necessidade de trabalho e, principalmente, o desinteresse pelos estudos. Segundo o Programa das Nações Unidas para o Desenvolvimento (PNUD), o país tem a terceira maior taxa de abandono escolar (24,3%) entre os 100 países com maior IDH (Índice de Desenvolvimento Humano), só atrás da Bósnia e Herzegovina (26,8%) e das ilhas de São Cristovão e Névis, no Caribe (26,5%). Na América Latina, só é superado pela Guatemala (35,2%) e pela Nicarágua (51,6%), não tendo sido divulgado o índice do Haiti.');

A saída deve ser tabular e conter algumas linhas como essas:

AliasDesc.TokenDicionáriosDicionárioLexema
wordWord, all lettersÍndice{portuguese_hunspell,unaccent,portuguese_stem}portuguese_hunspell{índice}
blankSpace symbols{}NULLNULL
asciiwordWord, all ASCIIde{portuguese_hunspell,unaccent,portuguese_stem}portuguese_hunspell{}
blankSpace symbols{}NULLNULL
asciiwordWord, all ASCIIDesenvolvimento{portuguese_hunspell,unaccent,portuguese_stem}portuguese_stem{desenvolv}
blankSpace symbols{}NULLNULL
asciiwordWord, all ASCIIHumano{portuguese_hunspell,unaccent,portuguese_stem}portuguese_hunspell{humano,humanar}
blankSpace symbols),{}NULLNULL
wordWord, all letters{portuguese_hunspell,unaccent,portuguese_stem}portuguese_hunspell{}
blankSpace symbols{}NULLNULL
wordWord, all lettersatrás{portuguese_hunspell,unaccent,portuguese_stem}unaccent{atras}
blankSpace symbols{}NULLNULL
asciiwordWord, all ASCIIda{portuguese_hunspell,unaccent,portuguese_stem}portuguese_hunspell{}
blankSpace symbols{}NULLNULL
wordWord, all lettersBósnia{portuguese_hunspell,unaccent,portuguese_stem}portuguese_hunspell{bósnio}
blankSpace symbols{}NULLNULL
asciiwordWord, all ASCIIe{portuguese_hunspell,unaccent,portuguese_stem}portuguese_hunspell{}
blankSpace symbols{}NULLNULL
asciiwordWord, all ASCIIHerzegovina{portuguese_hunspell,unaccent,portuguese_stem}portuguese_stem{herzegovin}
blankSpace symbols({}NULLNULL
uintUnsigned integer26{simple}simple{26}

Cada linha representa um token identificado no parágrafo, como ele foi identificado, por qual regra e qual o resultado final após a aplicação da regra.

Agora como salvamos no banco esse registro? Primeiro vamos criar uma tabela:

CREATE TABLE artigos (
   id SERIAL PRIMARY KEY,
   conteudo TEXT NOT NULL,
   conteudo_fts TSVECTOR NOT NULL
);

Em seguida, vamos inserir o registro (repare que conteúdo é duplicado, mas na segunda vez, usamos a função to_tsvector para converter ele):

INSERT INTO artigos (conteudo, conteudo_fts) VALUES (
    'Algumas das principais razões da evasão escolar no Brasil atual são a pobreza, a dificuldade de acesso à escola, a necessidade de trabalho e, principalmente, o desinteresse pelos estudos. Segundo o Programa das Nações Unidas para o Desenvolvimento (PNUD), o país tem a terceira maior taxa de abandono escolar (24,3%) entre os 100 países com maior IDH (Índice de Desenvolvimento Humano), só atrás da Bósnia e Herzegovina (26,8%) e das ilhas de São Cristovão e Névis, no Caribe (26,5%). Na América Latina, só é superado pela Guatemala (35,2%) e pela Nicarágua (51,6%), não tendo sido divulgado o índice do Haiti.',
    to_tsvector('pt_br', 'Algumas das principais razões da evasão escolar no Brasil atual são a pobreza, a dificuldade de acesso à escola, a necessidade de trabalho e, principalmente, o desinteresse pelos estudos. Segundo o Programa das Nações Unidas para o Desenvolvimento (PNUD), o país tem a terceira maior taxa de abandono escolar (24,3%) entre os 100 países com maior IDH (Índice de Desenvolvimento Humano), só atrás da Bósnia e Herzegovina (26,8%) e das ilhas de São Cristovão e Névis, no Caribe (26,5%). Na América Latina, só é superado pela Guatemala (35,2%) e pela Nicarágua (51,6%), não tendo sido divulgado o índice do Haiti.')
);

Agora sim podemos fazer uma consulta:

---- Bucansdo por 'nação unidas'
SELECT id, conteudo FROM artigos WHERE conteudo_fts @@ plainto_tsquery('pt_br', 'nação unidas');

---- A mesma busca da parte 1
SELECT id, conteudo FROM artigos WHERE conteudo_fts @@ plainto_tsquery('pt_br', 'evasão escolar do brasil');

Ambas vão encontrar nosso artigo.

Vale a pena estudar um pouco sobre as funções que o Postgres oferece na busca textual:

  • ts_debug(configuracao, texto): Ajuda a entender como sua configuração interpreta um texto.
  • ts_lexize(dicionario, palavra): Aplica a regra do dicionário na palavra/token.
  • to_tsvector(configuracao, texto): Converte seu texto para um vetor de busca usando sua configuração.
  • to_tsquery(configuracao, texto): Converte seu texto para uma query de busca de uma forma estrita. Palavras devem ser ligadas usando operadores explícitos (é uma junção? ou condicional?).
  • plainto_tsquery(configuracao, texto): Converte seu texto para uma query de busca usando uma linguagem natural, próxima ao do Google.

Da forma como está, você já consegue fazer uma busca textual básica, mas ela ainda é ineficiente porque não criamos nenhum índice. Colunas do tipo tsvector podem ser indexadas em índices dos tipos GIN e GIST – cada qual com sua vantagem. Em termos gerais, o GIN oferece uma tradeoff melhor entre tempo de escrita e otimização de busca. O GIST possui um custo consideravelmente maior para escrita mas oferece uma velocidade melhor de leitura.

Adicionando um índice em nossa tabela:

CREATE INDEX idx_artigos_conteudo_fts ON artigos USING gin(conteudo_fts);

E temos uma busca prática, sem depender de sistemas externos e que atendem vários cenários de pesquisa.

Ainda podemos trabalhar com ranqueamento do resultado, destaque do texto encontrado e dicionário de sinônimos que estão presentes em sistemas complexos e geralmente apontados como única solução para buscas de verdade.

Na próxima e última parte vou focar apenas no plugin Autopage\PgSearch, que implementa e abstrai uma parte desses recursos para aplicações CakePHP.

Categorias
Desenvolvimento Web Tutoriais

Fulltext Search – Busca Textual com Postgres – Parte 1

Hoje em dia qualquer aplicação precisa de uma interface de busca, mas ainda é muito comum achar sistemas que dependem de uma entrada do usuário quase perfeita para conseguir encontrar um resultado. Internamente, essas aplicações usam e abusam de operadores SQL como LIKE e ILIKE , por vezes contando com a ajuda do coringa %% para encontrar palavras ou expressões que contém a expressão pesquisada (uma substring em outras palavras).

Mas qual a diferença de usar um simples LIKE e uma busca textual? A diferença começa pelo fato de um índice de busca textual armazenar os dados depois de um pré-processamento. Esse pré-processamento costuma envolver uma normalização (tudo em caixa baixa, por exemplo), identificação de tokens (pedaços lógicos do texto) e descarte daquilo que não possui valor semântico (remove artigos e preposições que costumam aparecer muito sem ter valor real pra quem pesquisa, por exemplo), transformação das palavras encontradas em seus radicais básicos (processo chamado de stemming) e as vezes até incluindo ou substituindo essas palavras por sinônimos. Parece complicado né? E é, mas você não precisa ser um pesquisador em NLP (processamento de linguagem natural) pra ter uma busca textual simples.

Em termos práticos, o que você ganha com uma busca textual?

Considere uma tabela chamada artigos e nela uma coluna conteudo do tipo TEXT. É um cenário comum onde se usa o operador LIKE. Agora vamos colocar uma segunda coluna conteudo_fulltext, essa do tipo TSVECTOR, que é um tipo próprio para busca textual.

Dentre os artigos salvos nessa tabela, temos um com o seguinte parágrafo:

Algumas das principais razões da evasão escolar no Brasil atual são a pobreza, a dificuldade de acesso à escola, a necessidade de trabalho e, principalmente, o desinteresse pelos estudos. Segundo o Programa das Nações Unidas para o Desenvolvimento (PNUD), o país tem a terceira maior taxa de abandono escolar (24,3%) entre os 100 países com maior IDH (Índice de Desenvolvimento Humano), só atrás da Bósnia e Herzegovina (26,8%) e das ilhas de São Cristovão e Névis, no Caribe (26,5%). Na América Latina, só é superado pela Guatemala (35,2%) e pela Nicarágua (51,6%), não tendo sido divulgado o índice do Haiti.

Wikipedia

Imagine que alguém queira encontrar esse parágrafo na busca da nossa aplicação. Esse alguém pesquisa: “evasão escolar do brasil”.

Como isso seria tratado usando apenas um LIKE:

SELECT conteudo FROM artigos WHERE conteudo ILIKE '%evasão escolar do brasil%';

E nosso alguém ficaria frustrado, sem nenhum resultado. Porque ele incluiu a preposição do que não faz parte do trecho contido no parágrafo (nele temos um no).

Agora, se nosso conteúdo está indexado para busca textual, a mesma consulta viraria:

SELECT conteudo FROM artigos WHERE conteudo_fts @@ to_tsquery('evasão escolar do brasil');

E nesse caso, o alguém ficaria feliz com o resultado.

Talvez você esteja perguntando “por que ele não usa Elasticsearch/Sphinx?”. A pergunta é justa e a resposta tão quanto: pra não complicar antes de precisar complicar. Ambos os projetos são excelentes e oferecem recursos avançados/otimizados para busca textual. Mas se sua aplicação já utiliza Postgres e você não tem bilhões de registros para indexar, não existe razão para otimizar prematuramente.

Vale mencionar ainda que em 2019 o Ifood apresentou sua migração da busca do aplicativo para usar esse mesmo mecanismo.

Agora que a gente viu uma vantagem em usar busca textual, precisamos aprender como realmente usar.

Mas vou deixar isso para o próximo artigo porque está ficando muito longo.

Antes de finalizar, só quero deixar aqui que o objetivo é ter mais 2 partes nessa sequência de posts. No último vou explicar como utilizar (ou usar como inspiração) um plugin que desenvolvi para CakePHP que adiciona ao framework suporte a busca textual do Postgres: o Autopage\PgSearch.

Atualizado em 19/10/2021: aplicada a correção na query de exemplo conforme o apontamento feito pelo JC Bombardelli nos comentários. Muito obrigado.

Categorias
Desenvolvimento Web Programação Tutoriais

Git + GPG = Assinando suas contribuições

Recentemente o core do PHP passou por uma situação, no mínimo, inusitada: 2 commits foram feitos em nome de personalidades da comunidade. Isso é possível porque quando registramos uma alteração no git através de um commit, ele registra os dados que queremos que sejam registrados, incluindo o usuário e email que você disse ter (git config user.name "Cauan" e git config user.email "[email protected]"). Veja que você não precisa validar email nem nada.

Aplicações que hospedam projetos em git geralmente pedem pra gente validar o email usado nos commits, assim são capazes de inferir que aquele código enviado é de quem disse ter enviado. Mas é apenas uma associação “lógica”. O commit diz que foi feito por fulana, e a fulana é uma usuária válida aqui no Github/Gitlab, então vou exibir a foto e nome dessa fulana aqui na interface.

Se o git não garante que quem fez uma alteração é quem diz ser, como a gente pode garantir? Assinando nossas mudanças com uma chave criptográfica.

Felizmente o git permite que a gente especifique uma chave privada configurada no GPG e cuida de todo o processo de assinar nossas mudanças. Na outra ponta, nós compartilhamos a chave pública com o Github/Gitlab para que valide o commit assinado e então possam garantir que aquele código foi feito por quem diz ter feito.

O pessoal do PHP preparou um guia bem completo sobre como configurar o GPG e git para que o incidente não se repita. Vou colocar aqui o resumo do resumo para quem tiver alguma dificuldade com inglês, mas se tiver alguma dúvida, pode usar os comentários.

Atenção: todos os comando devem ser executados com seu usuário normal. Quando necessário, o sudo vai estar explicitado.

O símbolo $ não faz parte do comando, é só pra diferenciar o que é um comando e o que é uma saída de comando. Sempre que tiver o $, você pode copiar o que está na frente e executar no seu terminal.

Primeiro, instale o GPG:

SistemaComando(s)
macOS com Homebrewbrew install gpg
Ubuntu, Debian, Mint, Kalisudo apt install gnupg
CentOS, Fedora, RHELsudo yum install gnupg

Se você usa Zsh como shell, você precisa configurar um tty para que funcione corretamente os comandos interativos com o GPG:

$ mkdir "${HOME}"/.gnupg
$ chmod 700 "${HOME}"/.gnupg
$ >> "${HOME}"/.zshrc echo 'GPG_TTY="$(tty)" && export GPG_TTY || echo "Could not determine TTY: $?" >&2'
$ source "${HOME}"/.zshrc

Verificando que a instalação funcionou:

$ gpg --version | head -2
gpg (GnuPG) 2.2.21
libgcrypt 1.8.6
$ gpg-connect-agent /bye && echo 'GPG ok' || echo 'ERROR: GPG not running'
GPG ok
$ [ -r "${GPG_TTY}" ] && echo 'TTY ok' || echo 'ERROR: TTY not found'
TTY ok

Agora vamos gerar sua chave de assinatura GPG. É imprescindível escolher uma senha forte para proteger sua chave:

$ gpg --batch --generate-key <(echo '
Key-Type: RSA
Key-Length: 4096
Expire-Date: 0
Name-Real: Fulana de Tal
Name-Email: [email protected]
')

Precisamos descobrir a versão curta do ID da chave gerada:

$ gpg -K --keyid-format SHORT
sec   rsa4096/02783663 2020-08-26 [SCEA]
      79694216A0DECA5B53E94E96910A1F8402783663
uid         [ultimate] Fulana de Tal <[email protected]>

Repare no resultado do comando anterior a primeira linha. O que vem após rsa4096/ é o ID que nós queremos, nesse exemplo: 02783663.

Vamos deixar esse valor em uma variável de ambiente para facilitar o restante das configurações, basta executar:

$ export GPG_KEYID=02783663

Estamos terminando, precisamos dizer ao git para usar essa chave para assinar nossas alterações no repositório:

$ git config --global --replace user.signingkey "${GPG_KEYID}"
$ git config --global --replace commit.gpgsign true
$ git config --global --replace tag.gpgsign true

Por último, precisamos informar ao Github/Gitlab nossa chave, para que ele possa verificar o autor das mudanças:

$ gpg --armor --export "${GPG_KEYID}" | pbcopy

pbcopy é um comando do macOS para jogar informação na área de transferência (equivalente a um Ctrl+C). Substitua essa parte pelo comando equivalente no seu ambiente se for outro, ou simplesmente retire o trecho | pbcopy e a chave será exibe no terminal, daí basta selecionar e copiar.

Com a chave copiada, acesse suas configurações:

Feito isso, todos os seus novos commits deve ser assinados e se tudo ocorreu bem, aparecerão como verificados nos Git da vida:

Imagem com uma lista de commits contendo o selo "verified" do Github

Atualizado em 13/04/2021: eu segui esses passos do artigo original em um macOS sem o gpg previamente instalado e com o git relativamente atualizado. Caso seu ambiente já tenha gpg ou a versão do git seja muito antiga, verifique a seguinte resposta no StackOverflow. Agradecimento ao Elton Minetto pela dica nos comentários.

Atualizado em 01/05/2021: como alertou nos comentários o Adjamilton, depois da gente atualizar o conteúdo do arquivo .zshrc precisamos recarregar seus valores usando o comando source "${HOME}"/.zshrc para que as mudanças surtam efeito. O trecho já está atualizado.

Categorias
CakePHP opensuse PHP Tutoriais

Trabalhando com PHP 5.2 no OpenSUSE 11.2 (Downgrade do PHP 5.3 para 5.2)

No final de 2009 foi lançado a versão 11.2 do OpenSUSE, e como de costume para esta distro, todos os seus pacotes foram atualizados para a última (ou uma das últimas) versão estável. Isso aconteceu como PHP (que no lançamento estava na versão 5.3) como o MySQL (versão 5.1) dentre vários outros.

Acontece que quem trabalha com Drupal, Joomla! ou CakePHP (última  versão estável é a 1.2) deve aguardar ainda para poder utilizar a versão 5.3 do PHP, que incluí várias mudanças, caso contrário eles podem não funcionar ou apresentar vários avisos.

Pesquisando sobre o problema descobri que não há no repositório do OpenSUSE (os oficiais nem nos mais conhecidos) o PHP 5.2 disponível, então como fazer? Baixar o fonte e compila-lo? É uma saída, mas queria algo “OpenSUSU-like” (mais fácil).

Dando uma vasculhada no oráculo encontrei openSUSE 11.2: Downgrade PHP 5.3 to 5.2

Resolvi adaptar algumas coisas e funcionou perfeitamente, vamos lá aos passos com minhas modificações:

  1. Abra o Gerenciador de Software;
  2. Vá no menu “Configuração” -> “Repositórios”;
  3. Procure o repositório “Atualizações Para o OpenSUSE 11.2-0”, clique sobre ele e depois no botão editar, na parte inferior da janela;
  4. No campo “Diretório do Servidor” altere o “11.2” para “11.1” e então clique em OK; Na versão 11.1 o PHP está na versão 5.2
  5. Procure o repositório “OpenSUSE 11.2 OSS”, clique sobre ele e depois no botão editar; Este e o próximo passo são necessário caso você deseje fazer o downgrade do MySQL para versão 5.0 (eu recomendo isso para deixar tudo compatível, como era no OpenSUSE 11.1)
  6. No campo “Diretório do Servidor” altere o “11.2” para “11.1” e então clique em OK;
  7. Novamente clique em OK na listagem de repositórios;
  8. De volta a janela de gerenciamento de software, pesquise por PHP5, caso você já tenha instalado o PHP 5.3 aproveite agora para remover tudo relativo a ele, caso contrário selecione os pacotes que precisar e tenha certeza de marcar a versão correta (para mim foi 5.2.11). Verifique a versão de cada pacote clicando sobre ele e em seguida na aba “Versões” da janela, se houver mais de uma, marque a relativa ao PHP 5.2.x (onde x for o maior disponível);
  9. Agora, pesquise os pacotes relativos ao MySQL (utilize o termo “mysql” na caixa de busca);
  10. Você deve marcar as opções “libmysqlclient15”, “mysql” e “mysqlclient” conferindo se todos estão com a versão selecionada para 5.0.x (onde x é o maior número disponível);
  11. Clique agora em OK para instalar os pacotes, uma janela irá abrir informando a necessidade de instalar alguma dependência. Dê uma olhada se não há conflitos e clique em OK; Agora é só aguardar.
  12. Abra agora o “Repositórios de Software” e volte os repositórios para sua configuração original (trocando o 11.1 para 11.2), caso contrário não receberá as últimas atualizações dos outros softwares. Recomendo também que vá ao “Gerenciador de Software” e bloqueie os pacotes que instalou, para que o OpenSUSE não tente atualiza-los (os pacotes do PHP e MySQL);
  13. Depois de instalar os pacotes, reinicie seu Apache logando-se como root no terminal e executando o comando “rcapache2 restart”; Verifique se o PHP está funcionando corretamente. Deve estar;
  14. No OpenSUSE 11.2 o socket do MySQL mudou de endereço, mas como instalamos a versão antiga do MySQL não teremos essa alteração, porém alguns aplicativos (além do PHP) usam o MySQL (como o meu Amarok), então vamos criar um link simbólico onde deveria ser o endereço novo apontando para o antigo para que não haja problema, faremos isso como root;
  15. Crie o diretório que é padrão para o socket na versão 11.2 do OpenSUSE: mkdir /var/run/mysql
  16. Entre no diretório criado e crie o link simbólico para o socket: ln -s mysql.sock /var/lib/mysql/mysql.sock
  17. Reinicie seu OpenSUSE e bom proveito.

Caso tenha alguma dúvida deixe-a nos comentários. Se necessário tiro alguns screenshots para ilustrar melhor.