Author Archives: Lucas Renan

Views no CouchDB

by

Views são o método de agregação e relatórios sobre os documentos em uma base de dados (os SELECTs dos bancos relacionais), e são construídas por demanda para agregar, juntar e reportar documentos. As views são construídas dinamicamente e não afetam o documento subjacente, você poder ter várias representações diferentes dos mesmos dados que desejar.

As definições de views são estritamente virtuais e somente mostram os documentos da instancia corrente do banco de dados, fazendo-os separados dos dados que eles mostram e compatíveis com replicação. As views do CouchDB são definidas dentro de documentos de design especiais e podem ser replicadas em várias instancias de bancos de dados como documentos regulares, de modo que não apenas os dados são replicados no CouchDB, mas o design da aplicação inteira também é replicado.

Funções Javascript

As views são definidas usando funções javascript que atuam como map em um sistema de map-reduce. Uma view pega um documento do CouchDB como um argumento e então faz o cálculo que precisar fazer para determinar os dados que serão disponibilizados pela view, se houverem. É possível adicionar multiplas linhas para a view com base em um único documento.

Índices de Views

Essa é uma tradução adaptada:
http://couchdb.apache.org/docs/overview.html

CouchDB – Propriedades ACID

by

O CouchDB possui totais características das propriedades ACID (atomicidade, consistencia, isolamento e durabilidade). Em disco, o CouchDB nunca sobrescreve dados salvos ou estruturas associadas, assegurando que os dados estejam sempre em um estado consistente. Trata-se de um design “crash-only” aonde o servidor CouchDB não passa por um processo de shut down, ele é simplesmente terminado.

Alterações nos documentos (adicionar, editar, deletar) são serializadas, exceto os blobs binários que são escritos concorrentemente. Leituras no banco nunca são bloqueadas (lock) e nunca tem que esperar por escritas ou outras leituras. Qualquer número de clientes podem ler documentos sem serem bloqueados ou interrompidos por atualizações concorrentes, mesmo no mesmo documento. O CouchDB lê operações utilizando o modelo MVCC (Multiversion concurrency control) aonde cada cliente ve uma cópia consistente do banco de dados desde o início até o fim da operação de leitura.

Os documentos são indexados em b-trees pelo seu nome (DocID) e um ID de sequência. Cada atualização para uma instância de banco de dados gera um novo número sequencial. IDs de sequência são usados depois para encontrar as mudanças de forma incremental em uma base de dados. Esses índices b-trees (árvores B) são atualizados simultaneamente quando os documentos são salvos ou deletados. A atualização dos índices sempre ocorre no final do arquivo (append-only updates).

Os documentos têm a vantagem dos dados serem convenientemente “embalados” para armazenamento em vez de dividir em numerosas tabelas e linhas como na maioria dos bancos de dados. Quando os documentos são salvos em disco, os campos dos documentos e metadados são colocados em buffers, sequencialmente um documento depois do outro (depois isso é útil para construção de views).

Quando os documentos do CouchDB são atualizados, todos os dados e índices associados são “descarregados” (flushed) no disco e o commit transacional sempre deixa o banco em um estado completamente consistente. Commits ocorrem em dois passos:

1 – Todos os dados dos documentos e atualizações em índices associados são “esvaziados” (flushed) no disco de maneira síncrona.
2 – O cabeçalho do banco de dados atualizados é escrito em dois pedaços consecutivos e idênticos para compor os primeiros 4k do arquivo, então é “esvaziados” (flushed) no disco de maneira síncrona.

No caso do sistema operacional dar “crash” ou uma falta de energia no passo 1, as atualizações parcialmente liberadas são simplesmente esquecidas ao reiniciar. Se acontecer algum acidente no passo 2 (commitando o cabeçalho), uma cópia sobrevivente idêntica aos cabeçalhos anteriores permanecerão, garantido a coerência de todos os dados previamente salvos. Exceto a área de cabeçalho, checagens de consistencia ou consertos depois de um crash ou falta de energia, nunca são necessários.

Essa é uma tradução adaptada:
http://couchdb.apache.org/docs/overview.html

