Problemas com o SQLITE

[Hispan]

Olá Galera,

Bom a pouco tempo estou desenvolvendo um jogo e inicialmente estou usando o Python para fazer a parte do emulador do jogo, mas quando fui testar o jogo com alguns amigos meu reparei que está com um certo delay, mexi e mexi no emulador e vi que havia muitas consultas na db (estou usando database em sqlite porque li que mysqlDB não é muito rápido com python) e isso estava gerando um certo lag.

Oque eu posso fazer para deixar as consultas no banco de dados mais rápidas? Eu tentei reduzir o número de conexões na db mas mesmo assim ainda tem muitas.

Oque posso fazer para resolver este problema com o SQLITE? Existe outro banco de dados mais rápido que sqlite e mysql? 

[Joao S. O. Bueno]

O SQLite é bem rápido - -
mas salvo engano, o correto para ele é usar _UMA_ conexão, e não o
máximo de conexões possíveis.

A idéia do SQLite é que seja umbanco de dados embutido "no processo", ou seja,
as funções para queries são chamadas dentro do próprio processo que
está usando o banco,
e devolvem direto os dados. A "conexão" então significa: o arquivo
que contem o DB está aberto.

Possivelmente, o jeito do SQLite lidar com as várias conexões que você
está forçando
é colocar um lock no arquivo, de forma que uma query só vai poder ser
completada quando
acabar uma query anterior.

No caso então ou você usa o MySQL (MariaDB) ou PostgresSQL - que podem
gerenciar várias
conexões simultâneas já que tem seus próprios processos para
gerênciar as conexões,
ou re-escrever seu sistema para ter apenas um processo falando com o
SQLite - e você
se comunica com ele com xmlrpc ou jsonrpc, por exemplo. Ou mesmo
multiprocessing, mas aí
acho que dá mais trabalho fazer todos os seus outros processos acharem
a mesma instância do
processo do banco de dados. (note que nesse caso, o jeito mais
simples é fazer as consultas "sincronas":
ou seja, uma chamada ao banco já faz a query e retorna todo o conjunto
de resultados ("cursor.fetchall")).
Claro que as suas consultas aobanco ficam sequênciais do mesmo jeito,
mas some o overhead do sqlite ter que lidar com locks para os quais
ele não foi feito.

Outras duas coisas: se mudar para MariaDB ou PostgreSQL - nem sempre
"o maior número de conexões possível" é a melhor coisa. E por fim, o
mais óbvio, se você aidna não viu: se o banco está lento, verifique os
índices que você está usando. Uma consulta por um único critério que
não esteja indexado pode ser degradada em várias ordens de grandeza
assim que o banco começa a ficar maiorizinho (e maiorzinho não é
muito grande não: 1000 registros já podem deixar uma consulta sem
índice umas 200x mais lenta, em média)


js
-><-

>
> --
> --
> ------------------------------------
> Grupo Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
>
> <*> Para visitar o site do grupo na web, acesse:
> http://groups.google.com/group/python-brasil
>
> <*> Para sair deste grupo, envie um e-mail para:
> python-brasi...@googlegroups.com
>
> ---
> Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos
> Grupos do Google.
> Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie
> um e-mail para python-brasi...@googlegroups.com.
> Para mais opções, acesse https://groups.google.com/d/optout.

[Luciano Ramalho]

Hispan, nem o SQLite nem o MySQL são lentos, portanto eu acho que o
problema é que você está usando errado o banco de dados, pelo menos
sua mensagem sugere isso.

Como o JS falou, o SQLite não é feito para ter muitas conexões, é para
ter uma, que na verdade nem é uma "conexão" de rede, é um arquivo
aberto sendo lido e atualizado pela biblitoeca SQLite integrada ao
processo Python.

Durante a operação normal o SQLite faz tudo em memória RAM, portanto
ele é MUITO rápido. Mas se você está com "muitas" conexões é porque
deve estar abrindo e fechando toda hora as conexões como SQLite e este
não é o jeito certo de usá-lo.

O MySQL suporta várias conexões concorrentes, mas em geral basta uma
por processo, se você está usando muitas também não me parece que está
certo.

Não sei que tipo de jogo você está fazendo, se é para desktop, ou se
tem uma parte no servidor, o se é só no servidor. Para a parte que
roda no desktop o SQLite é a escolha certa. Para a parte servidor eu
usaria o PostgreSQL, mas se preferir o MariaDB ou o MySQL também
atendem.

Finalmente, o JS falou também sobre índices, e isso é importantíssimo:
não dá para esperar alto desempenho de nenhum banco de dados se você
não tem índices para suportar cada uma das consultas mais frequentes
que o seu sistema faz.

Mas me parece que o seu problema real é de arquitetura: como integrar
o BD na sua aplicação. Do jeito que está fazendo claramente não está
correto, porque esse desempenho ruim não é característico do SQLite
nem do MySQL.

[ ]s
Luciano

2015-01-28 10:25 GMT-02:00 Hispan <gustavomi...@gmail.com>:

> --
> --
> ------------------------------------
> Grupo Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
>
> <*> Para visitar o site do grupo na web, acesse:
> http://groups.google.com/group/python-brasil
>
> <*> Para sair deste grupo, envie um e-mail para:
> python-brasi...@googlegroups.com
>
> ---
> Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos
> Grupos do Google.
> Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie
> um e-mail para python-brasi...@googlegroups.com.
> Para mais opções, acesse https://groups.google.com/d/optout.

--
Luciano Ramalho
Twitter: @ramalhoorg

Professor em: http://python.pro.br
Twitter: @pythonprobr