Danielle Monteiro é mestre em Engenharia da Computação, Microsoft MVP e MongoDB Female Innovator, além de colunista do iMasters. Mas, de acordo com a própria, o que melhor a representa é a definição do seu chefe “um espirito inquieto!”.

Danielle começou a trabalhar com tecnologia no segundo semestre da faculdade. Era desenvolvedora e, apesar de adorar o que fazia, alega que a transição para a área de dados foi natural. Quando conheceu o SQL Server 2005, se apaixonou! Hoje, ela trabalha com arquitetura de dados e participa de diversas comunidades, ministra treinamentos, escreve artigos e mantém um blog, o DB4Beginners.com. Se mantém inquieta!

Nesta entrevista, ela fala mais sobre a atuação dos arquitetos de bancos de dados, a (às vezes conturbada) relação desses profissionais com desenvolvedores e sobre o mercado em questão.

Revista iMasters: Como arquiteta de dados, qual é o seu maior desafio quando falamos da dificuldade de gerir essa enorme quantidade informações?

Daniele Monteiro: São vários os desafios. O maior deles é ter governança de dados e agilidade (ao mesmo tempo e em igual proporção). Outro é conhecer a linhagem dos dados mesmo tendo uma quantidade enorme de sistemas e integrações; Tamém é importante (e difícil) garantir a segurança e integridade em bancos de dados NoSQL. E por fim, mas não menos importante, estar aderente às leis cada vez mais rígidas, como a GDPR e a Lei Geral de Proteção de Dados.

Revista iMasters: Muitas pessoas ainda não entendem a real diferença entre banco de dados relacionais (SQL) e não relacionais (noSQL), você conseguiria traçar um perfil para cada um e onde cada tipo é melhor utilizado?

Daniele Monteiro: Adorei esta pergunta! Bom, em 1970, Edgar Frank Codd, um brilhante matemático da IBM, publicou um artigo onde definia formalmente o modelo relacional. Entre os anos de 1981 e 1983, a IBM vendeu os primeiros bancos de dados relacionais.

Neste momento, o modelo relacional já era bem popular e eu me arrisco a dizer que trazia tanta euforia quanto os bancos de dados NoSQL trazem hoje.

O hardware era caro e os dados redundantes aumentariam muito o custo dos sistemas. Por isso, a opção mais prudente e sábia era normalizar os dados.

E aqui, entenda normalização como “um conjunto de regras que visa, principalmente, a organização de um projeto de banco de dados para reduzir a redundância de dados, aumentar a integridade e o desempenho.

Quando usamos um banco de dados relacional, a linguagem SQL é o padrão para consultas. Os dados são armazenados em tabelas (linhas e colunas bem definidas) e costumam ser normalizados, terem integridade referencial, e as consultas normalmente fazem a junção (JOIN) de dados armazenados em diversas tabelas.

O termo NoSQL foi utilizado no início de 2009 para nomear um evento que discutiria bancos de dados open source e distribuídos. NoSQL é o agrupamento de um conjunto de bancos de dados não relacionais, sem esquema, executados em clusters, e que (em sua maioria) não utilizam a linguagem SQL para consultas.

Além disso, os dados estão organizados de outras formas diferentes de linhas e colunas, e uma boa prática é ter em um único objeto (por exemplo um documento JSON) toda a informação necessária, ou seja, as junções de dados não são recomendadas, porque com o barateamento do hardware a redundância de dados (desde que controlada) deixou de ser um ofensor, e os Joins podem ser um problema quando o volume de dados é muito grande.

De acordo com a organização dos dados, podemos categorizar os banco de dados NoSQL em 4 grandes grupos:

Key-Value

• Redis é o banco de dados key-value mais usado, as consultas são muito rápidas, utilizam a memória dos servidores e as pesquisas são feitas somente nas chaves. São fantásticos para cache, fila, mensageira, e normalmente usados como mecanismo de armazenamento secundário.

Documentos

• O MongoDB é o banco de dados NoSQL mais usado no mundo. É fenomenal para armazenar dados semiestruturados, normalmente no formato JSON. Use-o quando a mesma entidade possui atributos diferentes. Por exemplo, um e-commerce que comercializa sofás, livros e geladeiras. Todos são produtos, mas cada um tem um conjunto diferente de atributos.

Família de colunas

• Nesta categoria, o Cassandra é o banco de dados mais conhecido. Ele é fenomenal para a escrita de grandes volumes de dados. Nele, a redundância é aceita e permitida, e os Joins são proibidos (conselho de amiga!).

Grafos

• Nesta categoria, o Neo4J é o banco de dados mais conhecido. O foco da modelagem de dados está na relação entre as informações. Este tipo de NoSQL é excelente para sistemas de indicação, detecção de fraudes e inteligência artificial.

Revista iMasters: Uma questão que sempre é colocada, ainda mais quando falamos da relação entre desenvolvedores e arquitetos de dados/ DBAs é a questão de onde a regra de negócio deve ser colocada. Para você, as regras de negócio devem estar no banco de dados ou na aplicação; por quê?

Daniele Monteiro: Momento rabugenta! Bancos de Dados armazenam e manipulam grandes volumes de dados. Regras de negócio devem ser tratadas na aplicação.

Não é só a chatice que impera, mas devemos considerar alguns pontos, por exemplo, como as regras de negócio no banco de dados causam acoplamento; como elas dificultam a portabilidade; normalmente os desenvolvedores não conhecem profundamente a linguagem SQL e suas variações (me perdoem as exceções, mas infelizmente conheço poucos desenvolvedores com este skill); a manutenção e os testes são mais complexos e os bancos de dados não são adequados para o processamento linha a linha.

