Arquivo de etiquetas: PostgreSQL

Medir o desempenho do PostGIS

Uma das formas de medir o desempenho do PostgreSQL no nosso servidor, é usar o pgbench, a ferramenta padrão incluída com a instalação do pgsql. Há tempos fiz uns testes de comparação de 2 servidores que publiquei aqui: http://blog.viasig.com/2014/08/medir-o-desempenho-do-postgresql/.

Ora, esses testes usam dados alfanuméricos e queries “normais”, de escrita e leitura, usando tabelas relacionadas. Ou seja, o pgbench tenta simular uma utilização usual do pgsql.

No nosso caso, SIGianos, a utilização usual não tem nada a haver – usamos dados espaciais e queries muito próprias. Este artigo mostra uma forma de medirmos o desempenho do PostGIS, usando também a ferramenta pgbench.

Uso “normal” de SIG

Quando um programa “normal”, não geográfico, consulta uma base de dados, em geral, obtém alguns registos, e pode até cruzá-los, para dar um resultado final. Provavelmente, apresenta uma tabela de resultados, paginados, com algumas colunas (menos de 10?). Um bom exemplo, é um programa de facturação ou de gestão de stocks. É este tipo de programas que o pgbench tenta simular.

Há uma enorme diferença para o uso que um programa de SIG faz de uma base de dados. O uso normal SIG é visualizar um mapa. E isso faz toda a diferença.

image

Este simples mapa de enquadramento usa 7 tabelas. A área visível usa um total de 618 registos (1+261+177+1+3+29+146). Se visualizarmos o país inteiro, a conta passa para 5841 registos. É muita informação para uma das operações mais básicas – pan e zoom.

Do ponto de vista da base de dados, o uso SIG é diferente:

  • Um mapa é, tipicamente, composto por diversos temas (facilmente mais de 10);
  • Cada tema é uma tabela espacial diferente na base de dados, logo em cada visualização vamos ler uma série de tabelas;
  • Cada tema/tabela pode ser lido na totalidade (não paginado) se visualizarmos toda a área do tema;
  • Cada tema/tabela pode ter aplicada uma selecção (filtro) logo de início com base nos atributos (e.g. para vermos apenas uma categoria de rios ou estradas);
  • Cada tema/tabela pode ainda ter aplicado um filtro espacial se estivermos a visualizar apenas uma área específica (ou seja, são apenas pedidos os dados relativos ao rectângulo visível no mapa);
  • Mas, principalmente, os dados geográficos são muitos mais “pesados” ou “gordos”: têm uma coluna que contém todos os vértices da geometria! (Cada vértice tem 2 números do tipo double, o que equivale a 2 colunas em dados alfanuméricos.)
  • Para agravar a coisa, os utilizadores nunca escolhem os campos que precisam para trabalhar, e assim quando abrem a tabela de atributos todos os campos são lidos.

Usar o pgbench para simular utilizadores SIG

Uma das capacidades do pgbench é que permite testar queries à base de dados feitas por nós, em vez de usar as pré-definidas. Basta criar um ficheiro sql que contém as nossas queries e passá-lo ao pgbench com o parâmetro –f.

É esta capacidade que usamos para simular queries espaciais e medir o desempenho em Transações por Minuto (TPS), tal com se faz para uma base de dados não espacial.

Assim, configuramos o PostgreSQL para que guarde no log todas as queries que recebe. Depois usamos o QGIS com um mapa típico que utilizamos frequentemente, e fazemos zoom a diversos locais e com diferentes escalas. A partir dos logs do PostgreSQL obtemos as queries SQL de cada zoom, e criamos um ficheiro .sql para cada zoom.

Em resumo, no nosso exemplo, obtivemos 10 ficheiros zoomN.sql que correspondem a 10 visualizações no QGIS do mesmo mapa, a escalas diferentes: zoom1.sql, zoom2.sql, … até zoom10.sql. Ou seja, um ficheiro .sql equivale a 1 mapa:

zoom1 – 1:1M                                                        zoom2 – 1:288.000

imageimage

zoom3 – 1:72.000                                                        zoom4 – 1:18.000

imageimage

Cada visualização criou um ficheiro .sql que podemos usar no pgbench, e simular vários utilizadores simultâneos de QGIS. Aqui,há uma simplificação: cada zoom é feito instantaneamente a seguir ao outro. Ou seja, vamos simular super-utilizadores! Piscar de olho que não fazem pausas entre zooms e pans.

O comando para simular 12 super-utilizadores que fazem 10 zooms/pans é o seguinte:

pgbench -f zoom1.sql -f zoom2.sql -f zoom3.sql -f zoom4.sql -f zoom5.sql -f zoom6.sql -f zoom7.sql -f zoom8.sql zoom9.sql zoom10.sql  -h <servidor> –U <user> -n -l -c 12 -j 2 -T 180 postgis

image

Tal como no artigo anterior sobre pgbench, o significado dos parâmetros é:

  • -n = não fazer vacuum aos dados, porque estamos a usar a bd de produção;
  • -l = log de tempos para um ficheiro;
  • -c 12 = simular 12 conexões simultâneas, ou seja, 12 utilizadores de SIG;
  • -j 2 = simular 2 threads por conexão (pouco impacto tem);
  • -T 180 = simular durante 180 segundos (3min);

Os resultados são:

transaction type: Custom query
scaling factor: 1
query mode: simple
number of clients: 12
number of threads: 2
duration: 180 s
number of transactions actually processed: 4004
tps = 22.148347 (including connections establishing)
tps = 22.188888 (excluding connections establishing)

O que quer isto dizer?

O que interessa é o valor final de 22.18 tps. Isto significa que o nosso PostGIS consegue responder a um ritmo de 22,18 mapas por segundo, em média. Ou seja, deviamos dizer 22,18 MPS (maps per second) Piscar de olho

Este valor é a média para todas as escalas que utilizámos no teste. Podemos testar cada escala em separado, e obter desempenhos por escala. Num outro teste usando dados do OpenStreetMap, fizemos este gráfico:

image

Obviamente, quanto maior a escala, maior o detalhe, e, geralmente, menos dados. Logo, à escala 1:1M temos um poder de processamento de 1,51 MPS, e à escala :1:5600 temos 112,92 MPS.

