janeiro 27th, 2012 | by admin | bigtable, cassandra, couchdb, escalabilidade, hbase, hypertable, memcached, mongodb, mysql, neo4j, nosql, redis
jan
27
Pessoal achei um pdf interessante sobre NOSQL do Rick Cattell quem quiser dar uma olhada está aí o link: http://cattell.net/datastores/Datastores.pdf
outubro 30th, 2011 | by Thiago Avelino | escalabilidade, java, mongodb, nosql, python
out
30
Edgar Silva é Solutions Architect Manager na Red Hat Brasil, responsável pelo time que define as tecnologias e soluções de plataformas Linux, middleware, virtualização e cloud computing. Na segunda edição do NoSQLBr, Edgar fez uma apresentação sobre o OpenShift, o PaaS da Red Hat, com demonstrações práticas de como utilizá-lo em conjunto com tecnologias como MongoDB e Infinispan para recurso de armazenamento de aplicações (que podem estar escritas em diversas linguagens, entre elas Python, PHP, Java e Ruby).
Edgar tem como missão na empresa pesquisar como combinar vários conceitos computacionais e de negócios para encontrar a solução mais adequada aos desafios de projetos propostos por seus clientes. “Até que ponto são relevantes questões como sistema operacional ou linguagem? As empresas querem ser bem atendidas, não importa muito tecnologia, linguagem ou sistema operacional. A questão está cada vez mais focada em negócios mesmo”, diz ele.
Com a “nova onda” de Cloud, várias soluções de PaaS surgem como alternativa para empreendedores e pequenos investidores atrairem negócios e transformar meras ideias em casos de sucesso. Projetos relacionados a dados públicos, jogos online em HTML5 para dispositivos móveis e geolocalização, entre outros, são casos de uso candidatos para começarem a ser desenvolvidos nesse tipo de infraestrutura – gratuita – como o OpenShift.
Assista ao vídeo com a íntegra da palestra de Edgar Silva no NoSQLBr 2011: clique aqui
Referência: Gonow Tecnologia - http://www.gonow.com.br/blog/2011/10/26/openshift-nosql-a-la-carte-em-um-paas-100-open-source/
maio 29th, 2010 | by alex | escalabilidade, mysql, nosql, sql
mai
29
Com essa onda de NoSQL pra cá, NoSQL pra lá, muitos ainda tem muitas duvidas em relação ao NoSQL, de quando usar, como usar e etc. E como não podia deixar de ser, vários mitos estão rodeando esse novo conceito de banco de dados.
NoSQL é uma nova forma de bancos de dados, que não usam apenas os comandos SQL que você está acostumado, SELECT, UPDATE, DELETE e todas as váriaveis dele. Normalmente essas instruções foram trocadas por funções e muitas vezes já em oop.
Não é só porque ele não usa instruções SQL que ele é melhor que o banco de dados que você usa. Os bancos de dados atuais, são muito antigos, o MySQL por exemplo começou em 1994, utilizando o modelo relacional de tabelas, isso é um conceito tão antigo quanto esses bancos de dados. Os bancos de dados NoSQL aproveitam e corrigem erros como a dificuldade de escalar esses bancos de dados.
Um dos mitos do NoSQL é que só 10% dos sites de hoje em dia, devem usar o NoSQL. Isso na verdade é uma interpretação errada, a idéia na afirmação é que 90% dos sites não sentiriam uma melhora consideravel de performance. Isso é verdade imagine um blog com 10 visitas diárias, qualquer banco de dados atual serve pra essa aplicação, até mesmo se você tiver 10mil visitas diárias.
Mas isso não siguinifica que você não possa usar um banco de dados NoSQL para a sua aplicação. Se você quiser usar um banco de dadso NoSQL no seu blog de 10 visitas diárias, isso não te impede de nada.
Você pode ter um site, que é bastante visitado o seu banco de dados estar aguentando bem, mas você quer gerar alguns logs, seja para estatisticas ou para qualquer outra coisa. Seria bastante viavel usar um banco de dados desses, porque você vai ter muitos dados, você vai precisar consultar de forma rápida e fácil, um NoSQL seria ótimo para isso.
Muito se tem visto sobre usar o NoSQL em aplicações web de grande porte, porem ela pode ser usada em qualquer tipo de aplicação, você pode usar na web ou no desktop, não tem limites para isso.
Você pode e deve usar um NoSQL com algum banco de dados relacional que você use. Você pode até usar vários tipos de NoSQL e um MySQL por exemplo. Pode usar um NoSQL para cache dos dados, outro para os registros de logs e assim por diante, claro que você não precisa disso, mas você pode fazer.
Você pode usar qualquer NoSQL, porem se você quer começar no mundo NoSQL eu aconselharia um banco de dados orientado a documentos, eu creio que seja o mais próximo de um banco de dados relacional, e são extremamente faceis de se usar. Apesar de serem bastante parecidos, eles tem conceitos diferentes, por exemplo, você não precisa de uma tabela para comentarios e uma para posts, você coloca tudo no mesmo documento(como se fosse uma tabela).
Como vocês puderam ver, um NoSQL pode ser usado para qualquer tipo de aplicação, seja web como desktop, pequena, média ou grande. Porem as vezes você pode sentir mais diferença estruturando corretamente o seu banco de dados atual do que mudando completamente para um NoSQL.
A vatagem de um NoSQL é a alta escalabilidade a velocidade de inserção e de consulta desses bancos são absurdos. Eles vieram para arrumar problemas que os bancos de dados relacionais tem e que não foram projetados nem imaginados na época que o sistema relacional foi criado.
maio 14th, 2010 | by alex | cassandra, couchdb, escalabilidade, mongodb, mysql, nosql
mai
14
Aposto todas as minhas fichinhas que todos que quiseram estudar NoSQL ficaram na duvida de qual dos dois usar, MongoDB ou CouchDB, mesmo que tenha ido para um cassandra ou qualquer outro NoSQL.
A duvida fica muito maior, porque são dois banco de dados muito semelhantes(orientado a documentos) e bastante usados. Vou colocar aqui o meu relato sobre o MongoDB e o CouchDB.
Quando vi as possibilidades do NoSQL, o primeiro banco de dados que vi foi o CouchDB, fiquei louco para começar a aprender ele, fazer alguns projetos e tudo mais, porem, dei uma olhada muito rápida no site deles, e não vi uma versão pra Windows. Falem o que quiserem, mas muita, muita gente e todo mundo sabe disso, faz tudo no Windows e se não tiver uma versão pra ele, não vão usar, vão continuar com o MySQL.
Demorei meses para voltar para o NoSQL, mas sempre com aquela vontade de realmente aprender um desses novos bancos de dados. Voltando aquele tesão inicial em aprender o NoSQL, vi muitos códigos usando o CouchDB, muita gente usando, muitas coisas pela internet sobre ele. Isso foi um ponto forte pra mim em relação a outros, quando vi que o CouchDB era incubado pela Apache, a balança pesou mais um pouquinho.
Já que o NoSQL é uma técnologia extremamente nova, eu queria pensar a longo prazo, várias vezes fiquei me perguntando as vantagens entre esses bancos de dados. Confesso que quando vi uma pesquisa falando sobre os bancos de dados que as pessoas mais tinham vontade de aprender, apontando o CouchDB como segundo, ele ganhou mais um ponto, em primeiro vinha o cassandra, porem ele ainda não tinha instalação pra windows. O PHP é muito forte, e um dos fatores principais é a grande comunidade e excelente documentação que eles possuem, levei isso em consideração na hora da escolha do NoSQL.
O CouchDB vinha cada vez mais ganhando pontos comigo, mas na mesma pesquisa, o terceiro colocado era o MongoDB, resolvi olhar ele mais de perto, uma vez que queria dar o ponta pé inicial.
Cheguei para olhar o MongoDB só por olhar mesmo, só para ir pro CouchDB com a consciencia limpa. Lia alguma coisa sobre ele, já pensava, mas o CouchDB faz isso também. Mas uma coisa começou a me chamar a atenção, o MongoDB para instalar era só baixar no site e extrair em algum diretório. Isso me chamou a atenção, pois o CouchDB precisava de algumas dependencias para rodar. Logo baixei e instalei, naquele momento comecei a pensar mais sobre ele, um coraçãozinho cresceu.
Rodei uma linha de comando, e está lá, um NoSQL funcioando direitinho. Isso foi tão empolgante, que não achava que pudesse melhorar, olhei no site do MongoDB, e para rodar com o PHP bastava instalar uma DLL. Fui lá e instalei a dll.
A facilidade me encantou, porem ainda pesava a incubadora do CouchDB e todas os outros pontos. Analizando mais um pouco o CouchDB vi que era preciso vários includes para fazer ele funcionar com PHP, menos pontos pra ele, uma vez que o MongoDB se saiu muito bem nessa. Agora fui colocar lado a lado a documentação.
Não precisei olhar muito para saber o escolhido, na imensa documentação do php.net esta uma documentação para o MongoDB. Foi ali que parei de ler o CouchDB e ler sobre o MongoDB. MongoDB funcioando na minha maquina, documentação no php.net, documentação no próprio site do MongoDB era incrivel, não tive mais tempo para o CouchDB.
| N º de inserções |
Couch Tempo Total (seg) |
Couch / Doc (ms) |
Mongo Tempo Total (seg) |
Mongo / Doc (ms) |
| 1 | 0,0015 |
1,46 |
0,0005 |
0,5 |
| 2 | 0,0015 |
0,75 |
0,0004 |
0,2096 |
| 3 | 0,0017 |
0,56 |
0,0005 |
0,1604 |
| 4 | 0,0017 |
0,44 |
0,0005 |
0,1190 |
| 5 | 0,0018 |
0,36 |
0,0005 |
0,1060 |
| 6 | 0,0019 |
0,32 |
0,0006 |
0,0931 |
| 7 | 0,0021 |
0,3 |
0,0006 |
0,0847 |
| 8 | 0,0022 |
0,27 |
0,0007 |
0,0789 |
| 9 | 0,0023 |
0,25 |
0,0007 |
0,0734 |
| 10 | 0,0025 |
0,25 |
0,0007 |
0,0721 |
| 50 | 0,007 |
0,14 |
0,0024 |
0,0476 |
| 100 | 0,0136 |
0,14 |
0,0044 |
0,0442 |
| 500 | 0,0687 |
0,14 |
0,0253 |
0,0505 |
| 1000 | 0,1361 |
0,14 |
0,0372 |
0,0372 |
| 2500 | 0,4686 |
0,19 |
0,0278 |
0,0372 |
| 5000 | 0,9165 |
0,18 |
0,0488 |
0,0371 |
| 7500 | 1,5116 |
0,2 |
0,0835 |
0,0098 |
| 10000 | 2,3111 |
0,23 |
0,1065 |
0,0111 |
| 25000 | 6,8684 |
0,27 |
0,2711 |
0,0107 |
| 50000 | 15,8227 |
0,32 |
0,5430 |
0,0109 |
| 100000 | 35,3071 |
0,35 |
1,7697 | 0,0177 |
| 250000 | 104.0009 |
0,42 |
6,4533 |
0,0258 |
| 500000 | 230.6021 |
0,46 |
11,7684 |
0,0235 |
| 750000 | 352.7959 |
0,47 |
17,0473 |
0,0227 |
| 1000000 |
487.3284 |
0,49 |
18,4376 |
0,0184 |
Analisando os dados do gráfico e da tabela podemos perceber que o tempo real do MongoDB quase sempre esta uma casa(decimal) abaixo do CouchDB, ou seja, enquanto o CouchDB demora 0,0025 o Mongo DB, para o mesmo conjunto de instruções, demora 0,0007 segundos. E por conseguinte notamos que no final da inserção de 1 milhão de registros o CouchDB demora 487.3284 e o MongoDB 18,4376 segundos ao total. É um tempo considerável a se levar em conta
Posso ter puxado o saco do MongoDB, mas a facilidade de instalação, sem dependencias nem nada, só instalar uma dll no meu php e rodar, foi fator decisivo. No meio do caminho da comparação, o processo foi tão simples que parei por ali. Ao ver a documentação do php.net vi que ali o MongoDB tinha o apoio que eu esperava. Apesar de muitas pessoas estarem entrando no NoSQL indo direto pro CouchDB o MongoDB tem uma comunidade bastante forte, a facilidade dele como um todo é incrivel, isso conta muitos pontos.
Eu escolhi o MongoDB, mas vou estudar o CouchDB e o Cassandra. Eles são tão faceis, que quero aprender nem que seja um pouco de cada um deles, mas estou estudando a fundo o MongoDB.
maio 11th, 2010 | by alex | benchmark, escalabilidade, mongodb, nosql
mai
11
Quem está começando com nosql deve estar maravilhado com todo o potencial. E para o ego ficar maior ainda, é legal medir o tempo de carregamento e fazer um benchmark no seu código.
É só você usar essa função:
[php]
function getTime(){
static $tempo;
if( $tempo == NULL ){
$tempo = microtime(true);
}
else{
echo ‘Tempo (segundos): ‘.(microtime(true)-$tempo).”;
}
}
[/php]
Com isso você vai saber o tempo extado que o seu script vai levar para carregar. Para você usar essa função é muito fácil também:
[php]
getTime();
//aqui você coloca o teu código
getTime();
[/php]
E é isso ai, aproveitem e coloquem aqui nos comentários o benchmark de vocês. @suissacorp obrigado pela função.
maio 7th, 2010 | by alex | escalabilidade, mongodb, mysql, nosql
mai
07
Quem já não teve vontade de testar o mundo nosql, mas ou não conseguiu instalar, ou teve preguiça ou não queria mudar para o linux? Aposto que mais de 90%.
Vendo essa necessidade, aproveitei o programa Lighty2Go que já vem com Lighttpd, php e MySQL, aproveitei e fiz algumas modificações e coloquei o MongoDB e PHP juntos, e de bonus o phpmoadmin, que serve para administrar o MongoDB.
Ele funciona de forma extremamente simples, depois de você baixar os arquivos extraia no pendrive ou em qualquer lugar do seu computador. Depois é só iniciar o servidor
Quando você iniciar o servidor, ele vai estar na porta 81, ou seja, para acessar ele você deve entrar em http://localhost:81
Para administrar o MySQL acesse:
http://localhost:81/phpmyadmin/
Para ver o phpinfo:
http://localhost:81/phpinfo
Para ver o phpmoadmin:
http://localhost:81/moadmin.php
Os arquivos do seu site você pode colocar tudo dentro de HTDOCS.
Fica ai esse excelente pacote, com um dos melhores servidores web o lighttpd, com a melhor programação o PHP, com o melhor banco de dados MongoDB, e o antigo melhor, MySQL.
http://www.megaupload.com/?d=A1MVB1YP
http://rapidshare.com/files/384566309/Lighty2Go.rar.html
maio 7th, 2010 | by suissa | cassandra, escalabilidade, java, nosql
mai
07
Hoje de manhã me deparei com a facilidade de instalar o Cassandra no Windows então vamos começar baixando a última JDK(Java SE Development Kit) e vai precisar do Cassandra, lógico,http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.6.1/apache-cassandra-0.6.1-bin.tar.gz
Modifique o arquivo de configuração Cassandra como você gosta e não se esqueça de atualizar as localizações dos diretórios de um UNIX como caminho para algo em seu diretório do Windows (no meu exemplo o arquivo de configuração está localizado em c:\cassandra\conf\storage-conf.xml
<CommitLogDirectory>C:/cassandra/data/commitlog</CommitLogDirectory>
<DataFileDirectories>
<DataFileDirectory>C:/cassandra/data/data</DataFileDirectory>
</DataFileDirectories>
Essas linhas não existem no arquivo padrão, então pode colá-las sem problema. Eu coloquei mais para o final do arquivo.
<CalloutLocation>C:/cassandra/data/callouts</CalloutLocation>
<BootstrapFileDirectory>C:/cassandra/data/bootstrap</BootstrapFileDirectory>
<StagingFileDirectory>C:/cassandra/data/staging</StagingFileDirectory>
Abra o cmd e execute o cassandra.bat arquivo (no meu exemplo está localizado em c:\cassandra\ bin\cassandra.bat)
Você pode verificar que Cassandra está funcionando, ao tentar se conectar ao servidor. Para fazer isso, abra um novo cmd e executar o cassandra-cli.bat arquivo a partir do diretório bin.
c:\cassandra\ bin\cassandra.bat
connect localhost/9160
Caso ainda assim não esteja rodando tente excutar o cassandra.bat e o cassandra-cli.bat apartir do C:\cassandra. Ex.:
cd cassandra
bin\cassandra.bat
E pronto nosso Cassandra já está pronto para uso.
maio 7th, 2010 | by suissa | escalabilidade, mongodb, nosql
mai
07
O MongoDB também oferece recursos que vão além das operações de banco de dados. Por exemplo, ele oferece uma boa solução para armazenar arquivos grandes e pequenos no banco de dados.
Os arquivos são automaticamente divididos em blocos. Se MongoDB é executado em um ambiente de auto-sharded, pedaços de arquivo também são replicados em vários servidores.
Armazenar arquivos é surpreendentemente muito difícil, um problema para resolver de forma eficiente, especialmente quando você precisa gerenciar um grande número de arquivos. Salve arquivos em um sistema de arquivos local muitas vezes não é boa solução.
Um exemplo dessa dificuldade é o problema que o YouTube tinha eficientemente servir miniaturas de milhões de vídeos , ou mesmo os cortes realizados pelo Facebook eficientemente servir milhares de milhões de fotos .
MongoDB resolve este problema através da criação de duas coleções internas: os arquivos collection para manter informações sobre os metadados de arquivos e os chunks collection mantém informações sobre os pedaços do arquivo.
Se você quer armazenar um arquivo de vídeo grande, você usaria um código como este:
[php]$metadata = array(
<pre> "filename" => "path.avi",
"downloads" => 0,
"comment" => "This file is foo bar",
"permissions" => array(
"crodas" => "write",
"everybody" => "read",
)
);
$grid = $db->getGridFS();
$grid->storeFile("/file/to/path.avi", $metadata);[/php]
Como você pode ver é simples de entender. #ficadica
parte retirada do artigo: http://www.phpclasses.org/blog/post/118-Developing-scalable-PHP-applications-using-MongoDB.html
maio 7th, 2010 | by suissa | escalabilidade, javascript, mongodb, nosql, sql
mai
07
Geralmente, com MongoDB não estamos construindo a partir de consultas SQL, logo ataques SQL Injection não são um problema.
No MongoDB as consultas são representados como BSON. Normalmente a linguagem de programação oferece uma maneira conveniente de construir estes objetos que está livre da injeção. Qualquer caracter especial não afetará o banco pois ele será apenas uma string.
Alguns cuidados são apropriados quando utilizando Javascript. Por exemplo, quando usando o $ em uma consulta, não concatenar fornecido usuário declaração de dados para compilar o código Javascript, o que seria análogo a uma vulnerabilidade de injeção SQL. Felizmente, a maioria das consultas em MongoDB pode ser expresso sem Javascript. Além disso, podemos misturar os dois modos. É uma boa idéia para fazer todos os campos fornecidos pelo usuário ir direto para um campo BSON.
Você pode usar db.eval () com valores fornecidos usuário, você pode usar o CodeWScope ou você pode fornecer argumentos extras para sua função. Algo como: function (db.eval (userVal ){…}, user_value); Isto irá assegurar que você obterá user_value enviadas como dados em vez de código.
As vezes é útil construir um objeto BSON onde a chave é fornecida pelo usuário. Nessas situações, as chaves precisam ter substituições. O usuário pode enviar uma $ valor com a_chave.meu_objeto onde {$algo: “coisas”}. Então podemos ver alguns casos:
Artigo semi traduzido de http://www.mongodb.org/pages/viewpage.action?pageId=7209106
maio 6th, 2010 | by suissa | cassandra, escalabilidade, flockdb, hadoop, mysql, twitter
mai
06
Fiquei pasmo coma quantidade de informação
Agora me pergunto seria possível sem NOSQL?