SQL Azure分片和社交网络应用

Question

SQL azure上的分片概念是超过50 DB大小限制的首选选项之一，目前已经有了。分片中的一个关键策略是将称为原子单元的相关记录分组到单个分片中，以便应用程序只需查询单个SQL azure实例即可检索数据。

然而，在社交网络应用程序等应用程序中，由于实体和记录之间的互连，将原子单元分组到单个分片中并不是一件容易的事情。基于这样的场景，推荐的方法是什么？

同样在分片的数据库中，表应该使用什么主键？Big Int或GUID。我目前使用的是BIGINT Identity列，但是如果由于某种原因要合并数据，这将是一个问题，因为不同分片中的值之间存在冲突。我听说有些人推荐GUID (UniqueIdentifier)，但我对这会如何影响性能持谨慎态度。使用UniqueIdentifier列对本地SQL server进行索引是不可能的，如果我使用UniqueIdentifier列，我想知道SQL azure如何实现类似的策略。

Answer 1

对于社交网络应用程序，我倾向于放弃使用SQL，转而使用MongoDB或Azure Table Storage等noSQL解决方案。这些非标准化但价格低廉的系统允许您创建多个实体数据集，这些数据集可根据您的各种索引需求进行自定义。

所以不是像这样..。User1 -< relationshiptable -< User2

相反，您将拥有像Users User1's Friends User2's Friends这样的表

如果用户1和2都是朋友，那么您应该有两个条目来定义该关系，而不是一个条目。但是if使得检索特定用户的朋友列表变得微不足道。现在，通过一次搜索多个索引表，它还为并行执行任务打开了大门。

此过程可伸缩性极好，但确实需要您在如何维护关系上投入更多时间。诚然，这是一个简单的例子。当你开始讨论像搜索整个用户群这样的任务时，事情会变得复杂得多。