Viva,
Vai decorrer no próximo dia 16 de Junho, na sala 201 da Fac. Letras da Universidade do Porto um evento técnico sobre traduções na distribuição Debian. A comunidade DebianPT agradece desde já o empenho do Porto Linux na organização do evento.
O programa inclui alguma conversa sobre aspectos importantes para a tradução do software Debian: programas, convenções, boas práticas, recursos, etc.. e de tarde vamos "meter mãos à massa" e traduzir alguns pacotes.
O evento deve começar lá pelas 10h30m, intervalo para o almoço aí pelas 12h30m e da parte da tarde é até haver força nas pálpebras :D
Mostrar mensagens com a etiqueta desenvolvimento. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta desenvolvimento. Mostrar todas as mensagens
2012-05-29
2008-07-28
Lenny "on the rocks"
Quer o título dizer que a próxima versão da distribuição Debian GNU/Linux já atingiu o estado de freeze.
A partir de agora só serão admitidas correcções de bugs e assim...
O anúncio completo está em http://lists.debian.org/debian-devel-announce/2008/07/msg00007.html.
Ide ver, ide....
A partir de agora só serão admitidas correcções de bugs e assim...
O anúncio completo está em http://lists.debian.org/debian-devel-announce/2008/07/msg00007.html.
Ide ver, ide....
2008-04-05
Partições de Dados - II
Já antes aqui tinha escrito da importância que pode ter uma correcta partição dos dados presentes numa base de dados de certa dimensão. Com os SGBDs modernos temos hipótese de usar diversos métodos de executar estas partições.
Os diferente métodos de particionamento de uma tabela dividem-se de acordo com a "orientação" das partições, e também de acordo com o modo como se definem os limites das partições.
Quanto à orientação, temos particionamentos "verticais" e "horizontais". O particionamento "vertical" consiste na divisão de registos com muitos campos em duas ou mais tabelas relacionadas e é, no fundo, a base da normalização.
O particionamento "horizontal" implica a divisão por duas ou mais tabelas dos registos inicialmente contidos numa só tabela. Esta divisão é feita considerando os valores de um campo de interesse. Normalmente consideram-se como interessantes para definir partições campos que tenham algum significado lógico no âmbito da aplicação usada, por exemplo, se tivermos uma tabela que guarde documentos é lógico dividi-la por datas.
Ao criar as partições de dados temos várias hipóteses de definir os intervalos a considerar: Intervalos de Valores, Listas, Funções de Hash ou combinações destas.
A particão de tabelas baseada em intervalos é talvez a mais comum e divide simplesmente a tabela original de acordo com o intervalo definido, por exemplo, se tivermos uma tabela de documentos "Doc" que armazene a data do documento no campo "DataDoc", podemos criar partições anuais (este exemplo é em PostgreSQL):
Claro que teríamos que ter o cuidado necessário para criar a restante estrutura e código para validar esta divisão. Noutros SGBD, por exemplo em Oracle, podíamos fazer simplesmente:
Em vez deste tipo de divisão, podemos usar uma lista de valores, por exemplo Cidades ou Países para obter as partições. Neste caso a diferença está na definição dos limites. Por exemplo, vendo o caso de uma tabela de Clientes que tivesse uma coluna Cidade, poder-se-ia fazer alguma coisa do género:
Por último, a divisão por Hash, usa uma função Hash para obter um valor que vai servir de base à definição das partições.
Os diferente métodos de particionamento de uma tabela dividem-se de acordo com a "orientação" das partições, e também de acordo com o modo como se definem os limites das partições.
Quanto à orientação, temos particionamentos "verticais" e "horizontais". O particionamento "vertical" consiste na divisão de registos com muitos campos em duas ou mais tabelas relacionadas e é, no fundo, a base da normalização.
O particionamento "horizontal" implica a divisão por duas ou mais tabelas dos registos inicialmente contidos numa só tabela. Esta divisão é feita considerando os valores de um campo de interesse. Normalmente consideram-se como interessantes para definir partições campos que tenham algum significado lógico no âmbito da aplicação usada, por exemplo, se tivermos uma tabela que guarde documentos é lógico dividi-la por datas.
Ao criar as partições de dados temos várias hipóteses de definir os intervalos a considerar: Intervalos de Valores, Listas, Funções de Hash ou combinações destas.
A particão de tabelas baseada em intervalos é talvez a mais comum e divide simplesmente a tabela original de acordo com o intervalo definido, por exemplo, se tivermos uma tabela de documentos "Doc" que armazene a data do documento no campo "DataDoc", podemos criar partições anuais (este exemplo é em PostgreSQL):
CREATE TABLE Doc_1999 (
CHECK( DataDoc >= DATE '01-01-1999' AND DataDoc <= DATE '31-12-1999') INHERITS (Doc) ; CREATE TABLE Doc_2000 ( CHECK( DataDoc >= DATE '01-01-2000' AND DataDoc <= DATE '31-12-2000' ) INHERITS (Doc) ; ... CREATE TABLE Doc_2008 ( CHECK( DataDoc >= DATE '01-01-2008' AND DataDoc <= DATE '31-12-2008' ) INHERITS (Doc) ;
Claro que teríamos que ter o cuidado necessário para criar a restante estrutura e código para validar esta divisão. Noutros SGBD, por exemplo em Oracle, podíamos fazer simplesmente:
CREATE TABLE Doc(...)
PARTITION BY RANGE (DataDoc)
(
PARTITION Doc_1999 VALUES LESS THAN (to_date('01-Jan-2000')),
PARTITION Doc_2000 VALUES LESS THAN (to_date('01-Jan-2001')),
...
)
Em vez deste tipo de divisão, podemos usar uma lista de valores, por exemplo Cidades ou Países para obter as partições. Neste caso a diferença está na definição dos limites. Por exemplo, vendo o caso de uma tabela de Clientes que tivesse uma coluna Cidade, poder-se-ia fazer alguma coisa do género:
CREATE TABLE Clientes_Lisboa (
CHECK( Cidade = 'Lisboa') INHERITS (Clientes) ;
CREATE TABLE Clientes_Porto (
CHECK( Cidade = 'Porto') INHERITS (Clientes) ;
...
Por último, a divisão por Hash, usa uma função Hash para obter um valor que vai servir de base à definição das partições.
2008-03-02
Jardim Zoológico
No seguimento dos artigos e das minhas aventuras com o Qemu, cá vai um site interessantíssimo para quem gosta de experimentar:
Free Operating Systems ZOO
Façam-lhe uma visita, que vale a pena.
Free Operating Systems ZOO
Façam-lhe uma visita, que vale a pena.
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-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-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-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-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...
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-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...
Subscrever:
Mensagens (Atom)