O que interessa nisto tudo é que podemos comparar agora entre servidores diferentes de PostGIS, e entre configurações diferentes num servidor, para determinarmos a melhor configuração.

Notem que este teste elimina o factor QGIS, ou seja, não se considera o desempenho do QGIS a desenhar o mapa. Uma vez que convertemos cada vizualização num ficheiro .sql, ao executar o teste só usamos o ficheiro .sql. Assim, o desempenho do QGIS não entra na equação, o que é necessário se queremos medir o desempenho do servidor PostGIS.

Outras questões de desempenho

Ao testar o desempenho do PostGIS, acabamos por nos apercebermos de alguns factores que influenciam e muito os resultados e o desempenho observado de um servidor PostGIS.

Por exemplo, se durante o teste verificarmos o que se passa no servidor, podemos ter algumas surpresas:

beja084_2

(Sim, eu sei… é windows…)

O CPU esteve a 91%, para conseguir responder aos nossos 12 QGIS simulados. É perigoso andar tão perto dos 100%, porque o desempenho começa a diminuir. Aqui temos de jogar com o n.º de conexões. Neste caso, baixar de 12 para 10 conexões simultâneas até poderia dar resultados melhores. Cada servidor terá o seu n.º de conexões para o qual se obtém o máximo de tps. Temos de experimentar vários valores e ver o melhor.

Os valores de memória apresentados no Task Manager são inúteis, porque a memória ocupada está sempre perto dos 100%. Teríamos de fazer outro tipo de análise.

Já a ocupação de rede é interessante: é enorme! 769 Mbps! É muito fácil limitar o desempenho do PostGIS por causa de uma má ligação de rede entre o PostGIS e os utilizadores. Se compararmos com o teste de queries “normais” não espaciais, vemos que a ocupação de rede é apenas de 22 Mbps (para o total das 12 conexões simultâneas).

image

Outra questão importante para os resultados dos testes é observar o estado do PC onde corremos o pgbench, principalmente quanto à ocupação do CPU: como o pgbench corre num só processo ocupa só 1 core, e podemos facilmente limitar os resultados porque o nosso CPU não consegue responder. Temos de verificar durante os testes se o processo pgbench.exe ocupa MENOS que 1 core. No meu caso, usei um i5, que tem 4 cores. Logo, o pgbench tinha de ocupar menos de 25% de cpu para que os resultados fossem bem medidos.

Conclusão

Usar o pgbench com dados espaciais dá-nos uma excelente forma de testar o desempenho do PostGIS. Podemos perceber qual o melhor servidor, se físico, se virtual, para o nosso caso particular. Podemos ainda testar configurações alternativas do PostgreSQL e identificar aquela que dá melhores resultados.

Melhor ainda, será criar um pacote de dados OSM e os scripts .sql correspondentes, e usá-los para termos um teste padrão de PostGIS. Se todos usarmos estes dados vamos conseguir partilhar resultados entre toda a comunidade. Hmmm, temos de pensar nisto…

Medir o desempenho do PostgreSQL

Não é todos os dias que temos a oportunidade de fazer um upgrade ao nosso velhinho servidor de PostGIS. Quando um servidor usado fica disponível ou, ainda melhor, quando recebemos uma máquina novinha em folha para instalar a nossa base de dados, queremos saber qual a melhoria de desempenho que vamos ter. Pelo menos eu quero Piscar de olho

Por outro lado, se vamos comprar um novo servidor temos de definir as características dentro do preço que podemos pagar. E convém ter uma orientação que nos ajude a perceber que tipo de desempenho podemos obter dentro desse orçamento.

Outra utilidade para este tipo de medição é perceber quais os melhores parâmetros de configuração do PostgreSQL para a nossa nova máquina. Podemos alterar os parâmetros e testar, vendo rapidamente qual a combinação de parâmetros que melhor desempenho consegue.

Este artigo mostra como medir o desempenho do PostgreSQL usando o comando standard para isso – o pgbench. Para outro post fica a proposta de um teste standard para medir o desempenho da componente geográfica – PostGIS – usando o pgbench com dados geográficos disponíveis publicamente. Isto permite que todos os utilizadores de PostGIS possam usar um teste padrão, tal como já existe para dados não-espaciais, e comparar diferentes servidores.

O ideal seria ter uma tabela online onde se pudessem comparar vários servidores, editada pelos utilizadores… isso é que era!

Os 2 servidores em confronto

Ao longo do artigo vão ser feitas comparações de desempenho entre 2 servidores praticamente iguais ao nível do hardware, onde apenas se altera o sistema de disco – o novo servidor promete muito melhor desempenho de disco. Mas há também diferenças no software – a versão do sistema operativo, e as versões do PostgreSQL e PostGIS são mais recentes e passam a 64bit. As características dos servidores são as seguintes:

Servidor CPU RAM Disco SO PostgreSQL PostGIS
velho Xeon E5420, 4cores 2,5GHz 12 GB SAN, 215GB Win 2003 x64 8.4.10, x32 1.4.2
novo Igual Igual SAN, 50GB Win 2008 x64 9.2.8, x64 2.1.1

Ambos os servidores têm a mesma configuração do PostgreSQL:

  • Shared Buffers: 512MB
  • Work Memory: 6MB
  • Effective Cache Size:  256MB

Usar o pgbench

O pgbench é uma ferramenta que vem incluída na instalação do PostgreSQL, e é usada para efectuar testes padronizados de desempenho transacional. Ou seja, é um teste que todos os utilizadores podem fazer e comparar entre si, já que o teste é sempre o mesmo, usando os mesmos dados. Como sempre, a documentação do PostgreSQL é excelente e o manual do pgbench também.

Como o pgbench envia comandos SQL para o servidor tentando levá-lo ao limite das suas capacidades, convém executá-lo a partir de outro computador ligado em rede, como por exemplo, o seu portátil ou desktop.

