Mais um: Digg também troca MySQL por Cassandra
Segundo o The H, os desenvolvedores do Digg anunciaram que estão abandonando o MySQL, que até então gerenciava os dados do popular site de compartilhamento de links, e estão de mudança para o Cassandra, seguindo os recentes passos do Twitter, e também de outros sites de grande porte, a exemplo do Facebook, desenvolvedor original da ferramenta que hoje está incubada no projeto Apache.
A medida é mais um exemplo da tendência NoSQL, ou pós-relacional, e a notícia do The H explica com detalhes algumas das razões da escolha, bem como algumas das vantagens cada vez mais associadas às alternativas “NoSQL”. (via h-online.com)
• Publicado por Augusto Campos em
2010-03-12
@brlinuxblog
Feed RSS
O Cassandra há um tempinho é um projeto incubado pela Apache. E acho interessante como todos os projetos Java que vão parar na Apache sempre viram sinônimo de extrema qualidade.
Heheh… E JAVA NÃO ERA LENTAO ?
Curioso humm ?
Li por ai que o java pode ser mais rapido até que C++ usando um gerador de bytecode super otimizado.
Kd esse gerador? isso é verdade?
Java é mais rápido que C++ sempre que você ganha na Mega Sena ou viaja para o País das Maravilhas.
Java em desktop não presta mesmo, mas em servidores…
Java é feito em C++ (deve ter assembly tbm), então não existe essa de Java ser mais rápido do que C++, no máximo do máximo tirando garbage collector e etc fica igual.
o que poderia acontecer é o programador C++ fizer caquinha, ai sim, mas naum tem como uma linguagem que usa maquina virtual ser mais rápida que uma que não use a menos que aconteça o que falei anteriormente
Existem técnicas de otimização que somente podem ser feitas em código interpretado… Portanto, um programa java ser mais ou menos rápido que um em C++ dependerá muito de como o código foi escrito (mais otimizável ou não).
Por falar em bancos de dados não relacionais, eu dei uma olhada no mongoDB. Achei bem interessante, é muito rápido, e as estruturas JSON-like são fáceis de interpretar. Muito legal principalmente para quem esta as voltas com Ajax. E é feito em C++ (não que isso seja muito importante, apenas é mais fácil para mim lidar com C++ que com outras linguagens).
@habeas_corpse… Discordo de você, embora não vejamos muito esse tipo de coisa em programas Java (especialmente de desktop, visto que as interfaces gráficas de Java ainda são pesadíssimas), é perfeitamente possível sim que código interpretado rode mais rapidamente que código nativo, por causa das vantagens de se inspecionar e manipular esse código em memória, podendo por exemplo otimizar código gerado dinamicamente. Mas, como eu disse, vai depender bastante do código específico.
Esse assunto é espinhoso e cheio de controvérsias e poréns, mais adequado a quem está fazendo pós-graduação em ciências de computação no campo de compiladores. Não vou adentrar nesta selva! Procure por JIT e Hotspot na wikipedia…
“Existem técnicas de otimização que somente podem ser feitas em código interpretado… Portanto, um programa java ser mais ou menos rápido que um em C++ dependerá muito de como o código foi escrito (mais otimizável ou não).”
nada a ver, o interpretador de código tbm num foi compilado?
isso não existe. agora se vc falar que é mais seguro eu acredito, mais rápido impossível.
A questão que levantei não é SE JAVA É OU NAO mais rapido que C++ , e sim o fato por ser MAIS UMA que escolhe JAVA a alternativas NATIVAS para trabalhar com banco de dados NonSQL…
Isso sim é curioso…
Acredito que escolha da linguagem para um projeto tem mas a ver com os programadores envolvidos do que com a linguagem em si. O tempo me mostrou que não existe essa coisa de projeto pequeno, quando você escolhe uma linguagem/plataforma para um projeto você praticamente casou com ela, portanto é bom que você se sinta bem desenvolvendo naquele ambiente seja ele qual for e que ele atenda suas necessidades.
Outro fator que considero muito relevante é que quando eu fui decidir se focava no C++ ou no java haviam umas 7 empresas que forneciam compiladores compatíveis com o padrão ANSI enquanto que para java avia apenas uma.
Nao estou me referindo a linguagem e sim a plataforma.;
Uma empresa que fornece compiladores para a linguagem e plataforma Java ? Eu poderia citar varias aqui… tem certeza ?
Sim, Diego, tenho certeza, na época que eu estava escolhendo entre C++ e Java era só a uma, hoje em dia claro que a situação é outra.
O que eu quis dizer com meu posto foi que talvez o motivo dos Cassandra ser desenvolvido em Java seja simplesmente porque os programadores envolvidos preferem Java, assim como eu prefiro C++ para meus projetos. Acredito que nenhum programador experiente fica pensando muito em qual linguagem adotar para um projeto, ele adota a que ele gosta a menos que ela não sirva.
s/posto/post/g
Para botar lenha na fogueira da discussão sobre Java vs C++:
“Java will be faster than C++” by Kirk Reinholtz, JPL, Apr 2001
“Performance of Java versus C++” by J.P. Lewis and Ulrich Neuman, USC, Jan. 2003 (updated 2004)
Vários benchmarks mostram que Java em conjunto com JIT pode ser mais rápido que C++ em algumas operações aritméticas. Admito ser tendencioso para o lado do Java, mas nunca falaria mal, nem rechaçaria linguagens tão boas quanto C/C++.
Esse JIT veio de Outro planeta ou é software que também é compilado?
da pior das hipoteses pode-se fazer um interpretador JIT com C++ e re-fazer o java pra se fazer uma aplicação.
o pessoal sempre fala de Java ser mais rápido que C++. Se fosse verdade pq a maioria dos jogos são C++?
dizer que Java é rápido tudo bem, eu nunca ví, mas até pode ser verdade. Agora dizer que é mais rápido que C++ é Mito.
Vou aproveitar que o pessoal parece manjar de java para perguntar, java compila a si mesma? compilador e interpretador? É uma duvida mesmo sempre achei que parte do código da maquina virtual do java fosse C.
O compilador Java não compila ele mesmo.
O JIT é parte da JVM que também é compilada, mas isso não interfere em nada em relação a ser ou não mais rápida.
O Java é mais rápido que C++ em alguns casos, não em todos, logo, não é usado em jogos por causa disso.
E não acho correto dizer que o Java é interpretado, e sim que ele é compilado e posteriormente traduzido pela máquina virtual, ou duplamente compilado (a tradução pela JVM seria a segunda compilação, esta feita pelo JIT).
“O Java é mais rápido que C++ em alguns casos”
como:
mais rápido lançar uma nova versão.
mais rápido para se desenvolver um software.
E essas partes compiladas são escritas em que?
@habeas_corpse
Não tem nada haver dizer que um algorítimo não pode ser mais rápido em Java que em C, pelo fato de o JIT não pode ser mais rápido. Uma coisa não tem nada haver com a outra.
Ao compilar um programa, você tem que otimizar para um hardware específico. Mas você não sabe quais serão as condições desse hardware no momento da execução do programa. O JIT tem, além das informações do hardware, informações do estado de cada componente e pode tomar decisões em tempo de execução, melhores que o C em tempo de compilação.
Dê uma pesquisada, de verdade. Para servidores, Java é MUITO rápido. Java é lento para interfaces gráficas. Por isso as pessoas tem a impressão que Java é lento.
@habeas_corpse
Eu quis dizer “pelo fato de o JIT ser compilado”.
Sorry
Dyego Souza do Carmo
A notícia é sobre o Cassandra, um projeto desenvolvido em Java. Vodê está misturando alhos e bugalhos ao dar tanto crédito ao Java.
Ou vai querer dizer que se não fosse em java ele não existira ?
O tal mongoDB está fazendo muito sucesso e foi feito em C++ .
O outro mais famoso é o CouchDb que é feito em Erlang. Linguagem aliás que anda se destacando para criar qualquer coisa facilmente escalável.
@Felipe, não adianta tentar discutir, pois fica claro que o habeas_corpse não sabe do que está falando.
Primeiro, o fato da JVM da Sun ser escrita em C++ não limita ela em nada quanto à performance do código que ela executará. Isso é meio óbvio já que ela possui seu próprio compilador para Java.
Essa afirmação é tão falaciosa quanto dizer que não é possível escrever um compilador de c++ mais rápido que o gcc se ele for escrito em c++ e compilado com o gcc.
Além disso, existe o fato de que em alguns cenários um JIT gera sim código mais eficiente que o equivalente em C++. Um exemplo claro disso são bibliotecas.
Chamar funções em uma biblioteca dinamicamente linkada é muito mais lento em C++ que em uma linguagem com JIT. Quem duvida disso recomendo olhar o código gerado p/ ambos os casos.
Porém, apesar disso, Java não é mais rápido que C/C++ em aplicações de alta performance como encoding de vídeo. Porém para algo como o Cassandra, acho pouco provável a diferença ser significativa.
Existem vários resultados mostrando linguagens com JIT sendo significativamente mais rápidas que aquelas compiladas estaticamente. O projeto Dynamo, por exemplo, conseguia produzir código tão eficiente quanto gcc -O4 (O3 + pgo).
“Primeiro, o fato da JVM da Sun ser escrita em C++ não limita ela em nada quanto à performance do código que ela executará. Isso é meio óbvio já que ela possui seu próprio compilador para Java.”
como disse anteriormente:
“da pior das hipoteses pode-se fazer um interpretador JIT com C++ e re-fazer o java pra se fazer uma aplicação.”
se ele foi feito em C++, ou seja, os 2 são C++, como que o C++ é mais lento?
Então depois dessas explicações do pessoal, minha opinião é que Java não é mais rápido que C++ e sim a técnica de se otimizar código “on the fly” produz resultados melhores que o esperado. Isso casa com o que eu já suspeitava e é perfeitamente logico, então que venha o LLVM.
:D
O fato do Cassandra sem melhor que o MySQL para grandes volumes de dados não tem nenhuma relação com a linguagem com a qual eles foram escritos, quem fala isso não sabem nem do que está falando. O Cassandra possui uma arquitetura totalmente diferente do MySQL, inclusive nem é um banco relacional. Tem gente comparando pão com pneu e pra tirar conclusões.
O Java é lento para interfaces gráficas caso estas sejam escritas com a API Swing. Caso as interfaces sejam escritas com o SWT, aí a história muda.
Pelo amor de Deus!
Sem querer inflamar, mas tá faltando um pouco de base nesta discussão!
NENHUM código interpretado pode ser igual ou mais rápido do que o MESMO código compilado!!!
Comparando-se é claro, exatamente o mesmo código, sem usar bibliotecas compartilhadas, recursos específicos das linguagens e outras artimanhas, artifícios ou ganbiarras.
Com um programa compilado, a execução é com linguagem nativa (em assembly) e muitas vezes otimizadas para o processador (amd, intel, mmx, sse1, sse2, sse3, 64bits), com instruções do processador, já a interpretada (mesmo com bytecode), tem um intermediário no meio do processo!
“NENHUM código interpretado pode ser igual ou mais rápido do que o MESMO código compilado!!!”
Você sabe o que é JIT? O Java COMPILA o bytecode à medida em que for sendo executado. E compila em relação à máquina que está executando e analisando o comportamento do programa pode ir compilando novamente com as otimizações que for levantando.
Isso faz a aplicação obter o máximo possível de otimização para o código nativo gerado.
Claro, que como a primeira execução do código é interpretada e nem todas as partes do programa serão executadas em loops ou em rotinas repetitivas, o ganho de performance de um compilador JIT varia muito entre as aplicações, daí que acontece benchmarks que dão ganho pro Java outros pros C++.
Fora isso, tem muita gente que conta o tempo da máquina levantar a Virtual Machine e contabilizam a memória alocada por ela, daí dependendo da aplicação o Java também pode perder.
Mas no frigir dos ovos, cada um tem a sua vantagem e não vai mudar a vida de ninguém se o Java ganhar ou perder.
Bom, talvez faça na vida do Larry Ellison! ehehehehe
Giga, o argumento do pessoal do Java é que o bytecode seria otimizado e compilado para código de maquina durante a execução do programa, como o JIT sabe as características finas da maquina por exemplo tipo de processador, tamanho dos caches internos L1, L2, Lx, etc. Teoricamente o JIT produziria um código de maquina melhor que o gerado por um compilador convencional que crie código estático para um numero numero grande de processadores, por exemplo que funcione em todos os i386.
Esse argumento é valido e verdadeiro mas existem duas formas do C++ ficar mais rápido, podemos usar um JIT no C++, assim como outros truques, e também podemos compilar informando para o compilador que deve habilitar todas as otimizações finas para um processador especifico que sera usado. É o que eu faço quando compilo meus sistemas, já que eu sei exatamente onde eles estão sendo executados.
@Weber Jr
Estou falando que se JAVA fosse tão lento… ninguem estava optando por ele (sim , prq quando escolem o cassandra optao por Java) no lugar deste MongoDB..
Este MongoDB faz tanto sucesso , mas o twitter e o digg resolveram confiar na BOLA LENTA E GORDA da plataforma Java…
Aqui fico a me perguntar… POR QUE ?