Cloud as a Story - Vunvulea Radu

One of my colleague tried implemented a browser history mechanism for MVC. Based on this data he would like to generate two simple reports: Top 5 web addresses accessed by a given user per day Top 5 web addresses accessed by all user When the data store is implemented using SQL Azure, this problem can be resolved very simple.  The question that appeared here is: Can we implement a data store model using Windows Azure Table Services? I will try to propose a possible data model that is using Windows Azure Table. In the default implementation (using SQL Azure), there were 3 kind of information that is stored in the SQL tables: URL visited User Date Because we don’t have an order by, count or a max function in a query over Windows Azure Table we need to think at a model that would help us with this. We will start with the first requirement: Top 5 web addresses accessed by a given user per day To be able to solve this problem we need a data model that permit us to refe...

I saw that there are a lot of people that use tracing infrastructure that is offered by .NET framework to trace information in Windows Azure Tables. Basically, after we configure the configuration file, the only thing that we need to do is to call the Trace class and write data to it. Trace.WriteLine(“Some trace data”); Trace.TraceWarning(“Some worning information”); Trace.TraceError(“An error that appeared in the application.”); We can do a log of thinks with this class. It is not something new. In the configuration file of our application we need to add a new trace listener that is able to write all the trace information to Azure Tables. <system.diagnostics> <trace> <listeners> <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics” name="DiagToAzureTables"></add> </listeners> </trace> </system.diagnostics> Next step is to add t...

Until now we talk about how to use Shared Access Signature on blobs and queues from Windows Azure. Today we will see how we can use Shared Access Signature with tables from Windows Azure. Using this feature we can give a limited access to a consumer to Windows Azure tables. In the next part we will look over what are the restrictions that can be made using Shared Access Signature: The first limitation that we can add is the time range. Based on the time a user can have a limited access to a table. For example a user can have access to a table only from 1st of July until the end of the week. We can limit what actions can be done using a Shared Access Signature. The following actions can be specified: add, update, delete and query. We can give access to a table or to only a part of a table. This limitation can be done using the partition key and row key. For example we can limit a consumer to have access only to partions keys from pkStart to pkEnd and from row rwStart to rwEnd. The...

I’m pretty sure that a lot of you had heard about Windows Azure Tables. I already described how we can work with this Windows Azure Tables. You can find a series of posts about them on my blog in this link . Today I want to talk about some limitation that we can have on Windows Azure Tables if we don’t use properly. A row in a table can store any kind of data that is serializable and one table can have more than one entity type saved. For example in the same table we can save Student entities and in the same time Dog entity and also Car entity. Each entity that is saved has 3 properties that need to exist all the time: Partition key – based on this property we can group items from a specific table based on this partition. It is used for load balancing across storage nodes. Row key – this a unique identifiers used to identify a unique row in a partition (the combination between partition key and row key form a unique key in the table). Timestamp – the last modified time for a row. ...

In mod default, cand pornim storage-ul local, acesta accesează 127.0.0.1. Dar ce ne facem daca avem o echipa de dezvoltare care doreste sa lucreze pe un storage comun. Prima posibilitatea este sa ne configuram un storage sus pe cloud, dar asta înseamna bani in plus si un lag, in cazul in care nu avem o conexiune foarte rapida. O alta varianta este s schimbam configurarea pe mașinile de development, astfel incat acestea sa bata spre aceiasi adresa. Pentru a putea face acest lucru trebuie sa deschidem fisierul DSService.exe.config din directorul ~Program Files\Windows Azure SDK\v1.4\bin\devstore\DSService.exe.config . Sub nodul services o sa gasim lista de adrese pentru blobs, queue si tables. Fiecare adresa a serviciului poate sa fie modificata, ca in exemplul de mai jos: <services> <service name="Blob" url="http://10.123.1.9:10000/"/> <service name="Queue" url="http://10.123.1.9:10001/"/> <service name="Table...