Para começar, temos de usar o pgbench para criar os dados necessários aos testes. Aqui temos de ter já uma ideia de quantas conexões vamos considerar. Isto depende do(s) processador(es) do nosso servidor. Quanto mais cores mais conexões simultâneas vamos conseguir executar em simultâneo. Podemos jogar pelo seguro e exagerar um pouco. Por exemplo, para o meu processador de 4 cores, vou iniciar os dados para 20 conexões simultâneas, embora saiba de antemão que são demasiadas (vou acabar por fazer os testes com apenas 12 conexões).

Para criar os dados, o pgbench precisa de saber o nome da base de dados a usar (que tem já existir). Se instalámos o PostGIS é provável que tenhamos criado uma bd com o nome “postgis” e é isso que vou usar nos exemplos. Também nos exemplos, o nome do servidor será “pgServer” e o utilizador será “userteste”.

Assim, para começar, executamos o pgbench no nosso computador (não no servidor) com o seguinte comando:

pgbench –i –s 20 –h pgServer –U userteste postgis

Este comando irá criar as tabelas do teste no schema do utilizador “userteste” e criará dados suficientes para testar 20 conexões simultâneas.

Em seguida vamos medir o desempenho do nosso servidor, medido em Transações por segundo, ou TPS.

O pgbench é muito completo, mas vamos simplificar e medir apenas 2 tipos de operações:

  • Transação típica, em que os registos são inseridos em tabelas relacionadas entre elas com chaves primárias e estrangeiras. Este é o desempenho mais típico de uma base de dados. É medida uma mistura de operações de escrita e leitura, com garantia de integridade.
  • Transação apenas de leitura, em que apenas se testa a componente de leitura da bd. Em princípio mede o valor máximo de TPS para o nosso servidor.

Vamos executar todos os testes durante 5 minutos. Assim, para testar a transação típica, vamos usar o comando seguinte:

pgbench –h pgServer –U userteste –c 12 –j 2 –T 300 postgis

A explicação do comando é a seguinte:

  • -c 12 => testar 12 conexões em simultâneo
  • -j 2 => cada conexão em 2 threads
  • -T 300 => testar durante 300 segundos, ou seja, 5 minutos

Já vamos ver os resultados mais à frente… para já temos de discutir como aparecem as 12 conexões…

Um servidor consegue responder a 1 só conexão com uma certa rapidez ou velocidade, medida em TPS. E queremos que seja o mais rápido possível. Ao aumentarmos o número de conexões, em principio, também vai aumentando o número de pedidos à base de dados que são processados por segundo pelo servidor. Até que estagna e começa a reduzir-se. Isto significa que o servidor tem um limite para processar pedidos em simultâneo. O seu máximo de TPS será obtido para um dado número de conexões. Este TPS máximo é um dos melhores indicadores de desempenho de um servidor de base de dados.

A questão que este comando coloca é: como vamos definir o n.º de conexões a testar? De forma geral, o servidor nunca deve ultrapassar os 85% de ocupação de CPU, porque acima deste valor começa a sentir-se contenção no acesso ao processador, ou seja, começa a formar-se uma fila de pedidos que aguardam pela disponibilidade do CPU para serem executados, e o próprio sistema operativo começa a atrapalhar-se. É este o nosso alvo – manter o CPU próximo dos 85% de uso.

Felizmente, podemos perceber rapidamente qual é o n.º de conexões que mantém o CPU perto dos 85%. Em geral, a partir daqui o valor de TPS não aumenta, podendo mesmo baixar.

Isto é muito fácil: basta executar alguns comandos pgbench rápidos, de 30 segundos (usando -T 30 em vez de –T 300), com cada vez mais conexões, e vigiar o CPU do servidor ao mesmo tempo que apontamos os resultados. Há um n.º de conexões que acaba por saturar o processador e partir do qual não se aumenta o desempenho. Por exemplo, podemos usar esta sequência de comandos:

pgbench –h pgServer –U userteste –c 6 –j 2 –T 30 postgis

pgbench –h pgServer –U userteste –c 8 –j 2 –T 30 postgis

pgbench –h pgServer –U userteste –c 10 –j 2 –T 30 postgis

pgbench –h pgServer –U userteste –c 12 –j 2 –T 30 postgis

pgbench –h pgServer –U userteste –c 14 –j 2 –T 30 postgis

No meu caso, as 12 conexões revelaram ser o ideal, o CPU nunca passou os 85%, e o desempenho foi o maior de todos. Já com 14 conexões, o desempenho começou a reduzir ligeiramente.

Resultados do pgbench

Os resultados do comando acima são os seguintes:

starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 20
query mode: simple
number of clients: 12
number of threads: 2
duration: 300 s
number of transactions actually processed: 537417
tps = 1791.328213 (including connections establishing)
tps = 1792.516930 (excluding connections establishing)

Qual a conclusão?

Este servidor conseguiu executar 537.417 transações “normais” do pgbench, em 5 minutos, o que dá um valor de 1.792 transações por segundo (TPS). Com este número já podemos comparar com outros servidores que tenham usado o pgbench.

Em seguida, medimos também o desempenho com transações apenas de leitura, usando um comando quase igual – apenas adicionamos o parâmetro –S:

pgbench –h pgServer –U userteste –c 12 –j 2 –T 300 –S postgis

Os resultados são os seguintes:

starting vacuum...end.
transaction type: SELECT only
scaling factor: 20
query mode: simple
number of clients: 12
number of threads: 2
duration: 300 s
number of transactions actually processed: 6844551
tps = 22815.432028 (including connections establishing)
tps = 22830.845226 (excluding connections establishing)

Ou seja, para queries apenas de leitura, conseguimos um TPS de 22.830, muito mais elevado, como é de esperar.

Assim, a comparação entre o servidor antigo e o novo fica com este aspecto:

Servidor Teste “normal” (TPS) Teste só leitura (TPS)
velho 590 20.944
novo 1.792 22.830

Boas notícias. Tudo aponta que o novo servidor vale a pena… +200% de desempenho em queries mistas, e +9% em queries de leitura apenas. Isto confirma a suspeita inicial: o sistema de discos do novo servidor é muitíssimo melhor, sendo o seu impacto terrivelmente visível no desempenho de escrita na base de dados, e ainda aumentando o desempenho de leitura em 9% (até porque grande parte das queries de leitura são efectuadas em memória). Claro que a introdução de uma nova versão de PostgreSQL também terá a sua influência, e neste caso é impossível determiná-la.

