Em 06-11-2015 10:13, Matheus Saraiva escreveu:
Em 05/11/2015 22:38, Guimarães Faria Corcete DUTRA, Leandro escreveu:
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.

Bem, lá vai a opinião de alguém bem menos experiente do que todos que participaram desse off, aja vista que eu não sou dba, apenas dev. Eu realmente não posso aqui debater a possibilidade de uma migração para 100% NoSQL, visto que ainda sei pouco sobre esse método de armazenagem e gerenciamento de dados. Mas, hoje em dia ainda existem, e em quantidades razoáveis, grandes sistemas rodando em tecnologias descontinuadas como cobol, dbase, dataflex, clipper, etc. Algumas redes bancárias ainda hoje tem seus sistemas rodando em cobol. A coisa ficou tão funcional, tão estável que eles não se atrevem a fazer uma migração para uma solução relacional. A questão que levanto é, se esse casos de uso, conseguem viver sem o modelo relacional e ter soluções satisfatórias, mesmo usando tecnologias descontinuadas à décadas. Por que, o NoSQL, na figura do mongoDB, casandra, etc, que são soluções mais atuais e de desenvolvimento e comunidade ativos não podem ser também usadas como único sgdb de forma satisfatória? Será as soluções NoSQL atuais tão ruins assim que conseguem ser piores do que tecnologias descontinuadas à várias décadas?
Bem, agora tá falando um cara dinossauro, li todos os comentários, aprendi um pouco com o que cada um disse, venho lá do mainframe Burroughs (Unisys) com o DMS-II, um banco hierárquico, aonde só tinha campo do tipo alpha e number, o resto era feito tudo dentro do código cobol68 e depois o 74. As constraints estavam todas definidas em código e o máximo que as tabelas tinham era o índice. Bem estas tecnologias não estão mais no topo, mas tem seu uso e os programadores de cobol são pagos a preço de ouro, é por isto que muitos bancos não migram seus dados, não pelo banco mas sim por ter de escrever todo o código e são milhões de linhas a serem convertidas, reescritas e etc. Agora os bancos eram bastante performáticos e algumas features de décadas atrás ainda nem foram implementadas na maioria dos bancos relacionais, exemplo, no DMS-II tinha uma recuperação chamada "rollback" que era trazer o banco no tempo atrás, via timestamp ou transaction_id, no postgresql podemos fazer somente ele do backup para frente. Vi até agora somente o Oracle fazer o rollback que eles chamam de flashback recovery. Vamos continuar que esse off-topic tá muito bom. Ah! hoje uso postgresql, mais exatamente o da EnterpriseDB e estou bastante satisfeito.
[]s
Rogerio Carvallho

_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a