interoperabilidade entre bancos de dados
TRANSCRIPT
2
Sobre mim• Mestre e doutorando em computação pelo ITA
• Escritor da SQL Magazine, Fórum Access, Java Magazine, SQLServerCentral.com e outras
• Colaborador do iMasters há 10 anos
• Autor do livro “Conversando sobre banco de dados” (http://migre.me/ahlSY)
• Co-autor do @databasecast
• Blog: http://pichiliani.com.br
3
Roteiro
• Cenário multi-banco
• Conceitos comuns
• Interoperabilidade na administração
• Trocando objetos, dados e instruções
• Conclusão
4
Cenário multi-banco (1)• Ambientes, plataformas e bancos de dados diferentes são uma realidade• O banco de dados nunca trabalha sozinho:
– ERP, PDV, CMS, Controle de acesso, IRPF, Intranet– Sistemas customizados e desenvolvimento interno– Sistemas multi-banco
• Principais SGBDR: SQL Server, Oracle, MySQL, PostgreSQL e DB2• Novo talento no pedaço: NoSQL e newSQL• Não esqueça dos BDs na núvem…• Profissionais de desenvolvimento, administração e infra devem dominar
individualmente os bancos de dados• E também saber como eles devem unir forças e trabalhar junto• Tarefas comuns: montar um ambiente de testes/homologação, transferir
dados, criar uma solução de replicação, analisar, comparar e estudar o desempenho de tarefas semelhantes em diferentes bancos de dados, etc
5
Cenário multi-banco (2) - Planejamento• A maioria dos sistemas e aplicações trabalha com apenas um BD• Suporte a diferentes BDs sub-utiliza recursos do mesmo. Mas fornece algum tipo
de escolha para o cliente• Geralmente software livre não se preocupa em ser multi-banco. E aplicações web
também não• Aplicação multi-banco requer desenvolvimento adicional e camadas adicionais de
software• Há também cenários de dados não estruturados, arquivos texto e bancos de
dados embarcados• Em cenário multi-plataforma (desktop, web, app. móveis, etc) tendência é
centralizar informações em um único BD• Planejamento da interoperabilidade:
– Documentação (diagramas, especificação, fluxo de dados, etc)– Saiba até onde é possível ir– Avalie com cuidado troca de BDs para consolidar dados– Mudar banco de dados de aplicação existente tem impacto profundo
6
Conceitos comuns (1)• SGBDR (e alguns NoSQL) sofrem pressão do mercado para suportar recursos
similares: SQL, backup, segurança, tabelas, constraints, programação, etc• A execução e suporte de diversas tarefas comuns se torna um commodity. E o
profissional deve saber como fazer a mesma tarefa com tecnologias diferentes• Sempre dar atenção aos conceitos básicos e fundamentos• Há diferenças de conceitos, nomenclaturas, siglas, especificações e
peculiaridades para cada BD. Ex: Log, configurações, opções de crescimento, etc
• Foco não é comparação entre bancos de dados. Artigo “Comparando a dificuldade nos bancos de dados” na SQL Magazine 75 http://migre.me/ahnEF
• EULA impede comparações de desempenho com alguns BDs• Há testes padrões do mercado como o TPC (http://tpc.org)• Não perca muito tempo discutindo funcionalidades ou comparando. Conheça
suas opções e parta para o trabalho!
7
Conceitos comuns (2)• Alguns fornecedores se preocupam mais com interoperabilidade no BD
do que outros
• Procure por recursos que vão além de importação/exportação
• Procure evitar formatos intermediários
• Há sempre a questão da segurança e confidencialidade
• Geralmente é preciso contar com tecnologias externas para conectividade: ODBC, JDBC, OLE Db, drivers específicos e conectores
• Dependendo do contexto pode ser interessante recorrer a ferramentas ETL do próprio fabricante ou de terceiros. Sugestões:
– Microsoft SQL Server Integration Server (SSIS http://migre.me/ahoeL)– Oracle Database Utilities http://migre.me/ahoiZ– PDI (antigo Kettle) http://kettle.pentaho.com/– Talend open Studio http://migre.me/ahooW
8
Interoperabilidade na administração (1)• Todos os BDs possuem ferramentas de console (shell) que permitem
trabalhar com scripts e arquivos individuais
• Fornecem boa produtividade, porém tem péssima usabilidade para tarefas administrativas. Não há recursos de interoperabilidade além do que o SO fornece (pipes)
• Tarefas administrativas podem ser realizadas por script, mas há ferramentas com GUI. Exemplos:
Management Studio Oracle Enterprise Manager
9
Interoperabilidade na administração (2)
RockMongoFuton
MySQL Workbench PgAdmin
10
Interoperabilidade na administração (3)
• Ferramentas com GUI auxiliam muito certas tarefas administrativas• Porém praticamente não há recursos de interoperabilidade entre dados, objetos e tarefas
administrativas• Para monitoria: artigo “Monitoramento de Base de Dados” da SQL Mag. 54
http://migre.me/ahqXE. • Soluções agregadoras: Nagios (http://www.nagios.org/), System Center (http://migre.me/ahr5Y)
e FogLight (http://migre.me/ahrgP)
DBArtisan da Embarcadeiro http://migre.me/ahqN9
11
Trocando objetos, dados e instruções (1)• Alguns bancos de dados possuem recursos para acessar objetos entre diferentes
BDs junto com as instruções SQL
• O SQL Server possui o conceito de servidores linkados: requer ODBC, provider OLE DB ou provider .NET
• O Oracle possui o recurso chamado Database Link Heterogeneous Services (DB-LINK). Acesso a fontes de dados ODBC. http://migre.me/ahv1o
• Linked servers e DB-Link fornecem algo do tipo:
SELECT * FROM {FONTE_REMOTA}…{OBJETO}
• PostgreSQL também possui DBLink mas apenas entre servidores PostgreSQL. Projetos alternativos:
– DBLink-ODBC: http://sourceforge.net/projects/dblink-odbc/– DBLink-TDS: http://pgfoundry.org/projects/dblink-tds/
• O MySQL não possui recurso semelhante. Mas há o Storage Engine FEDERATED que permite acessar tabelas de outro MySQL remotamente http://migre.me/ahv9e
• Bancos NoSQL e newSQL não possuem recursos de interoperabilidade direta em instruções
12
Trocando objetos, dados e instruções (2)• Todos os BDs possuem recursos para importar e exportar dados. Geralmente
no formato CSV (Comma-separated values) ou XML
• Replicação heterogência envolve BDs de diferentes fornecedores
• Há recursos para implementar replicação de dados síncrona, assíncrona ou multi-síncrona entre diferentes BDs
• Cuidado: não confudir replicação com tecnologias para escalabilidade (sharding), alta disponibilidade (cluster) ou disaster e recovery
• Deve-se planejar muito bem como será a replicação. Aspectos principais:– Papéis (masters ou slaves) e locais de replicação– Latência e disponibilidade– Conversão de tipos de dados– Fluxo de dados (direção) e forma de replicação– Conflitos– Objetos, filtros, índices full-text e outros elementos do banco de dados
• Geralmente a replicação é uma maravilha quando tudo funciona bem• Mas quando algum problema aparece a situação vira um inferno• Alguns fornecedores de BD provém replicação heterogênea. Espere apenas recursos
básicos neste contexto• Há diversas ferramentas de terceiros para replicações heterogêneas• Importante: replicar dados NÃO faz com que sistemas sejam multi-banco
13
Trocando objetos, dados e instruções (3)• SQL Server (> 2000) pemite replicação nativa apenas para Oracle
• Há como montar solução utilizando servidores linkados+view+triggers
• Oracle possui dois recursos: view materializada e Oracle Streams para qualquer fonte ODBC
• PostgreSQL, MySQL, DB2, NoSQL e newSQL não possuem recursos para replicar dados para BD de outros fabricantes. Alternativas de terceiros:
• Código livre:– Tungsten Replicator (http://migre.me/ahvKy): replicação JDBC em linha de comando– SymmetricDS (http://migre.me/ahvRw): sincronia de tabelas– DBReplicator (http://dbreplicator.org/): replicação JDBC com GUI – Daffodil Replicator (http://migre.me/ahwdR): versão enterprise e open source
• Proprietárias:– DBMoto (http://migre.me/ahw2g)
– SharePlex for Oracle (http://migre.me/ahw84)
– ObjectMMRS (http://migre.me/ahwnI)
– InfoSphere Data Replication (http://migre.me/ahww6)
• Nota: algumas ferramentas ETL também fazem replicação heterogênea
14
Trocando objetos, dados e instruções (4)• Em muitas situações desejamos converter uma instrução SQL de um banco
para outro
• Formatador on-line de SQL: http://migre.me/ahwIi
• Testadores de SQL: SQLFiddle (http://sqlfiddle.com/) e Ideone (http://t.co/1VqDRoZs) e Try MongoDB (http://try.mongodb.org/)
• SwisSQL Console (http://migre.me/ahxef) separação e conversão de instruções
15
Trocando objetos, dados e instruções (5)• SQL Translator (http://migre.me/ahxjR) scripts do Linux para conversão de
instruções SQL
• SQL Injection Knowledge Base: http://t.co/Hc6PLWdE
• Tabelas, guias e posters de conversões de sintaxe SQL e NoSQL. Nota: atualmente há muitas linguagens *QL de acordo com cada produto
• Site com lista de Cheat-Sheets: http://www.cheat-sheets.org/
• Diversas APIs, bibliotecas, frameworks, camadas, components, design patters e arquiteturas para trabalhar com sistemas multi-banco
• Exemplo: SwisSQL API (http://migre.me/ahxIL)
• Muitos são ORM e servidores de cache também! Cuidado com soluções que prometem interoperabilidade e na verdade substituiem o seu BD por outro
• Há soluções amálgamas e com alguma compatibilidade entre BDs– Fyracle (Oracle-mode Firebird) http://migre.me/ahoy0– DotNetFirebird (Access, MSDE e Firebird) http://migre.me/ahzHG– SQLite (SQL Server) http://www.sqlite.org/ e SharpHSQL
(http://www.codeplex.com/sharphsql)
16
Conclusão
Ambiente multi-banco e diferentes abordagens (SQL, NoSQL, newSQL) convivendo junto
Conceitos e tecnologias comuns x Novas idéias
Sofware proprietário com mais recursos de interoperabilidade
Poucos recursos para interoperabilidade de tarefas administrativas
Muitos recursos para troca de dados, instruções e objetos entre BDs diferentes
Ainda estamos na era da especialização e divergência
Novas e interessantes possibilidades para avanços nas área de interoperabilidade, usabilidade, comunicação e compatibilidade entre BDs diferentes