Can Zend easily handle read/write splitting and multiple read slave load balancing

Log in

12:41 pm November 12th, 2008

No account? Create an account

Remember me




			Mark Atwood

fallenpegasus


	Can Zend easily handle read/write splitting and multiple read slave load balancing
	I've been posed with an interesting question, and because I don't know Zend very well, I don't have the answer. I want to do a pretty standard MySQL replication configuration, with one write master and with multiple read slaves. Is there a straightforward way to configure Zend's database interface to split the reads off from the writes, and to load balance the reads? It can be done with MySQL proxy, but, I like to have as few moving parts as possble, so can it be done without proxy, and without having to completely rewrite the Zend DB interface. Tags: mysql

6 comments or Leave a comment


	Comments

	From: karlgreat	Date: November 12th, 2008 09:19 pm (UTC)		(Link)

I'm not sure about load balancing, but we've done the read/write distinction with Zend. It's probably not the best way, but we just create two MySQLi adapters, one for each operation. Each has its separate config settings in the registry; we just instantiate one of each and use them as needed.

(Reply) (Thread)

From: bkarwin	Date: November 12th, 2008 10:15 pm (UTC)		(Link)
No but here are a couple of ideas

I worked on Zend_Db quite a bit through the 1.0 release.

There's no plumbing in Zend_Db to support what you are describing per se.

One idea would be to extend Zend_Db_Table_Abstract to keep two Db adapter objects. Use one during fetch operations and the other during insert/update/delete operations. If you do custom queries outside of the Table interface, you'd have to use the appropriate Db adapter manually.

Another idea would be to write a proxy class extending Zend_Db_Adapter_Abstract, which inspects the type of SQL query and then delegates to one of two connection objects.

As you said, managing this in MySQL Proxy may be the best transparent solution. Similar to relying on the MySQL query cache, instead of caching query results manually in application space.

When I asked Andi Gutmans directly about the goals of Zend Framework, he said the priority is on making development rapid and easy. Support for good performance was secondary, or not a priority at all.

Not surprising, considering Zend is in the IDE tools business. Their raison d'être is to reduce development time, and therefore provide value to their customers.

(Reply) (Thread)

	From: fallenpegasus	Date: November 12th, 2008 10:47 pm (UTC)		(Link)
	Re: No but here are a couple of ideas

The problem is that NONE of the ORM people seem to care about good performance at all, and so seem to go out of their way to generate pessimale queries.

(That Rails always does a "SELECT *", no matter what column you ask for, is the most straightfoward to explain and the most slam-the-head-into-the-desk answer.)

(Reply) (Parent) (Thread)

From: bkarwin	Date: November 12th, 2008 10:57 pm (UTC)		(Link)
Re: No but here are a couple of ideas

Believe me, I sympathize. It was a bit painful to work on Zend_Db with no management support for performance goals. I mean he didn't literally say, "make it run slow," but the emphasis was clearly to make the interface simple, and to advance the project to its 1.0 milestone ASAP.

I don't think ORM people don't care about performance, I think they just have other priorities. "Make it right, make it beautiful, then make it fast."

It's a bit like the stories of programmers in the 1960's who knew they were creating problems related to Y2K, but they were given requirements to store and display year values using two digits, for space optimization.

(Reply) (Parent) (Thread)

	From: awfief	Date: November 13th, 2008 04:07 am (UTC)		(Link)
	Re: No but here are a couple of ideas

ORM's are not "make it right, make it beautiful, then make it fast." ORM's are designed to take the confounded relational database model and squeeze it into an object-oriented model.

The problem is the people that design ORM's are developers, not DBAs, so performance is awful, pretty much as bad as if the developer end-users would just attempt to write the queries themselves.

(Reply) (Parent) (Thread)

	From: fallenpegasus	Date: November 13th, 2008 02:46 pm (UTC)		(Link)
	Re: No but here are a couple of ideas

Often they are even worse, and harder to fix.

(Reply) (Parent) (Thread)


	6 comments or Leave a comment