Como os documentos são armazenados no CouchDB?

by

O CouchDB armazena os dados em documentos. Cada documento tem um nome único no banco e o CouchDB provê uma API HTTP RESTful para ler e atualizar (adicionar, editar, excluir) os documentos do banco de dados.

Os documentos são as unidades primárias de dados, consistem em um número qualquer de campos e anexos. Os documentos também incluem metadados que são mantidos pelo sistema de banco de dados. Os campos possuem nomes únicos (por documento) e contem valores de vários tipos (texto, número, booleano, listas, etc) e não há qualquer limite definido para o tamanho do texto ou elemento.

O modelo de atualização de documentos do CouchDB é lockless (sem lock) e otimista. Edições nos documentos são feitas por aplicações clientes que carregam os documentos, aplicam as alterações e salvam de volta ao banco de dados. Se outro cliente que estiver editando o mesmo documento salvar as alterações primeiro, o cliente recebe um erro de conflito de edição. Para resolver o conflito de atualização, a versão mais recente do documento pode ser aberta, a edição é reaplicada e a atualização é tentada novamente.

As alterações nos documentos (adicionar, editar, excluir) são “tudo ou nada”, tem sucesso completamente ou falha completamente. O banco nunca contem documentos salvos ou editados parcialmente.

Essa é uma tradução adaptada do início do Overview técnico do CouchDB:
http://couchdb.apache.org/docs/overview.html

MongoDB

by

No post que eu falo que conheci o conceito de NoSQL e fiz uma pequena tradução sobre o CouchDB eu disse que em breve falaria sobre o MongoDb.

Assim como o Couch o Mongo é um banco de dados orientado a documentos, é open source, também tem como propósito a escalabilidade e é desenvolvido em C++.
Os documentos são armazenados com a simplicidade de esquemas de dados JSON-like, mais precisamente BSON (Binary JSON). Assim como o JSON, suporta a incorporação de objetos e arrays dentro de outros objetos e arrays.
As consultas também são bem simples:

db.clientes.find()

em SQL seria

SELECT * FROM clientes

Suporta Map/Reduce, provê algumas funcionalidades para buscas full text e tem muitas outras vantagens.

Com certeza os bancos orientados a documentos mais falados no momento são o MongoDB e o CouchDB. Não arrisco um papilte em dizer qual é melhor, particularmente eu gosto bastante do CouchDB. Notei que o MongoDB está em uma fase de desenvolvimento mais evoluída que o CouchDB, porém acho o Couch um pouco mais simples, até mesmo de instalar.
Como referência aqui no Brasil, temos o pessoal da Improve It utilizando o Couch e o pessoal do time de Cloud Computing da Locaweb utilizando o Mongo.
E você prefere qual? Por que?

Instalar CouchDB no Ubuntu

by

Para instalar o CouchDB no Ubuntu você pode simplesmente rodar o seguinte comando:

sudo apt-get install couchdb

Se quiser ter a última versão:

sudo apt-get build-dep couchdb
sudo apt-get install libmozjs-dev libicu-dev libcurl4-gnutls-dev libtool

Baixe a última versão (.tar.gz)
http://couchdb.apache.org/downloads.html

Descompacte (hoje a versão mais nova é a 0.10.1)
tar -zxvf apache-couchdb-0.10.1.tar.gz
cd apache-couchdb-0.10.0

Instale
./configure
make
sudo make install

Com o couchdb instalado, rode para testar:
sudo couchdb
e abra no browser http://localhost:5984/_utils

Você pode encontrar mais detalhes na wiki do couchdb.

Prepared Statements MySQL

by

O que são prepared statements?

Prepared statment serve para setar uma consulta e executá-la várias vezes com parâmetros diferentes. São desenvolvidos para queries ad hoc, são mais seguros e mais eficientes. Segue um exemplo simples:

SELECT * FROM cidade WHERE idCidade = ?

O ? (ponto de interrogação) é chamado de placeholder. Quando a consulta acima for executada é necessário passar um valor, que será substituído pelo ? na consulta.

Por que usar prepared statements?