No próximo artigo vamos medir o desempenho do PostGIS, usando o pgbench com dados geográficos.

Até lá, bons desempenhos! Piscar de olho

PostgreSQL e ESRI – parte 3

Esta é a parte 3 desta série, sobre a utilização de PostGIS com ArcGIS, que aborda a estruturação da bd PostGIS. Os artigos anteriores são:

Depois de instalar o PostgreSQL+PostGIS+ArcSDE, e configurar o formato de armazenar os nossos dados na bd, para que usemos as geometrias nativas do Pg em vez dos objectos ESRI (para compatibilidade com software Open Source), teremos de definir que utilizadores vamos criar na bd, e a forma como organizamos os dados.

Bases de Dados e Utilizadores

A organização interna do PostgreSQL é algo semelhante à do SQL Server, e bastante diferente do Oracle. Por exemplo, um servidor PostgreSQL contém várias bases de dados, ao contrário do Oracle onde uma bd corresponde a um serviço ou instância. Se quisermos mais bd’s temos de criar novas instâncias, com configuração independente, conexões, dados, utilizadores, etc.

Durante a instalação do PostGIS é instalada uma bd chamada “postgis”, e podemos usá-la para armazenar os nossos dados geográficos ou podemos criar outras bd’s ao nosso gosto…

Podemos assim guardar a informação geográfica na base de dados postgis que é criada durante a instalação do PostGIS. Ultrapassada esta decisão, temos de criar e configurar os utilizadores que vamos usar para carregar a nossa informação, evitando usar os utilizadores de sistema, criados durante a instalação, que são o “postgres” e o “sde” (utilizador criado pela instalação do ArcSDE e que serve para efectuar a sua gestão). A criação de novos utilizadores é muito recomendado e geralmente é omitido nos tutoriais e instruções de instalação…

Pessoalmente, prefiro configurações com poucos utilizadores, criando apenas 1 login para cada uso: os utilizadores do SIG usam o mesmo login para a visualização, e um outro para a gestão dos dados (criação, edição, eliminação de layers, metadados, etc.). Aplicações webgis podem partilhar também um único login para acesso aos dados. A abordagem oposta é a de criar um login por utilizador, ou usar a autenticação integrada do Windows (em que as contas de utilizador de domínio são também usadas na bd). Esta é uma decisão que se repercutirá mais tarde na manutenção e monitorização da actividade da bd. Se começarmos com a abordagem mais simples (poucos logins), podemos mais tarde introduzir o esquema de autenticação por utilizador do SIG.

Uma das razões apontada para usar o esquema de mais utilizadores, é que podemos controlar exactamente quem está ligado, ou mesmo até saber quem editou os dados numa dada altura. E esta é uma argumentação válida. Mas a abordagem mais simplista, de poucos logins, também permite algum controlo, uma vez podemos ver no servidor a listagem de conexões activas, e estas são descritas não só pelo login usado, mas também pelo nome da máquina de onde são efectuadas. Como em geral, uma máquina pertence a um utilizador, acabamos por saber que utilizador “real” está efectivamente ligado à bd.

Utilizadores e Schemas

Outra questão a considerar é a de quantos “schemas” serão criados na bd. Um schema é um agrupamento de objectos na bd ao qual se atribui um nome; o nome dos objectos apenas se podem repetir em schemas diferentes. Por exemplo, podemos ter schemas com o nome “Ambiente” com os dados desta temática, ou “Cadastro”, e por aí fora. É preciso sublinhar que podemos controlar quem tem acesso a um schema, podendo proibir o acesso a certos utilizadores, dar acesso apenas de leitura, ou por fim, dar controle completo.

Quando possível, prefiro usar o schema “public” criado de raiz durante a instalação do PgSQL, e não criar mais schemas. Esta abordagem é muito simples, e tem a vantagem de ser a mais compatível com o software que interage com o PostGIS (já aconteceu usar software que não via outros schemas além do public), além de simplificar a gestão de privilégios (o que também pode ser limitativo, caso as nossas necessidades exijam compartilhar os dados por áreas de edição).

Mas sucede que o ArcSDE necessita que todos os utilizadores que criam dados tenham o seu próprio schema. Pelo que a centralização dos dados geográficos no schema public não é possível. Temos de ter tantos schemas quantos os utilizadores que criam dados. Ou seja, se o utilizador João for alguém que tem de criar tabelas novas na bd, então terá de ter obrigatoriamente o seu próprio schema, e com o mesmo nome “João”!

A questão não é complicada se tivermos poucos criadores de dados, porque teremos de criar poucos schemas. Isto não impede que haja muitos editores, que podem editar dados de outros utilizadores e por isso não precisam de ter o seu próprio schema.

Mais info sobre schemas pode ser encontrada na documentação do PgSQL.

Criar Utilizadores

Para criar utilizadores no PostgreSQL usamos o PgAdmin (programa de administração) para criar “login roles“. Podemos também criar perfis que no PgSQL são denominados “group roles“, e que permitem gerir conjuntos de utilizadores em simultâneo, que partilham privilégios. O ArcSDE necessita que certas regras sejam seguidas na criação de utilizadores, se quisermos usar o ArcGIS para criar, editar e visualizar os dados.

Em resumo, para criar um novo utilizador que pode criar novos dados através do ArcGIS/ArcSDE, vamos:

i) criar um schema com o mesmo nome do novo utilizador; e

ii) criar um novo login na base de dados postgis, chamado por exemplo “gestorsig”. (Podemos usar o PgAdmin, mas aconselho usar a janela de sql para criar o utilizador.)

O utilizador deverá ter privilégios totais no seu próprio schema, mas também o privilégio de “usage” sobre o schema “sde”, onde são colocadas as tabelas de sistema do ArcSDE. Isto é necessário porque quando o utilizador cria uma nova tabela tem de a registar numa série de tabelas de sistema. Claro que isto é feito automaticamente pelo par ArcSDE/ArcGIS, mas se o utilizador não tiver privilégios não será possível.

Por outro lado, o utilizador “sde” precisa de ter acesso às tabelas criadas, sendo por isso necessário atribuir-lhe o privilégio “usage” sobre o schema do novo utilizador, para que seja capaz de efectuar algumas operações de manutenção (limpeza do versionamento).

