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...
Subscrever:
Mensagens (Atom)