Eventual consistency

In JOIN via materialized view, we have discussed the lower efficiency of direct query and filtering, and introduced materialized view as a solution. Plus, we know there is a latency in updating a view when a user updates his profile.

In a view this user may have hundreds of products purchased:

{view_name=jackson, view_payment=500, view_product=phone, view_popularity=5, view_age=28}  
{view_name=jackson, view_payment=1500, view_product=TV, view_popularity=3, view_age=28}  
{view_name=jackson, view_payment=45, view_product=book, view_popularity=4, view_age=28} 
{view_name=jackson, view_payment=5, view_product=soap, view_popularity=5, view_age=28} 
......

When he changes his age from 28 to 29 in table user, which is quick, all his hundreds of orders in view must be updated. Maybe there is hundreds of disk visitation, so always we use back ground threads to finish this task.

This extra view is for data query only. Any changes of a user must firstly update his record in the underlying user table, where stores the origin latest data, and then we notify the back ground thread to update all the related views. LunarBase executes this process strictly, otherwise the view may have inconsistency data.

Visualization of this process is as below:

update 1: get record from user table;   
update 1: user changes his age from 28 to 29 in table user;  
update 1: finishes;  
update 1: notifies the view thread to update related records;  
update 1: finishes;  
update 2: get record from user table;
update 2: user changes his name from "jackson" to "jackson senior";  
update 2: finishes;  
update 2: notifies the view thread to update related records;  
update 2: finishes;  
...  

If any disorder occurs, then update 2 may rewrite the change of update 1, and finally we have a user "jackson senior" with age 28! Or if we select user data from a view to update, then there is no guarantee that the data will be consistent, since the underlying user table may already has a new version.

Materialized view is not the only one choice for both data consistency and quick query. But it's exclusive advantage is it incremental update, which means any change only updates the affected records in a view. Also it is on demand, views have different priorities, and may be updated in the middle night to avoid the high traffic moments.

As a data redundant of the underlying table, view is invented for demonstration purpose. When time change, some old view will be discarded, and new view is designed to show new business logic. This evolution is very cheap, since we do not have to redesign the underlying data structure, and migrant old data to fit new table schema.