SQL e a programação por Objectos

Existe uma grande separação entre as representações de dados baseadas na teoria relacional de Codd e Date, implementadas correntemente nas Bases de Dados Relacionais e as representações dos mesmos dados do ponto de vista da programação orientada a objectos. As modernas frameworks de programação incluem APIs de "persistência" de dados, ou seja, mecanismos que permitem converter a representação baseada nas tabelas relacionais em classes e objectos adequados à manipulação pela linguagem em causa. Esta tradução é, muitas vezes, deixada ao critério da framework usada.

Correntemente não se pode prescindir de uma ou de outra forma de representar os dados e há necessidade de recorrer a uma qualquer espécie de mapeamento ou tradução de variáveis "relacionais" (os registos das bases de dados) para variáveis "Objecto" (os elementos do código da aplicação). Esta diferença de representações e os problemas a ela associados são normalmente chamados de "Object-Raltonal Impedance Mismatch".

Num artigo muito interessante, Ted Neward fala deste problema como o Vietname da Informática, ou seja um problema cuja solução mais óbvia (o mapeamento Objecto-Relacional) está condenada ao fracasso.

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):

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.

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.

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 !

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...

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.

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...

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".

Rapidinha

Uma pergunta rápida, que me "assaltou" o espírito...

Será que um ERP baseado em Web Services pode ter algum interesse ??

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...

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.

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...

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...

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 !

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...