Tabelas Particionadas

    Toda tabela particionada serve para auxiliar nos serviços de consultas, melhor distribuição e atualizações e remoção de dados. Geralmente é recomendado para seguir com particionamento de tabelas com muitos registros e mesmo otimizadas quando são feitos tuning e mesmo assim ocorrendo um má desempenho sendo comprometedor para o ambiente.

Segue abaixo um exemplo de como ficaria uma tabela particionada:

Alguns pontos abaixo para seguir com particionamento de tabelas:

• Processo de Leitura a Disco

• Uma leitura não irá trazer um único registro e sim um conjunto de registros, se o registro for muito grande, isto é, muitas colunas, é provável que ele esteja armazenado em mais de um bloco, isso poderá acarretar em diversos processos de I/O na busca de determinado dado.

• Desmembramento Horizontal

• Uma tabela com trinta ou quarenta colunas, muito comum em sistemas desenvolvidos a muito tempo, mas também poderá ser encontrado em situações em que são cadastrados detalhes de uma peça, como dimensões, peso, material, etc., além do código e da descrição da peça. Se formos olhar apenas para questões de estoque e faturamento, o código, nome e quantidade são relevantes, as demais informações não são. Se olharmos para uma linha de produção, os demais itens são imprescindíveis, pois temos que colocar a peça certa, caso contrário nosso produto será falho, incompleto ou incorreto.

• Desmembramento Vertical

• Os registros de ligações controladas por uma empresa de telefonia, mês a mês uma nova partição irá surgir e será alimentada com os dados referentes àquele mês, normalmente a consulta é realizada no período da partição, mas eventualmente é necessário fazer uma consulta mais abrangente, necessitando de uma varredura em toda a tabela. Quando esta tabela é consultada, a varredura acontecerá na partição referenciada, diminuindo assim sensivelmente o tempo de busca de cada registro.

Quais vantagens:

• Desempenho em leitura.
• Diferentes dispositivos de gravação.
• Desempenho em gravação.
• Expurgo de dados.
• Rotinas de manutenção.
• Pontos de falha
• Escalabilidade.

Quais desvantagens:

• Administração
• Desenvolvimento

Conclusão:

    Entendemos que uma grande quantidade de SGBDs oferecem, e é muito importante entender os benefícios para trazer em uma organização onde existem bancos enormes no qual sempre vem crescendo uma mal desempenho devido o volume de dados. A particionar tabelas apresenta um tuning enorme em cima de desempenho para um banco de dados com tabelas grandes no qual conseguimos garantir a distribuição e recuperação de dados com eficiência.

História Ingres

Bom novamente, acabei ficando um pouco ausente do meu blog mas hoje estou de volta!

Gostaria de contar um pouco da história de um banco chamado Ingres.

Então vamos lá!.

Ingres é um SGBD (Sistema Gerencial de Banco de Dados) relacional, pertence a CA (É uma empresa de software estadunidense, fundada em Nova Iorque por Charles Wang em 1976).

 

Em 2004, ela acabou lançando o Ingres r3 e seu código fonte foi liberado para a comunidade open source e demais usuários do banco, que podem a partir desse momento, utilizarem-no sem nenhum custo com licença de uso.

Vem sendo considerado um dos mais robustos e poderosos SGBD para armazenamento de dados de missão crítica, e que necessitam de um grande nível de segurança no acesso e armazenamento, bem como ter suporte a grande concorrência de acesso às informações nele armazenadas.

Em 1973 quando o Sistema R havia sido iniciado pela IBM, os pesquisadores liberaram muitos artigos descrevendo o sistema que construíam. Dois cientistas de Berkeley, Michael Stonebraker e Eugene Wong, se interessaram após lerem os artigos, e decidiram iniciar um projeto de banco de dados relacional para eles.

Eles já tinham conseguido dinheiro por terem pesquisado um Banco de Dados Geográfico para o grupo econômico Berkeley’s, que chamaram de Ingres, para Sistema de Recuperação de Gráficos Interativo. Eles decidiram usar este dinheiro para fundar seu projeto relacional, e usado isso para criar um projeto novo muito melhor e maior. Para conseguir mais dinheiro, Stonebraker aproximou o grupo DARPA, a fonte de financiamento óbvia para pesquisas de computação daquele tempo. Stonebraker introduziu sua ideia para outras agências, e, com ajuda de seus amigos ele obteve a sustentação do NSF e de três agências militares: o Escritório de Pesquisas Científicas da Força Aérea Americana, o Escritório de Pesquisas do Exército Americano e o Comando Eletrônico dos Sistemas da Marinha Americana.

