就性能而言，哪种分片策略更好？散列 GUID 或联系横向扩展经理？
我们正在建立一个相对较高知名度的网站，预计在推出的第一天就会有 1 亿次点击。我的前任主张使用具有 1 TB RAM 和 32 个内核的单个服务器来扩展 SQL 策略。我们被告知这不是一个可行的解决方案。
作为回应，我转向了具有多个 SQL 服务器和水平分区的横向扩展策略。我的问题围绕如何将 DAL 定向到适当的数据库服务器。应用程序的每个用户都会有多次读取和写入操作。我的第一个想法是使用单个横向扩展服务器来存储每个用户的配置文件 ID (GUID)，并将连接字符串返回到该用户的分片。这看起来开销很大，并且造成了单点故障。
我的第二个策略是通过 GUID 路由到数据库，这样我就可以直接将其编码到 DAL 中。 GUID 不是随机的，所以我想我需要对其进行哈希处理，以便在数据库分片之间获得相对均匀的分布。每个用户（包括匿名用户）都有一个 GUID，因此这实际上是我可以用于分片的唯一属性。
所以问题是我是否会因为必须发生的哈希而降低性能。我非常有信心散列将比数据库读取更少成为瓶颈，但我真的很想得到一些对此的反馈或社区想要分享的关于我的策略的任何其他想法。
一些具体细节： 我们在数据库服务器上使用 SQL 2008 R2 Enterprise。每个数据库将有 64GB RAM 和 8 个核心。数据库将位于共享存储上。如果服务器出现故障，将使用 Vmotion。启动时将会有大量的 Web 服务器（30-40？），但确切的数量将由性能测试决定。该应用程序基于 .net 4.0 和 Enterprise Library v5 构建。 Web 服务器负载平衡将由 Cisco ACE 处理。我们要求每个数据库服务器位于单独的 vSphere 实例上。
谢谢！
We're building a relatively high profile site that is expected to have 100 million hits on the first days of launch. My predecessor had argued for a scale-up SQL strategy using a single server with 1 TB RAM and 32 cores. We have been advised that this is not a feasible soluiton.
In response, I have shifted to a scale-out strategy with multiple SQL servers and horizontal partitioning. My question revolves around how I will direct the DAL to the appropriate database server. There will be many reads and writes for each user of the application. My first thought was to use a single scale out server that stored the profile id (GUID) of each user and would return the connection string to that user's shard. This seemed like a lot of overhead and created a single point of failure.
My second strategy was to route to the database by GUID so I could directly code this into the DAL. GUID's aren't random though so I'm thinking I'd need to hash it in order to get a relatively even distribution between my database shards. Every user including anonymous users has a GUID, so this is really the only property I have available to me that I can use for sharding.
So the question is whether I'm going to kill performance with the hashing that will have to occur. I'm pretty confident that the hash will be less of a bottleneck than a database read, but I'd really like some feedback on this or any other thoughts the community would like to share about my strategy.
Some specifics:
We're using SQL 2008 R2 Enterprise on the db servers. Each db will have 64GB RAM and 8 cores. The databases will be on shared storage. Vmotion will be used if a server goes down. There will be a slew of web servers at launch (30-40?) but the exact number will be dictated by performance testing. The application is built on .net 4.0 with the Enterprise Library v5. Web server load balancing will be handled by a Cisco ACE. We have requested that each of the database servers be on a separate vsphere instance.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是否有任何用户配置文件需要与另一个用户配置文件交互？典型的例子是某种墙，例如。您可以在其中看到所有朋友的状态更新。请参阅使用 Reliable 横向扩展 SQL Server发消息以了解我为什么问这个问题。
至于散列，一个好的散列方案可以适应分布的变化（例如，机器 A 拥有的段被分成现在由 A 和 B 拥有的两个新段），而无需对应用程序进行更改。应用程序层中的散列并不能解决这个问题，拥有一个专用的“横向扩展管理器”会更好，只要您将横向扩展管理器设计为高可用并控制它必须响应的请求数量（例如前端层的每个 HTTP 请求少于 1）。
Is any user profile needing to interact with another user profile? Typical example would be a Wall of some sort, eg. where you see the status updates from all your friends. See Scale out SQL Server by using Reliable Messaging to understand why I'm asking this.
As for hashing, a good hashing scheme can accommodate a change in the distribution (eg. a segment owned by machine A is split into two new segments now owned by A and B) w/o changes to the application. Hashing in the app layer does not solve this problem, having a dedicated 'scale-out manager' is better, as long as you design the scale-out manager to be highly available and control the number of requests it has to respond to (eg. less thatn 1 per HTTP request on the front end layer).