Em 9 de março de 2016 09:32, Flavio Henrique Araque Gurgel
<fha...@gmail.com <mailto: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.
Desculpe, não havia JDBC na pergunta original do colega, ele usa Delphi.
Não tenho parâmetros de comparação JDBC/libpq, mesmo se eu use ambos
todos os dias.
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.
Não foi minha intenção colocar nenhuma das respostas em detrimento de
outras. Mas sim, mantenho minha opinião de que uma camada REST vai
incluir mais problemas do que soluções. A opinião é minha e é meu dever
colocá-la aqui.
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.
Foi exatamente o que falei, não entendi porque você escreveu isso.
O overhead é sim, muito baixo - mas pode se tornar importante se você
tem alta latência (como eu disse) ou centenas de conexões/desconexões
por segundo (como você disse)
Logo, estamos plenamente de acordo que um pool de conexões deve *sim*
ajudar no cenário.
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.
Eram de outras respostas, talvez não as suas.
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.
Existem duas possibilidades, latência e taxa de transferência.
Eu respondi de acordo com minha experiência, tentando ajudar.
Assim, só de passagem, eu administro de um local central, servidores de
bancos de dados em 3 continentes.
E, coloquei na minha resposta, as técnicas que uso - menos consultas,
com mais dados por consulta = ganho expressivo.
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".
Desculpe, ORM é uma entidade desacreditada no mundo dos bancos de dados
e só tenho a discordar. Vide movimentos pelo jOOQ (mundo Java) e Pomm
(mundo PHP).
Passo meus dias a tirar consultas de um ORM "padrão de
mercado"(Hibernate) e passando para SQL direto numa aplicação e
resolvendo pelo menos um problema de desempenho por semana fazendo isso.
E, por favor, explique-me como fazer uma transação complexa de banco de
dados em REST.
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.
Desculpe, não alterei a pergunta, coloquei minha experiência no assunto.
pena que não foi tão bem vinda. Eu não queria incomodar ninguém.
Grande abraço,
Flavio.
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