E ainda um passo final – como optámos por armazenar os nossos vectores usando o tipo espacial nativo do PostGIS, o nosso utilizador necessita de acesso de escrita à tabela “public.geometry_columns”, onde se registam todas as tabelas espaciais do PostGIS. De outra forma, as nossas tabelas não seriam reconhecidas como tendo geometrias.

Concluindo, para criar um utilizador capaz de criar novas tabelas, usamos o seguinte SQL:

Update (13/06/2010): é também necessário dar pelo menos acesso (SELECT) à tabela de sistemas de coordenadas (spatial_ref_sys).

create role gestorsig login password 'PasswordDoUtilizador' noinherit createdb;
create schema gestorsig authorization gestorsig;
grant usage on schema sde to gestorsig;
grant usage on schema gestorsig to public;
grant select, insert, update, delete on table public.geometry_columns to gestorsig;
grant select on table public.spatial_ref_sys to gestorsig;

Neste código há uma pequena nuance: damos acesso ao nosso schema a todos os outros utilizadores (“…to public”), e assim não nos preocupamos se damos acesso a A ou B.

Para criar um utilizador que edita dados, mas não cria novas tabelas, o processo é quase igual. Apenas não necessita do seu próprio schema (usará o public por default):

create role editorsig login password 'PasswordDoUtilizador';
grant usage on schema sde to editorsig;
grant select, insert, update, delete on table public.geometry_columns TO editorsig;

Nota: como o nosso utilizador que cria dados (gestorsig) deu acesso a todos os utilizadores, não temos de o fazer explicitamente para novos utilizadores.

Nota 2: para podermos editar os dados criados pelo gestorsig, temos de dar privilégios de UPDATE ao nosso editor. Podemos fazê-lo usando o ArcCatalog (selecionar as Feature Classes, e com botão direito usar a opção “Privileges”), ou usando SQL.

No caso de utilizadores que só visualizam dados, o processo é igual. A diferença é que no ArcCatalog apenas damos o privilégio de SELECT sobre os objectos criados.

Deixo aqui 2 links que resumem a forma de criar novos utilizadores:

Todo este processo é muito semelhante ao que se passa com outros SGBDR’s, como Oracle ou SQL Server. Apenas muda a terminologia, e alguma da lógica de compartimentação da estrutura da bd. Para quem vem do mundo Oracle, a adaptação ao PostgreSQL é muito fácil, e para utilizadores de SQL Server não é muito diferente…

PostgreSQL e ESRI – parte 2

Este post é o 2º sobre integrar ArcGIS e PgSQL. A 1ª parte pode ser encontrada aqui.

Este artigo continua a experiência de usar o PgSQL como base de um SIG baseado em ArcSDE/ArcGIS, debruçando-se sobre a instalação e tipo de conexões. Não é uma introdução ao PostgreSQL/PostGIS, e é assumido que o leitor tem algum conhecimento prévio ou que o irá obter noutra fonte… por exemplo aqui:

Instalação do ArcSDE+PostgreSQL+PostGIS

O instalador do ArcSDE é muito simples, e até inclui o PostgreSQL. Mas se seguirmos o wizard de instalação do ArcSDE, não será instalado o PostGIS e o ArcSDE será instalado no seu modo default, com o seu próprio tipo espacial (coluna de geometria) e o seu próprio SQL espacial. Desta forma, só se consegue aceder aos dados geográficos com software ESRI.

Para instalar o ArcSDE de forma a que os dados sejam armazenados usando o tipo espacial do PostGIS é necessário desviarmo-nos um pouco do caminho seguido pelo wizard de instalação. Quando o wizard acaba de instalar o PostgreSQL, temos de parar, e instalar o PostGIS, antes de prosseguir com o wizard do ArcSDE. Tudo é bem explicado neste artigo da ESRI:

HowTo:  Install PostgreSQL 8.3.0, ArcSDE 9.3, and PostGIS 1.3.2 on Windows

No final da instalação ficamos assim com o PostgreSQL, o PostGIS, e o componente ArcSDE.

O componente ArcSDE cria uma base de dados no PostgreSQL, chamada “sde”, e um utilizador próprio chamado “sde”. É nesta bd que ficam as tabelas de sistema do ArcSDE e a suas próprias funções, triggers, etc.

O nosso servidor PostgreSQL fica também com a estrutura habitual do PostGIS, havendo uma bd denominada “postgis”. Nesta bd também são instalados objectos do ArcSDE, como tabelas de configuração da geodatabase que mantém registo dos objectos que são criados através de software ESRI e que compõem o modelo de dados da geodatabase.

Na instalação há um problema com privilégios – a instalação do ArcSDE pára porque não consegue escrever nas directorias do PostgreSQL (“lib” e “bin”). Para resolver basta usar o explorador do Windows para adicionar o privilégio de escrita nessas pastas ao nosso utilizador (que estamos a usar ao executar o instalador do ArcSDE). Se usarmos o utilizador “Administrator” o problema não surge.

Outra nota importante é que o PostgreSQL é instalado com as definições pré-definidas. Sucede que estas definições são à prova de equipamento pré-histórico… ou seja, o PostgreSQL instalado e sem alterações funciona até num Intel 486 com 256MB de memória. Mas claro que a performance não é a desejada e deve-se editar as configurações. Noutro artigo espero discutir um pouco as opções mais comuns a alterar.

A título de curiosidade, os valores default de configuração ocupam cerca de 60MB de memória (sem iniciar o serviço SDE e sem contar com o pg_ctl.exe).

Tipo de Ligações ArcSDE

Depois da instalação são criados 2 novos serviços no Windows: o usual do PgSQL, e um próprio do ArcSDE.

O serviço do ArcSDE é o gestor de conexões do ArcSDE. Ou seja, as aplicações da ESRI ligam-se a este serviço, que depois inicia as conexões à base de dados para cada aplicação. A ESRI designa este esquema conexões como “Application Server connections” ou de 3 camadas (3-tier). Cada utilizador de ArcGIS que se liga deste modo vai criar um processo no servidor chamado “gsrvr.exe”, que optimiza a comunicação dos dados entre a bd e o ArcGIS. Cada um destes processos ocupa entre 15MB e 100MB de memória, para além da memória ocupada pelo próprioPgSQL. Se houver 10 postos ArcGIS, serão lançados 10 processos destes no servidor, ocupando 150-1000MB de memória. Isto para além dos processos que o PgSQL irá criar por si.

