tag:blogger.com,1999:blog-768233104244702633.post3086191220848581838..comments2023-11-16T03:16:54.746-08:00Comments on The Scale-Out Blog: The System of Record Approach to Multi-Master Database ApplicationsRobert Hodgeshttp://www.blogger.com/profile/05379726998057344092noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-768233104244702633.post-32793117760261134492012-01-04T07:36:45.429-08:002012-01-04T07:36:45.429-08:00Hi Anonymous! Thanks for reading the blog carefull...Hi Anonymous! Thanks for reading the blog carefully. Let me respond to your comments point by point. <br /><br />1.) Multi-master. There are several approaches to multi-master, of which this article describes one. The system-of-record approach makes the same kind of trade-offs as Yahoo's PNUTS DBMS (see a nice write-up on the issues by Daniel Abadi at http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html). It's a very scalable design choice, especially when you start to think about failures. Also, the code modifications are relatively simple in many cases. For many SaaS applications they reduce to changing connection strings. Changes for true multi-master SQL applications as you describe are often much greater and reach into the app logic itself. This is a problem that SQL makes harder because it allows table-spanning transactions with constraints. <br /><br />2.) I may be misunderstanding your point but schemas are the basic subsetting mechanism. We replicate schemas bi-directionally. You can replicate table sets as well; Tungsten does that but somewhat awkwardly at this time. <br /><br />3.) Updating shared tables is worth the other costs (app changes, failure complexity, etc.) and that's why Oracle, Microsoft, and others address them. We have work in progress on that problem as well.Robert Hodgeshttps://www.blogger.com/profile/05379726998057344092noreply@blogger.comtag:blogger.com,1999:blog-768233104244702633.post-14987374399669220432012-01-04T02:23:30.275-08:002012-01-04T02:23:30.275-08:00Your solution is not really a multi-master solutio...Your solution is not really a multi-master solution. <br /><br />Your solution does not allow for the modification of the same row of data from multiple sites. Many applications, particularly as companies become more global, have cross-geogrpahic collaboration on the same customer, vendors, etc. Most applications would need to be modified to understand where the master data resides and to perform operations accordingly.<br /><br />Also, you do not detail how the data in the system of record makes its way to other tables. Given that you cant use master/slave replication on subsets of tables, I dont see how you do this.<br /><br />I also disagree that problems with true multi-master become intractible. These challenges are difficult, but have been overcome by most major MMR applications (see Oracle Advanced Replication).Anonymousnoreply@blogger.com