Proper use of Azure storage. (When to use SQL, Tables and Blobs) -

i relatively new azure storage , have been implementing solution time now. , keep hitting obstacles, making me feel i'm not applying right storage type data i'm storing.

so more of overall question:

• when should use azure sql?
• when should use azure table storage?
• when should use azure blobs?

so far have been using table storage lot, , i'm paying it. requirements solution grow find myself unable access data needed.

for instance need fetch 50 latest entries in table, can not user orderby in query. need fetch total amount of entries, can not use count.

i keep getting impression data plan access regularly without knowing exact rowkey , partitionkey should indexed in azure sql aswell being stored in table. correct?

i find myself recreating objects entity objects, severe limitations on datatypes end serializing object byte array. , though table row may hold 1mb byte array on row may hold 64kb, @ point end using blob storage instead.

so in end feel have been better off putting data in azure sql , indexing larger data saving blobs. of course not feel quite right, since leave table storage no real purpose.

so i'm wondering if there guidelines when use kind of storage.

in case have large amount of data in areas, of consumes fair amount of space (often above 64kb), need access data , need able filter , sort values.

• do need index data plan access in sql?
• and better off avoiding table data potentially exceed 64kb?

i feel there's i'm not doing right. didn't understand. missing here?

i keep getting impression data plan access regularly without knowing exact rowkey , partitionkey should indexed in azure sql aswell being stored in table. correct?

table storage not support secondary indexes , efficient queries should contain rowkey , partitionkey. there can workarounds such saving same data twice in same table different rowkeys. can become pain. if eventual consistency ok this. need take care of transactions , rollbacks.

in case have large amount of data in areas, of consumes fair amount of space (often above 64kb), need access data , need able filter , sort values.

use table storage basic nosql functionality , ability scale quickly. however, if want secondary indexes , other such features might have take @ dynamodb on aws afaik seems have better support secondary indexes etc. if have data has complex relationships in other words data requires rdbms go sql azure.

now, far options on azure go i'd think need store on sql azure , large objects blobs or on table storage.

do need index data plan access in sql?

tough say. if each partition going contain 100 rows can query partition key , of columns. @ point partition scan going pretty fast. however, if have million rows problem.

i feel there's i'm not doing right. didn't understand. missing here?

a bunch of azure users started using table storage without understanding nosql (and in case particularly stunted version of nosql) entails.