Com este financiamento o INGRES foi desenvolvido em meados dos anos 1970, por uma equipe que continham estudantes e professores. INGRES alcançou uma evolução similar ao Sistema R, com um protótipo adiantado em 1974 seguidos por revisões para fazer o código principal. INGRES conquistou uma pequena comunidade de usuários, e os membros dos projetos reescreveram o projeto muitas vezes para incorporar a experiência acumulada, e novas ideias. INGRES remanesceu pela maior parte do tempo como o Sistema R da IBM, mas baseado nos sistemas "low end", chamados Unix em máquinas do DEC.

Atualmente a CA apontou para uma definição interna extremamente importante para dar garantia de continuidade do Ingres. A CA está revendo grande parte de seus software internos que utilizam banco de dados para executarem sobre bases de dados Ingres.

Bom é isto ai, espero que tenham gostado após um bom tempo sem postar.

Mas espero voltar sempre com atualizações de informações sobre Bancos de Dados.

 

Matriz de Interações - CRUD

Bom pessoal hoje vamos falar um pouco mais sobre o que é um conceito de Matriz - CRUD.

Vou me expressar de uma forma simples e clara, pois não tem muito o que esconder sobre o conceito CRUD.

• Primeiramente vamos começar o que é CRUD?

A abreviação CRUD mapeada para o padrão ISO/SQL de uma forma como: (Create, Retrieve, Update e Destroy) ou seja estas expressão em língua inglesa deriva-se de Create, Read, Update e Delete, assim elas são usadas para definir quatro operações básicas utilizadas em banco de dados relacionais (RDBMS) ou para termos de usuários, Criação, Consultas, Atualização e Destruição de Dados.

Existem também outros acrônimos que podem ser utilizados para definir as operações acima, como:

• ABCD: Add, Browse, Change e Delete
• BREAD: Browse, Read, Edit, Add e Delete
• VADE(R): View, Add, Delete, Edit (e Restore, para sistemas com processos transacionais)

• Como é construida uma Matriz - CRUD?

É construída de uma forma que as funcionalidades são listadas em um dos seus eixos e as entidades no outro. Cada células de interseção possuem algum tipo de interação existente, ou seja, mostram que a entidade será afetada pela execução de uma determinada funcionalidade e explicita as propriedades CRUD para tal interseção.

São definidas entre um desenho de sistemas de informações de diferentes naturezas, modeladores podem usar o artefato para verificar a consistência entre as definições funcionais e de dados inerentes à solução que estão desenvolvendo um ambiente para melhor desempenho dos usuários e eficácia na organização de dados com enorme rapidez nas respostas para os usuários. 

Um dos grandes pontos é criar células de processo para comunicarem a cada uma das suas células quem vem descrevendo as suas devidas ações de uma atividade que exerce sobre o tipo de objeto de dados associado, vindo a expressar as expressões como, (Criação, Consultas, Atualização e Destruição de Dados).

As matrizes CRUD, são muito útil na identificação de clusters (ou blocos de construção) que podem ser usados para elaborar componentes como, patterns, módulos ou mesmo aplicações voltadas ao suporte de processos de negócio específicos.

Assim as matrizes de interações CRUD são utilizadas para se definirem em relacionamentos de uma forma muito concisa, também trazendo alguns benefícios do seu uso, também não sendo limitados.

Imagino que seja isto meus caros leitores espero que tenham gostado.

Em breve estarei postando mais sobre as derivações de algumas matrizes de interações utilizando conceito CRUD, assim citando mais conceitos de uma utilização de uma Análise de Cobertura e Análise de Cluster para fechar um conjunto com todo o conceito CRUD.

História MariaDB

Bom pessoal hoje vamos falar um pouco sobre o famoso banco MariaDB.

MariaDB é um banco de dados que surgiu como fork do MySQL, criado pelo próprio fundador do projeto após sua aquisição pela Oracle. O Google está seguindo a mesma trilha de projetos como a Wikipedia e distribuições como a SUSE e trocando o MySQL pelo seu fork MariaDB. O Google também está colaborando com a MariaDB Foundation, incluindo o desenvolvimento de recursos no software que permitam a migração.

A intenção principal do projeto é manter uma alta fidelidade com o MySQL.

O líder do MariaDB é Michael 'Monty' Widenius, o fundador do MySQL e da Monty Program AB.Para conseguir isso, Programa Monty trabalha para contratar os melhores e mais brilhantes desenvolvedores do setor, trabalhar em estreita cooperação com a maior comunidade de usuários e desenvolvedores no verdadeiro espírito do software livre e open source e software de lançamento de uma forma que equilibre a previsibilidade com confiabilidade.