Daca lucram cu tabelele din Windows Azure o sa avem nevoie sa facem paginare. Default nu avem nici un mecanism de paginare, dar acesta este usor de implementat. In postul anterior am descris modul prin care se pot obtine mai mult de 1000 de entitati dintr-un tabel. Pe baza mecanismului prezentat anterior putem sa parcurgem datele din tabel in format paginat. Trebuie sa ne folosim de metoda Take din LINQ, care din fericire este suportata si de LINQ folosit pentru tabelele din Windows Azure( nu trebuie sa uitam ca doar o parte din LINQ este implementat pentru Windows Azure in acest moment). Apeland metoda Take putem sa obtinem doar o parte din entitati care ne sunt returnate de catre query. Folosindu-ne de token-urile nextPartitionToken si nextRowToken putem sa luam urmatoarele x elemente incepand de pe o anumita pozitie. Mai jos gasiti o implementare minimala a unui mecanism de paginare. public class Pagination<TItem> where TItem : class { private const...

Pentru a putea obtine date din tabelele din Windows Azure putem sa folosim DataServiceQuery . Acesta suporta LINQ, astfel ne va fi foarte usor sa filtram continutul. DataServiceQuery<Person> queryPersons = ApplicationServiceContext .PersonEntryTable .Where( p => p.Age >= 18 ); var result = queryPersons.Execute(); In variabila result o sa avem toate persoanele care au varsta mai mare sau egala cu 18. Problema apare cand rezultatul contine mai mult de 1000 de entitati. Un query pe tabele din cloud va returna maxim 1000 de rezultate. In cazul in care acest numar este depasit acesta va contine doua token-uri pe baza carora se pot obtine si celelate entitati din query. Cele doua token-uri reprezinta token-ul pentru Partition Key si Row Key. Se pot obtine din heather-ul rezultatului: var resultQOR = (QueryOperationResponse)result; string nextPartitionToken = null; string nextRowToken = null; resultQOR.Headers.TryGetValue("x-ms-continuation-NextPartitionKey...

Partea 1 http://vunvulearadu.blogspot.com/2011/02/propietati-de-tip-vector-in-tabele-din.html Continuare: In ultimul meu post am descris trei variante prin care se poate persista o entitate care contine o propietate de tip array( lista) intr-un tabel. Ultima varianta, care la prima vedere pare cea mai buna era folosind DataServiceContext . Aceasta solutie este viabila, atata timp cat nu trebe sa facem un query direct pe tabel. In acest moment tabelel din Windows Azure nu suporta pe query expresii de genu: Contains Count Select Din aceasta cauza, daca avem o propietate de tip lista nu o sa putem avea un query de genul: (item => item.ListaElemente.Contains(id) Din aceasta cauza, pentru a putea face un astfel de query ar fi nevoie sa incarcam toate elementele din tabel si sa le procesam din cod, cea ce nu tocmai optim. Dar nici prima varianta nu se poate folosii din pacate( lista sa fie stocata ca si un string cu un caracter despartitor), din cauza ca urmatorul query nu este suportat:...

Am inceput sa folosesc din plin tabelele din Windows Azure. Orice fel de date se pot salva acolo, atata timp cat sunt serializabile. Cu ajutorul lor am facut maparea unor entitati fara probleme. Am ajuns in momentul in care intre doua entitati A si B aveam o relatie n la m, iar intre alte doua entitati 1 la n. Fara nici o problema am scris: public List<Guid> ItemIds { get; set; } Am continuat sa scriu codul in continuare fara nici o problema, iar intr-un final am ajuns la unit-teste unde am avut o surpriza nu tocmai placuta. Cea ce am ignorat de la bun inceput a fost faptul ca tabele din Windows Azure nu sunt O/R, ele nu stiu sa stocheze in mod default o lista. Greseala mea, fapta fiind deja comisa a trebuit sa caut solutii la aceasta problema. Am gasit urmatoarele solutii: o propietate de tip string care sa stocheze id-urile despartite printr-un caracter special. Solutia destul de viabila, daca tinem cont de faptul ca obiectele care se stocheaza pe tabele nu ajung sa fie folosit...

Se da obiectul de tip Point, cu doua propietati de tip int X si Y si un id tot de tip int, unde point implementeaza TableServiceEntity . Initalizare : //Initializare cont (se poate incarca din fisierul de configurare). StorageAccountInfo account = ... TableStorage tableStorage = TableStorage.Create(account); //Creare tabel cu un anumit nume. tableStorage.TryCreateTable("Point"); Salvare : Point point = new Point(); ... TableStorageDataServiceContext context = table.GetDataServiceContext(); context.AddObject(point); //Doar pe save se salveaza in tabel obiectul nostru. context.Save(); Interogare : TableStorageDataServiceContext context = table.GetDataServiceContext(); //Trebuie specificat numele tabelului. Un tabel poate sa contina orice tip de obiecte, chiar si de tipuri diferite. var query = context .CreateQuery("Point").Where(item => item.Id == 10); IEnumerable resultList = new TableStorageDataServiceQuery((DataServiceQuery)query).ExecuteAll(); Stergere : //Dupa...