Em 9 de março de 2016 09:32, Flavio Henrique Araque Gurgel <fha...@gmail.com
> escreveu:

>
> Colocar um servidor Web para fazer uma camada REST sobre o protocolo do
> PostgreSQL, só vai colocar MAIS UMA camada por cima. A libpq continua lá.
>
>
​Aqui não continua, uso jdbc type 4, não usamos libpq. O drive jdbc do
Postgres tem sido mais rápido do que acessar com a libpq em C++ em todos os
testes que fizemos. ​

REST não serve pra substituir uma conexão direta com um banco de dados.
>
>
​Ninguém disse isto pelo que me lembro. Temos um problema que é a
velocidade de acesso a dados em um banco PostgreSql remoto. Uma das
possíveis idéias (que não deveria ser ignorada simplesmente por não ser a
sua) é utilizar REST para fazer isto. REST pode ser a solução para a
"velocidade de acesso remoto" que é o título da pergunta e não para
"substituir uma conexão direta com banco de dados" como você está dizendo.
Estamos respondendo a pergunta, e não o que você acha que está sendo
perguntado.


> 1) Manter um pool de conexões, mesmo que 1:1, pode sim melhorar as coisas
> por evitar o (baixo, mas importante quando o banco tá longe) overhead de
> abrir e fechar conexões.
>
>
​Não é baixo. Talvez seja irrelevante se você tem poucos acessos, mas não é
baixo. Em um server que responde a um sistema em PHP que temos, usar um
pool de conexões reduziu o tempo de resposta em média de 25ms linearmente
em todas as requisições com acesso à dados. O banco estava na própria
máquina onde estava o sistema. Junte-se isto a uma média de 100 req/seg em
horário de pico que temos sim uma grande diferença.


> Extra: Comparar PHP com Delphi, libpq com REST, sua comparação aqui =
> Flamewar besta.
>
>
​Acho que sou ingênuo. Não vi estas comparações aqui.​


> Foco no problema - latência de rede
>

​O problema não é este, isto é o que você acha que é. Mudar a pergunta para
inutilizar respostas de outros membros não é legal. De acordo com o título,
o problema é "velocidade de acesso remoto ao postgresql" e você está apenas
inferindo que isto se trata de latência de rede.​ Não se está ignorando a
latência de rede, claro que ela pode ser sim um dos problemas, mas podem e
certamente existem vários outros problemas que podem influenciar, assim
como existem várias técnicas para se contornar cada um destes problemas.


Foro na solução - técnicas para eliminar viagens de rede - são inúmeras,
> citei algumas.
>
>
​Solicitações utilizando um serviço remoto que responde em algum protocolo,
HTTP no caso de REST também é uma técnica para eliminar viagens de rede.​
Usar um ORM também é uma boa técnica para isto já que você pode fazer
dezenas de instruções Sql que somente irão ser enviadas ao banco "flush" no
momento do "commit".


> Vamos subir o nível desta lista?
>
>
​Simbora, começando por não alterar a pergunta​ para desvalorizar respostas
que não sejam a sua além de parar de inferir que todo munda usa as
ferramentas que você acha que elas usam.

--
​Shander Lyrio​
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a