3 Replies Latest reply: Jan 31, 2014 10:58 PM by jaybytez RSS

    Key design or best practices for newbies?

    jaybytez

      I am a noob to NoSQL and just started messing with Oracle's NoSQL.  Is there a guide or best practice around the design for keys (dynamic vs static values in the major/minor) or how nested of keys, or whether it is better to stored individual properties per key or a whole object per key (like a Document DB)?

       

      For instance, a DB that holds basic user info and the products they own.  Their is a unique id for the user (like a username), sometimes there might be there IP, as keys and other information for values.

       

      Person

      - ID/username

      - IP Address

      - Title

      - Country

      - Company

      - Products Owned

      - Products Evaluated

       

       

      Products

      - ID

      - Name

      - Category

      - Training

       

       

      Thanks...Jay

        • 1. Re: Key design or best practices for newbies?
          Charles Lamb

          Hi Jay,

           

          Have you looked at Chapter 3 of the GSG yet?

           

          Chapter 3. Record Design Considerations

           

          In general, the major key is used to hash to a shard and the minor key is used to look up records within the shard. You want to keep your key size as small as possible.


          There are also sizing and planning spreadsheets included in the distribution that you may want to take a look at.


          Charles

          • 2. Re: Key design or best practices for newbies?
            Gmfeinberg-Oracle

            Jay,

             

            To add to the reply from Charles, using the example you put forward it would make sense to keep relatively static information in a single record under a major key of user id, e.g. a key of

              /U/<userId>

            with the data being the serialized (using Avro schema) value of the mostly-static information for a user.

            Given that your Products would be minor key components under a given user, e.g. a product owned by a user might have the key

              /U/<userId>/-/P/<productId>

            With a value that is the serialized (again Avro) value of the product state.

             

            The documentation reference Charles provided has a lot of good information.  A few highlights:

            o keep keys short (hence use of "U" vs "User" above)

            o it is fast, efficient, and transactional to get/modify records that have the same major key (e.g. all products owned by user with id "1").

            o it's generally a good idea to separate static and dynamic data, depending on update rates, so use that to decide if something should be in a separate record vs another field in a record that has multiple "fields" in its value.

            o know your access patterns, updates, etc and factor them into the design

             

            Regards,

            George

            • 3. Re: Key design or best practices for newbies?
              jaybytez

              Thanks...both answers were very helpful.  I did read through the GSG and have been reading the "Oracle NoSQL Database: Real-Time Big Data Management for the Enterprise" on Safari.

               

              I think the confusion exists in the different examples from the GSG and the book where data is stored with coarse keys and objects as opposed to fine grained major/minor with individual properties.  It is a question that gmfeinberg alluded to is how to determine whether to create very granular major/minor key combinations to store individual bits of information vs storing the whole Object under a single major/minor key.

               

              The GSG sample (the Oracle NoSQL Database book has the same type of example in Chapter 6 where they have a 3 major/4 minor key combination):

               

              /Smith/Bob/-/birthdate

              /Smith/Bob/-/phonenumber

              /Smith/Bob/-/image

              /Smith/Bob/-/userID

              /Smith/Patricia/-/birthdate

              /Smith/Patricia/-/phonenumber

              /Smith/Patricia/-/image

              /Smith/Patricia/-/userID

              /Wong/Bill/-/birthdate

              /Wong/Bill/-/phonenumber

              /Wong/Bill/-/image

               

              More of a model based on the example in gmfeinberg's response with an Avro Schema:

               

              /Smith/Bo=Avro Binding of Person

              /Smith/Patricia=Avro Binding of Person

              /Wong/Bill=Avro Binding of Person

               

              Is the discriminator as to how granular the minor key gets and the level of the value (whether an individual property or a whole Object) based on how much data one needs to access.  Such as I may query for a persons birthday multiple times, but only need the whole person record a few times, so in that example it makes more sense to be granular/specific with minor keys/values so that just the birthday is being read.  As opposed to instances where it is always necessary when interacting with a Person to have access to the whole data set and therefore would benefit more from a major key (little minor) and Avro Binding of the Person?

               

              Thanks for the direction and information!