Azure DocumentDb

Esse post foi migrado do blog antigo. A publicação original foi no dia 21/08/2014

E aí! O Azure entrou, oficialmente, na briga dos bancos NoSql orientados a documentos. E isso é muito bom! Veja o anúncio completo.

Azure DocumentDb, ainda em Preview, é similar ao mongodb. A grande diferença é que é totalmente gerenciado pelo Azure!

Azure DocumentDB gerencia os dados através de recursos. Esses recursos são replicados para alta disponibilidade e acessados por uma url única. Como vários outros serviços do Azure, o DocumentDb disponibiliza uma api HTTP RESTful para todos os recursos.

Todos os recursos dentro do Azure DocumentDB são modelados e armazenados como documentos JSON.

O relacionamento dos recursos funciona assim: Um Database tem várias Collections. Uma Collection tem vários Documents que podem ou não ter um Attachment. Uma Collection tem várias Stored Procedures, vários Triggers e várias User Defined Functions.

Vantagens

As principais vantagens do Azure DocumentDb, são:

• Armazenamento de documentos JSON sem schema
• Queries parecidas com T-SQL
• Execução de JavaScript no servidor
• Níveis de consistência configuráveis
• Performance

Queries parecidas com T-SQL

Calma! Linq não morreu! Mas, se você precisar fazer uma query mais complexa ou dinâmica, você pode escrever uma linguagem parecida com T-SQL.

Por exemplo, vamos supor que temos o seguinte documento na coleção “families”:

{
    "id": "WakefieldFamily",
    "parents": [
        { "familyName": "Wakefield", "givenName": "Robin" },
        { "familyName": "Miller", "givenName": "Ben" }
    ],
    "children": [{
            "familyName": "Merriam", 
            "givenName": "Jesse", 
            "gender": "female",
            "grade": 1,
            "pets": [
                { "givenName": "Goofy" },
                { "givenName": "Shadow" }
            ]
        },{ 
            "familyName": "Miller", 
            "givenName": "Lisa", 
            "gender": "female", 
            "grade": 8 
        }
    ],
    "address": { "state": "NY", "county": "Manhattan", "city": "NY" }
}

Para achar esse documento, podemos fazer a pesquisa assim:

var family = client.CreateDocumentQuery<Family>("families")  
                   .First(f => f.Id == "AndersenFamily");

ou assim

var sql = @"  
  SELECT * 
  FROM families f 
  WHERE f.id = ""AndersenFamily""
";
var family = client.CreateDocumentQuery<Family>("families", sql).First();

Execução de JavaScript no servidor

Existem 3 tipos de funções no servidor:

• Stored Procedure
• Trigger
• UDF (user defined functions)

As Stored Procedures são criadas para coleções e podem agir tanto nas próprias coleções quanto nos documentos e anexos dentro da coleção.

Os Triggers são criados para coleções também, mas só tem acesso aos documentos que dispararam a trigger. Um trigger pode ser pre-trigger ou post-trigger, ou seja, é uma função que pode ser rodada antes (pre) ou depois (post) de alguma operação ser executada sobre um documento.

As UDF’s, são funções que só podem ser chamadas dentro de queries e devem ser utilizadas para retornar um valor computado. Por exemplo:

var udf = new UserDefinedFunction  
{
    Body = @"
//isso é javascript e vai ser rodado no Azure DocumentDb
function calculeImposto(salario){  
    if(salario < 1000){
        return salario * 0.1;
    }
    if(salario < 3000){
        return salario * 0.2;
    }
    return salario * 0.3;
}
"
};
await client.CreateUserDefinedFunctionAsync(_collection.SelfLink, udf);


var sql = @"  
  SELECT * 
  FROM Funcionarios f 
  WHERE calculeImposto(f.salario) > 10
";
var f = client.CreateDocumentQuery<Funcionario>("Funcionarios", sql).ToList();

Todos esses 3 conceitos já existem em outros bancos relacionais e é bom que eles estejam nesse novo serviço do Azure também. Facilita bastante a transição das pessoas que estão acostumadas com bancos relacionais!

Níveis de consistência configuráveis

Normalmente, encontramos sempre dois tipos de consistência de dados: 100% consistente (bancos relacionais) ou eventualmente consistente (NoSql em geral). Essa parece ser uma decisão difícil de tomar logo no início do projeto e sempre envolve uma certa dose de risco. Mas, na maioria dos casos, seria melhor que você pudesse fazer uma escolha mais refinada para cada tipo de documento. Por exemplo, uma coleção de transações bancárias deve ser 100% consistente, mas um cadastro de usuário pode ser eventualmente consistente.

No Azure DocumentDb existem quatro tipos de níveis de consistência. A cada escrita feita, essa escrita é replicada em outros nós. O tipo de consistência indica quando essa escrita é disponibilizada para leitura.

Strong

Esse nível garante que uma escrita só será visível depois de ter sido persistida e replicada para todos os nós, por isso, é a melhor garantia de que os dados estarão sempre consistentes, mas tem o menor nível de performance para ler e escrever.

Bounded Staleness

Esse nível garante a ordem das escritas, mas as leituras podem ser adiadas até que as escritas tenham sido persistidas, por isso, tem uma latência menor na escrita.

Session

Esse nível é igual ao Strong, mas o escopo da consistência é para uma única sessão. Normalmente, esse nível é o suficiente.

Eventual

É o nível que apresenta a forma mais fraca de consistência, ou seja, é possível que, ao buscar um dado, o cliente receba um dado mais antigo do que já tinha sido buscado anteriormente. Isso acontece pois as leituras são feitas de qualquer réplica e essa réplica pode não ter recebido o novo dado ainda. Por conta disso tudo, é o método que tem a menor latência para ler e escrever.

Curtiu? O próximo post é sobre o Cache Redis do Azure!