几个较小的一个大型SQL服务器表？

我有一些设计问题要问。几个较小的一个大型SQL服务器表？

假设我有一些TBL_SESSIONS表，其中我保留每个登录的user-id和一些Dirty-flag（表明他拥有的内容是否已被更改，因为他得到了它）。

现在，该表格应该每隔几秒就由该登录用户每隔几秒询问一次，即该表格上有很多读取调用，并且该Dirty-flag也有很大改变。

假设我期望许多用户同时登录。我想知道是否有任何理由创建像说10个这样的表并让用户在这些表之间分发（根据他们的用户id）。

我从两个方面提出这个问题。首先，就性能而言。其次，在可扩展性方面。

我很想听听你的意见

来源

2014-02-06 dsb

请定义“llarge”。几十亿行？因为低于1亿的东西应该是一个完全没有问题的东西（除非你认为这是数据 - 许多开发者可悲地做）。 25年前，一百万行很大，今天很小。 – TomTom

假设有100万行（这意味着有100万用户登录） – dsb

哎呀..我在回答之前没有收到完整的消息。那么，你是说，每隔几秒钟至少读取一行100万行的表格不是问题吗？ – dsb

如果你有很多的记录，比如数十亿，以及你的服务器无法处理的高负载，那么拥有多个表格会让你感到惊讶。这样你就可以执行分片 - >将不同的服务器拆分成几个表。例如。在服务器A（id为1到100 000 000），接下来的1亿在服务器B（100 000 001到200 000 000）等等上有第一亿条记录。其他方式 - 有相同关于的数据不同和查询数据通过某种平衡器，这可能会更困难（复制不是RDBMS的关键特性，所以它取决于引擎）

来源

2014-02-06 11:45:55 Sergio

在您的示例分片计划中，您将所有新用户加载到单个分片上。这听起来不像一个好计划。 –

对于1米行使用单个表。

使用正确的索引访问时间不应该是一个问题。如果您使用多个分布在其中的用户，则需要进行额外的处理以找到要读取/更新的表。

另外，您将为每个表分配多少用户？当用户数量增长时会发生什么......添加更多表格？我想你最终会遇到维修噩梦。

来源

2014-02-06 11:45:48 Tony

在没有更多信息的情况下，这当然应该是缺省方法。 –

几个较小的一个大型SQL服务器表？

回答

相关问题