2007-12-22
Bom Natal
Não tenho tido muito tempo para adicionar conteúdo a este blog, de qualquer forma aqui ficam os votos de Bom Natal para todos.
2007-11-30
O Software e a globalização
Vivemos num mundo cada vez mais "globalizado", onde há cada vez mais contacto entre diferentes culturas e povos, onde as fronteiras físicas têm cada vez menos importância (pelo menos nalgumas zonas do globo).
Algumas pessoas, quiçá descendentes do famoso "Velho do Restelo" tão bem retratado n' Os Lusíadas, afirmam aos quatro ventos que se está a perder a nossa cultura, que se importam demasiados hábitos do estrangeiro em especial dos países anglófonos, que qualquer dia já ninguém fala português, etc e tal...
Aqui há dias vi num fórum um "argumento" comercial para a não existência de software em português... ao autor do post recomendo passar pelo site do projecto Debian e pelo site da Comunidade Portuguesa de Debian para ver como se pode ter software de qualidade, em português (e, já agora, na língua que se queira) e a baixo custo...
Algumas pessoas, quiçá descendentes do famoso "Velho do Restelo" tão bem retratado n' Os Lusíadas, afirmam aos quatro ventos que se está a perder a nossa cultura, que se importam demasiados hábitos do estrangeiro em especial dos países anglófonos, que qualquer dia já ninguém fala português, etc e tal...
Aqui há dias vi num fórum um "argumento" comercial para a não existência de software em português... ao autor do post recomendo passar pelo site do projecto Debian e pelo site da Comunidade Portuguesa de Debian para ver como se pode ter software de qualidade, em português (e, já agora, na língua que se queira) e a baixo custo...
Powered by ScribeFire.
2007-11-13
Partições de Dados
As Bases de Dados são, essencialmente, repositórios de informação. Com o passar do tempo, a quantidade de dados a gerir aumenta,assim como a difculdade em geri-los bem.
Para ajudar os DBAs nesta tarefa surgiu o conceito de partição da Base de Dados.
Uma partição, numa Base de Dados, serve três propósitos: facilidade de gestão dos dados, disponibilidade, performance. Dos diversos sistemas de gestão de bases de dados disponíveis no mercado, existem alguns que implementam este conceito, nomeadamente os comerciais IBM DB2, Oracle, MS SQL Server 2005 e os livres MySQL 5.2 e PostgreSQL 8.
Os benefícios de particionar os dados revelam-se quando temos um grande conjunto de dados e facilmente encontramos um parâmetro que define um sub-conjunto desses dados, distinto dos restantes, o qual nos é útil para fazermos as nossas consultas. Um exemplo comum são dados históricos, e.g., dados de anos anteriores que são menos consultados, ou então dados referentes a áreas geográficas diversas.
Com as potencialidades dos SGBD aqui apresentados, torna-se relativamente simples implementar um esquema de "rotação" dos dados, que coloque os mais antigos e menos usados em partições diferentes.
Vamos supor que temos um sistema de facturação no qual vamos guardando os movimentos diários. Ao fim de um certo tempo, temos um conjunto de dados que já não é actual mas que ainda tem valor histórico. Se, em vez de guardar tudo numa tabela, criarmos uma tabela particionada em função do tempo, podemos ir movendo os dados mais antigos para as partições correspondentes e evitamos que interfiram com a operação diária da Base de Dados.
Para ajudar os DBAs nesta tarefa surgiu o conceito de partição da Base de Dados.
Uma partição, numa Base de Dados, serve três propósitos: facilidade de gestão dos dados, disponibilidade, performance. Dos diversos sistemas de gestão de bases de dados disponíveis no mercado, existem alguns que implementam este conceito, nomeadamente os comerciais IBM DB2, Oracle, MS SQL Server 2005 e os livres MySQL 5.2 e PostgreSQL 8.
Os benefícios de particionar os dados revelam-se quando temos um grande conjunto de dados e facilmente encontramos um parâmetro que define um sub-conjunto desses dados, distinto dos restantes, o qual nos é útil para fazermos as nossas consultas. Um exemplo comum são dados históricos, e.g., dados de anos anteriores que são menos consultados, ou então dados referentes a áreas geográficas diversas.
Com as potencialidades dos SGBD aqui apresentados, torna-se relativamente simples implementar um esquema de "rotação" dos dados, que coloque os mais antigos e menos usados em partições diferentes.
Vamos supor que temos um sistema de facturação no qual vamos guardando os movimentos diários. Ao fim de um certo tempo, temos um conjunto de dados que já não é actual mas que ainda tem valor histórico. Se, em vez de guardar tudo numa tabela, criarmos uma tabela particionada em função do tempo, podemos ir movendo os dados mais antigos para as partições correspondentes e evitamos que interfiram com a operação diária da Base de Dados.
2007-11-07
Quero ser programador quando for grande...
... mas não um programador qualquer !
Quero fazer como vi hoje: Por um trabalho que consistiu em acrescentar um botão a um formulário, num programa já muito desenvolvido, um programador teve a coragem de apresentar uma factura de 7 horas de trabalho !!
O complicadíssimo evento despoletado por esse botão, que deve concerteza justificar tal quantidade de horas despendidas com este "projecto", é o seguinte, em todo o seu detalhe:
E pronto... 7 horas de "sangue, suor e lágrimas" despendidas por um afincado programador, com a respectiva compensação...
Ah... ainda bem que não foi este programador que desenvolveu o resto do programa... o cliente era capaz de pedir a reforma à espera do resultado final...
Quero fazer como vi hoje: Por um trabalho que consistiu em acrescentar um botão a um formulário, num programa já muito desenvolvido, um programador teve a coragem de apresentar uma factura de 7 horas de trabalho !!
O complicadíssimo evento despoletado por esse botão, que deve concerteza justificar tal quantidade de horas despendidas com este "projecto", é o seguinte, em todo o seu detalhe:
- Ligar-se a uma Base de Dados ;
- "SELECT * FROM tabela" ;
- Preenche uma grelha (controlo já existente previamente no tal programa) com os dados recolhidos ;
- "DELETE FROM tabela" ;
- Desligar da Base de Dados ;
E pronto... 7 horas de "sangue, suor e lágrimas" despendidas por um afincado programador, com a respectiva compensação...
Ah... ainda bem que não foi este programador que desenvolveu o resto do programa... o cliente era capaz de pedir a reforma à espera do resultado final...
2007-11-01
Propriedade Intelectual
Como não sou advogado, nem nunca tive formação em Direito, resta-me apenas dizer o que penso (pela chamada lógica do senso-comum) sobre este tema:
Propriedade Intelectual engloba Copyright, Patentes, Marcas e agora parece que também querem por os sistemas de DRM no saco.
O Copyright, que devia proteger os autores de obras artísticas (ou equivalentes, tais como livros, música, programas de software) é neste momento uma exelente fonte de rendimento para os intermediários dessas mesmas obras (editoras de música, distribuidoras de filmes...). Portanto, devia ser profundamente revista toda esta legislação para defender quem precisa e deixar de proteger quem abusa. Para cúmulo desta situação, podem comprar e vender-se os "direitos de autor" de tal modo que muitas vezes (senão todas) o verdadeiro autor da obra nunca tirará benefícios da sua obra, protegida pela "legislação de direitos de autor". Numa palavra: ridículo.
As patentes destinavam-se, originalmente, a proteger produtos inovadores de possíveis cópias, por um tempo pré-determinado. Aplicar este conceito a programas de computador (software) é como patentear ideias: por exemplo, se eu tivesse a ideia para criar um chapéu, e patenteasse essa ideia, mas ninguém poderia fazer chapéus sob que forma fosse. Além de ridícula, esta situação estagna o desenvolvimento, pois ao patentear ideias proíbe-se de facto o uso dessas ideias por alguém que não seja o dono da patente, ou quem a licencie. Quem ganha com esta situação ? As grandes empresas que podem assim impedir a criação de produtos concorrentes, fortalecendo os seus monopólios. A legislação das patentes é de tal modo absurda que existem empresas nos Estados Unidos (onde o absurdo é maior) cuja actividade se resume a comprar e vender patentes... Mais uma vez: as patentes deviam aplicar-se apenas a "Produtos físicos" e nunca a ideias. Numa palavra: ridículo.
O registo de marcas parece ser a área de propriedade intelectual onde há menos polémica. Penso que seja porque os proprietários das marcas não gostam de má publicidade...
O DRM: O maior absurdo inventado para tentar ganhar dinheiro. Parece que os defensores dos sistemas de DRM (nomeadamente as editoras e distribuidoras de grandes dimensões) já não conseguem atrair mais talentos para as respectivas carteiras de artistas, portanto inventaram um esquema onde acham que podem dizer a quem lhes paga o salário e lhes fornece os lucros o que podem ouvir ou ver, quando o podem fazer, onde o podem fazer e, se quiserem, revogar esse "direito" que o consumidor tem de usufruir daquilo que pagou. Enfim, ou está tudo doido ou perto disso. Se se aplicasse um sistema de DRM aos livros e jornais poderíamos ter uma cena do tipo:
Cliente: Quero levar este livro.
Livreiro: Com certeza, mas só o pode ler ao deitar, entre as 23h e 23h30m, iluminado por uma lâmpada da marca X. Se não seguir estas instruções é-lhe retirado o livro.
Cliente: Mas eu queria leva-lo para as férias....
Livreiro: Para isso tem que adquirir outro exemplar, que poderá ler no carro ou na sua casa de férias, mas terá que o manter fechado fora dessas localizações...
Numa palavra: Ridículo.
Não revejam esta legislação e depois digam que eu não avisei... qualquer dia o pessoal chateia-se a sério...
Fiquem bem...
Propriedade Intelectual engloba Copyright, Patentes, Marcas e agora parece que também querem por os sistemas de DRM no saco.
O Copyright, que devia proteger os autores de obras artísticas (ou equivalentes, tais como livros, música, programas de software) é neste momento uma exelente fonte de rendimento para os intermediários dessas mesmas obras (editoras de música, distribuidoras de filmes...). Portanto, devia ser profundamente revista toda esta legislação para defender quem precisa e deixar de proteger quem abusa. Para cúmulo desta situação, podem comprar e vender-se os "direitos de autor" de tal modo que muitas vezes (senão todas) o verdadeiro autor da obra nunca tirará benefícios da sua obra, protegida pela "legislação de direitos de autor". Numa palavra: ridículo.
As patentes destinavam-se, originalmente, a proteger produtos inovadores de possíveis cópias, por um tempo pré-determinado. Aplicar este conceito a programas de computador (software) é como patentear ideias: por exemplo, se eu tivesse a ideia para criar um chapéu, e patenteasse essa ideia, mas ninguém poderia fazer chapéus sob que forma fosse. Além de ridícula, esta situação estagna o desenvolvimento, pois ao patentear ideias proíbe-se de facto o uso dessas ideias por alguém que não seja o dono da patente, ou quem a licencie. Quem ganha com esta situação ? As grandes empresas que podem assim impedir a criação de produtos concorrentes, fortalecendo os seus monopólios. A legislação das patentes é de tal modo absurda que existem empresas nos Estados Unidos (onde o absurdo é maior) cuja actividade se resume a comprar e vender patentes... Mais uma vez: as patentes deviam aplicar-se apenas a "Produtos físicos" e nunca a ideias. Numa palavra: ridículo.
O registo de marcas parece ser a área de propriedade intelectual onde há menos polémica. Penso que seja porque os proprietários das marcas não gostam de má publicidade...
O DRM: O maior absurdo inventado para tentar ganhar dinheiro. Parece que os defensores dos sistemas de DRM (nomeadamente as editoras e distribuidoras de grandes dimensões) já não conseguem atrair mais talentos para as respectivas carteiras de artistas, portanto inventaram um esquema onde acham que podem dizer a quem lhes paga o salário e lhes fornece os lucros o que podem ouvir ou ver, quando o podem fazer, onde o podem fazer e, se quiserem, revogar esse "direito" que o consumidor tem de usufruir daquilo que pagou. Enfim, ou está tudo doido ou perto disso. Se se aplicasse um sistema de DRM aos livros e jornais poderíamos ter uma cena do tipo:
Cliente: Quero levar este livro.
Livreiro: Com certeza, mas só o pode ler ao deitar, entre as 23h e 23h30m, iluminado por uma lâmpada da marca X. Se não seguir estas instruções é-lhe retirado o livro.
Cliente: Mas eu queria leva-lo para as férias....
Livreiro: Para isso tem que adquirir outro exemplar, que poderá ler no carro ou na sua casa de férias, mas terá que o manter fechado fora dessas localizações...
Numa palavra: Ridículo.
Não revejam esta legislação e depois digam que eu não avisei... qualquer dia o pessoal chateia-se a sério...
Fiquem bem...
2007-10-30
OpenSolaris Starter Kit
Acabei de encomendar o OpenSolaris Starter Kit (2 DVDs).
Quem quiser pode seguir este link para pedir também este conjunto. No kit vem incluido o OpenSolaris Express e alguns LiveCDs com distribuições criadas pela comunidade.
Daqui a algum tempo veremos que tal é na prática :)
Até breve !
Quem quiser pode seguir este link para pedir também este conjunto. No kit vem incluido o OpenSolaris Express e alguns LiveCDs com distribuições criadas pela comunidade.
Daqui a algum tempo veremos que tal é na prática :)
Até breve !
2007-10-28
Mudança da Hora
Cumpriu-se esta madrugada (dia 28 de Outubro de 2007) mais uma vez, um dos mais inúteis rituais da nossa sociedade: A Mudança da Hora !
Para que serve tal descalabro ? Para acordarmos no Domingo, meio atarantados com os horários, correr a casa a alterar a hora dos 527 relógios (incluindo relógios de equipamentos como o leitor de DVD, e afins...), verificar se os nossos computadores sabem a quantas andamos, etc e tal... só para em Março do ano seguinte repetirmos tudo isto, de modo inverso !
A mudança da hora é uma característica da nossa "Hora Legal" que eu sinceramente não percebo como ainda está em vigor. A motivação económica que presidiu à criação deste mecanismo de alteração da Hora de Inverno e da Hora de Verão, embora pudesse ter tido valor no início, já não se justifica. Alguns estudos apontam mesmo algum aumento de consumo de energia devido aos aparelhos de refrigeração (ver artigo sobre o tema em http://en.wikipedia.org/wiki/Daylight_saving_time).
Um efeito cada vez mais perturbador desta mudança é a complexidade aumentada em Sistemas de Informação e software, especialmente se lidam com vários fusos horários que, potencialmente, têm diversos limites das Horas de Verão e Inverno. À medida que aumenta a nossa dependência destes sistemas maiores riscos corremos de haver um erro ou condição que perturbe o funcionamento dos ditos sistemas, causando perdas de dados e, consequentemente, acarretando custos para a sociedade. No artigo da Wikipédia refere-se um custo de 500 a 1000 milhões de dólares para a alteração das regras de mudança de hora em 2007.
Para terminar, respondam a uma das perguntas:
- Onde estava às 01:35 de 28 de Outubro de 2007 ;
- o que estava a fazer às 02:20 de 25 de Março de 2007.
Quem conseguir responder correctamente, merece um prémio !
Para que serve tal descalabro ? Para acordarmos no Domingo, meio atarantados com os horários, correr a casa a alterar a hora dos 527 relógios (incluindo relógios de equipamentos como o leitor de DVD, e afins...), verificar se os nossos computadores sabem a quantas andamos, etc e tal... só para em Março do ano seguinte repetirmos tudo isto, de modo inverso !
A mudança da hora é uma característica da nossa "Hora Legal" que eu sinceramente não percebo como ainda está em vigor. A motivação económica que presidiu à criação deste mecanismo de alteração da Hora de Inverno e da Hora de Verão, embora pudesse ter tido valor no início, já não se justifica. Alguns estudos apontam mesmo algum aumento de consumo de energia devido aos aparelhos de refrigeração (ver artigo sobre o tema em http://en.wikipedia.org/wiki/Daylight_saving_time).
Um efeito cada vez mais perturbador desta mudança é a complexidade aumentada em Sistemas de Informação e software, especialmente se lidam com vários fusos horários que, potencialmente, têm diversos limites das Horas de Verão e Inverno. À medida que aumenta a nossa dependência destes sistemas maiores riscos corremos de haver um erro ou condição que perturbe o funcionamento dos ditos sistemas, causando perdas de dados e, consequentemente, acarretando custos para a sociedade. No artigo da Wikipédia refere-se um custo de 500 a 1000 milhões de dólares para a alteração das regras de mudança de hora em 2007.
Para terminar, respondam a uma das perguntas:
- Onde estava às 01:35 de 28 de Outubro de 2007 ;
- o que estava a fazer às 02:20 de 25 de Março de 2007.
Quem conseguir responder correctamente, merece um prémio !
2007-10-27
Genealogias
No artigo da Wikipédia, http://en.wikipedia.org/wiki/Linux_distribution sobre distribuições de linus, podemos ver
uma imagem que representa a "genealogia" das distribuições Linux, desde 1992 até 2007. Uma vista rápida permite-nos
concluir que hoje o "mundo" linux está dividido em três famílias, com origem em três distribuições distintas: As
distribuições Debian e Slackware, de 1993 e a RedHat, de 1994.
Hoje em dia temos as famílias de cada uma representadas por (não contam mudanças de nome das distribuições):
De entre as diversas distribuições que não são parte de nenhuma família ou têm uma família muito reduzida, temos a
SLS de 1992, entretando desaparecida e percursora da Slackware, a DLD de 1993 entretanto integrada na família RedHat
e mais cerca de 30 distribuições, das quais metade já desapareceram.
Das distribuições portuguesas apenas aparece a Caixa Mágica, descendente do SuSE.
uma imagem que representa a "genealogia" das distribuições Linux, desde 1992 até 2007. Uma vista rápida permite-nos
concluir que hoje o "mundo" linux está dividido em três famílias, com origem em três distribuições distintas: As
distribuições Debian e Slackware, de 1993 e a RedHat, de 1994.
Hoje em dia temos as famílias de cada uma representadas por (não contam mudanças de nome das distribuições):
- RedHat - 53 distribuições, das quais 39 ainda activas
- Debian - 41 distribuições, das quais 35 ainda activas
- Slackware - 26 distribuições, das quais 23 ainda activas
De entre as diversas distribuições que não são parte de nenhuma família ou têm uma família muito reduzida, temos a
SLS de 1992, entretando desaparecida e percursora da Slackware, a DLD de 1993 entretanto integrada na família RedHat
e mais cerca de 30 distribuições, das quais metade já desapareceram.
Das distribuições portuguesas apenas aparece a Caixa Mágica, descendente do SuSE.
Optimizações
Ao fazer a análise a uma Base de Dados para resolver problemas de performance ou optimizar as queries que são realizadas, começamos, normalmente, por verificar quais as queries mais lentas, que levam mais tempo a executar, de modo a actuar nessas queries.
Ora, além do tempo de execução das queries, temos também que analizar a "big picture", isto é, a actividade geral do sistema e o número de vezes que cada uma dessas queries é executada num determindao período de tempo.
Vamos a um exemplo concreto:
- Um sistema que analisei tinha problemas de performance (tempo de resposta) na Base de Dados. Após obter uma lista das queries que estavam a demorar mais de 10 segundos a executar, verifiquei que havia algumas que demoravam mesmo mais de 60 segundos em tempo de execução.
- Ao verificar o número de vezes que cada query corria no período em análise,foi fácil verificar que era mais preocupante uma query que estava a demorar entre 10 e 20 segundos que as que demoravam mais tempo, e isto porque essa query era executada cerca de 30 vezes mais que a que demorava 60 segundos !!
- Após algumas mudanças no sistema, que dispensaram 99% das execuções dessa dita query, o número de queries que ultrapassaram os 10 segundos de execução caiu para menos de um quinto, no mesmo período da análise anterior !!
Conclusões:
- Muitas vezes ganha-se mais em actuar numa query relativamente "normal" que é executada muitas vezes que procurar optimizar logo uma queriy muito longa;
- Ao optimizar um sistema, neste caso uma Base de Dados, a solução pode estar "fora" da Base de Dados, ou seja, podemos actuar noutro ponto do sistema e obter ganhos de performance na Base de Dados;
Até breve !
Ora, além do tempo de execução das queries, temos também que analizar a "big picture", isto é, a actividade geral do sistema e o número de vezes que cada uma dessas queries é executada num determindao período de tempo.
Vamos a um exemplo concreto:
- Um sistema que analisei tinha problemas de performance (tempo de resposta) na Base de Dados. Após obter uma lista das queries que estavam a demorar mais de 10 segundos a executar, verifiquei que havia algumas que demoravam mesmo mais de 60 segundos em tempo de execução.
- Ao verificar o número de vezes que cada query corria no período em análise,foi fácil verificar que era mais preocupante uma query que estava a demorar entre 10 e 20 segundos que as que demoravam mais tempo, e isto porque essa query era executada cerca de 30 vezes mais que a que demorava 60 segundos !!
- Após algumas mudanças no sistema, que dispensaram 99% das execuções dessa dita query, o número de queries que ultrapassaram os 10 segundos de execução caiu para menos de um quinto, no mesmo período da análise anterior !!
Conclusões:
- Muitas vezes ganha-se mais em actuar numa query relativamente "normal" que é executada muitas vezes que procurar optimizar logo uma queriy muito longa;
- Ao optimizar um sistema, neste caso uma Base de Dados, a solução pode estar "fora" da Base de Dados, ou seja, podemos actuar noutro ponto do sistema e obter ganhos de performance na Base de Dados;
Até breve !
2007-10-24
Versatilidade
Ao ver o site com a lista dos 500 mais poderosos computadores do mundo, reparei que o sistema operativo mais usado nessas "maquinetas" é o Linux, com 398/500 (78%), o que faz do Linux um sistema no mínimo versátil, pois tanto equipa sistemas com processadores "embedded", tipo telemóveis e afins, como é usado pelo BlueGene/L de 131000 processadores que detém o recorde de computador mais rápido do mundo !!
As Gordas
Um projecto recente que merece uma visita: http://letrasgordas.ignitiva.com/ é um espaço onde se podem passar os olhos pelas "Gordas" da net, ou seja, uma espécie de RSS reader no browser, com a particularidade de ser configurável (não necessita de registo) e podermos escolher de uma lista de fontes a acompanhar. Para já as fontes constam de uma lista fixa, mas pode ser que mude.
Fica a imagem, para aguçar o apetite :
Até breve
Fica a imagem, para aguçar o apetite :
Até breve
2007-10-23
Mudanças no blog
Hoje reparei que as visitas passaram a marca psicológica do milhar... obrigado a todos.
Resolvi incluir anúncios do Google neste blog. Espero que não sejam demasiado intrusivos...
Resolvi incluir anúncios do Google neste blog. Espero que não sejam demasiado intrusivos...
2007-10-20
As Maiores Bases de Dados
Tenho andado às voltas na net à procura de dados sobre bases de dados, isto é, informações, o mais fiáveis possível, sobre as dimensões e características das maiores bases de dados em utilização.
O melhor estudo que consegui encontrar foi um realizado em 2005 pela empresa Winter Corp, disponível em www.wintercorp.com/VLDB/2005_TopTen_Survey/TopTenwinners.asp.
Este estudo resulta de um inquérito feito a diversas empresas e entidades em todo o mundo e reflecte as informações de bases de dados em uso real. Claro que só respondeu quem quis, portanto pode não representar fielmente a realidade. Se alguém souber de um melhor e/ou mais actual, agradeço a comunicação.
Analisando as informações disponíveis, podemos tirar algumas conclusões interessantes:
As maiores BD são dedicadas a Data Warehousing, ou seja a sistemas de suporte à decisão. Neste estudo a maior BD para Data Warehousing chega-se aos 100 TiB (98 TiB) enquanto que a maior Base de Dados em OLTP atinge "apenas" 22,5 TiB (cerca de 4,5 vezes menos). Existem outras Bases de Dados que não se encaixam nestas categorias e que estão normalmente ligadas a projectos científicos, tal como a BD do Instituto Meteorológico de MaxPlanck com mais de 200 TiB de Dados e a do Stanford Linear Accelerator Center, da Universidade de Stanford, que conta já com mais de 800 TiB de dados, de acordo com esta informação. De notar que este último valor é recente e não está incluído no estudo da WinterCorp.
Analizando por plataforma, em Data Warehousing, (divididas entre Linux, Unix e Windows), vemos que as maiores Bases de Dados estão em sistemas Unix com cerca de 370 TiB nos dez maiores, depois temos os sistemas Windows com cerca de 75 TiB e por fim o Linux com pouco mais de 60 TiB (embora neste caso apenas tenham respondido 8 entidades). Em OLTP temos uma predominância de sistemas mainframe clássicos (especialmente IBM z/OS), Unix e alguns Windows. O Linux não faz parte dos dez maiores nesta categoria. Nas bases de dados de outras categorias, aparecem apenas 5 entidades, com um total de 253 TiB, distribuidos entre Linux, Unix e NonStop OS.
Se considerarmos os dados na sua forma normalizada (descomprimidos, sem índices, etc...) o cenário altera-se um pouco, já que os 100 TiB do Yahoo! se transformam em cerca 17 TiB depois da normalização e os 92 TiB da AT&T "incham" até aos 320 TiB !!
Em número de registos (Row Number), as maiores tabelas pertencem à operadora de telecomunicações americana Sprint, com mais de 2,5 triliões, seguida pela AT&T com 1,8 triliões, na categoria de Data Warehousing. Em OLTP, a maior fica-se pelos 89 milhões de linhas.
Finalmente, avaliando a posição dos fabricantes de Bases de Dados, temos na categoria de Data Warehousing a Oracle "ocupa" 164 TiB dos 370 TiB das dez maiores, seguida pela AT&T (com um produto desenvolvido "in-house") com 117 TiB e pela IBM (DB2 em Unix) com 67 TiB. Nesta categoria o SQL Server da Microsoft "vale" 19 TiB e o da Sybase 17 TiB. Na categoria de OLTP temos mais equilíbrio entre os vários vendedores, com 34 TiB para a Oracle, seguida pela IBM (DB2 em z/OS) com 32 TiB e Microsoft com 21 TiB. Na categoria de "outras" a Oracle domina com 252 TiB, seguida pela HP com uma instalação no límite mínimo para o estudo (1 TiB).
Por último, é de notar a ausência de Bancos e outras instituições financeiras, que são conhecidas portambém terem algumas das maiores Bases de Dados do mundo. Outra ausência de nota é a de aplicações Open-Source. Talvez um próximo estudo revele algumas alterações a este panorama...
O melhor estudo que consegui encontrar foi um realizado em 2005 pela empresa Winter Corp, disponível em www.wintercorp.com/VLDB/2005_TopTen_Survey/TopTenwinners.asp.
Este estudo resulta de um inquérito feito a diversas empresas e entidades em todo o mundo e reflecte as informações de bases de dados em uso real. Claro que só respondeu quem quis, portanto pode não representar fielmente a realidade. Se alguém souber de um melhor e/ou mais actual, agradeço a comunicação.
Analisando as informações disponíveis, podemos tirar algumas conclusões interessantes:
As maiores BD são dedicadas a Data Warehousing, ou seja a sistemas de suporte à decisão. Neste estudo a maior BD para Data Warehousing chega-se aos 100 TiB (98 TiB) enquanto que a maior Base de Dados em OLTP atinge "apenas" 22,5 TiB (cerca de 4,5 vezes menos). Existem outras Bases de Dados que não se encaixam nestas categorias e que estão normalmente ligadas a projectos científicos, tal como a BD do Instituto Meteorológico de MaxPlanck com mais de 200 TiB de Dados e a do Stanford Linear Accelerator Center, da Universidade de Stanford, que conta já com mais de 800 TiB de dados, de acordo com esta informação. De notar que este último valor é recente e não está incluído no estudo da WinterCorp.
Analizando por plataforma, em Data Warehousing, (divididas entre Linux, Unix e Windows), vemos que as maiores Bases de Dados estão em sistemas Unix com cerca de 370 TiB nos dez maiores, depois temos os sistemas Windows com cerca de 75 TiB e por fim o Linux com pouco mais de 60 TiB (embora neste caso apenas tenham respondido 8 entidades). Em OLTP temos uma predominância de sistemas mainframe clássicos (especialmente IBM z/OS), Unix e alguns Windows. O Linux não faz parte dos dez maiores nesta categoria. Nas bases de dados de outras categorias, aparecem apenas 5 entidades, com um total de 253 TiB, distribuidos entre Linux, Unix e NonStop OS.
Se considerarmos os dados na sua forma normalizada (descomprimidos, sem índices, etc...) o cenário altera-se um pouco, já que os 100 TiB do Yahoo! se transformam em cerca 17 TiB depois da normalização e os 92 TiB da AT&T "incham" até aos 320 TiB !!
Em número de registos (Row Number), as maiores tabelas pertencem à operadora de telecomunicações americana Sprint, com mais de 2,5 triliões, seguida pela AT&T com 1,8 triliões, na categoria de Data Warehousing. Em OLTP, a maior fica-se pelos 89 milhões de linhas.
Finalmente, avaliando a posição dos fabricantes de Bases de Dados, temos na categoria de Data Warehousing a Oracle "ocupa" 164 TiB dos 370 TiB das dez maiores, seguida pela AT&T (com um produto desenvolvido "in-house") com 117 TiB e pela IBM (DB2 em Unix) com 67 TiB. Nesta categoria o SQL Server da Microsoft "vale" 19 TiB e o da Sybase 17 TiB. Na categoria de OLTP temos mais equilíbrio entre os vários vendedores, com 34 TiB para a Oracle, seguida pela IBM (DB2 em z/OS) com 32 TiB e Microsoft com 21 TiB. Na categoria de "outras" a Oracle domina com 252 TiB, seguida pela HP com uma instalação no límite mínimo para o estudo (1 TiB).
Por último, é de notar a ausência de Bancos e outras instituições financeiras, que são conhecidas portambém terem algumas das maiores Bases de Dados do mundo. Outra ausência de nota é a de aplicações Open-Source. Talvez um próximo estudo revele algumas alterações a este panorama...
2007-10-17
SQL - Standards e Implementações
Hoje, ao deambular pela net, encontrei um site muito interessante, pelo menos para quem gosta destas coisas de Bases de Dados, que faz a comparação entre as implementações de SQL de alguns dos mais comums SGBD, nomeadamente PostgreSQL 8.2.0, IBM DB2 Express-C v9.1 LUW, Microsoft SQL Server 2005, MySQL 5.0.18 e Oracle 10g R2. Outras comparações podem ser encontradas na wikipédia, em http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems e nas referências do primeiro artigo.
Da leitura destes artigos vê-se que existem grandes diferenças de implemtação do standard SQL:2003 e até características aparentemente tão simples como o tipo de dados CHAR pode ter comportamentos diferentes entre os vários sistemas. Daqui se conclui que é muito difícil escrever uma aplicação em que a camada de acesso a dados seja genérica, o que leva a que as aplicações estejam muitas vezes ligadas a,e dependentes de, um SGBD particular. Por vezes, existem diferenças comportamentais até entre versões diferentes do mesmo SGBD.
O melhor que se pode tentar conseguir é usar as potencialidades de cada sistema através de procedimentos e linguagens embebidas nos SGBD (tais como PL/SQL em Oracle ou pgPlSql em PostgresSQL) e criar uma camada de acesso via esses procedimentos, para que se afastem as especificidades do armazenamento de dados o mais possível da lógica da aplicação. Com este processo ganha-se em versatilidade, segurança e clareza da arquitectura da aplicação.
Da leitura destes artigos vê-se que existem grandes diferenças de implemtação do standard SQL:2003 e até características aparentemente tão simples como o tipo de dados CHAR pode ter comportamentos diferentes entre os vários sistemas. Daqui se conclui que é muito difícil escrever uma aplicação em que a camada de acesso a dados seja genérica, o que leva a que as aplicações estejam muitas vezes ligadas a,e dependentes de, um SGBD particular. Por vezes, existem diferenças comportamentais até entre versões diferentes do mesmo SGBD.
O melhor que se pode tentar conseguir é usar as potencialidades de cada sistema através de procedimentos e linguagens embebidas nos SGBD (tais como PL/SQL em Oracle ou pgPlSql em PostgresSQL) e criar uma camada de acesso via esses procedimentos, para que se afastem as especificidades do armazenamento de dados o mais possível da lógica da aplicação. Com este processo ganha-se em versatilidade, segurança e clareza da arquitectura da aplicação.
2007-10-09
Picuinhices com dados
Uma Base de Dados Relacional não é apenas um conjunto de dados "arrumadinhos" em tabelas, obedece a uma teoria matemática baseada na lógica de predicados e teoria dos conjuntos. Esta teoria é conhecida como o Modelo Relacional e foi descrito em 1969 por E.F.Codd, numa publicação para consumo interno da IBM, e em 1970 num artigo público.
Hoje em dia, a maioria dos sistemas profissionais de gestão de bases de dados (tanto comerciais como open-source), implementam este Modelo, portanto têm como base para a forma como guardam e acedem aos dados uma construção matemática já bem conhecida.
Portanto, ao desenhar ou desenvolver uma Base de Dados, devemos sempre procurar aproximarmo-nos do modelo matemático e não afastarmo-nos dele. Ao seguir com rigor este modelo e escolher uma implementação de qualidade do mesmo (o SGBD), podemos estar certos que os problemas de performance associados a uma determinada aplicação não se deverão atribuir a "mau desenho" da Base de Dados. Desta maneira, eliminam-se as "desculpas" para des-normalizar, para criar dados redundantes e outros artifícios que tais...
Tudo isto é válido numa lógica de OLTP, ou seja,em Bases de Dados que servem essencialmente sistemas de transacções, tais como sistemas de venda, de recolha de dados de produção, etc. Para sistemas que suportam Sistemas de Apoio à Decisão o caso é outro, mas fica para a próxima...
Hoje em dia, a maioria dos sistemas profissionais de gestão de bases de dados (tanto comerciais como open-source), implementam este Modelo, portanto têm como base para a forma como guardam e acedem aos dados uma construção matemática já bem conhecida.
Portanto, ao desenhar ou desenvolver uma Base de Dados, devemos sempre procurar aproximarmo-nos do modelo matemático e não afastarmo-nos dele. Ao seguir com rigor este modelo e escolher uma implementação de qualidade do mesmo (o SGBD), podemos estar certos que os problemas de performance associados a uma determinada aplicação não se deverão atribuir a "mau desenho" da Base de Dados. Desta maneira, eliminam-se as "desculpas" para des-normalizar, para criar dados redundantes e outros artifícios que tais...
Tudo isto é válido numa lógica de OLTP, ou seja,em Bases de Dados que servem essencialmente sistemas de transacções, tais como sistemas de venda, de recolha de dados de produção, etc. Para sistemas que suportam Sistemas de Apoio à Decisão o caso é outro, mas fica para a próxima...
2007-10-01
Sistemas operativos: 2017
Um dos aspectos da agregação deste blog ao Planetgeek(link) é a definição de um "Tema do Mês", que pressupõe que todos os blogs agregados escrevam um artigo sobre esse tema, a ser publicado no início do mês.
O tema deste mês (Outubro) incide sobre uma possível antevisão dos Sistemas Operativos num prazo de dez anos.
Como é mais ou menos evidente, penso que os sistemas operativos da próxima década irão ser desenvolvidos de modo a aproveitar as características dos processadores entretanto já desenvolvidos, tais como virtualização por hardware, multíplos núcleos de processamento, sistemas com dezenas de GiB de memória RAM, interfaces multi-touch ou por voz, etc...
Ainda assim, não deve haver grandes alterações no panorama global do mercado de sistemas operativos, que continuará a ser dividido entre os concorrentes actuais. Evoluções futuras do lado de Redmond, dos Pinguins e do pessoal da Maçã, irão no sentido de transitar os sistemas para os 64-bits, eventualmente eliminando o código de 32-bit ainda existente. A consequência destas evoluções será a disponibilidade de recursos para as aplicações, nomeadamente em espaço de endereçamento da memória, que tornarão possíveis sistemas capazes de trabalhar com maior quantidade de informação ao mesmo tempo. Isto significa, melhores (e maiores) videojogos, ambientes gráficos estonteantes e outras "ajudas" à produtividade geral...
No fim de contas, o que interessa são os dados dos utilizadores, o Sistema Operativo é um meio e não um fim (pelo menos para a maior parte dos utilizadores).
Já agora, numa tentativa de futurologia, deixo aqui algumas características dos sistemas operativos em 2017:
Microsoft - Windows Cataract (tb conhecido como Windows "Será que é desta?")
Finalmente inclui a nova versão do Sistema de ficheiros, o famoso WinFS (afinal, notícias de última hora revelam que ainda não é desta que o WinFS ficou pronto a tempo... mantém-se o NTFS com mais uns remendos...). Inclui também o suporte para multi-touch (só para dispositivos certificados, uma vez que o CEO da MS gerou um écran azul na apresentação pública desta funcionalidade). O suporte para comandos por voz será lançado com o SP1, para o final do ano que vem (se tudo correr como planeado). Ainda mantém a camada de código de compatibilidade com 32-bit, uma vez que alguns comandos ainda não foram actualizados para a nova API.
Linux - Kernel versão 2.12
Segundo Linus Torvalds, "ainda não há necessidade de marcar este código como versão 3, pois é apenas uma extensão do que já havia, não havendo nada que quebre a compatibilidade...". Esta versão do kernel foi portada com sucesso para mais algumas arquitecturas, nomeadamente os processadores da Playstation 6 e da Nintendo Wii 4.
Como de costume, a versão 17.10 da distribuição Ubuntu ("Linux for human beings and alike") irá incluir esta versão do kernel.
Apple - Mac OS X, v. 10.26 (Nome de código "Lince da Malcata")
Mais uma versão do bem sucedido Sistema Operativo da empresa de Steve Jobs, especialmente dedicado ao novo dispositivo multifunções da Apple, o iSwissArmyKnife. Com capacidades multimédia e cheio de estrondosos efeitos gráficos, prevê-se que seja um sucesso nos consumidores fiéis à marca (cerca de 0.05% do mercado).
Vamos a ver quantas destas suposições serão verdade, daqui a dez anos...
O tema deste mês (Outubro) incide sobre uma possível antevisão dos Sistemas Operativos num prazo de dez anos.
Como é mais ou menos evidente, penso que os sistemas operativos da próxima década irão ser desenvolvidos de modo a aproveitar as características dos processadores entretanto já desenvolvidos, tais como virtualização por hardware, multíplos núcleos de processamento, sistemas com dezenas de GiB de memória RAM, interfaces multi-touch ou por voz, etc...
Ainda assim, não deve haver grandes alterações no panorama global do mercado de sistemas operativos, que continuará a ser dividido entre os concorrentes actuais. Evoluções futuras do lado de Redmond, dos Pinguins e do pessoal da Maçã, irão no sentido de transitar os sistemas para os 64-bits, eventualmente eliminando o código de 32-bit ainda existente. A consequência destas evoluções será a disponibilidade de recursos para as aplicações, nomeadamente em espaço de endereçamento da memória, que tornarão possíveis sistemas capazes de trabalhar com maior quantidade de informação ao mesmo tempo. Isto significa, melhores (e maiores) videojogos, ambientes gráficos estonteantes e outras "ajudas" à produtividade geral...
No fim de contas, o que interessa são os dados dos utilizadores, o Sistema Operativo é um meio e não um fim (pelo menos para a maior parte dos utilizadores).
Já agora, numa tentativa de futurologia, deixo aqui algumas características dos sistemas operativos em 2017:
Microsoft - Windows Cataract (tb conhecido como Windows "Será que é desta?")
Finalmente inclui a nova versão do Sistema de ficheiros, o famoso WinFS (afinal, notícias de última hora revelam que ainda não é desta que o WinFS ficou pronto a tempo... mantém-se o NTFS com mais uns remendos...). Inclui também o suporte para multi-touch (só para dispositivos certificados, uma vez que o CEO da MS gerou um écran azul na apresentação pública desta funcionalidade). O suporte para comandos por voz será lançado com o SP1, para o final do ano que vem (se tudo correr como planeado). Ainda mantém a camada de código de compatibilidade com 32-bit, uma vez que alguns comandos ainda não foram actualizados para a nova API.
Linux - Kernel versão 2.12
Segundo Linus Torvalds, "ainda não há necessidade de marcar este código como versão 3, pois é apenas uma extensão do que já havia, não havendo nada que quebre a compatibilidade...". Esta versão do kernel foi portada com sucesso para mais algumas arquitecturas, nomeadamente os processadores da Playstation 6 e da Nintendo Wii 4.
Como de costume, a versão 17.10 da distribuição Ubuntu ("Linux for human beings and alike") irá incluir esta versão do kernel.
Apple - Mac OS X, v. 10.26 (Nome de código "Lince da Malcata")
Mais uma versão do bem sucedido Sistema Operativo da empresa de Steve Jobs, especialmente dedicado ao novo dispositivo multifunções da Apple, o iSwissArmyKnife. Com capacidades multimédia e cheio de estrondosos efeitos gráficos, prevê-se que seja um sucesso nos consumidores fiéis à marca (cerca de 0.05% do mercado).
Vamos a ver quantas destas suposições serão verdade, daqui a dez anos...
2007-09-24
Sobre a definição de dados
Num qualuqer sistema de informação, talvez o contributo mais importante para o seu desempenho seja a definição das estruturas de dados que o vão suportar...
Após tantos anos decorridos da criação do modelo relacional, é ainda habitual criarem-se bases de dados não normalizadas e que a desculpa para a desnormalização das mesmas seja sempre a mesma: performance.
Este problema afecta em maior grau os chamados sistemas de OLTP, ou seja, bases de dados muito dinâmicas com grande percentagem de operações de alteração de dados em relação ao total de operações realizadas.
Embora haja casos específicos em que um pequeno grau de desnormalização traz alguma melhoria de performance, são situações que envolvem a replicação de dados em tabelas diferentes, o que obriga a um maior esforço dos programadores do sistema para que não existam dados incoerentes. Esta duplicação de dados vai aumentar o espaço necessário para guardar a base de dados e a complexidade das operações de alteração de dados.
Um outro problema que afecta a performance dos sistemas de informação é o tipo de dados com que se criam os diversos camposnas tabelas. Muitas vezes, ao tentar definir o tipo de dados que queremos atribuir a determinado campo deparamo-nos com a dificuldade de prever os valores que irão "povoar" esse campo e existe sempre a tendência de "usar o maior que se possa", ou seja, definir os campos de inteiros como BIGINT e os campos de caracteres como VARCHAR(2000) ou algo semelhante. Para além deste erro, existem outros que indicam desperdício de recursos, tais como usar dois campos DATETIME para guardar data e hora de entrada (um dos campos só tem datas e o outro só tem horas)...
Ao estruturar correctamente os dados, e criar código SQL eficiente estamos a contribuir de modo muito importante para que o sistema de informação tenha a maior performance possível.
No caso de ser necessário alterar ou expandir um esquema que tenha erros de concepção pode ser mais fácil redesenhar o sistema (ou a parte a intervencionar) do que tentar rodear os problemas, pois como diz o ditado popular: "O que nasce torto, tarde ou nunca se endireita".
Após tantos anos decorridos da criação do modelo relacional, é ainda habitual criarem-se bases de dados não normalizadas e que a desculpa para a desnormalização das mesmas seja sempre a mesma: performance.
Este problema afecta em maior grau os chamados sistemas de OLTP, ou seja, bases de dados muito dinâmicas com grande percentagem de operações de alteração de dados em relação ao total de operações realizadas.
Embora haja casos específicos em que um pequeno grau de desnormalização traz alguma melhoria de performance, são situações que envolvem a replicação de dados em tabelas diferentes, o que obriga a um maior esforço dos programadores do sistema para que não existam dados incoerentes. Esta duplicação de dados vai aumentar o espaço necessário para guardar a base de dados e a complexidade das operações de alteração de dados.
Um outro problema que afecta a performance dos sistemas de informação é o tipo de dados com que se criam os diversos camposnas tabelas. Muitas vezes, ao tentar definir o tipo de dados que queremos atribuir a determinado campo deparamo-nos com a dificuldade de prever os valores que irão "povoar" esse campo e existe sempre a tendência de "usar o maior que se possa", ou seja, definir os campos de inteiros como BIGINT e os campos de caracteres como VARCHAR(2000) ou algo semelhante. Para além deste erro, existem outros que indicam desperdício de recursos, tais como usar dois campos DATETIME para guardar data e hora de entrada (um dos campos só tem datas e o outro só tem horas)...
Ao estruturar correctamente os dados, e criar código SQL eficiente estamos a contribuir de modo muito importante para que o sistema de informação tenha a maior performance possível.
No caso de ser necessário alterar ou expandir um esquema que tenha erros de concepção pode ser mais fácil redesenhar o sistema (ou a parte a intervencionar) do que tentar rodear os problemas, pois como diz o ditado popular: "O que nasce torto, tarde ou nunca se endireita".
2007-09-10
Rapidinha
Uma pergunta rápida, que me "assaltou" o espírito...
Será que um ERP baseado em Web Services pode ter algum interesse ??
Será que um ERP baseado em Web Services pode ter algum interesse ??
2007-09-04
BarCamp Portugal 2007
Decorreu no passado fim de semana (dias 1 e 2 de Setembro), mais uma edição do BarCamp Portugal 2007. Por razões pessoais só lá pude estar uma parte do domingo, mas, pelo que vi, gostei da iniciativa. Para quem quiser saber mais em promenor o que fez e o que se passou, visite BarCampPortugal2007. Aqui ficam apenas algumas fotos do evento, para terem uma ideia:
Início do segundo dia, discussão sobre a ordem de apresentações e actividades.
Início do segundo dia, discussão sobre a ordem de apresentações e actividades.
A reunião prosseguiu no mesmo tom descontraído, e daí a pouco houve a "obrigatória" pausa para comes e bebes:
E pronto, assim se passou um alegre dia nas margens do mondego !
2007-09-03
Planetgeek
Boas,
Desde há algum tempo este blog encontra-se agregado ao PlanetGeek. Como manda a tradição, todos os meses há um tema para um post. Embora devido a algumas alterações recentes no agregador este post tenha saído curto e tardio, cá vai o tema do mês:
"Escrever em inglês ou português em blogues portugueses"
Pois bem, escrevam em que língua quiserem, mas escrevam bem, não tenho nada contra a lingua de Shakespeare desde que bem escrita, assim como não tenho nada contra a minha língua materna, desde que bem escrita. Muito mais irritante que ver um artigo escrito em inglês num blogue português é ver artigos escritos em mau {português, inglês}.
Desde há algum tempo este blog encontra-se agregado ao PlanetGeek. Como manda a tradição, todos os meses há um tema para um post. Embora devido a algumas alterações recentes no agregador este post tenha saído curto e tardio, cá vai o tema do mês:
"Escrever em inglês ou português em blogues portugueses"
Pois bem, escrevam em que língua quiserem, mas escrevam bem, não tenho nada contra a lingua de Shakespeare desde que bem escrita, assim como não tenho nada contra a minha língua materna, desde que bem escrita. Muito mais irritante que ver um artigo escrito em inglês num blogue português é ver artigos escritos em mau {português, inglês}.
2007-08-29
Análise de Performance em Linux e Windows - II
Acho que encontrei um modo bastante fácil para resolver um problema que já me vinha a atormentar há algum tempo.
Eu explico, como fazer para recolher, a certas horas do dia, alguns dados dos computadores que interessam, uns Linux e outros Windows e fazer uns gráficos todos bonitos para que depois o administrador de sistemas olhasse para eles (os gráficos) ?
Ora a solução por mim adoptada envolve uns scripts, criados para a funçao, e um programa muito versátil e simples de usar chamado Gnuplot.
Para recolher os dados em Linux uso um shell-script que me vai ler as informações que quero ao /proc e coloca num ficheiro do tipo .csv; Para efectuar a recolha em Windows uso um script VBS, executado através do "motor" WSH e que também exporta esses dados pera um ficheiro tipo .csv.
Por fim tenho um terceiro script, para o gnuplot, que me vai criar os gráficos relevantes e exporta-os para um ficheiro de imagem (no caso PNG).
A vantagem de executar todas estas acções através de scripts é a facilidade de parametrização e definição de horários para a recolha e geração dos ditos gráficos.
Assim, basta um cron job no Linux ou uma tarefa agendada no Windows para criar automaticamente o que é pretendido.
Um resultado possível é este :
Mostra um gráfico com três indicadores relativos à utilização de memória numa máquina Linux.
2007-08-24
2007-08-20
Análise de Performance em Linux e Windows - I
Tenho estado a experimentar a melhor maneira de analisar a performance de sistemas Windows e Linux em Windows e Windows e Linux em Linux... Parece uma lenga-lenga mas interessa por vezes ter dados de performance de um conjunto de servidores, em ambientes heterogéneos (ou seja, dados de máquinas Linux e máquinas Windows) e analizá-los numa outra máquina (normalmente um computador pessoal ou portátil)...
Para recolher as informações relevantes podemos recorrer a diversos métodos mas, para o caso, sigo "a lei do menor esforço" e uso as ferramentas disponíveis com os diversos S.O., no caso do Windows uso o Performance Monitor e no caso do Linux uso informações do /proc. Esta acção permite-me obter os dados que quero todos "arrumadinhos" num ficheiro de texto que é facilmente "importável" para a aplicação de análise.
Ora aqui é que a porca torce o rabo... porquê ? Porque não me apetece usar o MS Excel para analisar os dados e fazer os respectivos gráficos, e nem sequer me apetece muito usar o OpenOffice.org Calc... Não é que estes dois programas não sejam capazes, nada disso, mas gosto das coisas mais automáticas. Gostava de fazer assim:
E gostava que isto fosse possível nos dois S.O., sem grandes complicações, artimanhas ou "instala-mais-este-software-que-te-faz-isso-e-te-tira-cafés-mas-
-que-só-dá-para-ver-assim-ou-assado".
E gostava que houvesse maneira de fazer isto tudo a partir de um scriptezito às segundas de manhã ou quartas à tarde ou quando quisesse sem pensar mais nisso.
E gostava de receber os ditos gráficos por mail...
Para já concluí a fase 1. Tanto no Windows como no Linux. Agora vou passar à fase 2, penso que daqui a um ou dois dias já tenho o que quero !
Ah!, é verdade, e também gostava de ganhar o EuroMilhões.... :)
Para recolher as informações relevantes podemos recorrer a diversos métodos mas, para o caso, sigo "a lei do menor esforço" e uso as ferramentas disponíveis com os diversos S.O., no caso do Windows uso o Performance Monitor e no caso do Linux uso informações do /proc. Esta acção permite-me obter os dados que quero todos "arrumadinhos" num ficheiro de texto que é facilmente "importável" para a aplicação de análise.
Ora aqui é que a porca torce o rabo... porquê ? Porque não me apetece usar o MS Excel para analisar os dados e fazer os respectivos gráficos, e nem sequer me apetece muito usar o OpenOffice.org Calc... Não é que estes dois programas não sejam capazes, nada disso, mas gosto das coisas mais automáticas. Gostava de fazer assim:
- Correr o script de recolha / tarefa do PerfMonitor
- Criar os gráficos relevantes.
- Ver os ditos num PDF todo geitoso.
E gostava que isto fosse possível nos dois S.O., sem grandes complicações, artimanhas ou "instala-mais-este-software-que-te-faz-isso-e-te-tira-cafés-mas-
-que-só-dá-para-ver-assim-ou-assado".
E gostava que houvesse maneira de fazer isto tudo a partir de um scriptezito às segundas de manhã ou quartas à tarde ou quando quisesse sem pensar mais nisso.
E gostava de receber os ditos gráficos por mail...
Para já concluí a fase 1. Tanto no Windows como no Linux. Agora vou passar à fase 2, penso que daqui a um ou dois dias já tenho o que quero !
Ah!, é verdade, e também gostava de ganhar o EuroMilhões.... :)
2007-08-17
De volta
Cá estou de volta, depois de uns (merecidos) dias de férias....
Estes dias serviram também para pensar um bocadito sobre alguns assuntos que vou deixando pendentes e arrumar mentalmente a casa.
Brevemente terei aqui mais artigos de geito :)
Estes dias serviram também para pensar um bocadito sobre alguns assuntos que vou deixando pendentes e arrumar mentalmente a casa.
2007-08-10
Férias
Também tenho direito :)
Os próximos 5 dias estarei ausente e (quase) incomunicável !!
Até breve
Os próximos 5 dias estarei ausente e (quase) incomunicável !!
Até breve
2007-08-08
SAN - NAS
Ao dimensionar um Sistema de Informação existem vários pontos a ter em conta, um dos quais é o espaço necessário para armazenar a informação pretendida.
Ora, visto que um Sistema de Informação não é uma entidade estática mas irá sofrer evoluções, é necessário contar também com as necessidades futuras que possam vir a exigir mais espaço de armazenamento.
Nesta área há duas tecnologias principais que permitem maior flexibilidade do nosso armazém de dados: NAS e SAN, ou seja "Netwok Attached Storage" e "Storage Area Network". Embora os nomes sejam parecidos e o fim seja o mesmo, os conceitos que estão por detrás de cada uma delas são muito diferentes e assentam em pressupostos também diferentes. Uma SAN é constituída por um conjunto de discos (o armazenamento propriamente dito) que se liga a um computador através de uma rede dedicada, normalmente de fibra óptica. Um sistema NAS é um conjunto de discos que está ligado à rede local (LAN) através de Ethernet. Dito assim, até parece que não existe grande diferença entre os dois, a não ser a tecnologia de rede usada. A outra (maior) diferença entre as duas opções é o tipo de informação que fornecem aos sistemas a eles ligados.
Uma SAN fornece os dados que tem armazenados sob a forma de "blocos" tal como se fosse mais um disco interno de um servidor. Deste ponto de vista a SAN serve para "esticar" o espaço disponível para armazenar ficheiros num servidor.
Um sistema NAS fornece os dados sob a forma de ficheiros, ou seja, comporta-se como um servidor de ficheiros independente do resto dos servidores da rede.
Apresentado um exemplo:
Temos um computador na rede, que precisa de aceder ao ficheiro "Projecto1.odt" armazenado num sistema NAS. O caminho para esse ficheiros será do género [Usando caminhos SAMBA/CIFS]:
\\SistemaNAS\Partilha\Projecto1.odt
Se, pelo contrário, o mesmo ficheiro estiver numa SAN, gerida pelo servidor Server1:
\\Server1\Partilha\Projecto1.odt
Portanto, do ponto de vista dos clientes, nada a assinalar. Então porquê esta "questão" à volta da tecnologia a implementar ? Porque não escolher uma delas e seguir em frente ??
Essencialmente porque as Bases de Dados não gostam de NAS, i.e., se tivermos que alojar uma Base de Dados de alguma dimensão torna-se incomportável transferir um ficheiro "pela rede".
Vendo outro exemplo:
Supomos que existe uma Base de Dados de suporte ao nosso Sistema de Informação que irá ter cerca de 10 GiB.
Ao alojar este ficheiro no NAS, teremos que configurar o SGBD para o usar e, uma vez que os SGBD requerem acesso exclusivo a todo o ficheiro da BD, este teria que ser transferido na totalidade para o sistema que corre o SGBD sempre que houvesse necessidade de leitura/escrita na BD. Mesmo com FastEthernet de 1Gb/s, a transferência do ficheiro demoraria cerca de 2 minutos. Claro que este tempo de espera ao abrir o ficheiro será incomportável para as aplicações, já para não falar em recursos de memória que seria necessários do lado do SGBD.
Se o alojarmos numa SAN, podemos atribuir essa área da SAN ao servidor do SGBD e comportar-se-á como armazenamento local. Quer isto dizer que nunca haverá necessidade de transferir todo o ficheiro, pois em caso de acesso a ficheiros locais só os blocos envolvidos são transferidos.
Para além das razões "técnicas" de acesso a ficheiros, ecistem também diferenças significativas na instalação, configuração e administração dos dois tipos de armazenamento, o que leva a que muitas vezes o NAS seja preferido pelo seu menor custo e maior facilidade de implementação. Pelo contrário, quando o que está em causa é a velocidade de acesso e facilidade de expansão (e o dinheiro chega) prefere-se implementar uma SAN.
Ultimamente tem-se vindo a aproximar as duas filosofias pela junção de um NAS na interface da SAN com a rede, o que cria, na prática, um NAS muito escalável e bastante rápido.
Tanto num NAS como numa SAN, são aplicáveis outros conceitos relativos ao armazenamento, nomeadamente níveis de RAID e tecnologias de Discos, que fiarão ar uma próxima ocasião.
Ora, visto que um Sistema de Informação não é uma entidade estática mas irá sofrer evoluções, é necessário contar também com as necessidades futuras que possam vir a exigir mais espaço de armazenamento.
Nesta área há duas tecnologias principais que permitem maior flexibilidade do nosso armazém de dados: NAS e SAN, ou seja "Netwok Attached Storage" e "Storage Area Network". Embora os nomes sejam parecidos e o fim seja o mesmo, os conceitos que estão por detrás de cada uma delas são muito diferentes e assentam em pressupostos também diferentes. Uma SAN é constituída por um conjunto de discos (o armazenamento propriamente dito) que se liga a um computador através de uma rede dedicada, normalmente de fibra óptica. Um sistema NAS é um conjunto de discos que está ligado à rede local (LAN) através de Ethernet. Dito assim, até parece que não existe grande diferença entre os dois, a não ser a tecnologia de rede usada. A outra (maior) diferença entre as duas opções é o tipo de informação que fornecem aos sistemas a eles ligados.
Uma SAN fornece os dados que tem armazenados sob a forma de "blocos" tal como se fosse mais um disco interno de um servidor. Deste ponto de vista a SAN serve para "esticar" o espaço disponível para armazenar ficheiros num servidor.
Um sistema NAS fornece os dados sob a forma de ficheiros, ou seja, comporta-se como um servidor de ficheiros independente do resto dos servidores da rede.
Apresentado um exemplo:
Temos um computador na rede, que precisa de aceder ao ficheiro "Projecto1.odt" armazenado num sistema NAS. O caminho para esse ficheiros será do género [Usando caminhos SAMBA/CIFS]:
\\SistemaNAS\Partilha\Projecto1.odt
Se, pelo contrário, o mesmo ficheiro estiver numa SAN, gerida pelo servidor Server1:
\\Server1\Partilha\Projecto1.odt
Portanto, do ponto de vista dos clientes, nada a assinalar. Então porquê esta "questão" à volta da tecnologia a implementar ? Porque não escolher uma delas e seguir em frente ??
Essencialmente porque as Bases de Dados não gostam de NAS, i.e., se tivermos que alojar uma Base de Dados de alguma dimensão torna-se incomportável transferir um ficheiro "pela rede".
Vendo outro exemplo:
Supomos que existe uma Base de Dados de suporte ao nosso Sistema de Informação que irá ter cerca de 10 GiB.
Ao alojar este ficheiro no NAS, teremos que configurar o SGBD para o usar e, uma vez que os SGBD requerem acesso exclusivo a todo o ficheiro da BD, este teria que ser transferido na totalidade para o sistema que corre o SGBD sempre que houvesse necessidade de leitura/escrita na BD. Mesmo com FastEthernet de 1Gb/s, a transferência do ficheiro demoraria cerca de 2 minutos. Claro que este tempo de espera ao abrir o ficheiro será incomportável para as aplicações, já para não falar em recursos de memória que seria necessários do lado do SGBD.
Se o alojarmos numa SAN, podemos atribuir essa área da SAN ao servidor do SGBD e comportar-se-á como armazenamento local. Quer isto dizer que nunca haverá necessidade de transferir todo o ficheiro, pois em caso de acesso a ficheiros locais só os blocos envolvidos são transferidos.
Para além das razões "técnicas" de acesso a ficheiros, ecistem também diferenças significativas na instalação, configuração e administração dos dois tipos de armazenamento, o que leva a que muitas vezes o NAS seja preferido pelo seu menor custo e maior facilidade de implementação. Pelo contrário, quando o que está em causa é a velocidade de acesso e facilidade de expansão (e o dinheiro chega) prefere-se implementar uma SAN.
Ultimamente tem-se vindo a aproximar as duas filosofias pela junção de um NAS na interface da SAN com a rede, o que cria, na prática, um NAS muito escalável e bastante rápido.
Tanto num NAS como numa SAN, são aplicáveis outros conceitos relativos ao armazenamento, nomeadamente níveis de RAID e tecnologias de Discos, que fiarão ar uma próxima ocasião.
2007-08-06
Sistemas de Informação - parte III
Tal como prometi no artigo sobre documentos dispersos e a sua relação com os sistemas de informação, este artigo aborda o terceiro componente que, na minha opinião, deve ser considerado parte dum sistema de informação bem estruturado e desenvolvido: o e-mail.
O e-mail é, dos serviços da Internet, um dos mais antigos e um dos mais usados. Embora criado há já muitos anos o protocolo POP sofreu várias revisões, sendo a última e mais recente a chamada versão 3, constituindo assim o protocolo POP3, descrito no RFC 1939, de Maio de 1996.
Uma vez que as condições das redes informáticas são agora muito diferentes de há dez anos atrás, nomeadamente na disponibilidade de acesso à informação por parte dos utilizadores, a quantidade de dados que é necessário manter na forma de mensagens de e-mail é cada vez maior. A existência de regulamentação legal para tornar obrigatória a manutenção de um arquivo de mensagens de e-mail, tal como os existentes para correio em papel, aumenta ainda mais essa necessidade.
O que fazer então para arquivar os milhares de mensagens que nos chegam por ano às caixas de correio, e, mais ainda, como fazer para que os utilizadores tenham acesso a tais quantidades de e-mail sem prejudicar o desempenho da rede ou do sistema onde estão a trabalhar ??
Deixo esta pergunta no ar, para reflectirem durante este mês de férias... Daqui a algum tempo voltaremos a este tema...
O e-mail é, dos serviços da Internet, um dos mais antigos e um dos mais usados. Embora criado há já muitos anos o protocolo POP sofreu várias revisões, sendo a última e mais recente a chamada versão 3, constituindo assim o protocolo POP3, descrito no RFC 1939, de Maio de 1996.
Uma vez que as condições das redes informáticas são agora muito diferentes de há dez anos atrás, nomeadamente na disponibilidade de acesso à informação por parte dos utilizadores, a quantidade de dados que é necessário manter na forma de mensagens de e-mail é cada vez maior. A existência de regulamentação legal para tornar obrigatória a manutenção de um arquivo de mensagens de e-mail, tal como os existentes para correio em papel, aumenta ainda mais essa necessidade.
O que fazer então para arquivar os milhares de mensagens que nos chegam por ano às caixas de correio, e, mais ainda, como fazer para que os utilizadores tenham acesso a tais quantidades de e-mail sem prejudicar o desempenho da rede ou do sistema onde estão a trabalhar ??
Deixo esta pergunta no ar, para reflectirem durante este mês de férias... Daqui a algum tempo voltaremos a este tema...
Eu sou...
Aqui encontra-se um teste para descobrir qual o que seriam se fossem uma linguagem de programação. Eu seria PHP... até concordo :)
Which Programming Language are You?
Podem ver todos os resultados possíveis, aqui.
Na mesma linha, aqui podemos encontrar a variante: se eu fosse um Sistema Operativo...
O meu resultado é:
Which OS are You?
Which Programming Language are You?
Podem ver todos os resultados possíveis, aqui.
Na mesma linha, aqui podemos encontrar a variante: se eu fosse um Sistema Operativo...
O meu resultado é:
Which OS are You?
2007-08-01
Sistemas de Informação - parte II
Boas,
No seguimento do post anterior sobre o que constitui um Sistema de Informação, interessa saber como fazer a integração da informação presente em conteúdo não estruturado (nos tais ficheiros de aplicações diversas) com a informação presente de forma estruturada na Base de Dados que suporta o Sistema de Informação.
Um método cada vez mais comum é transformar os ficheiros em documentos XML que depois podem ser integrados nas Bases de Dados, pois os principais fabricantes de Bases de Dados já incluem esta funcionalidade há algum tempo. Uma vantagem deste método é que pode permitir a pesquisa de informação dentro do documento original usando a linguagem XPath o uoutra semelhante. A principal desvantagem é a necessidade de conversão de documentos, que podem ser milhares ou mais, tornando este processo num processo moroso e sujeito a erros.
Podemos também admitir que os documentos existem fora da Base de Dados e criar um repositório, eventualmente com controlo de versões ou mantido por uma ferramenta de trabalho colaborativo. Esta segunda hipótese resulta normalmente da necessidade de rever ou alterar documentos a posteriori.
Ambos os métodos têm as suas vantagens e o seus pontos fracos, que devem ser avaliados antes da implementação.
Para um próximo artigo, fica o grande problema do e-mail...
No seguimento do post anterior sobre o que constitui um Sistema de Informação, interessa saber como fazer a integração da informação presente em conteúdo não estruturado (nos tais ficheiros de aplicações diversas) com a informação presente de forma estruturada na Base de Dados que suporta o Sistema de Informação.
Um método cada vez mais comum é transformar os ficheiros em documentos XML que depois podem ser integrados nas Bases de Dados, pois os principais fabricantes de Bases de Dados já incluem esta funcionalidade há algum tempo. Uma vantagem deste método é que pode permitir a pesquisa de informação dentro do documento original usando a linguagem XPath o uoutra semelhante. A principal desvantagem é a necessidade de conversão de documentos, que podem ser milhares ou mais, tornando este processo num processo moroso e sujeito a erros.
Podemos também admitir que os documentos existem fora da Base de Dados e criar um repositório, eventualmente com controlo de versões ou mantido por uma ferramenta de trabalho colaborativo. Esta segunda hipótese resulta normalmente da necessidade de rever ou alterar documentos a posteriori.
Ambos os métodos têm as suas vantagens e o seus pontos fracos, que devem ser avaliados antes da implementação.
Para um próximo artigo, fica o grande problema do e-mail...
2007-07-31
Sistemas de Informação
Nestes últimos posts tenho-me debruçado principalmente sobre a performance e questões
relacionadas com as Bases de Dados que, geralmente, suportam um Sistema de Informação. No entanto, um Sistema de Informação não se esgota na Base de Dados. O que deve, afinal, constituir um Sistema de Informação (SI)?
No meu ponto de vista, o SI de uma qualquer organização deve incluir toda a informação relevante para o negócio/actividade da dita organização, esteja esta informação numa BD ou dispersa por documentos diversos de aplicações várias, tais como processadores de texto, folhas de cálculo, etc.
Um SI bem conseguido deve ainda ser capaz de apresentar a informação desejada aos
vários utilizadores, independentemente do tipo de acesso que estes possuam no momento, por exemplo, um vendedor de uma empresa que esteja numa visita a um cliente deve poder aceder aos dados relevantes sobre esse cliente mesmo que tenha apenas um telemóvel com internet.
Mas como conseguir esta característica? Será tema para um próximo post...
Fiquem bem.
relacionadas com as Bases de Dados que, geralmente, suportam um Sistema de Informação. No entanto, um Sistema de Informação não se esgota na Base de Dados. O que deve, afinal, constituir um Sistema de Informação (SI)?
No meu ponto de vista, o SI de uma qualquer organização deve incluir toda a informação relevante para o negócio/actividade da dita organização, esteja esta informação numa BD ou dispersa por documentos diversos de aplicações várias, tais como processadores de texto, folhas de cálculo, etc.
Um SI bem conseguido deve ainda ser capaz de apresentar a informação desejada aos
vários utilizadores, independentemente do tipo de acesso que estes possuam no momento, por exemplo, um vendedor de uma empresa que esteja numa visita a um cliente deve poder aceder aos dados relevantes sobre esse cliente mesmo que tenha apenas um telemóvel com internet.
Mas como conseguir esta característica? Será tema para um próximo post...
Fiquem bem.
2007-07-27
Dia do Administrador de Sistemas
Hoje, dia 27 de Julho de 2007, comemora-se mais um dia do administrador de sistemas, um dia onde todos devemos reconhecer o árduo trabalho desses profissionais :)
Vejam o site oficial (inglês) em System Administrator Appreciation Day
E, já agora, não se esqueçam do autor deste post ;)
Vejam o site oficial (inglês) em System Administrator Appreciation Day
E, já agora, não se esqueçam do autor deste post ;)
2007-07-23
Mais dicas sobre o tamanho
Boa noite,
O comentário de um "corajoso internauta" a um post anterior, leva-me a fazer mais um post relacionado com tamanhos :)
Tem isto a ver com o que se pode ganhar em termos de tamanho de uma BD ao aplicar algumas técnicas de optimização de dados.
Hoje estive a ver uma BD, real, que tem uma tabela com cerca de um milhão e meio de registos. Um dos campos é do tipo "bigint", ou seja ocupa 8 bytes de armazenamento e permite que sejam guardados números inteiros entre -2^63 a 2^63-1. Se não forem necessários valores tão grandes podemos transformar este campo para um tipo "int" (valores entre -2^31 e 2^31) ou até um "smallint" (valores entre -65000 e 65000 aprox.)
Nestas transformações ganham-se respectivamente 4 ou 6 bytes de cada registo. Como a tabela tem um milhão e meio de registos, diz-nos a matemática que se podem ganhar entre 6 a 9 MiB de espaço nesta coluna :)
Parece pouco, mas podemos ainda fazer a análise de outro modo: podemos medir a "largura" de uma tabela, ou seja, o tamanho de cada registo. Nesta tabela em particular vamos começar com uma largura de 356 bytes. Se cada página de armazenamento da BD tiver 8KiB, temos cerca de 8000 bytes para armazenar os dados (devido a headers e informação administrativa da BD). Desta quantidade, pode estar definida uma percentagem máxima de ocupação (vamos supor 80%), que nos dá uma capacidade efectiva de 6400 bytes. Dividindo 6400 por 356 podemos armazenar 17 registos completos numa página (os registos não podem estar divididos por duas páginas), ou seja, para 1500000 de registos, necessitamos de 88236 páginas, ou cerca de 689 MiB. Se reduzirmos 6 bytes a cada registo e fizermos novamente as contas passamos a ocupar 83334 páginas, ou cerca de 651 MiB, poupamos 38 MiB de espaço efectivo de armazenagem... e isto numa tabela de dimensão média... :)
Propagando estas alterações para outras colunas e outras tabelas dentro desta BD, podemos poupar dezenas ou centenas de MiB, conforme o grau que quisermos levar esta análise. Claro que estas mudanças têm o seu preço e poderão envolver também alterações na programação subjacente ao Sistema que faz uso destes dados.
E para já é tudo !
Até breve.
O comentário de um "corajoso internauta" a um post anterior, leva-me a fazer mais um post relacionado com tamanhos :)
Tem isto a ver com o que se pode ganhar em termos de tamanho de uma BD ao aplicar algumas técnicas de optimização de dados.
Hoje estive a ver uma BD, real, que tem uma tabela com cerca de um milhão e meio de registos. Um dos campos é do tipo "bigint", ou seja ocupa 8 bytes de armazenamento e permite que sejam guardados números inteiros entre -2^63 a 2^63-1. Se não forem necessários valores tão grandes podemos transformar este campo para um tipo "int" (valores entre -2^31 e 2^31) ou até um "smallint" (valores entre -65000 e 65000 aprox.)
Nestas transformações ganham-se respectivamente 4 ou 6 bytes de cada registo. Como a tabela tem um milhão e meio de registos, diz-nos a matemática que se podem ganhar entre 6 a 9 MiB de espaço nesta coluna :)
Parece pouco, mas podemos ainda fazer a análise de outro modo: podemos medir a "largura" de uma tabela, ou seja, o tamanho de cada registo. Nesta tabela em particular vamos começar com uma largura de 356 bytes. Se cada página de armazenamento da BD tiver 8KiB, temos cerca de 8000 bytes para armazenar os dados (devido a headers e informação administrativa da BD). Desta quantidade, pode estar definida uma percentagem máxima de ocupação (vamos supor 80%), que nos dá uma capacidade efectiva de 6400 bytes. Dividindo 6400 por 356 podemos armazenar 17 registos completos numa página (os registos não podem estar divididos por duas páginas), ou seja, para 1500000 de registos, necessitamos de 88236 páginas, ou cerca de 689 MiB. Se reduzirmos 6 bytes a cada registo e fizermos novamente as contas passamos a ocupar 83334 páginas, ou cerca de 651 MiB, poupamos 38 MiB de espaço efectivo de armazenagem... e isto numa tabela de dimensão média... :)
Propagando estas alterações para outras colunas e outras tabelas dentro desta BD, podemos poupar dezenas ou centenas de MiB, conforme o grau que quisermos levar esta análise. Claro que estas mudanças têm o seu preço e poderão envolver também alterações na programação subjacente ao Sistema que faz uso destes dados.
E para já é tudo !
Até breve.
2007-07-18
Tamanho e performance
Boas noites,
No seguimento dos posts sobre performance de sistemas e tamanho, cá vai mais um texto supostamente inteligente :)
Ao fazer umas pesquisas sobre sistemas de alta disponibilidade de servidores SQL, deparei-me com um artigo interessante sobre a relação entre o tamanho das bases de dados e a possível performance dos servidor.
O que se passa é que, ao desenhar uma Base de Dados, se deve ter em conta o tamanho máximo dos campos das tabelas necessário para guardar os dados e não sobre-estimar esta medida. Passo a explicar:
Queremos criar uma tabela que contenha 2 campos:
Numero - campo numérico que contém o número de funcionário;
Nome - campo de texto que irá ter o nome do dito funcionário.
Ao criar os campos temos várias hipóteses para o tipo de dados que podemos usar. Se usarmos o tipo numérico comum (int) ocupamos 4 bytes em cada valor, ora se pensarmos que não iremos ter mais de 65000 funcionários, podemos poupar 2 bytes em cada registo se mudarmos o tipo de int para smallint. Do mesmo modo se tivermos o cuidado de verificar o tamanho máximo dos nomes dos funcionários, podemo-nos cingir a uma coluna do tipo char em vez de varchar e mais ainda se prescindirmos dos tipos Unicode.
Claro que este é um exemplo muito simples mas se extrapolarmos para toda uma Base de Dados com vários gigabytes de tamanho podemos poupar vários megabytes.
Mas no fundo, qual é o interesse desta redução de tamanho?
É essencialmente uma maneira de poder guardar mais dados por página da Base de Dados, ou seja, as Bases de Dados estão normalmente estruturadas (em termos de armazenamento em disco) numa série de páginas que têm entre 4 e 32 KiB, e cada página pode guardar um número limitado de registos. Se conseguirmos colocar mais registos por páginas beneficiamos as operações de entrada/saída de dados (feitas a nível de página) ao movimentar mais registos de cada vez.
Claro que estas considerações terão mais importância à medida que aumenta a dimensão geral dos dados, mas é sempre útil termos noção destes factores para optimizarmos o mais possível o desempenho dos sistemas.
Por hoje não vos maço mais...
No seguimento dos posts sobre performance de sistemas e tamanho, cá vai mais um texto supostamente inteligente :)
Ao fazer umas pesquisas sobre sistemas de alta disponibilidade de servidores SQL, deparei-me com um artigo interessante sobre a relação entre o tamanho das bases de dados e a possível performance dos servidor.
O que se passa é que, ao desenhar uma Base de Dados, se deve ter em conta o tamanho máximo dos campos das tabelas necessário para guardar os dados e não sobre-estimar esta medida. Passo a explicar:
Queremos criar uma tabela que contenha 2 campos:
Numero - campo numérico que contém o número de funcionário;
Nome - campo de texto que irá ter o nome do dito funcionário.
Ao criar os campos temos várias hipóteses para o tipo de dados que podemos usar. Se usarmos o tipo numérico comum (int) ocupamos 4 bytes em cada valor, ora se pensarmos que não iremos ter mais de 65000 funcionários, podemos poupar 2 bytes em cada registo se mudarmos o tipo de int para smallint. Do mesmo modo se tivermos o cuidado de verificar o tamanho máximo dos nomes dos funcionários, podemo-nos cingir a uma coluna do tipo char em vez de varchar e mais ainda se prescindirmos dos tipos Unicode.
Claro que este é um exemplo muito simples mas se extrapolarmos para toda uma Base de Dados com vários gigabytes de tamanho podemos poupar vários megabytes.
Mas no fundo, qual é o interesse desta redução de tamanho?
É essencialmente uma maneira de poder guardar mais dados por página da Base de Dados, ou seja, as Bases de Dados estão normalmente estruturadas (em termos de armazenamento em disco) numa série de páginas que têm entre 4 e 32 KiB, e cada página pode guardar um número limitado de registos. Se conseguirmos colocar mais registos por páginas beneficiamos as operações de entrada/saída de dados (feitas a nível de página) ao movimentar mais registos de cada vez.
Claro que estas considerações terão mais importância à medida que aumenta a dimensão geral dos dados, mas é sempre útil termos noção destes factores para optimizarmos o mais possível o desempenho dos sistemas.
Por hoje não vos maço mais...
2007-07-10
O tamanho interessa..... às vezes
Boas,
Este post resulta de uma conversa que tive há dias com alguém que, não sendo da área de informática, se viu confrontado com a necessidade de desenvolver uma base de dados.
Ora, nessa situação, fez um raciocínio lógico para quem não está muito "por dentro" deste assunto: tentou perceber quantos dados (portanto, que tamanho) teria na Base de Dados...
Até certo ponto este raciocínio está correcto na medida em que pode, por alto, definir algumas necessidades de armazenamento / backup da dita Base de Dados, mas, por outro lado, a quantidade é muito menos importante que a qualidade pois uma Base de Dados não precisa, normalmente, de aceder a TODO o seu conteúdo ao mesmo tempo. O tipo de dados influencia coisas como o tipo de índices que se podem criar, o tipo de pesquisas a fazer e até a boa ou má utilização que o software gestor de Bases de Dados vai fazer do espaço em disco disponível.
Portanto, como em tantas outras coisas, o tamanho é apenas um dos muitos factores que interessa.... :)
Fiquem Bem, até breve...
Este post resulta de uma conversa que tive há dias com alguém que, não sendo da área de informática, se viu confrontado com a necessidade de desenvolver uma base de dados.
Ora, nessa situação, fez um raciocínio lógico para quem não está muito "por dentro" deste assunto: tentou perceber quantos dados (portanto, que tamanho) teria na Base de Dados...
Até certo ponto este raciocínio está correcto na medida em que pode, por alto, definir algumas necessidades de armazenamento / backup da dita Base de Dados, mas, por outro lado, a quantidade é muito menos importante que a qualidade pois uma Base de Dados não precisa, normalmente, de aceder a TODO o seu conteúdo ao mesmo tempo. O tipo de dados influencia coisas como o tipo de índices que se podem criar, o tipo de pesquisas a fazer e até a boa ou má utilização que o software gestor de Bases de Dados vai fazer do espaço em disco disponível.
Portanto, como em tantas outras coisas, o tamanho é apenas um dos muitos factores que interessa.... :)
Fiquem Bem, até breve...
2007-06-17
Performance em Linux e Windows
Bom dia,
Em relação aos processos de medição de performance de sistemas de Informação, importa ter em conta o tipo de sistema que temos, nomeadamente, se se trata de um sistema baseado em Linux, em Windows ou noutro Sistema Operativo. Este facto obriga-nos a fazer algumas escolhas quanto ao processo de recolha da informação.
Se nos computadores com Windows podemos usar o "Performance Monitor" para recolher informação do computador local, ou remoto, nos computadores com Linux beneficiamos do sistema /proc que nos dá, em modo texto, informação sobre vários aspectos do sistema do computador local. Se exportarmos o /proc via nfs para um cliente remoto podemos obter indicadores de várias máquinas de uma forma centralizada.
Além do tipo de sistema devemos ter em conta a versão que estamos a analizar, já que a informação disponibilizada pelas diferentes versões dos sistemas operativos não é a mesma. Por exemplo, no Linux, com kernel da série 2.4 o ficheiro /proc/stat tem o seguinte aspecto :
já nas versões 2.6 será mais como (para dois CPUs) :
Para já é só... até breve !
Em relação aos processos de medição de performance de sistemas de Informação, importa ter em conta o tipo de sistema que temos, nomeadamente, se se trata de um sistema baseado em Linux, em Windows ou noutro Sistema Operativo. Este facto obriga-nos a fazer algumas escolhas quanto ao processo de recolha da informação.
Se nos computadores com Windows podemos usar o "Performance Monitor" para recolher informação do computador local, ou remoto, nos computadores com Linux beneficiamos do sistema /proc que nos dá, em modo texto, informação sobre vários aspectos do sistema do computador local. Se exportarmos o /proc via nfs para um cliente remoto podemos obter indicadores de várias máquinas de uma forma centralizada.
Além do tipo de sistema devemos ter em conta a versão que estamos a analizar, já que a informação disponibilizada pelas diferentes versões dos sistemas operativos não é a mesma. Por exemplo, no Linux, com kernel da série 2.4 o ficheiro /proc/stat tem o seguinte aspecto :
cpu 1132 34 1441 11311718 3675 127 438
cpu0 1132 34 1441 11311718 3675 127 438
intr 114930548 113199788 3 0 5 263 0 4 (...)
ctxt 1990473
btime 1062191376
já nas versões 2.6 será mais como (para dois CPUs) :
cpu 2255 34 2290 22625563 6290 127 456
cpu0 1132 34 1441 11311718 3675 127 438
cpu1 1123 0 849 11313845 2614 0 18
intr 114930548 113199788 3 0 5 263 0 4 [... lots more numbers ...]
ctxt 1990473
btime 1062191376
processes 2915
procs_running 1
procs_blocked 0
Para já é só... até breve !
Visitas (ou falta delas)....
Bom dia,
Parece que este blog ainda não é muito visto... paciência... vai ficando em histórico :)
Será que há maneira de traduzir estes textos para outras línguas ?? (Sem escrver os posts novamente, é obvio)...
Se alguém vir, dê ideias, please !!
Parece que este blog ainda não é muito visto... paciência... vai ficando em histórico :)
Será que há maneira de traduzir estes textos para outras línguas ?? (Sem escrver os posts novamente, é obvio)...
Se alguém vir, dê ideias, please !!
2007-06-05
Promessas....
Boa noite,
Como prometido, cá estou eu para "falar" mais um pouco do tema da performance nos sistemas de informação.
O primeiro passo para poder avaliar com alguma confiança a performance de um sistema consiste em conhecer o sistema, ou seja, conseguir obter uma série de indicadores que nos digam como se está a comportar. Esta medida inicial, também chamada "baseline", server para termos uma base para comparação futura.
E aqui entra a segunda fase do processo de avaliação da performance: fazer comparações com a baseline e inferir tendências de comportamento que nos indiquem se a performance se está a degradar ou se, pelo contrário, se mantêm.
E para que serve isto, no fim de contas ?
Serve, principalmente, para tomar decisões informadas sobre assuntos como: actualização dos sistemas, planeamento de expansão futura, determinação de problemas ou até de potenciais problemas....
Um resultado prático pode ser demonstrado pelo exemplo seguinte:
Vamos supor que temos um servidor de Base de Dados, já com algum tempo em operação "em velocidade de cruzeiro" e começa a apresentar algumas dificuldades de desempenho.
Se não houver algum cuidado na avaliação da situação podemos ser tentados a investir em mais RAM ou em processadores mais rápidos, quando, por exemplo, o factor limitante pode ser a resposta do tempo de E/S do sistema de armazenamento (discos) e, portanto, podemos investir em discos diferentes/mais rápidos para resolver o problema inicial em vez de deitar dinheiro fora a melhorar componentes que provavelmente não precisarão de actualizações.
Para concluir, devo referir que estas análises devem ser feitas a intervalos regulares para melhores resultados.
Por agora ficamos por aqui... até breve.
Como prometido, cá estou eu para "falar" mais um pouco do tema da performance nos sistemas de informação.
O primeiro passo para poder avaliar com alguma confiança a performance de um sistema consiste em conhecer o sistema, ou seja, conseguir obter uma série de indicadores que nos digam como se está a comportar. Esta medida inicial, também chamada "baseline", server para termos uma base para comparação futura.
E aqui entra a segunda fase do processo de avaliação da performance: fazer comparações com a baseline e inferir tendências de comportamento que nos indiquem se a performance se está a degradar ou se, pelo contrário, se mantêm.
E para que serve isto, no fim de contas ?
Serve, principalmente, para tomar decisões informadas sobre assuntos como: actualização dos sistemas, planeamento de expansão futura, determinação de problemas ou até de potenciais problemas....
Um resultado prático pode ser demonstrado pelo exemplo seguinte:
Vamos supor que temos um servidor de Base de Dados, já com algum tempo em operação "em velocidade de cruzeiro" e começa a apresentar algumas dificuldades de desempenho.
Se não houver algum cuidado na avaliação da situação podemos ser tentados a investir em mais RAM ou em processadores mais rápidos, quando, por exemplo, o factor limitante pode ser a resposta do tempo de E/S do sistema de armazenamento (discos) e, portanto, podemos investir em discos diferentes/mais rápidos para resolver o problema inicial em vez de deitar dinheiro fora a melhorar componentes que provavelmente não precisarão de actualizações.
Para concluir, devo referir que estas análises devem ser feitas a intervalos regulares para melhores resultados.
Por agora ficamos por aqui... até breve.
2007-05-29
Novidades, novidades...
... só no continente, como dizia a publicidade, mas de facto tenho estado mais ocupado com um assunto que ando a preparar para depois publicar aqui qualquer coisa... tem a ver com a medição de performance de sistemas...
Já agora, acrescentei também um link para quem necessitar de ajuda com algum projecto que tenha em mãos... façam favor de contactar para tratar das formalidades :)
Fiquem bem que já é tarde !
Já agora, acrescentei também um link para quem necessitar de ajuda com algum projecto que tenha em mãos... façam favor de contactar para tratar das formalidades :)
Fiquem bem que já é tarde !
2007-05-19
Velocidades II
Boa noite,
Antes de mais, quero agradecer ao elmig o comentário, já que foi o primeiro :)
Em resposta a esse comentário resolvi escrever um novo post, sobre o mesmo tema.
Para optimizar o desempenho de um sistema de informação temos que ter em conta vários factores, sendo que um dos mais importantes é o software que serve de interface entre os utilizadores e o sistema de gestão de base de dados(SGBD) que o suporta, vulgo software de gestão ou ERP. Alguns dos outros factores que tem muita importância no desempenho final do Sistema de Informação vão desde o hardware escolhido até à configuração do SGBD.
Como o software de gestão é o factor que mais impacto tem na performance final do Sistema (pois um programa mal arquitectado raramente terá bom desempenho), devemos começar por avaliar o desempenho dos vários factores envolvidos, escolher a melhor configuração possível e desenvolver o programa de acordo com essa configuração.
Para além destas medidas, que podem ser distintas para cada situação, há um conjunto de opções geralmente aceites pela comunidade no que respeita a configurações recomendadas do SGBD, opções de arquitectura do hardware (nomeadamente sistema de armazenamento), práticas de programação, estruturação das bases de dados, etc...
Claro que tudo isto é muito bonito quando se está a desenvolver o sistema, mas quando este já existe há algum tempo e não é viável alterar a sua arquitectura ? Só nos resta medir a performance do mesmo e melhorar o que for possível, ou seja, actuar onde se puder, nomeadamente a nível de opções de configuração do SGBD, hardware, etc...
Mas como medir a performance ? Que indicadores escolher ? Hoje em dia quase todos os SGBD têm opções, plugins ou ferramentas para obter indicadores acerca do desempenho do SGDB. Devemos recolher essa informação e interpretá-la para alterar o que for necessário.
Vamos a um exemplo: Vamos imaginar que temos um sistema que está suportado pelo PostgreSQL. Neste SGBD existe uma opção para obter estatisticas. Um dos indicadores que podemos obter, chamado pg_stat_all_indexes (é uma tabela) dá-nos informação importante sobre a utilização dos índices das tabelas. Com esta informação podemos afinar os índices que nos dêm mais problemas, ou então podemos usar uma das tabelas pg_stat_io_* que nos dão informações sobre a performance de I/O da Base de Dados, ao analizar estes valores podemos descobrir que temos que optimizar a configuração do sistema de armazenamento...
Isto é só a ponta do iceberg... há imensas opções diferentes e abordagens que variam conforme o SGBD usado, o hardware, etc...
Por agora espero que tenham ficado com a ideia geral...
Até breve !
Antes de mais, quero agradecer ao elmig o comentário, já que foi o primeiro :)
Em resposta a esse comentário resolvi escrever um novo post, sobre o mesmo tema.
Para optimizar o desempenho de um sistema de informação temos que ter em conta vários factores, sendo que um dos mais importantes é o software que serve de interface entre os utilizadores e o sistema de gestão de base de dados(SGBD) que o suporta, vulgo software de gestão ou ERP. Alguns dos outros factores que tem muita importância no desempenho final do Sistema de Informação vão desde o hardware escolhido até à configuração do SGBD.
Como o software de gestão é o factor que mais impacto tem na performance final do Sistema (pois um programa mal arquitectado raramente terá bom desempenho), devemos começar por avaliar o desempenho dos vários factores envolvidos, escolher a melhor configuração possível e desenvolver o programa de acordo com essa configuração.
Para além destas medidas, que podem ser distintas para cada situação, há um conjunto de opções geralmente aceites pela comunidade no que respeita a configurações recomendadas do SGBD, opções de arquitectura do hardware (nomeadamente sistema de armazenamento), práticas de programação, estruturação das bases de dados, etc...
Claro que tudo isto é muito bonito quando se está a desenvolver o sistema, mas quando este já existe há algum tempo e não é viável alterar a sua arquitectura ? Só nos resta medir a performance do mesmo e melhorar o que for possível, ou seja, actuar onde se puder, nomeadamente a nível de opções de configuração do SGBD, hardware, etc...
Mas como medir a performance ? Que indicadores escolher ? Hoje em dia quase todos os SGBD têm opções, plugins ou ferramentas para obter indicadores acerca do desempenho do SGDB. Devemos recolher essa informação e interpretá-la para alterar o que for necessário.
Vamos a um exemplo: Vamos imaginar que temos um sistema que está suportado pelo PostgreSQL. Neste SGBD existe uma opção para obter estatisticas. Um dos indicadores que podemos obter, chamado pg_stat_all_indexes (é uma tabela) dá-nos informação importante sobre a utilização dos índices das tabelas. Com esta informação podemos afinar os índices que nos dêm mais problemas, ou então podemos usar uma das tabelas pg_stat_io_* que nos dão informações sobre a performance de I/O da Base de Dados, ao analizar estes valores podemos descobrir que temos que optimizar a configuração do sistema de armazenamento...
Isto é só a ponta do iceberg... há imensas opções diferentes e abordagens que variam conforme o SGBD usado, o hardware, etc...
Por agora espero que tenham ficado com a ideia geral...
Até breve !
2007-05-14
Velocidades...
Boas,
Na base de um qualquer sistema de informação (afinal o assunto principal deste blog), existe sempre uma Base de Dados. Ora, as bases de dados, ou melhor, os sistemas de gestão de bases de dados não são um arquivo morto de dados mas sim um ponto fundamental da arquitectura e desempenho dos sistemas de informação.
Como deve ser (será ?) óbvio a arquitectura, o desenvolvimento e a manutenção da dita base de dados são pontos de extrema importância na criação e evolução dos sistemas de informação.
Esta introdução resume a minha opinião sobre a importância deste tema, e também para apresentar uma históriazinha:
Era uma vez um sistema de informação (vulgo ERP) sustentado por uma base de dados não muito grande (< 20 GiB) que demorava cerca de 17 horas (eu escrevo outra vez, 17 horas) a fazer um fecho de mês. Colocado o problema a um dos programadores do sistema, este respondeu: "eh pá isso é muito, deviam ser aí umas 8 ou 9 horas !!"...
(cai o pano para evitar mais vergonhas)
8 ou 9 horas para fazer umas contas a stocks e custos, enfim... será preciso mais para tirar a conclusão lógica ?
Será que isto é um sistema vagamente optimizado ??
Por hoje não digo mais nada...
Na base de um qualquer sistema de informação (afinal o assunto principal deste blog), existe sempre uma Base de Dados. Ora, as bases de dados, ou melhor, os sistemas de gestão de bases de dados não são um arquivo morto de dados mas sim um ponto fundamental da arquitectura e desempenho dos sistemas de informação.
Como deve ser (será ?) óbvio a arquitectura, o desenvolvimento e a manutenção da dita base de dados são pontos de extrema importância na criação e evolução dos sistemas de informação.
Esta introdução resume a minha opinião sobre a importância deste tema, e também para apresentar uma históriazinha:
Era uma vez um sistema de informação (vulgo ERP) sustentado por uma base de dados não muito grande (< 20 GiB) que demorava cerca de 17 horas (eu escrevo outra vez, 17 horas) a fazer um fecho de mês. Colocado o problema a um dos programadores do sistema, este respondeu: "eh pá isso é muito, deviam ser aí umas 8 ou 9 horas !!"...
(cai o pano para evitar mais vergonhas)
8 ou 9 horas para fazer umas contas a stocks e custos, enfim... será preciso mais para tirar a conclusão lógica ?
Será que isto é um sistema vagamente optimizado ??
Por hoje não digo mais nada...
2007-05-09
Acto de criação
A ignorância tem destas coisas:
Houve uma pessoa aqui há tempos que me perguntou porque é que uma "newsletter" que desenhou em HTML não saía como deve ser no browser... Uma análise superficial do código veio a revelar que afinal os endereços dos ficheiros de suporte (imagens e afins) estavam a apontar para os ficheiros do PC do dito "web developer" em vez de apontarem para os ficheiros que foram colocados no servidor...
Até aqui nada de novo, qualquer um se engana... O que mais me espantou foi o facto do "web developer" não saber distinguir entre os dois tipos de referência...
Digamos que isto se compara a um médico não saber qual é a posição correcta do estetoscópio, ou pelo menos devia-se comparar....
... em frente com o Choque Tecnológico, a minha parte de Choque já cá canta :)
Fiquem bem.
Houve uma pessoa aqui há tempos que me perguntou porque é que uma "newsletter" que desenhou em HTML não saía como deve ser no browser... Uma análise superficial do código veio a revelar que afinal os endereços dos ficheiros de suporte (imagens e afins) estavam a apontar para os ficheiros do PC do dito "web developer" em vez de apontarem para os ficheiros que foram colocados no servidor...
Até aqui nada de novo, qualquer um se engana... O que mais me espantou foi o facto do "web developer" não saber distinguir entre os dois tipos de referência...
Digamos que isto se compara a um médico não saber qual é a posição correcta do estetoscópio, ou pelo menos devia-se comparar....
... em frente com o Choque Tecnológico, a minha parte de Choque já cá canta :)
Fiquem bem.
OpenSource nas Empresas
Porque são as empresas portuguesas tão avessas ao Open Source ??
Será da capacidade técnica ?
Será que somos muito amigos das grandes companhias de software ?
Será que temos dinheiro a mais ?
Não nos preocupa o facto de podermos a vir não ser capazes de ler os nossos arquivos de informação no futuro ?
Enfim, algumas preocupações nocturnas para hoje, abertas a comentários ....
Será da capacidade técnica ?
Será que somos muito amigos das grandes companhias de software ?
Será que temos dinheiro a mais ?
Não nos preocupa o facto de podermos a vir não ser capazes de ler os nossos arquivos de informação no futuro ?
Enfim, algumas preocupações nocturnas para hoje, abertas a comentários ....
2007-05-04
Apresentação
Boa noite a todos !
Este é o primeiro post deste (novo) blog.
Pretendo com este espaço divulgar algumas ideias e recolher opiniões sobre Sistemas de Informação em geral e o Software Livre no âmbito dos Sistemas de Informação.
Para primeiro "desafio" vou propor que lancem temas que gostariam de ver abordados aqui.
Até já.
Este é o primeiro post deste (novo) blog.
Pretendo com este espaço divulgar algumas ideias e recolher opiniões sobre Sistemas de Informação em geral e o Software Livre no âmbito dos Sistemas de Informação.
Para primeiro "desafio" vou propor que lancem temas que gostariam de ver abordados aqui.
Até já.
Subscrever:
Mensagens (Atom)