Existem numerosas vantagens em usar prepared statements em suas aplicações, por duas razões: segurança e performance.

Os prepared statements podem ajudar a aumentar a segurança, pois separam SQL lógico dos dados fornecidos pela aplicação. Essa separação ajuda a previnir uma série de vulnerabilidades conhecidas como Ataques de SQL Injection. Normalmente quando se recebe valores de uma aplicação em uma query ad hoc, você precisa ter muito cuidado com o dado recebido, para isso é necessário utilizar algumas funções de escape de caracteres, como escape de aspas simples, aspas duplas, barras, etc para garantir que nenhum usuário malicioso consiga injetar código na sua query. Quando se está utilizando prepared statments isso não é necessário, a separação dos dados permite que o MySQL automaticamente leve em conta esses caracteres e eles não precisam ser escapados por nenhuma função especial.

O crescimento de performance nos prepared statements podem vir de algumas características diferentes. Primeiro é a necessidade de parsear a consulta apenas uma vez. O MySQL vai parsear a consulta na primeira vez para checar a sintaxe e setar a consulta para ser executada. Então, se você executar a consulta várias vezes, ele não vai precisar ter esse trabalho novamente. Esse pre-parsing pode causar um aumento de velocidade se você precisar executar a consulta várias vezes, como por exemplo quando se precisa fazer vários INSERTs.
A segunda coisa que pode ser mais rápida é que os prepared statments podem utilizar um protocolo binário. O protocolo tradicional utilizado pelo MySQL sempre converte tudo em strings antes de mandar pela rede. O protocolo binário resolve esse problema, todos os tipos são enviados na sua forma binária nativa, o que economiza tempo de conversão da CPU e pode diminuir o tráfego na rede.

Quando você deve utilizar prepared statments?

Os prepared statements podem ser utilizados para uma infinidade de razões, mas não devem ser utilizados em toda sua aplicação. Algumas vezes podem ser mais lentos que uma consulta normal. A razão é que existem dois round-trips (“idas”) para o servidor, o que pode comprometer a performance para consultas que são executadas apenas uma vez. Cabe ao desenvolvedor decidir se compensará ter impacto na performance para ganhar mais segurança.

Considerações finais

Prepared statments são recursos muito bons de banco de dados quando utilizados adequadamente, podem aumentar performance e segurança.
Esse texto é uma tradução adaptada do texto de Harrison Fisk.
O artigo original pode ser encontrado em
http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html

CouchDB

by

Um conceito interessante que conheci recentemente é o do NoSQL. Existem alguns bancos de dados orientados a documentos que estão sendo comentados com certa frequência pela comunidade. Fiz uma tradução sobre o CouchDB, em breve vou escrever sobre ele e também sobre o MongoDB.

O Apache CouchDB é um banco de dados orientado a documentos que pode ser consultado e indexado com MapReduce utilizando Javascript. O CouchDB também oferece replicação incremental com detecção de conflitos bi-direcionais e resolução.

O CouchDb provê uma API JSON RESTful que pode ser acessada por qualquer ambiente que permita requisições HTTP. Existem inúmeras bibliotecas de terceiros que fazem seu uso mais fácil da linguagem de programação de sua escolha. CouchDB tem um console de administração web que fala diretamente com o banco de dados usando requisições HTTP enviadas do seu navegador.

É escrito em Erlang, uma linguagem de programação robusta, funcional ideal para construir sistemas distribuídos concorrentes. Erlang permite design flexível que é facilmente escalável e facilmente extensível.

Por que as empresas perdem bons desenvolvedores?

by

A “implantação” do sistema neoliberal no Brasil (e em outros lugares do mundo) contribuiu para o aumento da competitividade entre as empresas e também entre os profissionais. A busca por uma melhor qualificação profissional se tornou constante, devido ao fato de que as empresas passaram a exigir profissionais com alto nível de conhecimento técnico e a concorrência cada vez mais acirrada.

Não é preciso ter muito conhecimento de economia ou política para se perceber que o capitalismo é um sistema que não tem como objetivo favorecer o trabalhador. Com todos os problemas do mundo, muitas pessoas se sujeitam a péssimas condições de trabalho para garantir o sustento de suas famílias.

