Indeed - there have been some significant improvements to MySQL
cluster just in the last month; and I'm not completely familiar with
all the improvements with the new MySQL Proxy. I'm looking forward
the the MySQL users conference to get caught up.
But I would say that being focused on sharding and connection pooling
- Spockproxy is easier to set up to do these things.
In Spockproxy there are 3 tables you need to populate:
-shard_range_directory (the list of low and high id's for each shard)
-shard_table_directory (the list of tables and are they 'universal'
or 'federated')
-shard_database_directory (the list of the database servers and
connection info for the shards)
Fill out these tables, load your schema in each shard and Spockproxy
will work, there's nothing else you need to do; no LUA Scripts,
nothing else to customize. (OK there's probably some tuning to your
schema to optimize the DB for sharding but you'd have to do this for
any sharding solution).
In fact I'm giving a talk on Spockproxy at the MySQL users conf http://en.oreilly.com/mysql2009/public/schedule/detail/6867
I will explore the differences between Spockproxy and the current
MySQL proxy. If you can't make that check out my blog where I will
also cover some of these issues:
http://www.frankf.us/wp/?cat=4
It future I do think it would be great to merge the Spockproxy back
into the MySQL proxy for a whole variety of reasons but I should
stress we're not particularly close to doing that.
If you do shard with either solution I'd like to know your experiences
- either email me personally or post here.
Frank
On Feb 11, 2009, at 9:21 AM, Jacques-Olivier Goussard wrote:
> Hi
> You mention on your site that
> "MySQL Cluster was designed for high availability and performance,
> not for sharding. All indices and the main data are stored in main
> memory, which causes problems if your combined dataset is larger
> than memory. It also requires changing storage engines."
>
> AFAIK, starting with MySQLCluster 5.1, only indexes are required to
> stay in memory and support for user-defined distribution algorithms
> was
> added.
> So now - how does SpockProxy compare with this solution ? It looks
> to me that putting your distribution algo (from the spock table) into
> MySQL cluster would remove the need for this proxy - but I'm no
> expert.
>
> /jog
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills
> and code to
> build responsive, highly engaging applications that combine the
> power of local
> resources and data with the reach of the web. Download the Adobe AIR
> SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com_______________________________________________
> spockproxy-devel mailing list
> spo...@li...
> https://lists.sourceforge.net/lists/listinfo/spockproxy-devel
|