MariaDB é um avançado substituto para o MySQL e está disponível sob os termos da licença GPL v2.

Segurança

A segurança é muito importante no mundo de hoje e é um foco especial para os desenvolvedores do MariaDB. O projeto mantém os seus próprios patches de segurança situados no core de MySQL. Para cada versão do MariaDB os desenvolvedores também incluem todos os patches de segurança do MySQL e suas melhorias, caso necessário. Quando problemas de segurança críticos são descobertos, os desenvolvedores imediatamente preparam e distribuem novas versões do MariaDB para obter as correções o mais rápido possível.

Muitos dos problemas de segurança encontrados no MySQL e MariaDB foram encontrados e relatados pela equipe MariaDB. A equipe trabalha em estreita colaboração com o MariaDB para garantir que todas as questões de segurança sejam prontamente comunicadas e explicadas o mais detalhadamente possível.

Compatibilidade

MariaDB é mantido atualizado com a última versão do MySQL e irá funcionar exatamente como MySQL. Todos os comandos, interfaces, bibliotecas e APIs que existem no MySQL também existem no MariaDB. Não há necessidade de conversão de dados para exibir MariaDB.

Vantagens do MariaDB sobre o MySQL

Objetivamente, as principais vantagens do MariaDB, já citadas acima, são:

• Velocidade;
• Menor exigência de hardware;
• Total compatibilidade com o MySQL.

Poderíamos citar vantagens subjetivas, mas deixaremos a critério de cada um pesquisar e formar sua própria opinião.

Como tirar máximo proveito do MariaDB

A simples conversão do MySQL para MariaDB já representa algum ganho de velocidade e de diminuição do consumo de recursos da máquina.

Entretanto, para tirar o máximo do banco de dados, é necessário converter as tabelas de MyISAM (padrão do MySQL) para XtraDB, o formato otimizado do MariaDB.

Desvantagens do MariaDB em relação ao MySQL

Não há desvantagens importantes do MariaDB com relação ao MySQL, a não ser o “peso” que as marcas MySQL e Oracle têm, sugerindo um produto de qualidade superior, ou com suporte “garantido” por mais tempo.

O que alguns podem encarar como uma desvantagem secundária é o fato de o MariaDB apresentar o seu melhor rendimento usando tabelas do tipo XtraDB (que substituem o InnoDB), que por sua vez não têm suporte a índices do tipo “full text”, característica que as tabelas MyISAM tem, e que pode ser requisito para algum sistema.

No caso do WordPress, o único plugin que sugere o uso de índices “full text” é o YARPP; ele usa este tipo de índice para encontrar posts relacionados a partir do texto completo do post.

Na prática, não chega a ser um problema. Primeiro, porque os índices “full text” não apresentam a mesma precisão para textos em Português que para textos em Inglês, e, segundo, porque as pesquisas baseadas em textos completos continuam funcionando, apenas não contam com o índice para acelerá-las.

Por fim, uma vez convertido um servidor cPanel para usar o MariaDB, não é seguro voltar a usar o MySQL original sem ter de “formatar” a máquina toda.

Eu recomendo é um ótimo!

Álgebra Relacional - História

Hoje vou falar sobre Álgebra Relacional , focando no conceito juntamente com a sua história no meio da ciências da computação, álgebra relacional é uma derivação descendente da lógica de primeira ordem (LPO) e da álgebra de conjuntos em relação das operações sobre a relação finítimo, que auxilia o trabalho ao identificar os componentes de uma tupla por nome (chamado o atributo) ao invés de uma coluna de chaves numéricas, o qual é chamado a relação na terminologia de banco de dados.

A principal aplicação da álgebra relacional é sustentar a fundamentação teórica de banco de dados relacional, particularmente linguagem de consulta para tais bancos de dados, entre os maiores o SQL.

A álgebra relacional recebia pouca atenção fora do campo da matemática pura até à publicação em 1970 do modelo relacional de dados de E.F. Codd. Codd propôs tal álgebra como a base das linguagens de consulta de banco de dados.

Na álgebra relacional, são admitidas ambas perspectivas de dar um nome ou não, dependendo se as tuplas são dotadas de nome de componente ou não. Na perspectiva sem nome, a tupla é simplesmente um membro de um produto cartesiano. Na perspectiva da tupla ter um nome de componente, tuplas são funções do conjunto finito de atributos U (da relação) a um domínio de valores (assumidos distintos dos de U). As álgebras relacionais obtidas das duas perspectivas são equivalentes.

