Aplicativos para a web, at\u00e9 poucos anos atr\u00e1s, eram sin\u00f4nimo de *PHP+MySQL*. Hoje em dia, h\u00e1 uma diversidade maior quanto as linguagens e frameworks utilizados _(embora o PHP ainda tenha muita for\u00e7a)_, mas poucos projetos saem do “padr\u00e3o” do MySQL e, quando o fazem, fatalmente utilizam outros bancos de dados baseados em SQL, como o Postgree, Oracle, ou Microsoft SQL Server.<\/p>\n
Este “padr\u00e3o” emp\u00edrico existe por um motivo bem simples – \u00e9 gratuito e funciona bem. Por\u00e9m, as necessidades evoluem – e bancos de dados baseados em SQL tem alguns s\u00e9rios problemas em lidar com elas.<\/p>\n
h2. Porqu\u00ea implicar com o SQL?<\/p>\n
Os bancos de dados que n\u00e3o utilizam SQL s\u00e3o considerados parte de um movimento chamdo *NoSQL*. Muitos desenvolvedores e analistas que ap\u00f3iam este movimento acreditam na “morte” de bancos de dados utilizadores de SQL, possuindo poucos argumentos para justificar tal opini\u00e3o al\u00e9m do fato destes bancos utilizarem SQL. Esta vis\u00e3o \u00e9 err\u00f4nea. Apesar do uso de linguagens de acesso a dados mais flex\u00edveis que o SQL ser um benef\u00edcio, os maiores problemas que estes novos bancos de dados tentam resolver tem a ver com outros aspectos.<\/p>\n
Ent\u00e3o, deve-se lembrar que os “bancos de dados SQL” s\u00e3o *transacionais, relacionais, dependentes de schema, e obedecem ao padr\u00e3o ACID*.<\/p>\n
h2. Qual \u00e9 o problema?<\/p>\n
Basicamente, o maior problema \u00e9 que estes bancos de dados n\u00e3o lidam muito bem com a “web social”. Sites da web 2.0 – que permitem a participa\u00e7\u00e3o e relacionamento ativo entre os usu\u00e1rios como parte integral de seu design – geram uma estutura conhecida como *gr\u00e1fico social*. O gr\u00e1fico social \u00e9 um gr\u00e1fico exibindo os relacionamentos de um usu\u00e1rio com outros usu\u00e1rios, itens e recursos do sistema.<\/p>\n
!http:\/\/blog.memuller.com\/uploads\/social_graph-bible.png!
\n_Um gr\u00e1fico social simples representando os relacionamentos entre personagens b\u00edblicos._<\/p>\n
Estes relacionamentos s\u00e3o de um tipo que n\u00e3o pode ser adequadamente representado atrav\u00e9s de um banco de dados relacional, principalmente em situa\u00e7\u00f5es que exigem alto desempenho.<\/p>\n
Pode parecer estranho dizer que bancos de dados relacionais n\u00e3o lidam bem com relacionamentos. De fato, eles s\u00e3o muito bons em representar relacionamentos um para muitos (1-n). Mas a maioria esmagadora de relacionamentos nos aplicativos modernos (e todos os envolvidos em um gr\u00e1fico social) s\u00e3o de outro tipo, o muitos para muitos (n-n). RDBMS tem muita dificuldade em representar estes relacionamentos, requerindo tabelas intermedi\u00e1rias que complicam consideravelmente a arquitetura.<\/p>\n
V\u00e1rias outros atributos de RDBMSs podem gerar complica\u00e7\u00f5es – como a lentid\u00e3o em escritas imposta pelo padr\u00e3o ACID, a dificuldade de realiza\u00e7\u00e3o de sharding, a presen\u00e7a de schema, dificuldade de mapeamento de l\u00f3gica de aplicativo para l\u00f3gica declarativa, tamanhos de campos for\u00e7ados, etc.<\/p>\n
h2. Pensando diferente<\/p>\n
Estas quest\u00f5es acima citadas n\u00e3o s\u00e3o problemas por padr\u00e3o – s\u00e3o problemas somente na maioria dos aplicativos web atuais. Os bancos de dados SQL s\u00e3o excelentes para uma grande variedade de usos, ent\u00e3o isso n\u00e3o \u00e9 uma cr\u00edtica a eles – e sim uma quieta admiss\u00e3o de que estamos usando a ferramenta errada para nossas necessidades, e precisamos pesquisar e entender novas formas de lidar com dados.<\/p>\n
Uma abordagem interessante \u00e9 representada pelos bancos de dados *orientados \u00e0 documentos*. A principal caracter\u00edstica destes \u00e9 que, ao inv\u00e9s de armazenar objetos em uma tabela previamente estruturada – que define quais os atributos do objeto, seus tipos e tamanhos – cada objeto \u00e9 armazenado como um *documento* separado, com *caracter\u00edsticas*. As caracter\u00edsticas n\u00e3o precisam ser uniformes entre os documentos, e cada caracter\u00edstica pode armazenar v\u00e1rias informa\u00e7\u00f5es.<\/p>\n
Para fins de compara\u00e7\u00e3o, vamos observar como um banco de dados relacional armazenaria uma estrutura de usu\u00e1rios.<\/p>\n
!http:\/\/blog.memuller.com\/uploads\/users-intranet.jpg!<\/p>\n
Pode-se ver que \u00e9 uma estrutura complexa, representando um problema t\u00edpico: a estrutura precisa crescer, para conseguir armazenar dados que ser\u00e3o relevantes somente para um pequeno n\u00famero de casos isolados.<\/p>\n
Usu\u00e1rios em um banco de dados orientado \u00e0 documentos podem ser representados da seguinte forma:<\/p>\n
* *nome:* Bill, *setor:* TI, *atividades:* Analista de Sistemas, *celular:* xx-xxxxxxx<\/p>\n
* *nome:* Anne, *setor:* TI, *atividades:* Analista de Sistemas, Consultora, *miss\u00e3o:* S\u00e3o Jos\u00e9 dos Campos, *fone-residencial:* xx-xxxxxxxx<\/p>\n
N\u00e3o h\u00e1 uma estrutura padr\u00e3o para um usu\u00e1rio, logo, eles podem ter atributos diferentes. N\u00e3o \u00e9 necess\u00e1rio utilizar um atributo que um usu\u00e1rio n\u00e3o possui; atributos podem possuir mais de um valor. Na maioria dos bancos de dados, \u00e9 poss\u00edvel, inclusive, inserir outros documentos inteiros dentro de um atributo.<\/p>\n
h2. Na Can\u00e7\u00e3o Nova<\/p>\n
Em fun\u00e7\u00e3o destas vantagens, o depto. de Pesquisa & Desenvolvimento de TI da Can\u00e7\u00e3o Nova realizou uma pesquisa extensiva, testando v\u00e1rios bancos de dados diferentes.<\/p>\n
Conclu\u00edmos que o “*MongoDB*”:http:\/\/mongodb.org\/ atende melhor nossas necessidades, e o mesmo j\u00e1 est\u00e1 em uso em dois projetos. Bancos de dados que possivelmente ser\u00e3o utilizados no futuro incluem o “*Cassandra*”:http:\/\/cassandra.apache.org\/ e o “*Neo4J*”:http:\/\/neo4j.org _(que usa um paradigma diferente – ele \u00e9 um banco de dados gr\u00e1fico)_.<\/p>\n
Em um post posterior, vamos mostrar os resultados desta pesquisa, explicar a decis\u00e3o, e descrever um pouco o *MongoDB* e nossos aplicativos que o utilizam. At\u00e9 l\u00e1!<\/p>\n","protected":false},"excerpt":{"rendered":"
Aplicativos para a web, at\u00e9 poucos anos atr\u00e1s, eram sin\u00f4nimo de *PHP+MySQL*. Hoje em dia, h\u00e1 uma diversidade maior quanto as linguagens e frameworks utilizados _(embora o PHP ainda tenha muita for\u00e7a)_, mas poucos projetos saem do “padr\u00e3o” do MySQL…<\/p>\n","protected":false},"author":4445,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_mi_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[30735],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/posts\/393"}],"collection":[{"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/users\/4445"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/comments?post=393"}],"version-history":[{"count":9,"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/posts\/393\/revisions"}],"predecessor-version":[{"id":401,"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/posts\/393\/revisions\/401"}],"wp:attachment":[{"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/media?parent=393"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/categories?post=393"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/tags?post=393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}