My SQL Dump

MySQL musings by a self professed MySQL Geek


  • 1

ummm....yeah, what you said

dude...I have been so into my own crap lately that I have let some very important things slip....I am very happy to see you posting again. Any chance on some sort of update on what is going on with you?

e.t.a.you have an icon of you! How cute!

Edited at 2008-02-26 02:50 pm (UTC)

Re: ummm....yeah, what you said

Good to hear from you too. Not much has been going on actually.

I started working on this during my Christmas holiday, and it is pretty much all I've done during waking hours since.

I like your user pic too. Great shot.

Nice idea

(Anonymous)
Given the amount of websites, especially forums (running on php) that could benefit from having materialized views this is a big step.
If you were to replicate the mview db back to the master, you get to have your cake and eat it too.

You could potentially run the propagate phase on a MySQL slave and instead of maintaining the delta table on the slave, instead maintain it via a Federated table that points to the master. You could then run the low-impact apply phase on the master. Since the delta table would be maintained by regular DML, that would replicate down to your slaves and they would all apply the changes properly to their copies of the view through regular MySQL replication.

Also, because incremental refresh maintains the views with regular DML statements, a materialized view log can be added to a materialized view itself.

This means that in a horizontally partitioned cluster, aggregated materialized views can be maintained on each shard. Another set of machines can then collect these changes and UNION them to maintain a centralized materialized view. This can help provide a solution to the "aggregate" problem in a horizontally partitioned cluster, that is: How to resolve queries involving aggregation over more than one shard?

In fact, this is a special case of multi-master replication. Given a well-defined conflict resolution protocol, table snapshotting can be used to implement almost any arbitrary table change based replication system including general multi-master replication.

You could even go crazy and implement block level replication for changes made by triggers and stored procedures (on MySQL 5.0, 5.1 already has this feature) with some elbow grease.

Edited at 2008-02-27 01:03 am (UTC)

Location of paper

(Anonymous)
The paper can be found, with a bunch of other interesting stuff at Kevin Beyer's webpage.
http://pages.cs.wisc.edu/~beyer/

Re: Location of paper

Thanks for the pointer.

Brilliant.

(Anonymous)
Brilliant. Looks like you have done an unreal job. How is the progress going?
Thanks
Tez

No progress. Still waiting on AdBrite to release under LGPL so I can pick it up and develop it further.

  • 1
?

Log in