I've pinged Alex @ twitter so hopefully he'll have some feedback too.
I haven't dug too deep in your code but I'm curious if there's a
reason this would be tough.
Great idea BTW :-)
::J. Danger
On Apr 12, 2:38 pm, "Dr Nic" <drnicwilli...@gmail.com> wrote:
> Here's an outline for a solution for supporting multiple connections
> to duplicate databases. I'm not an expert in production environments,
> so whilst the tutorial works, I'm not sure how it will play out in
> "the real world".
>
> I've pinged Alex @ twitter so hopefully he'll have some feedback too.
>
> http://drnicwilliams.com/2007/04/12/magic-multi-connections-a-facilit...
"Though perhaps we could use your idea and pass a :connection option in the crud methods; or perhaps :connection_group."
I might investigate implementing these, just for laughs and giggles.skype: nicwilliams
(p) +61 7 3102 3237 (Finds me anywhere in the world, via Skype)
(m) +4673 768 1389 (Swedish mobile)
(f) +61 7 3305 7572 (sends fax to my email)
Björnsonsgatan 153, 16 844 Bromma, Sweden
If you are trying, on the other hand, to connect different models to
different databases, or even the same model to different databases at
different times, then there are already patterns to do that (which you
know.)
V/r
Anthony
--
Cell: 808 782-5046
Current Location: Melbourne, FL
Perhaps the following database.yml syntax cleanly describes the
desired usage of a hidden connection pool with different CRUD
operations for an assumed one master-many slaves setup (one master
only being a subset of this).
production:
adapter: mysql
...
read_only:
clone1:
...
clone2:
...
We'd then use cloneN for select calls if read_only was specified.
If people think this is nice syntax for specifying multiple
connections, I'll go an implement it.
Nic
On Apr 13, 12:29 am, "Anthony Eden" <anthonye...@gmail.com> wrote:
> I'm not really feeling it. Connecting to multiple database instances
> to provide greater database scaling should be transparent. It seems to
> me that *that* was Alex's biggest gripe. I'd rather see the
> transparency either a.) at the adapter level or b.) through the use of
> load balancing (load balancing is great for non-HTTP traffic).
>
> If you are trying, on the other hand, to connect different models to
> different databases, or even the same model to different databases at
> different times, then there are already patterns to do that (which you
> know.)
>
> V/r
> Anthony
>
> On 4/12/07, Dr Nic <drnicwilli...@gmail.com> wrote:
>
>
>
> > Here's an outline for a solution for supporting multiple connections
> > to duplicate databases. I'm not an expert in production environments,
> > so whilst the tutorial works, I'm not sure how it will play out in
> > "the real world".
>
> > I've pinged Alex @ twitter so hopefully he'll have some feedback too.
>
> >http://drnicwilliams.com/2007/04/12/magic-multi-connections-a-facilit...
If that has any sense from a load balancing pov (I think it does for
highly write-intensive apps) and it is manageable in the code, then I'd
like to be able specify the role (write/read/both) for each node.
E.g.
production:
adapter: mysql
cluster:
node1:
host: X.Y.Z.1
role: write
node2:
host: X.Y.Z.2
role: read
node3:
host: X.Y.Z.3
role: read
or:
production:
adapter: mysql
cluster:
node1:
host: X.Y.Z.1
role: readwrite
node2:
host: X.Y.Z.2
role: readwrite
node3:
host: X.Y.Z.3
role: readwrite
Luca
--
Web: http://spazidigitali.com - http://thetyper.com
Email mailto://luca.m...@gmail.com
Skype callto://l.mearelli
--
Nonetheless, it occurred to me that some slaves might be read-write,
so some syntax for that:
production:
adapter: mysql
...
read_only:
clone1:
...
clone2:
...
read_write:
master1:
...
master2:
...
There is also the case where you have federated data, so you'd have:
db1: users 1 - 100k
db2: users 101k - 200k
db3: users 201k - 300k
etc
I don't think you can possibly handle all the different cluster setups
out there. Just as long as the developer can manually pick the
connection in the code if need be, it will be clean for those with
simple setups (rw to master, read-only slaves), and a uglier but
manageable for the massive, extremely complicated setups.
Thought: given that concurrency in Rails is obtained with additional
processes, each Rails instance/Mongrel probably doesn't need a
connection to all DBs. But might be over-assumptive.
Inserts + Updates in rails are followed by fetches to retrieve ids.
So, having write_only databases might get ugly.
Nic
> Email mailto://luca.meare...@gmail.com
> Skype callto://l.mearelli
> --
> Inserts + Updates in rails are followed by fetches to retrieve ids.
> So, having write_only databases might get ugly.
>
ugh I didn't think of it :(
I do absolutely agree though with what you say below, that is should be
at least possible for the developers to address a specific connection.
> I don't think you can possibly handle all the different cluster setups
> out there. Just as long as the developer can manually pick the
> connection in the code if need be, it will be clean for those with
> simple setups (rw to master, read-only slaves), and a uglier but
> manageable for the massive, extremely complicated setups.
>
yes it should be trivial for simple setups and doable for
data-partitioned clusters
“Standard MySQL clients: These are no different for MySQL Cluster
than they are for standard (non-Cluster) MySQL. In other words, MySQL
Cluster can be accessed from existing MySQL applications written in
PHP, Perl, C, C++, Java, Python, Ruby, and so on.”
Manfred
http://www.drnicwilliams.com - Ruby/Rails/Javascript/Web2.0
I think the "best" approach might be to simply have a hook into the
connection selection method using a block that is yielded certain
"interesting" information about the pending operation and is expected
to return the name of the connection to use for the operation. The
ability to specify a global default and override it on specific models
would be nice, too. In general, I think that for anyone who /needs/
this type of behavior, such a setup would not be considered too
complicated; and it means you don't have to decide on a least common
denominator for the various situations that one might run in to. What
it provides is a central place to configure the behavior, as well as a
convention.
http://revolutiononrails.blogspot.com/2007/04/actsaswithreadonly-to-support-read-only.html
On Apr 15, 1:19 am, "Dr Nic" <drnicwilli...@gmail.com> wrote:
> Val Aleksenko is about to release a plugin to support the read-only
> database.yml syntax discussed earlier.
>
> http://revolutiononrails.blogspot.com/2007/04/actsaswithreadonly-to-s...
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-overview.html
Paul.
If you're trying to scale your database you're likely to already have
the whole thing in memory anyway.
Kind regards,
Thijs
--
Fingertips - http://www.fngtps.com