We are excited to announce the release of the Oracle NoSQL Database version 20.1. With this release, we are highlighting our multi-region table feature. In this blog, we'll look at a high-level introduction of the feature and different customer scenarios that can benefit from this feature.
When it comes to measuring an application's performance, network latency and throughput are the most commonly used metrics. Network latency is the minimum (latent) time a data packet takes to travel across the network, typically expressed in terms of the round-trip time(RTT) and throughput is the quantity of data transmitted across the network during a specified period via a network.
As Einstein outlined in his theory of relativity, the speed of light is the maximum speed at which conventional matters and information can travel. As such, the speed of light places a hard upper limit and is a regulator on the propagation time of any data packet. The speed of light is 299,792,458 meters per second or 186,282 miles per second. However, that is the speed of light in vacuum, and the data packets travel through a medium such as a copper wire or a fiber-optic cable, which further slows down the signal.
Let's take an example: the distance between New York to San Francisco is about 2578 miles (or 4148 KM). If we consider the most optimistic scenario wherein the packet travels along the great-circle path (the shortest distance between two points on the globe) between the cities, the RTT in fiber (speed of light to be about 30% slower in a normal optical fiber) is about 42 ms. Now, looking between Europe (London) and the US east coast (New York), it is about 56 ms. But in reality, the packets take a much longer route passing through multiple routers before they reach their final destination. At each hop, along the route, there's going to be some additional routing, processing, queueing, and transmission delays as a result of which the actual RTT between US East and West is approx. 80 milliseconds and between the US and Europe is approx. 140 milliseconds - which may not be acceptable to applications, such as gaming, eCommerce, multi-player online gaming, collaborative work, and mobile. Today's applications are getting more and more personalized (e.g., recommendation engines, personalized discounts, and offers), interactive and immersive. For such applications, fast response times – or conversely, low latency is of utmost importance. There are published studies that show that every 100-millisecond delay in website load time can hurt the conversion rates by 7%. There are other studies from internet companies that show that web performance translates directly to dollars and cents; for example, a 2,000 ms delay on Bing search pages decreased per-user revenue by 4.3%!.
In the last several years, we have heard from many large customers that they want to deploy Oracle NoSQL Database in a geographically distributed fashion because of the global nature of their business. All of these applications demand very high availability and ALWAYS-ON (operating 24x7x365 days) capabilities spread across multiple data centers separated by a significant speed of light distance (> 10 ms).
The two most popular methods adopted by the network and system managers today to achieve this are active-passive and active-active configurations. An active-passive configuration typically consists of at least two data centers or regions. However, as the name "active-passive" implies, not all the regions are going to serve write requests. One region actively serves write requests, while the second region is somewhat passive, able to support reads and ready to support failover in case the active region fails. In Oracle NoSQL Database, this can be done easily where the active Data Center will have a primary zone, and the secondary(passive) Data Center will be set up as a secondary zone. In this case, ALL master nodes will always be in the active Data Center, and changes to data will be propagated asynchronously to the secondary zone. Read more about zones in our documentation.
An active-active configuration comprises at least two regions. In this configuration, the application is deployed across multiple regions, and all the regions are actively serving read and write requests simultaneously. This architecture provides the following benefits:
Enter the Multi-Region table or MR Table that helps to realize active-active configurations with Oracle NoSQL Database.
A Multi-Region Table is a global logical table that eliminates the problematic and error-prone work of replicating data between regions, enabling a developer to focus on application business logic. All updates performed in one region are automatically propagated to all the other regions. An important by-product of this propagation is disaster proofing an application with data redundancy. You can guard against a region's failure in the application because the data is in multiple regions. If your application gets a failure because a region is unavailable, it can redirect that request to a different region. This is a cost-effective disaster recovery solution.
Here's a high-level architecture diagram of a scenario where a company deploys three on-premise instances of Oracle NoSQL Database one each at Phoenix (US -West), Frankfurt (Germany) and Tokyo (Japan) and there's a table called ShoppingCart which stores the shopping cart information from customers shopping in our globally distributed store. In such a setup involving multiple geographic locations, each independent Oracle NoSQL Database deployment is referred to as a Region. An architecture having two or more independent, geographically distributed NoSQL instances is known as Multi-Region Architecture. The table ShoppingCart is a Multi-Region Table that is a read-anywhere and write-anywhere table that lives in multiple regions. The glue that connects one region to another is our Cross-Region Service (XRegion Service). The XRegion service is a standalone service that runs in each of the regions and has the knowledge of all the regions identified in an MR table. It subscribes to changes from MR tables from all the remote regions and persists those changes to the local region.
Figure 1. Depicting Multi-region architecture and multi-region tables.
Let's look at some real-world use-cases that can benefit from this feature and ensure that your company is ahead of the curve in today's global competitive landscape.
The Traveling User/Package
There are two specific use cases that we have heard, one from a leading mobile company with a global presence and the other from a leading courier/logistics company. However, when sifted through thoroughly, we can consider these as the same use case. In the case of the mobile company, the application team had the mandate from their management to make their mobile eCommerce store user experience seamless and performant no matter where in the world a user happens to access it. In the traveling user problem, a user in California wakes up in the morning, shops online, and adds a mobile phone to the shopping cart. The west coast region serves this session, and the user experiences good read and write request latency from the region local data center. This user then gets on a plane to Germany, lands 13 hours later, gets to the hotel, connects to the wifi network, goes to the mobile company's online store, and finds that there's another model of the phone that looks more appealing to him. So he decides to update the shopping cart with this new model of the phone and continues to browse the mobile e-commerce Store. The EU regional data center, which is the most proximal data center, serves this session, and provides the user with the same low latency read and write experience as he had in the US.
In the case of the courier/logistics company, however, the traveling entity is a package, and the package delivery status is getting updated in two different regions.
Both these cases can benefit from the multi-region table because a user can read and write the same data record with the same key in two different data centers with local latencies.
The Telco Problem – Offering a Family Plan
This use case comes from a large Telco company. Let's say you have a family of five, three young adults, and both parents. Like a lot of parents, you want to find the best cost option for cell phone service for the family. After spending a few hours scouring the internet, you find the unlimited plus plan by GoFam. You get five lines for one fixed rate along with unlimited nationwide talk and text, and 50 GB of data. This is perfect because your kids are off in college with one in Hawaii, one in Seattle and one in Boston, while you are in Chicago. Everyone can use as much data as they want up to 50GB, at which point you will be charged a premium for data overage. All data access activity is occurring in different regions and in different time zones across the US. To be able to view a consolidated report of data access at any time during the billing cycle, data for the account must be synchronized across all regions.
Furthermore, for a good, low latency user experience, application access to the account should be routed to an application server and NoSQL Database store that is closest to the user. The Telco can now offer accurate consolidated summaries to its customers as well as alerting capability that can alert customers when their overall data usage across regions is approaching the alert threshold. All of the plumbing to make this happen is taken care of by Oracle NoSQL Database multi-region tables.
We'll follow-up with another blog on how to set up the MR Table and look at the architecture in more detail.
If you are interested in learning more about this feature, refer to our product documentation.