# Sharding

**URL:** <https://www.ruby-forum.com/t/sharding/153692>\
**Category:** Rails\
**Created:** [November 20, 2008, 6:57am UTC](https://www.ruby-forum.com/t/sharding/153692 "2008-11-20T06:57:22Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![grayson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/c77e96/32.png) [@grayson](https://www.ruby-forum.com/u/grayson)\
**Post date:** [November 20, 2008, 6:57am UTC](https://www.ruby-forum.com/t/sharding/153692/1 "2008-11-20T06:57:22Z")

</div>

Does anyone have any experience they’d like to share on data sharding?

In particular working with a gem like this:

[http://blog.fiveruns.com/2008/7/9/introducing-data\_fabric](http://blog.fiveruns.com/2008/7/9/introducing-data_fabric)

My concerns are:

1. This doesn’t appear to use SQL level replication so I assume it’s  
doing some type of a “call-back” after the initial commit. How do those  
call-backs get queued? Is the rails process going to be freed up after  
all these callbacks are done or before? What happens under extremely  
large volumes?

2. It’s not clear to from reading the documentation if/how this can be  
used for failover. In other words if the master for a particular shard  
goes down does that mean that that shard becomes read-only?

3. Their readme says "When marked as replicated, all write and  
transactional operations for the model go to the master, whereas read  
operations go to the slave. " Which slave? Is this a good idea? what  
if your slave is in Europe and your master is in NA.

GP