Nos últimos anos, a ESRI tem vindo a incentivar o uso de outro tipo de conexões – conexões directas.

Nas conexões directas não é necessário usar o serviço ArcSDE, o  ArcGIS liga-se directamente à bd. Isto é possível porque o ArcGIS passou a incluir as dll’s do ArcSDE, e assim a memória que era ocupada no servidor passa a ser consumida no PC com o ArcGIS. O inconveniente é que estas conexões ocupam um pouco mais a rede, mas teoricamente não há impacto perceptível. Com as conexões directas apenas temos de contar com os processos do próprio PgSQL.

Naturalmente, desde que a rede não esteja congestionada, é preferível usar conexões directas. No entanto, o esquema de conexões 3-níveis permite separar o ArcSDE da bd, o que possibilita a utilização de clusters, beneficiando da distribuição de carga que este tipo de sistemas oferece.

Conexões PgSQL

O PgSQL quando inicia cria um conjunto de 6 processos em memória no servidor. Em Windows, todos estes processos se chamam “postgres.exe”. Um destes processos é o processo principal do servidor que mantém a cache de dados e outras informação que persistem entre conexões. A configuração do PgSQL influenciará principalmente este processo, que tanto pode ocupar 26MB como 500MB, ou mais.

Por cada cliente que se conecta (QGIS, gvSIG, …), o PgSQL cria mais 1 processo na memória do servidor, correspondendo a essa conexão (curiosamente, no caso do ArcGIS são sempre criados 2 processos postgres.exe). Este processo ocupará memória consoante as definições do PgSQL, dependendo fortemente do tipo de operações executadas pelo cliente. Assim, uma pesquisa simples consumirá pouca memória, mas a visualização de um layer com 120.000 registos já ocupará +200MB. O caso de maior carga que encontrei foram operações de carregamento de informação em massa ocupando 500MB de memória ou mais.

Confesso que não estou habituado a esta flutuação no consumo de memória. Ao usar Oracle, temos uma certa rigidez no consumo de memória, que orbitará em redor dos parâmetros determinados pelo gestor. Se o Oracle der sinal de necessitar de mais memória, é o gestor que tem de redefinir os parâmetros permitindo que o Oracle consuma mais memória.

No caso do PgSQL, a memória ocupada é também reflexo da configuração definida pelo gestor, mas a variação da memória ocupada é muitíssimo maior. E varia por cada utilizador que se liga, e pelas operações que irá efectuar. É um dimensionamento mais difícil de manter dentro dos limites do servidor.

Suponho que é uma questão de habituação ao processo. Durante uma fase inicial de implementação será necessário monitorizar de perto a utilização de memória no servidor, e adaptar as configurações do PgSQL. Tal e qual como se passa com outros servidores SGDB. Penso ainda regressar a este assunto, continuando esta série de artigos… até breve.

Novo fornecedor de alojamento

Espero que este seja o meu último post sobre alojamento de sites por muitos e bons anos!

Concluí a transferência do domínio viasig.com (blog e planetasig) para um novo fornecedor.  Já relatei aqui a razão que me levou a mudar da Esoterica para outro fornecedor e não desejo voltar a ter problemas deste género…

Mas acabou por ser uma experiência positiva porque acabei por ficar melhor servido. Se não vejamos as condições do novo serviço:

Preço Anual 29,40€
Espaço em disco 1 GB
Tráfego Ilimitado
Domínios 1
Subdomínios Ilimitados
PHP 4 e 5
Python 2.4.3
Tomcat/JSP ok
Ruby ok
MySQL 5.0
PostgreSQL 8.1
Tarefas Agendadas Cron
Acesso Shell JailedShell

Por um preço muito semelhante consigo mais 3 características a que não tinha acesso e que fazem uma grande diferença:

  1. Tarefas agendadas para controlar facilmente o refrescamento das entradas no Planeta SIG;
  2. Acesso Shell para perceber os problemas com os scripts do Planeta SIG (Planet Venus);
  3. e ainda… PostgreSQL!!

Na verdade o meu novo fornecedor – Lefatech – não inclui o acesso à shell de raíz neste pack. Mas bastou-me solicitar, justificando a necessidade, e o acesso foi configurado na hora. Em contraste, quando pedi à Esoterica para criar uma tarefa agendada informaram-me que teria de fazer um upgrade para um plano que custa 108€/ano!

Com este novo alojamento ainda ganho o suporte a PostgreSQL o que poderá ser útil se surgir a oportunidade de criar algum site com mapas dinâmicos. Faltará o módulo PostGIS, mas também faltava o módulo mod_python ao Apache, e foi compilado e configurado pelo suporte técnico em poucos dias. Por isso pode ser que se consiga o PostGIS se for necessário!

A transferência para o novo servidor ficou activada hoje, sem que eu notasse qualquer anomalia. Aproveitei para actualizar o WordPress para a última versão (2.8.6). Se algum leitor notar algum problema por favor avise-me usando os comentários.

A propósito, o WP ganhou o prémio de melhor CMS Open Source de 2009!

PostgreSQL e ESRI – Parte 1

A atracção do software Open Source é também sentida pelos utilizadores ESRI. Numa discussão na web li uma vez alguém descrever um utilizador de ArcGIS da seguinte maneira: “a única forma de retirar o ArcGIS das mãos de um utilizador é arrancá-lo das suas mãos mortas e frias”… a crer nisto, no lado de aplicações SIG desktop não será fácil substituir o ArcGIS por qualquer outra alternativa.

Será no entanto mais fácil explorar alternativas para os componentes que se encaixam na área dos servidores SIG, ou seja, bases de dados espaciais e servidores webGIS. Um dos produtos Open Source que tem recebido muita atenção na comunidade ESRI é o par PostgreSQL+PostGIS, que recentemente foi incluída na lista de bases de dados suportadas pela ESRI.

