2015-11-05 21:46 GMT-02:00 Vinícius Aquino do Vale <aquino.v...@gmail.com>: > […] > MemCached, TitanDB entre outras todas são consideradas noSQL.
Claro que não. Memcached é apenas um mecanismo para acelerar o acesso físico a dados, independentemente do modelo, como o nome já indica: MEMory CACHE Daemon, ou serviço de cache de memória. > Essas > aplicações vieram resolver diversos limitações que atualmente assolam o SQL, > principalmente pela norma ACID. Mito. Acid e SQL são ortogonais. > Existem vários tipo de noSQL: > * Hash (Dynamo, Memcached) > * Grafos - (TitanDB) > * Documentos (MongoDB, CouchDB) > * Multicolunar (HBase, Bitable) Todos prerrelacionais, reempacotados para a nova ignorância do século XXI. > 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. E aí vêm as limitações. Leia o artigo do EF Codd. Ele já aponta problemas e soluções em, se não me falha a memória, 1969 (mas acho que a primeira versão pública é de 1971). Algo como _Large shared data banks_. > Situações onde é mais necessário gerar relacionamento O que é trivial no modelo relacional (embora o nome se refira a relações matemáticas, que diferem de relacionamentos que são implementados as restrições de integridade relacional). > 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. Não, foi uma melhor solução para alguns casos muito específicos com a tecnologia da época. Muitos desses casos já estão cobertos, com as vantagens inerentes ao modelo relacional, nas últimas versões do PostgreSQL, e com muito mais maturidade que qualquer NoSQL. > É 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. Isso é absolutamente falso. > 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. Para de exibir sua ingenuidade! Mil perdões, mas é isso. Aprenda relacional primeiro. > 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. E depois sofre as conseqüências da inexperiência e da falta de conhecimento. Ponto e vírgula. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
