database sharding strategy

i want to sp开发者_如何学Golit a product table into many smaller one, and put the table in diffrent server. but there has some problems with me: if i sharding the database with the product id. how can i get all product belong to some categorys when someone list one product category. anybody get a good ideals ?

---

This is a good question. If all you want to do is put some records in another database and you are not going to be doing joins with those records on any other tables, then yes all you have to do it tell your application to insert records 1-10000 in shard 1 and 10001 -20000 in shard 2. But if you want to do a query from shard 1 to shard 2, that won't work, and you will need a product like dbShards. dbShards is a good sharding tool and has great reviews. Also they will help you develop an overall sharding strategy for your application.

Hope that helps.

---

The basic problem with sharding is always the same: you don't know how to shard from the start.

If you don't have 100 million of rows in table then it's quite obvious you don't need to bother with sharding. Shards are not solving any type of query performance.

I've tried once to guess what will be popular and problematic in DB and failed miserably. Now I understand that I need to tackle that problem when it's happening and I need to write good and clean code to make changes like this possible in the future (check repository pattern for example).

Also basic knowledge about database performance is good. Add to that fixing slow queries (slowlog is a good place to start) and ignore join operations.