A partir da versão 9.3 a ESRI incluiu a possibilidade de utilizar, com toda a sua família de software ArcGIS, a base de dados PostgreSQL e o seu módulo geoespacial PostGIS, ambos Open Source. Esta possibilidade é muito atraente por vários motivos, sendo para mim os mais importantes:

  • PostgreSQL e PostGIS são produtos de grande qualidade, grande difusão, com utilizadores de referência credíveis, existindo uma comunidade muito activa ao seu redor;
  • São Open Source e gratuitos;
  • Oferecem funções de manipulação e análise geográfica de dados vectoriais através de SQL, ombreando com os melhores produtos existentes, open source ou comerciais;
  • Seguem os standards da indústria para SQL espacial (da OGC, e neste momento está em fase de implementar o standard da ISO), o que é obviamente uma abordagem irrepreensível e de enorme importância;
  • Quase a totalidade das aplicações SIG Open Source são compatíveis com esta bd;
  • O facto da ESRI incluir esta base de dados no grupo de sistemas suportados “oficialmente”, oferece uma segurança aos departamentos de TI que pode ser um factor decisivo na adopção ou não do PostgreSQL na empresa (e eu sei que este ponto gera polémica na comunidade de utilizadores e apoiantes, mas é um facto que existe esta barreira).

Porquê mudar?

Uma plataforma SIG muito comum, e aquela com que mais trabalho, é baseada em Oracle e ArcSDE, onde vários utilizadores de ArcGIS visualizam e editam a informação aí residente, havendo também servidores webGIS e aplicações que utilizam a informação residente em Oracle/ArcSDE. Neste artigo vou frequentemente referir esta arquitectura como ponto de comparação.

Quando já existe, trocar de base de dados não é tarefa fácil, consoante o volume e complexidade da informação existente, da dependência das aplicações desenvolvidas, e das novas competências que será necessário adquirir. Mas, há um  momento fulcral na vida de uma base de dados durante o qual vale tudo: a migração de servidor e upgrade de versão!

Nesta situação, a vantagem de migrar para PostgreSQL/PostGIS é passar a contar com um grande conjunto de aplicações SIG Open Source que podem usar a base de dados sem passar pelo ArcSDE – ou seja, podemos usar software não-ESRI e software ESRI para ler e manter a base de dados geográfica, efectivamente criando um sistema híbrido. (NOTA: uso aqui a expressão “SIG Híbrido” no sentido de integrar componentes comerciais e componentes Open Source num sistema de forma a usufruir das vantagens de cada componente, com as dificuldades inerentes, tal como Dan Dale Lutz tão bem explicou aqui.)

Note-se que esta interoperabilidade já é possível em alguma medida, especialmente com Oracle, desde que os dados sejam armazenados em Oracle Spatial ou Locator (sempre incluído em todas as versões Oracle). Só que neste caso existem muito menos aplicações SIG que lêem este tipo de dados, algumas Open Source. Mas em geral, as opções Open Source têm uma compatibilidade pouco fiável e de instalação nem sempre fácil. Por outro lado, tenho encontrado sistematicamente um desempenho muito inferior ao usar ArcGIS com dados Oracle Spatial quando comparado com o modo tradicional do ArcSDE armazenar dados em Oracle (denominado SDEBINARY). Mais sobre estas opções adiante…

Um sistema híbrido porquê?

O cenário de adoptar o PostgreSQL num SIG baseado em ESRI (ou Autodesk) implica que se pode manter todo o restante ecossistema SIG – ferramentas desktop, servidores webGIS, e aplicações desenvolvidas, bem como o nível de produtividade actual da equipa de edição/análise (que tipicamente é atingido após anos de experiência da equipa técnica com estas ferramentas). E ainda se abrem as portas para alargar o ecossistema a ferramentas  Open Source e de outros vendedores.

No caso da ESRI, todo o seu software comunica com o ArcSDE para chegar aos dados, e não directamente com a base de dados. Por isso a troca por outra bd não tem qualquer impacto sobre a restante plataforma SIG. E isto é uma vantagem. Claro que a desvantagem é o preço do ArcSDE…

No caso em que o ArcSDE já existe, podemos alegremente ignorar este custo (embora o custo de manutenção anual continue a existir)!! Em situações onde não exista ArcSDE deve-se incluir o seu custo de aquisição na análise das alternativas disponíveis.

A vantagem do SQL espacial

Um dos grandes trunfos de usar uma bd que, como o PostgreSQL+PostGIS, oferece funções de manipulação e análise espacial por SQL é podermos usar comandos na própria bd que vão efectuar as análises que estamos habituados a fazer apenas com as nossas ferramentas SIG desktop favoritas.  (Aliás, para ser exacto, o ArcSDE desde a v9.3 adiciona sempre o seu próprio dialecto de SQL espacial à bd onde é instalado, que pode ser usado como alternativa ao SQL nativo da bd. Isto também se aplica ao PostgreSQL. O administrador da bd é que decide se usa o dialecto da ESRI ou o dialecto nativo da bd.)

Por exemplo, com SQL espacial é possível seleccionar as classes de solo intersectadas pelo novo traçado do IP2, recorrendo apenas ao PostgreSQL, e sem usar ArcView. E como a máquina onde se instalam bases de dados é tipicamente muito mais potente que o nosso posto de trabalho, a velocidade de processamento destas análises será também superior. Já para não falar de evitar a transmissão de dados na rede entre a bd e o posto de trabalho. Apenas os resultados são transmitidos à aplicação SIG para visualização.

Então porque é que não estamos todos a usar SQL espacial para fazer análise geográfica?

Porque ainda é preciso que o utilizador saiba escrever estes comandos SQL! E isto não é uma tarefa trivial. Notem que escrevi “ainda é preciso saber…” sendo a palavra chave “ainda“. Isto porque hoje todas as bases de dados comerciais têm suporte a SQL espacial – Oracle, SQL Server, DB2, Informix – umas há mais tempo que outras, umas com SQL mais padronizado que outras, mas a funcionalidade está lá. O que falta são as aplicações que sabem executar essa análise nessas bd’s, facilitando a vida ao utilizador com botões e menus amigáveis, e dispensando assim o conhecimento de SQL espacial!

