Todas as quintas-feiras é dia de palestra técnica na Locaweb. E hoje, pela segunda vez, eu falei sobre Mongo, mas desta vez com um foco maior em desenvolvimento (queries, modelagem, índices, …) usando MongoMapper. Bom, eis a apresentação a seguir. Em caso de dúvidas, já sabe 
Há uns dias eu fiz uma apresentação para a equipe da Locaweb sobre NoSQL e MongoDB. Para quem se interessar, eis a apresentação:
Até pouquíssimo tempo, ao definir a arquitetura de um novo sistema, a única coisa da qual tínhamos certeza é que usaríamos um banco de dados relacional para guardar o estado do nosso sistema, independente de qual linguagem ou design iríamos usar. Esta única “certeza” talvez derive um tanto por causa dos fracassos que outras abordagens para armazenamento de dados estruturados tenham tido no passado (bancos hierárquicos complicados, bancos XML com performance ruim, bancos OO que nunca deixaram de ser vaporware…), mas principalmente por causa de uma atitude mezzo conservadora, mezzo “silver-bullet-driven” por parte do “mercado”, que preferiu assumir que bancos relacionais são a única solução decente e segura para armazenar dados.
O grande problema desta “verdade universal” é quando ela não se mostra tão universal assim (pois, como todos sabem, there is no silver bullet) e, por falta de um melhor repertório tecnológico ou por basear decisões técnicas em dogmas, acabam recorrendo a alguns “jeitinhos” que, no fundo no fundo, nada mais são do que dívidas técnicas (dívidas pesadas, como aquelas que você contrai quando pede dinheiro emprestado a um mafioso) que um dia vão ter que ser pagas (imagine os capangas do mafioso batendo à sua porta).
"Si, io *SEMPRE* usarei Oracle, Don Vito."
Exemplos destas dívidas técnicas não faltam por aí, mas vou citar dois cenários nada incomuns:
Provavelmente você deve estar rindo porque você já se deparou com alguma destas aberrações e que lhe tiraram boas horas de sono. Horas estas que poderiam muito bem ter sido poupadas se ferramentas certas fossem usadas. E é nesta hora que ampliar um pouco os horizontes e, neste caso, conhecer um pouco sobre NoSQL iria resolver sua vida.
NoSQL é o termo usado para se referir a um conjunto de novas tecnologias de armazenamento de dados que não seguem as regras estabelecidas pela álgebra relacional e podem não conter todas as propriedades que caracterizam um banco de dados relacional como transacional.
Na verdade, embora o termo leve “SQL” no nome, seria muito mais correto se o nome fosse NoACID, uma vez que, em troca de obter coisas como escalabilidade horizontal e/ou habilidade para lidar com imensos conjuntos de dados (e considere algo como imenso a partir do momento em que você tiver que movimentar algumas dezenas de Terabytes) de maneira muito rápida, estes bancos de dados NoSQL abrem mão de coisas como consistência e o tamanho do escopo de uma transação (explicações sobre isso ficam para um próximo post). E, para o contexto em estes bancos foram criados (a maioria nasceu como solução de armazenamento de informações para redes sociais ou sites de mídia), o trade-off ACID x escalabilidade valia muito a pena. Afinal de contas, ninguém vai morrer se o Orkut perder uma ou duas atualizações de profiles. Por outro lado, este mesmo trade-off não faz o menor sentido para uma aplicação de compensação financeira, por exemplo (se fizer sentido para você, diga-me para qual banco você trabalha, por favor).
Além da questão de consistência, outra característica comum e muito interessante destes bancos é o fato de eles serem schema-free, i.e., diferentemente de um banco de dados relacional, em que entidades são mapeadas como tabelas, que possuem uma estrutura de dados bem definida usando colunas (que possuem um tamanho fixo), um banco de dados não-relacional pode guardar um vários tipos de entidades cada qual com estruturas diferentes. Por exemplo, você pode ter uma entidade Pessoa no seu sistema, mas as instâncias desta entidade podem ter estruturas diferentes entre si.
E, por fim, embora o nome (banco de dados não-relacional) sugira erradamente que estes bancos não permitem relacionamento entre entidades, a maioria deles suporta os mesmos tipos de relacionamentos que bancos relacionais suportam (1-1, 1-N, N-M,…), apesar das implementações destas poderem diferir um pouco do jeito relacional de ser. Além disso, bancos orientados a documentos permitem um tipo de relacionamento que não existe em bancos relacionais que é a incorporação, ou seja, um documento pode embutir outros documentos em sua estrutura.
Primeiro de tudo, escolha uma das várias alternativas de bancos não-relacionais disponíveis por aí. Eu sou meio suspeito, gosto muito do MongoDB e do CouchDB, dois bancos de dados orientados a documentos e que usam Javascript como linguagem para manipulação de dados. Mas existem outras alternativas muito boas, como o Apache Cassandra, Riak ou Redis (que são do tipo key-value) ou o Neo4J (banco de dados de grafos). Em segundo lugar, esqueça por alguns instantes SQL, pare de pensar em forma de tabelas, projeções, JOINs, etc etc etc. Muitas vezes o desenho que estamos acostumados a dar às nossas entidades no mundo relacional são completamente diferentes do desenho a que teremos numa abordagem orientada a documentos, por exemplo. E, por fim, não entre no hype do NoSQL e comece a tentar enfiar bancos não-relacionais em qualquer lugar porque nem sempre eles serão a melhor solução. NoSQL não é silver bullet 
Eu já fui um cara muito mais eloquente e bem pouco criterioso em relação ao que eu decidia escrever, e isso resultava em um blog cheio de atualizações (muitas vezes quase diárias) e um conteúdo relativamente pobre, proporcionalmente à quantidade de conteúdo gerado. Com o tempo, eu fui ficando, senão menos eloquente, pelo menos mais criterioso em relação ao que eu publico, mesmo porque ficar apenas repetindo a mesma opinião de todo mundo não agrega muito, o que tem feito com que este blog ficasse sob espessa camada de poeira e com várias teias de aranha devido à pouca atualização.
Mas, o fato é que começamos 2010 e botei na minha cabeça que, além de me exercitar todos os dias, acordar cedo, parar de tomar refrigerantes e moderar o consumo de doces, eu vou passar a atualizar este blog regularmente, muito disso inspirado pelos meus colegas de Locaweb, como Fábio Kung, Daniel Cuckier e Fábio Akita. E, por “regularmente”, entenda-se 1 vez por semana, ao menos, o que, ao final deste ano vai resultar em, no mínimo, 52 posts.
Claro, eventualmente, posso acabar me atrasando e entregar dois posts em uma semana, mas o objetivo é ter 52 posts até 31/12/2010 Mas não 52 posts quaisquer. Minha idéia é que estes 52 textos tratem não só sobre tecnologia ou arquitetura de software, mas também tratem sobre vários outros aspectos que fazem parte do nosso mundinho de desenvolvimento de software, tais como relações humanas, aspectos econômicos ou qualquer outra coisa que nos afete E, lógico, aceito sugestões de temas também.
Este blog está parcialmente de volta. Acabei de migrá-lo para os servidores da Locaweb, empresa para qual estou trabalhando desde novembro, embora ainda não tenha restaurado os meus antigos posts (e nem sei se vou). Mas, enfim, estou de volta