locked
azure table storage, real world cases? RRS feed

  • Question

  • hello, good day

    I'm trying to think of real world cases where azure table storage is beneficial. but my mind is blank.

    could you guys name some examples where it has helped your website/app ?

    Wednesday, May 7, 2014 8:21 AM

Answers

  • Hi,

    I suggest you have a look at the azure table storage article from azure document, below is the link, this article tell us what is azure table storage, and how to use azure table storage.

    #https://acom-int.azure.com/en-us/Documentation/Articles/storage-dotnet-how-to-use-tables/

    Best Regards,

    Jambor


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    • Marked as answer by nickzzzx Wednesday, May 14, 2014 10:09 AM
    Wednesday, May 7, 2014 8:48 AM
  • Azure Table storage has a few big advantages over SQL Azure for example (and some disadvantages)

    -Azure Table Storage is VERY FAST when it comes to queries

    -Azure Table Storage is VERY CHEAP when it comes to cost

    -Azure Table Storage can store A LOT more data than SQL Azure DB's. And I mean A LOT MORE DATA :)

    So Azure Table Storage uses a NoSQL provide. And you'd have to familiarize yourself with how to work with NoSQL. 

    But as far as like what a real world example is, you can use it just like you would any other data backend for your app. You have to consider what type of backend if best for your web app when it comes time to decide.

    But safe to say Azure Table Storage is quite popular right now with its usage, though I'll admit it's not as "easy" to hook up an Azure Table Storage to a generic ASP.NET web app as it to hook up a Sql Azure DB.

    HTH - Matt Sampson


    R. Matt Sampson

    Wednesday, May 7, 2014 12:21 PM
  • One angle I'm just getting started with (so I'm not sure of a happy ending) is to provide an interim storage on the way to a fully validated SQL-based entity. My reasoning is this:

    Persisting records to SQL fails at the slightest deviation to the schema whereas NoSQL will happily eat it up.

    I'm creating a Rest API that 3rd parties will want to post to. The data they post from isn't rigorously validated. If my first point of persistence is to a Table Store, I'm establishing a checkpoint that can provide fallback. If subsequent attempts to store to 'real' sql fail, I have something that a human can lay eyes on and tweak as needed.

    Granted....this is less 'real world Azure Table Storeage' than a wild-eye foray into NoSQL storage pattern, but I wouldn't be in a position to play with it without the tight integration to Azure.

    • Marked as answer by nickzzzx Wednesday, May 14, 2014 10:10 AM
    Wednesday, May 7, 2014 2:07 PM
  • Hi Nick,

    Table storage have tremendous speed benefits and I completely agree with Jambor and Matt and recommend you to go through the links they provided.

    From my personal experience on one of my websites (ogleogle.com), I use table storage for following beside many more.

    * Storage of log files

    * My website allows users to curate photos and i store the path of uploaded image in tables.

    now all the functionality that i am using is very much possible even without using table storage, and i am sure you can already see it from what I am using it for but beside being dirt cheap cost of table storage I get a lot of advantages when I compare it with SQL relational tables

    In cases when i really do not need relational data storage i get mega scalability, cost of course is super low as compared to SQL, on the flip side if you have a situation where you need to frequently access Azure Table Storage (ATS), it gets expansive, as it quite some amount of CPU power from your web/worker instances to manipulate.

    It will really need to be evaluated to see if you have a scenario in mind and see if really ATS fits better or SQL Azure.

    Hope this helps

    -----------------------------------------

    Please mark as answered if it helped


    Vishal Narayan Saxena http://twitter.com/vishalishere http://www.ogleogle.com/vishal/

    Wednesday, May 7, 2014 2:19 PM
  • There are a lot of situations where SQL and mainly the performance of SQL is limiting.

    One example that I'm working on now is a multi-tenant data SAAS service.  In SQL, one tenant storing 10,000 items per second will effect all the other tenants on the same SQL database - either for row, index, table locking or just IO time getting stuff to/from disk.  So, you either break apart the database, do some wizardry with the storage in attempt to minimize IO bottlenecks, or you cluster the SQL servers.  (Sometimes you can't do any of those - and end up just living with it.) Often a solution is splitting tenants into multiple DB's at some point - not easy to do on-the-fly.

    You can also think of situations where heavily multitasked calculations need to be saved at the same time in order to reduce time/costs of running VM's - or due to the amount of data queued for processing.  There's no need to spawn 1000 threads across 15 VMs to process some sort of data if only 1 thread can actually write to an SQL table at once - SQL again becomes the IO bottleneck.  I've seen this in geophysical apps where they process ground radar data.  We ended up halving the total number of monster, data-crunching machines that were processing data because too many were bottlenecked writing inserts to the oracle database.  (plain old server storage IO was the issue here...)

    I've worked with databases almost constantly since 1994 and always tended to think in terms of structured relational data such as within SQL.  At first I found it really awkward to get an app to market using only azure tables, but once I did - I am very happy with the results.  Now I look at my Azure SQL DB and keep thinking I should move more and more over.

    About the only thing I miss is free text querying, and perhaps the ability to search on fields other than PartitionKey or RowKey on-storage-server.  But, at something like seven million table ops for only 1 cent - I can't complain.  I query and filter later.  Or, I roll my own in-memory cache on each VM.


    Darin R.

    • Marked as answer by nickzzzx Wednesday, May 14, 2014 10:10 AM
    Thursday, May 8, 2014 5:51 PM

