On Sep 27, 2008, at 1:45 PM, Jim Starkey wrote:
Jay Pipes wrote:
Jim Starkey wrote:
Something that I believe warrants reconsideration is prepared
statement handling. I am aware that prepared statements were
handled
badly in MySQL, but that doesn't mean they are a bad idea.
Prepared
statements enable a compiled statement cache, intrinsically much
faster than parsing, compiling, and optimizing the same statements
over and over and over -- no matter how fast the parser and
optimizer
are, not parsing and optimizing is faster.
Why? Because then proxies along the way have access as well. I also
believe that the parsed bits won't be that large.
I guess I don't understand this at all. What proxies need this
information and what would they do with it?
Things like load balancing and shard-awareness. If the proxy cannot
translate or understand the prepared statement's bind params it has
no
chance of being able to redirect a request to a particular shard (or
even issue a NOOP if it knows the statement requests cached
information). Less in the server the better, IMHO.
Isn't there a better, easier, smaller, faster, more reliable way to
do this than to require the client to generate, the server to
process, and the proxy to inspect entrails of partially digested
SQL? And, as has been pointed out, trashes consistent transactions
in the process?
Let me propose an alternative solution for sharding and load
balancing (oh, I hate the very idea of this being user visible!).
Suppose you added a mechanism to associate an arbitrary ordered set
of attribute/value pairs with a connection that would be sent along
as part of the protocol. Your proxy could use these to decide where
to direct a connection. After, after making this weighty decision,
it could pre-pend its own attribute/value pair indicating where it
sent the connection so subsequent statements would go the same
place. This has many advantages:
* It doesn't require standardization of SQL entrails
* It isn't dependent on client winks and proxy nudges -- it's all
above board
* It provides a consistent mechanism to direct a series of
transactional statements to a particular server
* It is consistent with compiled statements (so is existing
proposal, incidentally)
* It is consistent with aggregating interfaces
How does this handle the fact that the data is partitioned and so not
all data is available to a particular node/server?
I've been redesigning the connection/service/protocol handling for
Nimbus over the last couple of days. If anyone's interested, I'd be
happy to sketch out the evolving design.
I would be most interested!
--
Paul McCullagh
PrimeBase Technologies
www.primebase.org
www.blobstreaming.org
pbxt.blogspot.com
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
