Re: [pgbr-geral] [off-topic] Only NoSQL
Le 5 novembre 2015 16:48:59 GMT-02:00, Matheus Saraiva a écrit : >Ok, muito se fala em usar NoSQL para casos específicos, geralmente >resultando uma solução final mista entre NoSQL e Relacional. Nunca vi por esse lado. Isso é majoritário hoje em dia? >Mas o que dizer de uma solução puramente NoSQL, ou seja, ter o mongoDb >como único SGDB de uma aplicação? NoSQL é muito mais que MongoDB. Mas eu diria: não perca seu tempo a menos que saiba exatamente porque quer algum sistema específico não-SQL. >Isso é praticável? Tudo é praticável em Informática, ou quase tudo, dados recursos suficientes: tempo, dinheiro, pessoal qualificado. > Que problemas e vantagens eu teria em fazer tal >coisa? Em termos genéricos, vantagens nenhumas e todos os problemas que levaram à criação do modelo relacional. Procure o artigo original do Codd, leia e entenda, e volte com as dúvidas específicas. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 (Net)gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691 (Vivo) 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
Re: [pgbr-geral] [off-topic] Only NoSQL
Em 05/11/2015 17:35, Leandro Guimarães Faria Corcete DUTRA escreveu: Le 5 novembre 2015 16:48:59 GMT-02:00, Matheus Saraiva a écrit : Ok, muito se fala em usar NoSQL para casos específicos, geralmente resultando uma solução final mista entre NoSQL e Relacional. Nunca vi por esse lado. Isso é majoritário hoje em dia? Mas o que dizer de uma solução puramente NoSQL, ou seja, ter o mongoDb como único SGDB de uma aplicação? NoSQL é muito mais que MongoDB. Mas eu diria: não perca seu tempo a menos que saiba exatamente porque quer algum sistema específico não-SQL. Isso é praticável? Tudo é praticável em Informática, ou quase tudo, dados recursos suficientes: tempo, dinheiro, pessoal qualificado. Que problemas e vantagens eu teria em fazer tal coisa? Em termos genéricos, vantagens nenhumas e todos os problemas que levaram à criação do modelo relacional. Procure o artigo original do Codd, leia e entenda, e volte com as dúvidas específicas. 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. 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. 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. Nunca vi ninguém pregando o uso exclusivo de bancos NoSQL. É 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. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [off-topic] Only NoSQL
Le 5 novembre 2015 17:54:09 GMT-02:00, Matheus Saraiva 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:leand...@jabber.org +55 (61) 9302 2691 (Vivo) 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
Re: [pgbr-geral] [off-topic] Only NoSQL
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 < l...@dutras.org> escreveu: > Le 5 novembre 2015 17:54:09 GMT-02:00, Matheus Saraiva < > matheus.sara...@gmail.com> 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:leand...@jabber.org > +55 (61) 9302 2691 (Vivo) 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [off-topic] Only NoSQL
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 Javarsrsrsr. 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 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 < > l...@dutras.org> escreveu: > >> Le 5 novembre 2015 17:54:09 GMT-02:00, Matheus Saraiva < >> matheus.sara...@gmail.com> 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 coloc
Re: [pgbr-geral] [off-topic] Only NoSQL
2015-11-05 18:42 GMT-02:00 Rogério F.Santo : > Cara o que eu li sobre o assunto até agora tem haver com coisas tipo > algoritmos de busca Sim, é tudo sobre técnicas de acesso a dados. Não é um modelo que compita com o relacional ou o SQL, e essas técnicas têm sido incorporadas paulatinamente ao PostgreSQL — e, em ritmo mais lento, a alguns outros SGBDs SQL também. > que para dados não estrurados Não há dados não estruturados. É um grande engano de quem não entendeu ainda o conceito de modelos de dados, tanto no sentido de uma teoria (como em ‘modelo relacional’) como no sentido da estrutura de uma base de dados específica (tabelas e índices e outros objetos de uma aplicação ou de uma organização). O que normalmente se chama de não estruturado significa pouco organizado, o que também significa pouco utilizável. Nada que não possa ser colocado em uma estrutura relacional com um pouco de exercício de dois ou três neurônios. > parece ser melhir e com o > próprio desenvolvimento do software onde nosql tende a ser mas próximo de > OO. Essa moda já passou. SGBDs OO é coisa da década passada. Na verdade, percebeu-se o que o modelo relacional sempre propôs: que espelhar estrutura e acesso a um modelo de programação atrapalha, engessa tanto acesso quanto desempenho de acesso a dados. > 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 O Facebook é um daqueles casos em que havia um uso muito específico numa escala muito extraordinária antes que os mecanismos estivessem incorporados aos SGBDs SQL. É um bom exemplo de como não dá para usar um caso muito específico como validação de um malentendido por falta de conhecimentos conceituais básicos. > e a busca de > relacionamento entre pessoas por usar o algoritmo de busca em grifo e não > árvore binária. Grifo é um bicho mitológico. O modelo de acesso a dados prerrelacional é o de grafos. E grafos ou relações nada têm a ver com árvores binárias. Árvores binárias são apenas uma estrutura de índice, não um modelo de dados. > 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. Isso é óbvio, não vale. E não é apenas grana; é também ter tempo e escovadores de bits, e uma necessidade muito específica. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/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
Re: [pgbr-geral] [off-topic] Only NoSQL
2015-11-05 21:46 GMT-02:00 Vinícius Aquino do Vale : > […] > 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 2691ICQ/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
Re: [pgbr-geral] [off-topic] Only NoSQL
Em 5 de novembro de 2015 22:38, Guimarães Faria Corcete DUTRA, Leandro < l...@dutras.org> escreveu: > E depois sofre as conseqüências da inexperiência e da falta de > conhecimento. Ponto e vírgula. > Bom, vejo várias startup e outras empresas mundo a fora adotando imensamente bancos noSQL, como eu disse o misto entre os dois é possível e muito usado atualmente. Todos os bancos que citei acima, são sim considerados noSQL. E nem todos são banco de dados, pois não fazem persistência, mas são noSQL. Bom, se está errado, vc terá que mudar o que está sendo falado e divulgado por ai, não fui eu que inventei. E sim, aceite ou não, nem todos precisam de ACID, e o mundo noSQL encaixa perfeitamente para muitas delas. Existem startup's que fazem uso de noSQL, e o fazem muito bem, usando ou não relacional por trás. Lembra do nome NoSQL- Not Only SQL - então "não somente SQL". []s ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [off-topic] Only NoSQL
Em 5 de novembro de 2015 22:38, Guimarães Faria Corcete DUTRA, Leandro < l...@dutras.org> escreveu: > 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. > Só como complemento - https://pt.wikipedia.org/wiki/NoSQL http://nosql-database.org/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [off-topic] Only NoSQL
2015-11-05 22:53 GMT-02:00 Vinícius Aquino do Vale : > > Bom, vejo várias startup e outras empresas mundo a fora adotando imensamente > bancos noSQL E muitos voltando ao SQL. Como o Google. > como eu disse o misto entre os dois é possível e muito usado > atualmente. E cada dia o PostgreSQL incorpora as técnicas de acesso, e diminui o nicho do NoSQL. > Todos os bancos que citei acima, são sim considerados noSQL. E nem todos são > banco de dados, pois não fazem persistência, mas são noSQL. Bom, se está > errado, vc terá que mudar o que está sendo falado e divulgado por ai, não > fui eu que inventei. Não tenho como mudar a ignorância geral. Haja visto quão poucas pessoas são capazes de sequer definir o que é o modelo relacional. Tente. Pode até pesquisar. > E sim, aceite ou não, nem todos precisam de ACID, e o mundo noSQL encaixa > perfeitamente para muitas delas. Existem startup's que fazem uso de noSQL, e > o fazem muito bem, usando ou não relacional por trás. Você havia dito que a maior parte das empresas não precisava de Acid. Já mudou o tom. E, infelizmente, /startup/ significa apenas ‘empresa iniciante’, com um nome metido a besta. Mais infelizmente ainda, a maior parte fecha depois de pouco tempo, e ignorância sobre os fundamentos técnicos não é a única razão, nem talvez a mais importante. > Lembra do nome NoSQL- Not Only SQL - então "não somente SQL". Isso foi a saída envergonhada que acharam quando o NoSQL de verdade se mostrou um engodo. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/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
Re: [pgbr-geral] [off-topic] Only NoSQL
2015-11-05 22:59 GMT-02:00 Vinícius Aquino do Vale : > > Em 5 de novembro de 2015 22:38, Guimarães Faria Corcete DUTRA, Leandro > escreveu: >> >> 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. > > Só como complemento - https://pt.wikipedia.org/wiki/NoSQL Infelizmente a Wikipedia em português é ainda pior que a inglesa nessa área. Praticamente inútil. Aliás, o que isso tem a ver com o meu parágrafo que você citou? > http://nosql-database.org/ Mera propaganda. Você já leu o Codd? Ou o Date? Isso seria conhecimento. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/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
Re: [pgbr-geral] [off-topic] Only NoSQL
> > > E sim, aceite ou não, nem todos precisam de ACID, e o mundo noSQL encaixa > perfeitamente para muitas delas. Existem startup's que fazem uso de noSQL, > e o fazem muito bem, usando ou não relacional por trás. > > E muitas não fazem muito bem. Ainda bem que algumas já se perceberam isso, vide o caso Diaspora: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [off-topic] Only NoSQL
Em 5 de novembro de 2015 23:58, Everton Berz escreveu: > E muitas não fazem muito bem. Ainda bem que algumas já se perceberam isso, > vide o caso Diaspora: > http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ > O artigo é de 2013, o mongodb sofreu diversas modificações estando hoje na versão 3.0, como toda aplicação ele ainda é recente e tem muito a melhorar. Como eu disse mudar a cabeça para noSQL ainda vai demorar, mas acredito ser um caminho sem volta. O mercado externo está migrando para este tipo de tecnologia, e no Brasil aos poucos algumas empresas grandes tem adotado. O mercado tem seguido essa maré de noSQL, e eu pretendo navegar nela. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [off-topic] Only NoSQL
O artigo é de 2013, o mongodb sofreu diversas modificações estando hoje na versão 3.0, como toda aplicação ele ainda é recente e tem muito a melhorar. Como eu disse mudar a cabeça para noSQL ainda vai demorar, mas acredito ser um caminho sem volta. O mercado externo está migrando para este tipo de tecnologia, e no Brasil aos poucos algumas empresas grandes tem adotado. O mercado tem seguido essa maré de noSQL, e eu pretendo navegar nela. Você será sempre bem vindo quando a maré baixar na sua praia :) Entrementes, conheça ToroDB e assista às apresentações superinteressantes do Álvaro que esteve no último PGBR em Rondônia on de ele explica todas as falácias do Schema-Less e do "desempenho do MongoDB". https://github.com/torodb/ http://pt.slideshare.net/8kdata/big-dataspain2014-torodbbridgebetweennosqlandrelational http://www.bigdataspain.org/2014/conference/torodb-a-new-nosql-database-that-replaces-mongodb []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [off-topic] Only NoSQL
So para deixar claro os termos usados como todo termo é usado diante de contexto e uma literatura e bom saber isso antes de apontar falhas. No caso dados não estrurados a que me refiro e o que consenso entre os grandes players de mercado e no caso são documentos, vídeos, fotos e etc coisas que se você quiser quardar em 8m banco diretamente você teria um campo blob e não acho que alguém queira fazer um Where em um blob. Os nosql em geral funcionam melhor com estes dados e tem implementação mais fácil. Os relacionais para suprir este problema implementam o full text sach mas nem todos ainda possuem está características. E por favor toda estrutura de dados tem um algoritmo mas eficaz para realizar buscas sobre elas. Acho que deixei bem claro estar falando do algoritmo e não dá forma como eles são organizados no banco. Em Sex, 6 de nov de 2015 06:47, Flavio Henrique Araque Gurgel < fha...@gmail.com> escreveu: > > O artigo é de 2013, o mongodb sofreu diversas modificações estando hoje > > na versão 3.0, como toda aplicação ele ainda é recente e tem muito a > > melhorar. Como eu disse mudar a cabeça para noSQL ainda vai demorar, mas > > acredito ser um caminho sem volta. O mercado externo está migrando para > > este tipo de tecnologia, e no Brasil aos poucos algumas empresas grandes > > tem adotado. > > > > O mercado tem seguido essa maré de noSQL, e eu pretendo navegar nela. > > Você será sempre bem vindo quando a maré baixar na sua praia :) > Entrementes, conheça ToroDB e assista às apresentações > superinteressantes do Álvaro que esteve no último PGBR em Rondônia on de > ele explica todas as falácias do Schema-Less e do "desempenho do MongoDB". > > https://github.com/torodb/ > > http://pt.slideshare.net/8kdata/big-dataspain2014-torodbbridgebetweennosqlandrelational > > http://www.bigdataspain.org/2014/conference/torodb-a-new-nosql-database-that-replaces-mongodb > > []s > Flavio Gurgel > ___ > 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
Re: [pgbr-geral] [off-topic] Only NoSQL
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 : […] 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? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [off-topic] Only NoSQL
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 : […] 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
Re: [pgbr-geral] [off-topic] Only NoSQL
> > E muitas não fazem muito bem. Ainda bem que algumas já se perceberam isso, > vide o caso Diaspora: > http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ > Artigo muito bom e bastante explicativo, em ambos pontos de vista. Cada um é livre pra ler (ou não) e tirar suas próprias conclusões. É dever de cada um explorar todas as opções de informação possíveis, e diversificar estas fontes. Fato disso é que, no Brasil, "metade" da população não acredita no que não passa na TV, o que é absurdo pra muitos que já aprenderam a ver além e explorar outras fontes, e é grande causa de MUITOS dos problemas que temos, mas isso já é assunto para outro off-topic. De qualquer forma, discussão muito interessante e de grande valia. Espero que todos entendam que é uma discussão saudável e que busca ajudar a todos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [off-topic] Only NoSQL
Em 6 de novembro de 2015 10:13, Matheus Saraiva escreveu: > 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 sou um misto de dba e dev, conheço pouco - ou nada - NoSQL e gostaria de exemplificar um caso real que acompanhei de perto. > 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. Eu acredito que posso dar um "pitaco". > 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. Muitas destas tecnologias armazenavam informações sob o conceito de linhas e colunas, e, apesar de não incorporarem nativamente um SGBDR não podem ser consideradas NoSQL. Não é possível armazenar objetos complexos, como um objeto JSON repleto de atributos multivalorados em arrays sem ter uma definição prévia (quantos atributos, tipo de atributos, etc.). No caso do Cobol e Clipper (.DBF) é possível até executar instruções SQL SELECT sobre o conjunto de tabelas/arquivos, portanto, aproximam-se mais do modelo relacional do que NoSQL. > 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? As tecnologias antigas citadas anteriormente não chegam perto dos conceitos de NoSQL atuais. E, de fato, trabalhei para o HSBC há alguns anos. Lá pelo menos é usado SGBDR em tudo. A parte em Cobol puro é utilizada para aplicações críticas que demandam processamento "quase real" e depois todas as informações são exportadas e armazenadas em bancos relacionais (Oracle e Sybase ASE). Apesar de eu nunca ter trabalhado com NoSQL participei de um time de desenvolvimento para uma empresa que estava indo fundo em um projeto que, à exemplo do OP, queria mesclar NoSQL com SGBDR. Eu, obviamente, fiquei no "subtime" do SGBDR. O time de desenvolvedores (Java) por muito tempo ficou excitado com as novas possibilidades usando MongoDB, pouca demanda era repassada para a minha equipe e muitas justificativas de usar o MongoDB (como desempenho, facilidade de programação, etc.) eram dúbias (tudo era possível ser feito em SGBDR). Lembro-me bem de um programador que dizia que "trabalhar com NoSQL era tão fácil quanto abrir um arquivo texto e inserir informações neles". Eu muito questionei como estes dados seriam consistentes depois, como seriam feitas as consultas, como garantir que uma informação de uma entidade (ou objeto para eles) estaria realmente gravada no banco de dados. As respostas sempre eram as mesmas: isso a aplicação irá resolver, a aplicação precisa estar bem desenvolvida e bem testada. Passaram pelo menos 4 anos desde que este projeto começou e ainda não terminou. A complexidade tornou-se tão enorme que para criar um "módulo" simples, um CRUD, são necessários pelo menos 4 dias. Depois de milhares (senão milhões) de reais gastos, o projeto dá sinais de que será abandonado. E a integridade de informações? Bem, o mesmo programador me disse que é um inferno na terra, que depois de um certo número de registros (ops, objetos) armazenados as consultas NoSQL são enormes tratando diversos tipos de atributos que podem ou não existir, muito lixo é armazenado e também há o caso do "programa bem desenvolvido e bem testado" que nunca existe, trazendo muito mais dor de cabeça que benefícios. > Será as > soluções NoSQL atuais tão ruins assim que conseguem ser piores do que > tecnologias descontinuadas à várias décadas? Para transportes terrestres não vi nada mais eficiente que rodas sob os veículos para permitir a locomoção. O ponto que quero chegar é que existem tecnologias e conceitos tão maduros que não precisem ser recriados, apenas aperfeiçoados. Clipper, por exemplo, foi o predecessor do FoxPro e do Visual FoxPro que já utilizavam SGBDRs rudimentares nativamente (se não me engano até existia um plugin OraClipper para acessar bancos Oracle no Clipper Summer 87, mas já não lembro). Com todas as novas implementações dos SGBDRs permitindo o armazenamento de objetos JSON e dados complexos, não vejo motivo algum para usar NoSQL. Isso é modinha à exemplo do Cachè antigamente, que tinha até propaganda na Revista Info. Mas quem quiser tentar, vai fundo e compartilha a experiência! TIAGO J. ADAMI http://www.adamiworks.com @tiadami ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://lis
Re: [pgbr-geral] [off-topic] Only NoSQL
On 06-11-2015 08:15, Rogério F.Santo wrote: > So para deixar claro os termos usados como todo termo é usado diante de > contexto e uma literatura e bom saber isso antes de apontar falhas. No > caso dados não estrurados a que me refiro e o que consenso entre os > grandes players de mercado e no caso são documentos, vídeos, fotos e > etc coisas que se você quiser quardar em 8m banco diretamente você teria > um campo blob e não acho que alguém queira fazer um Where em um blob. Só para constar, o PostgreSQL é tão extensível (e isso é algo maravilhoso) que é possível sim fazer um "where" em um blob... veja essa extensão "ImgSmlr – similar images search for PostgreSQL" [1]. Não estou dizendo que vc "tem que fazer isso"... só exemplificando que o PostgreSQL tem capacidades excepcionais de extensibilidade que se por acaso existe alguma necessidade específica e ele não implementa, então vc pode ir lá e implementar. > Os nosql em geral funcionam melhor com estes dados e tem implementação mais > fácil. Não creio que armazenar documentos (aqui vc não se referiu a JSON né?), vídeos e fotos seja o "grande" diferencial do NoSQL. Digo porque os relacionais já fazem isso há décadas. Mas não estou dizendo que os relacionais fazem isso bem, até porque existe um cara chamado "filesystem" que foi projetado pra lidar de forma estruturada com esse tipo de informação. Não quero gerar ok! > Os relacionais para suprir este problema implementam o full text > sach mas nem todos ainda possuem está características. Lidar com "blobs" e "FTS" são coisas distintas não? > E por favor toda > estrutura de dados tem um algoritmo mas eficaz para realizar buscas > sobre elas. Acho que deixei bem claro estar falando do algoritmo e não > dá forma como eles são organizados no banco. > Com certeza, e por isso podemos confiar nos relacionais porque são décadas de aperfeiçoamento nos algoritmos para lidar com heap, btree, rtree, hash, gin, gist, etc. IMHO JSON é uma estrutura de dados relativamente nova e creio que seus algoritmos ainda tem muito a evoluir, e cada implementação tem feito isso pouco a pouco, seja o MongoDB (e outros) e o próprio PostgreSQL. Att, [1] https://github.com/postgrespro/imgsmlr -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [off-topic] Only NoSQL
On 06-11-2015 06:47, Flavio Henrique Araque Gurgel wrote: >> O artigo é de 2013, o mongodb sofreu diversas modificações estando hoje >> na versão 3.0, como toda aplicação ele ainda é recente e tem muito a >> melhorar. Como eu disse mudar a cabeça para noSQL ainda vai demorar, mas >> acredito ser um caminho sem volta. O mercado externo está migrando para >> este tipo de tecnologia, e no Brasil aos poucos algumas empresas grandes >> tem adotado. >> >> O mercado tem seguido essa maré de noSQL, e eu pretendo navegar nela. > > Você será sempre bem vindo quando a maré baixar na sua praia :) > Entrementes, conheça ToroDB e assista às apresentações > superinteressantes do Álvaro que esteve no último PGBR em Rondônia on de > ele explica todas as falácias do Schema-Less e do "desempenho do MongoDB". > Tentei ao máximo trazer o Álvaro novamente para o PGBR para falar sobre o ToroDB, mas infelizmente pela "mancada" que os gringos deram em marcar a "PGConf Silicon Valey" no mesmo período do PGBR (se desculparam muito durante a PGCon esse ano conosco, mas já estava feito) nos prejudicou bastante para trazer patrocinadores e palestrantes internacionais. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [off-topic] Only NoSQL
Este tópico já teve bastante informação, eu queria só levantar alguns pontos que acho relevante. 2015-11-05 16:48 GMT-02:00 Matheus Saraiva : > Ok, muito se fala em usar NoSQL para casos específicos, geralmente > resultando uma solução final mista entre NoSQL e Relacional. > Isso é mesmo muito comum, por exemplo, alguns exemplo: - é comum usar bancos de dados chave/valor, como o Redis, Aerospike, e até memcached como um cache distribuído ou até mesmo armazenar dados de sessão de usuário, carrinho de compra, etc. - usar ElasticSearch, Sphinx, Solr, etc. para prover uma busca mais avançada, mas sempre armazena-se os dados em outros lugares para poder reconstruir os índices nesses bancos. - entre outros mais avançados, BigData-like, como Hadoop (HDFS, HBase, etc.) ou Spark, para processamento de grandes volumes de dados > Mas o que dizer de uma solução puramente NoSQL, ou seja, ter o mongoDb > como único SGDB de uma aplicação? > Isso é praticável? Que problemas e vantagens eu teria em fazer tal coisa? > Sinceramente só vejo desvantagens nesse caminho, não vou fazer uma lista enorme pois muita gente já fez... :) O que vejo é muita gente usando um NoSQL por não conhecer a real capacidade e extensibilidade do PostgreSQL. Tanto que fiz uma palestra sobre o assunto onde expresso mais detalhadamente minha opinião no assunto: "PostgreSQL, porque você não precisa de NoSQL" [1][2] (OBS: não sou *contra* NoSQL, só acho que tem que conhecer bem antes de usar, qual usar, e saber as limitações e as vantagens). [1] http://www.slideshare.net/matheus_de_oliveira/postgresql-porque-voc-no-precisa-de-nosql (somente slides) [2] http://www.infoq.com/br/presentations/postgresql-e-porque-voce-nao-precisa-de-nosql (vídeo) Atenciosamente, -- Matheus de Oliveira ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [off-topic] Only NoSQL
O grande problema na area de TI eh a falta de conceitos. Muitas decisoes sao tomadas baseadas em achismos ou casos isolados de sucesso. Os profissionais da nossa area nao tem o costume de ler artigos tecnicos, cientificos, pesquisas... Ai podemos perceber porque mais de 60% dos projetos de TI fracassam. Com relacao ao topico vou deixar aqui meus 2 cents. Em 6 de novembro de 2015 18:15, Rogério F.Santo escreveu: > So para deixar claro os termos usados como todo termo é usado diante de > contexto e uma literatura e bom saber isso antes de apontar falhas. No caso > dados não estrurados a que me refiro e o que consenso entre os grandes > players de mercado e no caso são documentos, vídeos, fotos e etc coisas > que se você quiser quardar em 8m banco diretamente você teria um campo blob > e não acho que alguém queira fazer um Where em um blob. Os nosql em geral > funcionam melhor com estes dados e tem implementação mais fácil. > Existe uma grande confusao aqui. Estamos misturando os conceitos de armazenamento, extracao, pesquisa, indexacao... Para armazenar arquivos a melhor alternativa ainda eh o sistema de arquivos. Arquivos binarios ou nao, seja qual for o formato, deixe a responsabilidade para o sistema de arquivos. Sobre indexar midias existem varios desafios e podemos perceber que de fato o termo "nao estruturado" nao cabe aqui pois todos possuem uma estrutura muito bem definida. Os desafios aqui remetem exatamente em decodificar tal estrutura. Eu vou considerar os documentos como "documentos texto", nao confundir com formato texto puro, tais como PDF's, arquivos M$ Word e formatos livre como ODT. Neste caso eh muito simples decodifica tais documentos, extrair os dados relevantes e indexa-los. O problema maior eh quando precisamos indexar imagens e videos. Nesse caso temos que utilizar tecnicas mais sofisticadas como visao artificial e existem muitas pesquisas nessa area e ate "concursos" que envolvem grandes empresas e universidades. Mas tudo isso nao tem absolutamente nada a ver com o banco de dados. Os dados sao extraidos utilizando-se tais tecnicas/algoritmos/bibliotecas/magica/vodoo. > Os relacionais para suprir este problema implementam o full text sach mas > nem todos ainda possuem está características. E por favor toda estrutura de > dados tem um algoritmo mas eficaz para realizar buscas sobre elas. Acho que > deixei bem claro estar falando do algoritmo e não dá forma como eles são > organizados no banco. > Novamente uma confusao sobre os conceitos. Para simplificar o conceito sobre full text search podemos pensar nele como uma pesquisa linguistica onde pode operar em palavras e frases com base em uma determinada regra a qual geralmente eh baseada em padroes linguisticos de idiomas especificos como ingles, chines, portugues, etc... Para finalizar, muito se fala em como os noSQL sao adotados "la fora". Bem, aqui fora os dados importantes ainda sao tratados com muito criterio e ainda precisa-se provar muita coisa. Existe muita publicidade sobre os noSQL e muitas empresas de fato estao ganhando muito dinheiro com isso. Eu ja conversei com no minimo uns 7 "consultores" noSQL apenas este ano os quais falavam das vantagens e de tudo o que poderiamos ganhar se adotassemos as solucoes deles. Eu acho muito interessante para armazenar sessao de usuario, cache, e em alguns casos como auxilio para DW e geracao de relatorios, graficos, etc... Eles tem sim seu uso mas nao sao tudo isso que falam e propagam por ai. PS. Desculpem-me pela falta de acentos mas ainda estou brigando com o meu teclado :-\ Abc, Charly Batista ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [off-topic] Only NoSQL
Em 9 de novembro de 2015 01:48, Charly escreveu: > O grande problema na area de TI eh a falta de conceitos. > > Pois é, depois de anos (décadas) integrando softwares de fabricantes diferentes vejo que o maior problema é esse mesmo. Coisas básicas como chaves primárias, estrangeiras, unique index, etc são pouco usadas. Um caso recente ocorreu em um cliente cujo PDV é de terceiros. Nós executamos *stored procedures* no BD deles para buscar os cupons fiscais; eles recém implementaram o suporte ao cupom fiscal eletrônico e nas últimas semanas ocorreram vários erros nessas *procedures*. Mandamos nesse período vários emails com logs pra eles; semana passada ELES nos mandaram um email dizendo que nosso software não estava conseguindo importar os cupons. Inicialmente acharam que o erro era no nosso código (pois eram mensagens do PostgreSQL), mas na verdade era um bug no código deles (de novo): por algum motivo começaram a mandar cupons NFCe de novembro com chaves de acesso (Sefaz) de cupons antigos, de setembro. Corrigiram a *procedure* e tudo voltou a funcionar. Esses cupons com erro não estavam entrando no nosso BD por causa do UNIQUE INDEX na coluna chave de acesso. *"Ah, que sorte que vocês checam isso, né?"* Eu não chamaria de sorte... -- Atenciosamente, Alexsander da Rosa ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