O desenvolvimento de software é uma tarefa criativa que exige profissionais com alto grau de conhecimento técnico. Não é uma tarefa braçal, isso quer dizer que o desenvolvedor tem seu capital intelectual como instrumento de trabalho.
Devido a tamanha complexidade das tarefas, é muito difícil encontrar bons profissionais (desenvolvedores, programadores, analistas, engenheiros etc) comparado a outras áreas profissionais em que o mercado já possui certa saturação de mão de obra.
Isso faz com que o profissional de tecnologia da informação seja um pouco menos desvalorizado.

Algumas empresas (principalmente as pequenas) sofrem grande impacto quando um bom desenvolvedor recebe uma boa proposta de trabalho e troca de emprego (já presenciei essa situação algumas vezes). Para minimizar esse problema as empresas estão investindo (não que elas sejam legais, o problema é o custo gerado).

Fiz uma pequena lista com os principais motivos (ao meu ver) que levam um desenvolvedor a mudar de trabalho:

- Salário
O motivo mais óbvio e comum. Quando uma outra empresa oferece salário mais alto, é improvável que o profissional recuse a proposta, caso a empresa atual não ofereça uma boa contra proposta.
É incrível como as empresas “tem mania” de achar que conseguem realizar um trabalho de qualidade contratando apenas estagiários (para pagar menos).

- Desafios
Um programador vive de desafios (não confunda com “buxas”). Passar o mês inteiro fazendo formulários não é tarefa que motive a maioria dos desenvolvedores web. Se o profissional não sentir que seu trabalho é “diferente”, é útil, é legal, ele não vai se sentir motivado a continuar.
Existe grande diferença em trabalhar “estilo produção” fazendo meia dúzia de pequenos sites por mês e cuidar de uma aplicação de alta disponibilidade com milhares de acessos por hora.
Cabe a empresa proporcionar novos desafios a sua equipe (pois em outras empresas existem vários).

- Tecnologia
Um fator interessante, que muitas vezes as empresas não enxergam, é a tecnologia utilizada para desenvolvimento. Se o programador apoia o software livre, ele não vai gostar (vai odiar) programar em .NET por exemplo, assim como um desenvolvedor Rails não gosta muito de Java por exemplo. (sei que dizem que devemos ser poliglotas, mas isso é só um detalhe =p)

- Equipe e chefe
Ponto crucial que pode levar o profissional até a se demitir da empresa. Um bom desenvolvedor não gosta de trabalhar com desenvolvedores medíocres, ele quer trabalhar ao lado de outros bons profissionais.
Também não suporta a idéia do chefe mala que faz pressão, não ajuda e só “passa buxa”.
Esse problema se agrava, quando o desenvolvedor é contratado como estagiário a certo tempo e já adquiriu certa experiência que o faz não depender do emprego para aprender mais.

- Ambiente de trabalho
Outro fator fundamental é o ambiente, o local de trabalho precisa ser bom, ter ar condicionado, ter comida a disposição, cadeira confortável, o mais importante um PC (ou MAC) de qualidade.
O calor irrita e tira a concentração, isso faz com que a produtividade diminua.
Como diria o velho ditado “saco vazio não para em pé”, a empresa tem que fornecer comida como bolachas, frutas, suco, etc. Comida fornece energia para o programador ser mais produtivo.
Talvez o que mais faça um programador ficar irritado, é quando o computador é lento, quando demora “meia hora” para compilar o software ou carregar a IDE.

- Flexibilidade de horários
Algumas empresas insistem em achar que desenvolver software é como fabricar uma peça ou montar um carro. Desenvolver software NÃO É PRODUÇÃO!
Não adianta fazer com que seu colaborador “bata cartão” as 8h da manha em ponto e não saia antes das 18h. Estamos lidando com humanos e não com máquinas, o dia que a pessoa está com problemas ou não está motivada, a baixa na produtividade é inevitável.
O colaborador não deve se sentir em uma prisão, em que não pode ir 5min no “bar da esquina” comprar um refrigerente.