I had a look at Azure Table and I just didn’t like the fact that I have to take care of partition key to have it scale properly, so I used Blob storage to store JSON data, this actually worked out very well as I was able to store F# Types to it without resorting to declaring classes.
The question I have is around Blob storage scaling, do I have to take care of any issues with Blob storage that could cause problems with scaling? I have googled but I haven’t found anything telling me that I need to worry about scaling with Blob storage, I just want some confirmation that this is the case and I will not run into any scaling issues later on.
Blobs and Tables are actually underneath the same storage mechanism (indeed they are shared from an Azure service point of view) and have the same underlying restrictions and benefits. One of these is that Azure shards out your data transparently based on a partitioning system. With Tables, this is explicitly done through the Partition Key. With Blobs, this is achieved through the combination of account name, container, and blob path.
You still have exactly the same constraints - blobs don’t make this go away - it’s simply that it’s surfaced differently. You can use folders (or pseudo folders really) in blobs as well to partition data, and blobs also let you use premium storage. However, Tables now have a CosmosDB layer - there are many pros and cons of both.
See https://docs.microsoft.com/en-us/azure/architecture/best-practices/data-partitioning#partitioning-azure-blob-storage for more details.
Does it mean I could run into 10GB limit with Blob storage if I keep adding blobs using GUID keys?
Which 10GB limit are you referring to?
Item collection in Table storage has a limit of 10GB.
Where’s that limit documented? I’ve seen tables with more than 10gb in them - as far as I know they’re only limited by the size of the storage account that they reside in.