Arquivo da categoria: Teoria de Banco de Dados

MySQL e o GDPR

O que é o GDPR?

Global Data Protection Regulation ou Regulamento Geral sobre Proteção de Dados é uma regulamentação, criado pela União Européia, mas, com abrangência global. Antes de ser uma regulamentação, é acima de tudo, um belo conjunto de boas práticas que deveria ser adotado por toda empresa que, de alguma forma, coleta e manipula dados de pessoas (físicas e/ou jurídicas) e estão interessadas em manter sua imagem institucional, além, obviamente, de mitigar prejuízos financeiros.

A GDPR não é uma regulamentação nem modismo de última hora. Ele começou a ser rascunhado em 2010, e, começou a ganhar corpo e forma por volta de 2012. Aprovado em 2016, quando foi definido sua data de entrada em vigor a partir de 25/06/2018, portanto, existiu um prazo extenso de quase 2 (dois) anos para que as empresas se adequassem à ele.

Continue lendo MySQL e o GDPR

MySQL 5.7 – TableSpace Genéricas v2.0 – A nova Onda

O conceito de tablespace não tem nada de novo. Só não é mais velho que eu. Vários outros RDBMS (bancos de dados) o implementam faz algum tempo. No MySQL foi implementado pelos primórdios do innoDB.

Em linhas gerais o que é uma tablespace?
Tem algumas palavras em inglês que não fazem o menor sentido traduzidas, ou, em traduzi-las. Concorda comigo? Para mim, tablespace é uma dessas palavras. Vamos lá: “espaço de tabelas”. Tablespace é uma área, física e/ou lógica, na qual se aglomeram uma ou mais tabelas. É como se fosse uma área reservada para uma, ou, um grupo de tabelas. Seja com o objetivo de organização (tabelas com mesmo fim, aplicação, etc), volumetria, performance, segurança, etc.

O MySQL e sua épica jornada com tablespaces
No princípio de tudo, e até a chegada da versão 5.1, todas as tabelas com storage engine innoDB eram, compulsoriamente, criadas dentro de uma tablespace única, também chamada de compartilhada (shared tablespace). Fisicamente, consistia de um arquivo com síndrome de Buzz (pois, crescia ao infinito e além), de nome ibdata, que, ficava logo abaixo da raiz do DATADIR (diretório de dados, definido pela variável datadir, e, onde reside o schema do MySQL). Esta implementação me rendeu muitas horas de sono, pois, era uma verdadeira armadilha. Por ser um único arquivo contendo várias tabelas, apresentava contenções de S/O, era de difícil sustentação e manutenção.

Continue lendo MySQL 5.7 – TableSpace Genéricas v2.0 – A nova Onda

Facebook: do MySQL ao TAO

Facebook-TAOO Facebook dispensa qualquer tipo de apresentação. Até acho que existe mais gente no “face” do que viva no mundo real. Durante muitos anos o Facebook rodou e confiou na plataforma LAMP com Linux, Apache, MySQL-MemCache e PHP. Com o passar dos anos sua base de dados foi crescendo: 1TB, 10TB, 50TB, 100TB… 200TB, 500TB e continua crescendo.

De fato, o Facebook usou, ativamente, o MySQL até por volta de 100TB. Ooops, quer dizer que o MySQL pode ser escalado até 100TB de base? Sim e não! Eu, particularmente, acredito que o MySQL é muito competente, mas, eu não me sentiria confortável com uma base maior que 2TB ou 3TB. A dificuldade de manutenção acima disso é muito grande. Até 1TB é tranquilo. Mas, voltando ao Facebook, para conseguir a façanha de usar o MySQL com 100TB eles lançaram mão de milhares de “shards” lógicos controlados pela aplicação e sistema operacional. Inclua-se na aplicação, não só o site, mas também o MySQL personalizado pela equipe interna de desenvolvimento. Personalizar o MySQL não é para qualquer um. E, passa a ser mais um ponto de atenção… a cada atualização da comunidade e/ou do fabricante é preciso ser revista com atenção pela equipe de desenvolvimento. Controlar uma dezena de “shards” lógicos já é um drama, imagine milhares. É muito “if”! “If” nome do fulano começa com “A” os dados estão no servidor tal, “If” o nome do ciclano inicia com “C’, e, mora na Holanda, os dados estão no servidor 1.321! “If’ o desenvolvedor se perdeu no monte de “If”… só sobra o “f” (complete a palavra)!

Continue lendo Facebook: do MySQL ao TAO