Também a álgebra relacional é equivalente em poder expressivo a cálculo relacional (e por conseguinte lógica de predicado ou primeira ordem); esse resultado é conhecido como o teorema de Codd. Na prática, deve ser prestada atenção em desambiguar as duas linguagens porque a negação quando aplicada a uma formula em cálculo, faz a construção da formula que pode ser verdadeira ou um conjunto infinito de tuplas, enquanto o operador diferença na álgebra relacional devolve sempre um resultado finito.

Para ultrapassar estas dificuldades, Codd restringiu os operando da álgebra relacional somente para relação finita e propôs suporte restrito para a negação (NOT) e a disjunção (OR). Restrições análogas são encontradas em muitas outras linguagens de programação lógicas. Codd definiu o termo completeza relacional para se referir a uma linguagem que está completa em respeito a cálculo de lógica da primeira ordem à parte com as restrições que ele propunha. Na prática as restrições têm um efeito adverso na aplicabilidade da sua álgebra relacional para usos de banco de dados.

Definimos assim a álgebra relacional como uma linguagem de consulta formal i.e. uma coleção de operações de alto nível sobre relações ou conjuntos.

As operações em questão são: 

• Restrição
• Seleção
• Projeção
• Produto
• União
• Intercessão
• Diferença
• Junção
• Dividir

De facto, dos oito, só 5 são primitivos, nomeadamente restrição, projeção, produto, união, e diferença. Os outros três podem ser definidos destes cinco. Todas essas operações produzem uma nova relação como seu resultado.

Bom é isto ai, em breve postarei mais sobre Álgebra Relacional com alguns exemplos de algumas operações para ficar de mais fácil entendimento.

Meio Corporativo - Utilização de Banco de Dados

Bom vamos falar um pouco sobre qual a grande finalidade de apresentar a importância de Banco de Dados dentro de uma organização no meio corporativo, vindo a buscar uma forma objetiva de identificar quais são os meios de informações que estão armazenadas em seu interior, mostrando os benefícios e os problemas trazidos para a realidade do meio corporativo.

Com o surgimento da tecnologia, os dados adquiriram uma imensa necessidade de armazenamento de volume na memória de armazenamento do computador. Sendo de modo que crie e extraia informações importantes que possam influenciar de alguma forma nas tomadas de decisões, assim surgindo o Banco de Dados ou DB (Data Base), nada mais é um conjunto de elementos que integrados entre si, que se relacionam de forma lógica consolidando registros armazenados de forma separada em arquivos que são fornecidos para as aplicações em bancos independentes dos programas de aplicação que são utilizados com um meio de dispositivos armazenados.

Com isso o Meio Corporativo consegue garantir uma grande necessidade que muitas empresas ou de algumas companhias onde eles têm uma falha que necessitam de uma grande integridade da informação vindo a ser continua para qualquer ação de tomada de decisões no exato momento. Assim o Meio Corporativo foca em busca de alguns resultados de extrema importância para o melhor desempenho destas informações, sendo muito segura e de fácil acesso e rápida para os usuários que as utilizam aplicações no interior das empresas ou das companhias trazendo grandes benefícios. Porém é necessário que os usuários tenham um conhecimento ou um treinamento antes de começarem a utilizar alguns sistemas de informações assim concretizando a utilização de forma eficácia.

Também não podemos deixar de mencionar que é de vasta importância para a base de informação ser sempre acompanhada por alguns DBA’s, pois é necessário um espelhamento do banco com seus devidos backups diários, caso ocorra alguma falha de infraestrutura levando a afetar a máquina de produção do banco. Necessário que os DBA's estejam preparados para realizar um remanejamento de fácil acesso para subir a máquina espelho que nada mais é uma contingência para produção sem ocorrer divergências nas informações, se a ocorrência for gravíssima afetando o local físico dos servidores é de grande extrema importância que menciono, pode-se também subir uma base de backup na nuvem ou em outro local.

Quando for necessário realizar uma manutenção na base de produção sempre deve homologar a mudança em uma base de homologue. Lembrando deve-se informar os usuários referente a indisponibilidade da mudança. Somente assim é possível realiza-la. Caso possível entrar com uma base contingência em produção ou mesmo até subindo a base na nuvem.

Principais pontos referentes ao banco de dados em uma organização são:

• Integridade nos dados.
• Rápidas tomadas de decisões, devido fácil acesso as informações.
• Atualizações de dados pelos usuários de forma extremamente e rápida.
• Ótima segurança nas informações devido a criticidade.

Bom é isto é, este tópico de hoje foi um diferencial devido a extrema importância de um Banco de Dados no dia a dia.