locked
Deleting a partition in Table Storage RRS feed

  • Question

  • Someone already requested Deleting a Partition feature back in 2009 in this post, and Steve Marx passed it to the storage team.  So has this feature been implemented or when will it be implemented?  It seems still not among all the operations you can do with Table Storage.

    I am upgrading a blog application to Table Storage, I stored BlogPosts and Comments in separate tables.  When I delete a blog post, I need to delete all the comments for that post.  The comments for each blog post are stored in a separate partition, thus deleting the partition makes sense.  Some posts have really large number of comments, there is one that has over 5000 comments, so retrieving and iterating and then batch delete them is not feasible any more.

    So far the options I see are these, and none of them is satisfactory,

    1. Have a Worker Role and get these comments 1000 at a time, loop through them and delete one at a time.  Now, with this approach I'd like to confirm, since my app will run in Azure, so all the bandwidth consumed in this operation of getting, iterating, deleting the comments will be free of charge right?

    2. Do not delete.  Since Table Storage is at $0.15/Gb per months, maybe I can afford not too delete them at all.  But another part of my app is a photo album which uses Blob Storage to store the images.  If a user stores a large number of photos in an album, then request deletion of it, if I don't really delete, then that is more space occupied for nothing.

    3. Create a separate table for each blog post to contain its comments is ridiculous.

    So how is everyone else handling a situation like this?  I really wish there could be  "delete from TABLENAME where PartitionKey == <value>" type of operation available.  Any ideas?

    Thank you so much for any input,

    Ray.

     

    Sunday, January 9, 2011 7:46 PM

Answers

  • Why is #3 ridiculous?  That seems like the best solution to me, assuming you never have to enumerate all comments (across all posts) at once.

    Note that being able to delete a whole partition at once wouldn't help you with #2 (cleaning up the corresponding blob storage).  To delete a bunch of blobs at once, they would have to be in the same container (which sounds a lot like putting comments in the same table, so perhaps it's not a solution you like).

    • Marked as answer by ray247ray Sunday, January 9, 2011 9:36 PM
    Sunday, January 9, 2011 8:18 PM

All replies

  • Why is #3 ridiculous?  That seems like the best solution to me, assuming you never have to enumerate all comments (across all posts) at once.

    Note that being able to delete a whole partition at once wouldn't help you with #2 (cleaning up the corresponding blob storage).  To delete a bunch of blobs at once, they would have to be in the same container (which sounds a lot like putting comments in the same table, so perhaps it's not a solution you like).

    • Marked as answer by ray247ray Sunday, January 9, 2011 9:36 PM
    Sunday, January 9, 2011 8:18 PM
  • Thanks Steve for your input.  I will give the "one comment table per blog post" another thought.  I use table explorer to access and maintain some of my tables, I just thought if you have a million blog posts then you may end up with a million comment tables, it will be really difficult to navigate through tables.  I'm actually inclined toward #2 not deleting any comments for now and maybe in future this could be solved really easily, to me it is like a pretty frequent operation.

    So will there be a deleting partition feature?

    Sunday, January 9, 2011 8:34 PM
  • I don't know if this feature is coming in the future.  (I haven't seen it as part of a committed roadmap, so I would guess that if it is coming, it won't be very soon.)
    Sunday, January 9, 2011 9:23 PM
  • Thinking again having a comment table for each blog post should work.  Thanks Steve.
    Sunday, January 9, 2011 9:34 PM
  • Any update on this feature being in Table Storage? Creating multiple table names won't work for me.
    Friday, April 8, 2011 12:46 AM