When you first begin to plan an application, you may start by thinking about how you'll store its data. You will probably also want to prototype your architecture, which is where CenturyLink Cloud can help. You can use our NoSQL database-as-a-service Orchestrate to help with these ruminations. The Orchestrate dashboard is an interactive interface into your data, exposing the API calls used for Orchestrate's five key query types: key/value, search, geographic, time series, and graph. The dashboard is a good way to make sense of Orchestrate and help you understand the data behind the application you're building.
In the video above, you can see a 10 minute walk-through of the Orchestrate dashboard as we build out the structure for an office tracking application. In the example, we created a database to store data about office locations and employees. If you prefer, you can read the corresponding knowledge base article that also walks through the dashboard queries.
Key/Value and Basic Search
Each location has a city name, state, number of employees, and geographic coordinates. Employees have a first name, last name, and title. Once those fields are stored in Orchestrate, they're indexed for search, which allows you to find names, employee count ranges, and more.
As you architect your own applications, you might want to be fluid with your data model. We've gone to a lot of lengths to make sure Orchestrate is truly schema-less to provide you flexibility as you determine how to store and query your data.
You can search geographically in two ways--bounding box or point and radius. In fact, many of the queries you'd want to do with an application could likely be achieved with search. However, there are two other common query types that we've simplified for you.
With your basic data stored in Orchestrate, you can track time-based events that are closely coupled to items or model relations between two items. What's that mean? Let's take them one at a time in our office tracking example.
In the walk-through, we use the Events API to spec out a time clock application. Each employee has a "time_clock" event stream, with data passed to denote clocking in and clocking out. In this scenario, you could retrieve the latest event to determine whether the employee is clocked in. Or, retrieve all the recent events for an employee and calculate their timesheet.
Of course, many types of data can be expressed as a time series. A blog post item might have comments stored as events, for example. If you need to aggregate events across multiple items, events are also indexed for search.
Lastly, the Graph API feature of Orchestrate allows us to model relations between items. While the social network example of friends/contacts is useful, relations don't need to be within the same collection.
In the office tracking example, employees are connected to locations with a "works_at" relation. There is no restriction on a relation name, and you could even graph multiple relations between two items. Using the works_at relation, we're able to query for which locations an employee works at -- and the walk-through shows an example of an employee who works at multiple locations.
Since graph relations are one direction, we can connect locations to employees separately, which we did with a "desk_for" relation. With the reverse relation set up you can query a location's employees, or at least the ones who have desks.
You can also go multiple levels down with graph relations (friend of a friend search, to go back to the social network example). There are many other advanced features of Orchestrate as well. This walk-through is meant to be an overview that gives you an idea of how you might prototype new ideas, even before you write the code.
Orchestrate is also here for you when you're ready to scale beyond a prototype. Check out the Orchestrate dashboard today and start thinking about how you want to represent your data.