All replies

  • Hi,

    I suggest you have a look at the azure table storage article from azure document, below is the link, this article tell us what is azure table storage, and how to use azure table storage.

    #https://acom-int.azure.com/en-us/Documentation/Articles/storage-dotnet-how-to-use-tables/

    Best Regards,

    Jambor


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    • Marked as answer by nickzzzx Wednesday, May 14, 2014 10:09 AM
    Wednesday, May 7, 2014 8:48 AM
  • thanks a lot buddy

    but it's all technical, doesn't say real world examples of using azure table storage

    one example i found is storing 150 email address. not really "useful" scenario. i wish someone could tell me successful implementations and how it benefited them.

    Wednesday, May 7, 2014 11:51 AM
  • Azure Table storage has a few big advantages over SQL Azure for example (and some disadvantages)

    -Azure Table Storage is VERY FAST when it comes to queries

    -Azure Table Storage is VERY CHEAP when it comes to cost

    -Azure Table Storage can store A LOT more data than SQL Azure DB's. And I mean A LOT MORE DATA :)

    So Azure Table Storage uses a NoSQL provide. And you'd have to familiarize yourself with how to work with NoSQL. 

    But as far as like what a real world example is, you can use it just like you would any other data backend for your app. You have to consider what type of backend if best for your web app when it comes time to decide.

    But safe to say Azure Table Storage is quite popular right now with its usage, though I'll admit it's not as "easy" to hook up an Azure Table Storage to a generic ASP.NET web app as it to hook up a Sql Azure DB.

    HTH - Matt Sampson


    R. Matt Sampson

    Wednesday, May 7, 2014 12:21 PM
  • One angle I'm just getting started with (so I'm not sure of a happy ending) is to provide an interim storage on the way to a fully validated SQL-based entity. My reasoning is this:

    Persisting records to SQL fails at the slightest deviation to the schema whereas NoSQL will happily eat it up.

    I'm creating a Rest API that 3rd parties will want to post to. The data they post from isn't rigorously validated. If my first point of persistence is to a Table Store, I'm establishing a checkpoint that can provide fallback. If subsequent attempts to store to 'real' sql fail, I have something that a human can lay eyes on and tweak as needed.

    Granted....this is less 'real world Azure Table Storeage' than a wild-eye foray into NoSQL storage pattern, but I wouldn't be in a position to play with it without the tight integration to Azure.

    • Marked as answer by nickzzzx Wednesday, May 14, 2014 10:10 AM
    Wednesday, May 7, 2014 2:07 PM
  • Hi Nick,

    Table storage have tremendous speed benefits and I completely agree with Jambor and Matt and recommend you to go through the links they provided.

    From my personal experience on one of my websites (ogleogle.com), I use table storage for following beside many more.

    * Storage of log files

    * My website allows users to curate photos and i store the path of uploaded image in tables.

    now all the functionality that i am using is very much possible even without using table storage, and i am sure you can already see it from what I am using it for but beside being dirt cheap cost of table storage I get a lot of advantages when I compare it with SQL relational tables

    In cases when i really do not need relational data storage i get mega scalability, cost of course is super low as compared to SQL, on the flip side if you have a situation where you need to frequently access Azure Table Storage (ATS), it gets expansive, as it quite some amount of CPU power from your web/worker instances to manipulate.

    It will really need to be evaluated to see if you have a scenario in mind and see if really ATS fits better or SQL Azure.

    Hope this helps

    -----------------------------------------

    Please mark as answered if it helped


    Vishal Narayan Saxena http://twitter.com/vishalishere http://www.ogleogle.com/vishal/

    Wednesday, May 7, 2014 2:19 PM
  • thanks all very very much for the informative answer. very helpful. can i mark few as answers?
    Thursday, May 8, 2014 3:03 AM
  • Hi nickzzzx,

    You can mark the replies if the replies give help to you, not only one.

    Best Regards,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Thursday, May 8, 2014 3:09 AM
  • There are a lot of situations where SQL and mainly the performance of SQL is limiting.

    One example that I'm working on now is a multi-tenant data SAAS service.  In SQL, one tenant storing 10,000 items per second will effect all the other tenants on the same SQL database - either for row, index, table locking or just IO time getting stuff to/from disk.  So, you either break apart the database, do some wizardry with the storage in attempt to minimize IO bottlenecks, or you cluster the SQL servers.  (Sometimes you can't do any of those - and end up just living with it.) Often a solution is splitting tenants into multiple DB's at some point - not easy to do on-the-fly.

    You can also think of situations where heavily multitasked calculations need to be saved at the same time in order to reduce time/costs of running VM's - or due to the amount of data queued for processing.  There's no need to spawn 1000 threads across 15 VMs to process some sort of data if only 1 thread can actually write to an SQL table at once - SQL again becomes the IO bottleneck.  I've seen this in geophysical apps where they process ground radar data.  We ended up halving the total number of monster, data-crunching machines that were processing data because too many were bottlenecked writing inserts to the oracle database.  (plain old server storage IO was the issue here...)

    I've worked with databases almost constantly since 1994 and always tended to think in terms of structured relational data such as within SQL.  At first I found it really awkward to get an app to market using only azure tables, but once I did - I am very happy with the results.  Now I look at my Azure SQL DB and keep thinking I should move more and more over.

    About the only thing I miss is free text querying, and perhaps the ability to search on fields other than PartitionKey or RowKey on-storage-server.  But, at something like seven million table ops for only 1 cent - I can't complain.  I query and filter later.  Or, I roll my own in-memory cache on each VM.


    Darin R.

    • Marked as answer by nickzzzx Wednesday, May 14, 2014 10:10 AM
    Thursday, May 8, 2014 5:51 PM