Por exemplo, quando o ArcView calcula um buffer não utiliza as capacidades da bd de cálculo de buffers, mesmo que elas existam. Apenas lê os dados armazenados na bd, e usa o nosso posto de trabalho para fazer o cálculo. E a esmagadora maioria das aplicações SIG actuais fazem o mesmo, quer comerciais quer Open Source.

Mas parece-me inevitável que ao longo dos próximos anos assistamos à mudança deste paradigma. Até porque desde que a Microsoft incluiu SQL espacial no SQL Server 2008 há toda uma nova geração de programadores que “acordou” para as capacidades do SQL espacial.

Quando uma aplicação SIG com peso no mercado conseguir fazer uma análise 10x mais rapidamente que os seus concorrentes (porque recorre às capacidades do servidor de base de dados) o que acham que vai acontecer?

Opções para utilizadores ESRI

Então que opções existem para os utilizadores ESRI que querem utilizar PostgreSQL+PostGIS?

ArcSDE

A opção standard do ponto de vista da ESRI é, claro, instalar o ArcSDE. Na versão 9.3 existe um setup de instalação que até instala o PostgreSQL e o PostGIS de uma forma muito automatizada. Pode-se encontrar alguns tutoriais de instalação, como este do Adriano Hantequeste: ArcSDE [Passo 1] Instalando o PostgreSQL. Há que ter atenção, no entanto, aos passos opcionais de instalar o PostGIS manualmente, para podermos no fim optar pelas suas capacidades nativas. (No manual de instalação do ArcSDE está tudo bem explicado.)

Mas há mais para além da instalação do ArcSDE. Podemos configurar a forma como o ArcSDE armazena os dados vectoriais no PostGIS. Existem 2 opções:

  • formato proprietário ESRI (ST_GEOMETRY)
  • formato nativo PostGIS (PG_GEOMETRY)

Estas opções definem o formato como as geometrias dos nossos vectores são armazenados na bd. Para o utilizador de ArcGIS é invisível se optamos por uma ou outra, mas há consequências importantes.

O formato ESRI guarda as geometrias no PostgreSQL de forma a que apenas se podem ler ou alterar usando software compatível (leia-se ESRI). Ou seja, o Quantum GIS para ler estes dados terá de usar um plugin ArcSDE (para ser exacto, o plugin é instalado no OGR que por sua vez é usado através do QGIS).

Por sua vez, o formato PostGIS guarda as geometrias usando as capacidades do PostGIS, e isso significa que todo o software compatível com PostGIS as pode ler e alterar. Ou seja, podemos carregar dados na bd usando o ArcCatalog (que passa pelo ArcSDE), e depois usar o QGIS para ler esses dados, sem passar pelo ArcSDE e sem plugins. Confuso? Espero que não… em última análise, esta opção permite ter na empresa aplicações gratuitas como o QGIS a usufruirem da bd central, a fazer impressões, análises, confrontações, etc. sem duplicação de dados ou conversões desconfortáveis.

Como se configura esta opção do formato de armazenamento das geometrias?

Sem querer entrar em grandes detalhes, pode-se dizer que é muito simples. Basta executar um comando que altera uma linha na tabela de configuração do ArcSDE. O comando é o seguinte:

sdedbtune -o alter -i 5151 -k DEFAULTS -P GEOMETRY_STORAGE -v “PG_GEOMETRY” -s <server_name> -D postgis -u sde -p <ArcSDE_admin_password>

Esta opção tem outras configurações e particularidades que terão de ficar para outra oportunidade.

zigGis

zigGIS é uma extensão para ArcGIS que permite ler e escrever em PostGIS, sem usar ArcSDE. É um produto que começou como Open Source, e que evoluiu para uma solução comercial. Embora a fonte do programa esteja disponível, é exigida a compra de licenças na maioria das situações (excepto para uso pessoal e académico que continuam isentos de pagamento – ver licença aqui).

Ora o preço é de apenas US $279! por posto de trabalho. É naturalmente muito apetecível. O cenário em vista é conseguir um SIG, com base de dados geográficos e aplicação desktop de topo, apenas pelo preço de ArcView + $279.  Será que há algum truque, uma armadilha? Parece que não, a ver pelo excelente exemplo da implementação na Câmara Municipal de Albufeira, é uma opção extremamente flexível.

O papel do ArcSDE

Claro que surge a questão óbvia: então para que serve o ArcSDE? Bom, esta questão é debatida há muitos anos, bem antes de existir o zigGIS, e posso apenas manifestar a minha opinião – o ArcSDE é o pivot de dados que serve toda a plataforma ArcGIS – desde o modelo de dados, ao servidor webGIS, às aplicações desktop. Sem o ArcSDE, as várias peças do ArcGIS “descolam”, e temos de recorrer a ficheiros para partilhar informação entre as componentes do sistema. Por outro lado, o ArcSDE permite à ESRI implementar funções para além dos standards. Em geral, os standards na área SIG e SQL são desenvolvidos mais lentamente que as aplicações desenvolvidas pelos maiores fabricantes. Por exemplo, antes de existir WMS já existiam servidores webGIS. Antes de existir standard de SQL espacial, já existiam bases de dados geográficos. Com o ArcSDE a ESRI implementa um modelo de dados com funcionalidade que não está padronizada pela indústria: rasters, terrains (para LIDAR), topologia com regras de validação automática, gestão de versões, gestão de histórico, bd’s distribuídas, sincronização de bd’s… bom, não é o meu papel “defender” o ArcSDE, mas encontro valor acrescentado no produto. Para os casos que não necessitam desta integração ou destas funções, fará menos sentido a sua aquisição. Para os outros casos…

Conclusão

Já vai longo este artigo… contra todas as regras de bom comportamento em blogs :)

Nos próximos tempos penso continuar este tema com mais alguns artigos, olhando com mais detalhe para a combinação PostgreSQL+PostGIS<->ArcSDE<->ArcGIS.

Para já, é certo que podemos contar com a possibilidade de criar sistemas híbridos com software ESRI e componentes Open Source, usando o melhor dos 2 mundos. E isso é um passo de gigante  que demorou décadas a chegar ao ArcGIS, mas finalmente aí está.