Revista iMasters: Como a evolução da capacidade de armazenamento e performance dos hardwares modificaram o modo como nós armazenamos e consumimos dados atualmente?

Daniele Monteiro: Eu sempre repenso a tecnologia quando converso com os meus avós. Diariamente, minha avó me manda vídeo, uma foto ou um áudio me desejando bom dia (às vezes manda tudo junto também). Recentemente, ela me mostrou o celular novo e eu perguntei se era melhor que o antigo.

A resposta foi fofa: “este tem mais gigas para eu guardar as fotos de vocês”. Moral da história, a evolução do hardware aproximou a tecnologia da população não técnica.

Em 1956, um HD de 4,4 MB pesava mais de meia tonelada e custava milhões de dólares. Era indispensável criar estruturas de dados que economizassem os recursos computacionais.

Os primeiros bancos de dados relacionais foram comercializados nos anos 1980, um período onde o custo do HW ainda era muito alto. Por isso, normalizar os dados era tão importante; pois, na questão de custo, a redundância era cara!

Hoje, temos muitos dados, e a mentalidade mudou. Existem novas linguagens, novos SGBDs, novas possibilidades que só são viáveis com novos HW. É mais caro perder um cliente do que armazenar muitos dados. A redundância que já foi a vilã, hoje pode ser aliada do desempenho almejado.

Para resumir, os novos HW (mais baratos e mais potentes) nos dão novas possibilidades de armazenamento (bancos de dados relacionais, bancos de dados NoSQL, data lakes etc.) e de uso (aplicativos mobile, inteligência artificial, aplicativos cliente/servidor), aumentando a nossa responsabilidade com a arquitetura das soluções, e por outro lado, possibilitando que todo tipo de pessoa tenha acesso a tecnologia.

Revista iMasters: O que pode acontecer com os dados ou a performance de um servidor de banco de dados mal configurado? Já que muitos desenvolvedores apenas instalam o banco ou criam instâncias de banco sem se preocupar com as configurações do mesmo.

Daniele Monteiro: Servidor de banco de dados configurado por desenvolvedor dá mini infartos nos DBAs… É preciso conhecer as características do SGBD que está sendo instalado, para que ele seja usado de forma eficiente e eficaz.

Algumas tragédias que podem acontecer, são:

• Incidentes de segurança;
• Má utilização do HW;
• Desempenho inadequado;
• Perda de dados;
• Inconsistências.

Revista iMasters: Qual a importância de sabermos o tipo de licença do banco de dados para a utilização do mesmo em uma aplicação?

Daniele Monteiro: Aproveitando o gancho, preciso fazer uma observação importante – principalmente sobre os bancos de dados NoSQL. Eles não são gratuitos e são executados em servidores. Vale lembrar que, em muitos casos, a versão Community tem limitações de recursos e suporte.

Voltando para a pergunta, uma licença é um documento que define os limites de uso que um usuário pode ter em relação a um software ou SGBD. Não observar as licenças pode acarretar em multas, erros, limitações de recursos, problemas de desempenho e de segurança.

Revista iMasters: Você é bastante ativa em várias comunidades de desenvolvimento. Entre as linguagens que você participa, qual a diferença da visão dos desenvolvedores quando falamos de banco de dados? É muito diferente a visão de acordo com a linguagem que é utilizada?

Daniele Monteiro: A maioria dos desenvolvedores não gosta de banco de dados, e isso independe da comunidade. Mas posso dizer que cada comunidade tem o seu “malvado favorito”; por exemplo, PHP com MySQL, .Net com SQL Server, Java com Oracle…

Revista iMasters: Recentemente, você falou sobre dados no TEDx São Paulo. Qual a dificuldade que você vê para as pessoas que não são da área de TI entenderem como funciona a relação de produção, armazenamento e consumo de dados? E qual artifício você utilizou para levar um tema tão complexo a um público não técnico.

Daniele Monteiro: O TEDx São Paulo foi um enorme desafio! Nas primeiras versões da minha talk, eu estava muito insatisfeita, porque os exemplos que eu estava usando eram jargões de tecnologia, e nos ensaios as organizadoras do TEDx disseram que não eram conhecidos pela maioria das pessoas. Insatisfeita ou não, segui este primeiro caminho. Ensaiei a talk, ajustei…

Durante o TDC-SP, o Bruno Souza me alertou sobre a minha conexão com o público. Eu realmente não tinha pensado neste “detalhe”, e nem sabia o que fazer. Mas em uma conversa com o Edson Yanaga e com o Bruno, comentei que eu gostaria de poder tirar uma selfie com meu pai (já falecido), porque não lembro bem do rosto dele e não tenho uma foto nítida. Neste momento a minha talk mudou.

Eu sabia que precisava mostrar que os dados fazem parte da nossa rotina, que são importantes e que podem acabar com as empresas. Para isso montei a seguinte sequência:

• A minha angústia em esquecer o rosto do meu pai – momento de conexão com a plateia;
• Quantidade de dados disponíveis e a explicação de que tudo são dados – Introdução da ideia;
• O desafio das empresas em lidar com dados – Conclusão da minha ideia.

Não usei nenhuma técnica infalível. Fui transparente em falar da minha dor, me expus, segui uma sequência definida e ensaiei. A loucura (ou a magia) foi ver gente chorando quando falei do meu pai. Saí do palco com a melhor sensação possível, e ainda tenho tremedeira de lembrar destes momentos.

***

Artigo publicado na revista iMasters, edição #28: https://issuu.com/imasters/docs/imasters_28_v5_issuu