数据库分片策略
我想将一个产品表分成许多较小的表，并将该表放在不同的服务器中。 但我遇到了一些问题：如果我用产品 ID 来分片数据库。当有人列出一个产品类别时，如何获得属于某些类别的所有产品。有人有美好的理想吗？
i want to split 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 ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是一个好问题。如果您想要做的只是将一些记录放入另一个数据库中，并且您不打算与任何其他表上的这些记录进行联接，那么您所要做的就是告诉您的应用程序在分片 1 中插入记录 1-10000分片 2 中为 10001 -20000。但是，如果您想从分片 1 到分片 2 进行查询，这是行不通的，您将需要像 dbShards。 dbShards是一款不错的分片工具，评价也很好。此外，它们还将帮助您为您的应用程序制定整体分片策略。
希望有帮助。
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.
分片的基本问题始终是相同的：您从一开始就不知道如何分片。
如果表中没有 1 亿行，那么很明显您不需要考虑分片。分片不能解决任何类型的查询性能。
我曾经尝试猜测数据库中什么会流行，什么会出现问题，但惨败了。现在我明白，我需要在问题发生时解决这个问题，并且我需要编写良好且干净的代码，以便将来可能进行这样的更改（例如，检查存储库模式）。
有关数据库性能的基本知识也很好。添加修复慢速查询（slowlog 是一个很好的起点）并忽略连接操作。
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.