O noSQL - Not Only SQL - tem sido usado em ambientes mistos. Juntando tanto o SQL com o NoSQL. Aplicações como Solr, MongoDB, Cassandra, Dynamo, MemCached, TitanDB entre outras todas são consideradas noSQL. Essas aplicações vieram resolver diversos limitações que atualmente assolam o SQL, principalmente pela norma ACID.
Existem vários tipo de noSQL: * Hash (Dynamo, Memcached) * Grafos - (TitanDB) * Documentos (MongoDB, CouchDB) * Multicolunar (HBase, Bitable) Todos eles são schemaless o que não obriga estruturação seguindo algum modelo como no caso do relacional. Basicamente vc cria a aplicação e vai salvando os dados, depois vc se preocupa com o que estão salvos. Soluções noSQL se baseiam no teorema de CAP ( https://en.wikipedia.org/wiki/CAP_theorem), onde dependendo da necessidade do seu ambiente vc o qual banco usar. Situações onde é mais necessário gerar relacionamento, igual na amazon onde "clientes que visualizaram isso, também visualizaram aquilo." é muito complicado de montar quando tem que ser para vários clientes simultaneamente - haja memória - Neste caso um banco de grafos como o TitanDB, seria a melhor solução. Já o mongoDB tem a vantagem de funcionar mesmo se um "shard" - (algo parecido com o tablespace) em um servidor parar de funcionar. Trabalha com o formato Jsonb e o PostgreSQL já o tem implementado. Foi usado pela NetFlix para separar "shard" por regiões. Hoje, foi substituído pelo Cassandra (que é Dynamo mudado para a necessidade do facebook) com intuito de dividir o envio de streaming, tipo um torrent. O Hbase é um banco multicolunar, no mesmo estilo do bigtable do google (aquele que armazena as pesquisas), muito usando com o Hadoop, que seria um FileSystem para diversos discos em diversos locais. Uma ferramenta muito poderosa, que por incrível que parece foi feita em Java, inclusive o cassandra é também Java....rsrsrsr. Coisa de doido né, feito em Java!!! Mas a ideia maior por trás desses noSQL, e facilidade no armazenamento de dados, tanto dados estruturados, semi-estruturados e não estruturados. Estamos falando ai de Pentabytes, Exbytes. Imagine seu ambiente com tabelas em torno de 5Tb, ou 1Pb. Um relacional ficaria horas para executar alguma coisa. É provável que o relacional, nunca seja substituído. Porém, muitas dessas ferramentas já estão adicionando partes da ACID em suas soluções. E se formos pensar bem, são poucas a empresas que realmente dependem de toda a ACID. O difícil está sendo convencer alguns gerentes a saírem do mundo relacional, e migrarem para novas tecnologias. O medo de trocar fazer uma troca dessa magnitude é grande, porém as vantagens são imensas, principalmente velocidade e diminuição de custos quando na nuvem. Minha startup mesmo, migrou do Postgresql para o MongoDB, devido algumas necessidades específicas do modelo de negócio. Tive muitas melhorias até o momento. Sei que é difícil dizer isso, pois o Postgresql é como um irmão, cresceu comigo. Mas é preciso mudar as vezes. De qualquer forma, acho muito valido analisar o modelo de negócio, entender os tipos de noSQL e aplicar um MVP (produto minimamente viavel). Resultado agradou, migra. Ponto final. []s Em 5 de novembro de 2015 18:42, Rogério F.Santo <[email protected]> escreveu: > Cara o que eu li sobre o assunto até agora tem haver com coisas tipo > algoritmos de busca que para dados não estrurados parece ser melhir e com o > próprio desenvolvimento do software onde nosql tende a ser mas próximo de > OO. Sobre busca um exemplo e o Facebook que usa o casandra um banco que > ele melhorou e para eles funciona bem para achar fotos e vídeos e a busca > de relacionamento entre pessoas por usar o algoritmo de busca em grifo e > não árvore binária. Para o modelo de negócio deles funciona bem mas não > sei se vale usar tecnologias "experimentais" se vc não tem grana pra bancar > o risco. > > Em Qui, 5 de nov de 2015 18:16, Leandro Guimarães Faria Corcete DUTRA < > [email protected]> escreveu: > >> Le 5 novembre 2015 17:54:09 GMT-02:00, Matheus Saraiva < >> [email protected]> a écrit : >> >Eu não tenho um motivo específico para usar NoSQL, eu cogito usar em >> >algum projeto, apenas para fins de aprendizado, mesmo que não traga >> >beneficio algum, mas sem trazer prejuízos. >> >> Sempre trará prejuízos, por abandonar independência de dados, o >> otimizador, a flexibilidade de esquemas &c. A questão é saber se haverá >> algum benefício que compense, e aí só analisando casos específicos, o que >> creio que não seja viável nesta lista por demandar muitas informações >> detalhadas. >> >> >> >Toda a palestra, video, etc, que eu vejo sobre NoSQL eles destacam o >> >uso >> >em casos específicos, ou seja, sanar algum problema que o relacional >> >não está conseguindo. >> >> A rigor, não tem nada a ver com o modelo relacional, que não impõe >> quaisquer limitações, mas com o SQL e suas implementações. >> >> >> > Ninguém fala em adotar NoSQL como base principal ou >> >como única base de dados. >> >É comum colocarem o NoSQL como algo meramente auxiliar ao relacional. >> >> Que bom, significa que o modismo está passando. Quem sabe daqui a alguns >> anos isso estará tão merecidamente esquecido quanto Codasyl, IBM IMS/DB, CA >> IDMS, Mumps, Caché, hierárquicos, de rede, multivalorados, SGBDOOs... >> >> >> >É possível e comum usar apenas banco relacional, mas não é comum o >> >contrário. Se NoSQL não pode substituir o relacional, então talvez ele >> >traga mais problemas do que soluções. >> >> O NoSQL não pode substituir o relacional, e de fato traz mais problemas >> que soluções. Mas o NoSQL não se compara ao modelo relacional, portanto o >> mais correto é comparar com SQL (que tem várias limitações conceituais e >> tecnológicas em relação ao modelo conceitual); na verdade, o SQL fica a >> meio caminho entre o modelo relacional, que é lógico, e o NoSQL, que não >> passa de um agregado disforme de técnicas específicas de acesso a dados, >> umas mais, outras menos interessantes. Comparando com o SQL, de fato há >> algumas situações muito específicas em que algum sistema NoSQL pode >> viabilizar algo que seria difícil, impossível, caro ou demorado com SQL. >> Mas geralmente quem chega a essa conclusão é porque desconhece ou >> PostgreSQL; a cada versão do PostgreSQL ele se aproxima mais do potencial >> do SQL, incorporando as técnicas usadas pelos NoSQL da vida. >> >> >> >> -- >> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra >> +55 (61) 3546 7191 (Net) gTalk: xmpp:[email protected] >> +55 (61) 9302 2691 (Vivo) ICQ/AIM: aim:GoIM?screenname=61287803 >> BRAZIL GMT−3 MSN: msnim:[email protected] >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
