Alexander Staubo wrote:
On 6/1/07, Andrew Sullivan <ajs@xxxxxxxxxxxxxxx> wrote:
These are all different solutions to different problems, so it's not
surprising that they look different. This was the reason I asked,
"What is the problem you are trying to solve?"
You mean aside from the obvious one, scalability?
Multimaster doesn't give you scalability (at least not like a lot of
people think it does).
The databases is becoming a bottleneck for a lot of so-called "Web
2.0" apps which use a shared-nothing architecture (such as Rails,
Django or PHP) in conjunction with a database. Lots of ad-hoc database
queries that come not just from web hits but also from somewhat
awkwardly fitting an object model onto a relational database.
Databases are a bottleneck when you get a bunch of so called web 2.0
developers thinking they know an inch about databases.
What you are basically saying below is... web 2.0 developers such as
rails developers have so fundamentally broken the way it is supposed to
be done, we should too...
Not too convincing.
As it stands today, horizontally partitioning a database into multiple
separate "shards" is incredibly invasive on the application
architecture, and typically relies on brittle and non-obvious hacks
such as configuring sequence generators with staggered starting
numbers, omitting referential integrity constraints, sacrificing
transactional semantics, and moving query aggregation into the app
level. On top of this, dumb caches such as Memcached are typically
layered to avoid hitting the database in the first place.
Still, with MySQL and a bit of glue, guys like eBay, Flickr and
MySpace are partitioning their databases relatively successfully using
such tricks. These guys are not average database users, but not they
are not the only ones that have suffered from database bottlenecks and
overcome them using clever, if desperate, measures. Cal Henderson (or
was it Stewart Butterfield?) of Flickr has famously said he would
never again start a project that didn't have a partitioning from the
start.
I would love to see a discussion about how PostgreSQL could address
these issues.
Alexander.
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
