none
Azure storage tables design to look for products by tags

    Question

  • Hi,

    I have a question about design, considering that the azure tables have a limitation of 5,000 transactions across a storage account and 500 across a partition key.

    I have a products table:

    PK = Product category
    RK = Product ID

    And a tags table:

    PK = Tag
    RK = Product ID

    Given a particular product like an iPad 2 16GB (ID = IP123) it has the following tags associated to it:

    Ipad, apple, 16gb, 16, gb, grey, wifi, 3gs, etc.

    I store this information in the tags table as follows:

    ipad, IP123
    apple, IP123
    2gb, IP123
    Etc

    So if a user searches for IPAD 16GB with WIFI

    The system will look into the tags table for all products matching the tag IPAD, all products matching the tag 16GB and all products matching the tag WIFI and add the to 3 different collections

    Then it will look for all unique products that exist on the 3 tag collections and return the list.

    In my opinion this will kill me down the road because if 1500 people are looking at the same tie for products with an average of 3 keywords, I will hit the azure storage transaction limit.

    What suggestions do you have from the architectural point of view to avoid this?

    I’m looking for the simplest solution possible.

     

    Thanks

     

     

    Tuesday, September 20, 2011 4:02 PM

Answers

  • There is not much of design issue here. If the information returned from the data repository is purely dependent on the type of query passed.

    If you know and could think through the solution and architect your data model in that way, you may benefit. 

    However, what I dont understand is the limitation in number of transactions? Do you mean the free tier ? Azure Storage Tables are not for your traditional Relation Data. 

    Look at this link for more details http://msdn.microsoft.com/en-in/magazine/ff796231(en-us).aspx

    Wednesday, September 21, 2011 11:31 AM

All replies

  • There is not much of design issue here. If the information returned from the data repository is purely dependent on the type of query passed.

    If you know and could think through the solution and architect your data model in that way, you may benefit. 

    However, what I dont understand is the limitation in number of transactions? Do you mean the free tier ? Azure Storage Tables are not for your traditional Relation Data. 

    Look at this link for more details http://msdn.microsoft.com/en-in/magazine/ff796231(en-us).aspx

    Wednesday, September 21, 2011 11:31 AM
  • Is using some sort of caching solution useful for reducing latency and transaction cost? You can look at smarx's blog post about memcached.

    Thanks,

    Jai

    Thursday, September 22, 2011 5:21 AM