TransGlobal Transport and Shipping (TGTS) coordinates the movement of goods around the globe for businesses of all sizes. Customers of TGTS contact the shipper and provide detailed information about packages and cargo that need to be shipped. Simple orders can be a single package shipped across the country, and more complicated orders can entail hundreds of parcels or shipping containers that are transported internationally. To help their customers track their shipments, TGTS is developing a mobile app called TGTS Tracker.
TGTS Tracker will run on the most popular mobile device platforms. To allow customers to monitor their shipments from any of their mobile devices, application designers have decided to keep configuration information about each customer in a centralized database.
This configuration information includes
• Customer name and account number
• Default currency for pricing information
• Shipment attributes to appear in the summary dashboard
• Alerts and notification preferences
• User interface options, such as preferred color scheme and font
In addition to configuration information, designers want the app to quickly display summary information in a dashboard. Slower response times are acceptable when customers need to look up more detailed information about shipments. The database supporting TGTS Tracker should support up to 10,000 simultaneous users, with reads making up 90% of all I/O operations.
The design team evaluated relational databases and key-value databases. Relational databases are well suited to manage complex relations between multiple tables, but the need for scalability and fast read operations convinced them that a key-value database was the better choice for TGTS Tracker.
The range of data that is required by the mobile app is fairly limited so the designers felt
confident that a single namespace would be sufficient. They chose TrackerNS as the name of the app’s namespace.
Each customer has an account number, so this was selected as a unique identifier for each customer.
The designers then moved on to decide on the structure of values. After reviewing
preliminary designs of the user interface, they determined that name and account number appear frequently together, so it made sense to keep them together in a single list of values. The default currency is also frequently required, so it is included in the list of values along with customer name and account number. Because this app is designed to track the status of shipments, there is little need for administrative information, such as billing address, so it is not stored in the key-value database.
The app designers decided to use the following naming convention for keys: entity type:account number. Given the list of data types the tracker manages, the designers decided the database should support four entity types:
• Customer information, abbreviated ‘cust’
• Dashboard configuration options, abbreviated ‘dshb’
• Alerts and notification specifications, abbreviated ‘alrt’
• User interface configurations, abbreviated ‘ui’
The next step in the design process is determining attributes for each entity. The customer entity maintains the customer name and preferred currency. The account number is part of the key, so there is no need to store it again in the list of values. The following is a sample customer key-value pair:
Click here to view code image
TrackerNS[‘cust:4719364’] = {‘name’:‘Prime Machine, Inc.’, ‘currency’:‘USD’}
The dashboard configuration detail is a list of up to six attributes about a shipment that will appear on a summary screen. The following are options, with abbreviations in parentheses:
• Ship to company (shpComp)
• Ship to city (shpCity)
• Ship to state (shpState)
• Ship to country (shpCountry)
• Date shipped (shpDate)
• Expected date of delivery (shpDelivDate)
• Number of packages/containers shipped (shpCnt)
• Type of packages/containers shipped (shpType)
• Total weight of shipment (shpWght)
• Note on shipment (shpNotes)
The following is a sample dashboard configuration specification:
Click here to view code image
TrackerNS[‘dash:4719364’] =
{‘shpComp’,‘shpState’,‘shpDate’,‘shpDelivDate’}
The alerts and notification data indicate when messages should be sent to a customer. An alert and notification can be sent when a shipment is picked up, delivered, or delayed. The message can be sent as either an email address or as a text message to a phone. Multiple people can receive messages, and each person receiving a message can be notified under different conditions.
This is modeled with a list of lists as a value. For example, the person with email address
‘[email protected]’ might get emails when packages are picked up and the person with phone number (202)555-9812 might get a text message when
packages are delayed. The key-value pair for that would look like the following:
Click here to view code image
TrackerNS[alrt:4719364] = { altList :
{‘[email protected]’,‘pickup’}, {‘(202)555-9812’,‘delay’}
}
Finally, the user interface configuration options are a simple list of attribute value pairs, such as font name, font size, and color scheme. A key-value pair for a user interface specification could be
Click here to view code image
TrackerNS[alrt:4719364] = { ‘fontName’: ‘Cambria’, ‘fontSize’: 9,
‘colorScheme’ : ‘default’
}
Now that the designers have defined the entity types, key-naming conventions, and
structure of values, developers can write supporting code to set and retrieve keys and their values.
Review Questions
1. Describe four characteristics of a well-designed key-naming convention.
2. Name two types of restrictions key-value databases can place on keys.
3. Describe the difference between range partitioning and hash partitioning.
4. How can structured data types help reduce read latency (that is, the time needed to retrieve a block of data from a disk)?
5. Describe the Time to Live (TTL) key pattern.
6. Which design pattern provides some of the features of relational transactions?
7. When would you want to use the Aggregate pattern?
8. What are enumerable keys?
9. How can enumerable keys help with range queries?
10. How would you modify the design of TGTS Tracker to include a user’s preferred language in the configuration?
References
Basho Technologies, Inc., Riak Documentation: http://docs.basho.com/riak/latest/.
FoundationDB. Key-Value Store 2.0 Documentation: https://foundationdb.com/key-value-store/documentation/index.html.
Katsov, Ilya. “NoSQL Data Modeling Techniques.” Highly Scalable Blog:
http://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/.
Oracle Corporation. “Oracle NoSQL Database, 12c Release 1”:
http://docs.oracle.com/cd/NOSQL/html/index.html.
Redis Documentation: http://redis.io/documentation.
Wikipedia. “Software Design Patterns”:
http://en.wikipedia.org/wiki/Software_design_pattern.
Part III: Document Databases
6. Introduction to Document Databases
“I am a man of fixed and unbending principles, the first of which is to be flexible at all times.”
—EVERETT DIRKSEN
FORMER U.S. SENATOR
Topics Covered In This Chapter