我创建了一个数据库，该数据库具有下表的用户活动：
user_id | INTEGER | user being notified
actor_id | INTEGER | user performing the action
activity_type | STRING | classname/type of the object being notified
activity_id | INTEGER | id of the object being notified
context_type | STRING | classname/type of the object's parent
context_id | INTEGER | id of the object's parent
read/view_at | DATETIME | timestamp of when user saw it
我不知道这种设计在表演方面是否良好。所以我想以某种方式对其进行测试。我可以用大量数据和打开页面填充数据库，我需要从该表获取数据，但我不知道这是否是相关的测试。
是否有一个很好的方法来查看此设计在10.000用户和feed表中有50.000.000记录时的性能？
我不知道这是否可以帮助，但是我正在使用MS SQL Server
如果性能至关重要，则需要在开发管道中构建。
我在关键绩效项目上所做的工作：
- 创建性能测试数据集；在您的情况下，我将加载一张带有100m测试记录的表，从而最好地猜测数据的分布。
- 编写询问该应用程序将用于查询数据
- 编写一个可以执行这些查询的测试脚本；我喜欢加特林。
- 猜测我的测试硬件与生产套件的关系的关系。理想情况下，它是相同的 - 但实际上，这可能太贵了。您必须根据可以观察到生产行为的情况来改善该猜测。
- 猜测流量模式-10K用户如果以良好，均匀分布的模式（10k/24小时/60分钟/60秒=小于1个请求每秒请求）并不多。如果他们都完全同时出现，那么您会有问题。我通常有3种负载模式：
- 逐渐升起（这是"最佳情况"），
- 激进的提升（这反映了您在繁忙时间期的期望，例如，如果您的用户倾向于在1小时内访问），
- 和最差的案例（反映有病毒视频峰或类似的情况会发生什么）
- 安排我的盖特林测试每天至少运行一次，理想情况下是每个签到的一部分
- 设定性能的目标，例如" 500ms或更少的查询90％"；当测试超过这些目标时，将时间和注意力用于改善
- 一旦您可以访问实时基础架构，请运行测试
- 有访问者后，监视查询性能，调整负载测试和目标
到目前为止，这对我有用：
- 确定表演的查询至关重要。 1
- 设计数据库，以便DBM可以使用快速执行计划来对上述查询。 2
- 用代表性的测试数据填充数据库，并确保上面预期的查询执行计划确实正在使用（每个单独查询的性能都是令人满意的）。
- 基准标准您软件的整个"垂直堆栈"。到现在为止，不应该有太多的不良惊喜。
您可以看到，数据库设计不仅仅是满足业务需求。实际上，了解客户打算如何访问数据是设计过程不可或缺的一部分。
换句话说，尽管"逻辑设计"传统上是不够的 - 逻辑和物理设计之间需要有一条"双向街道"。
有一个很好的方法可以查看该设计在有10.000用户和50.000.000记录时的性能？
中的50.000.000记录
该句子没有足够的信息来回答。
首先告诉您您打算如何访问数据，也许我们可以帮助您（重新）设计数据库以有效地支持该特定访问模式。
1 例如，如果"加载页面"对于用户体验至关重要（通常是），请列出通常在此过程中执行的查询列表。
2 包括"物理"技术，例如索引，聚类，分区等，但也可以包括一些传统上是"逻辑"设计的方面，例如钥匙和关系的设计。如果您了解典型DBMS使用的基本数据结构，则可以预测大多数设计决策的性能后果。使用索引，卢克！是关于该主题的绝佳介绍。
关于性能，没有假设是安全的。您应该遵循以下步骤：
-
定义有关负载和响应时间的绩效目标。您应该确定特定数据加载的接受的响应时间。
-
定义资源。并非每种机器配置都会相同。您应该使用目标配置构建虚拟机。
-
执行负载测试。您可以使用SQL Server Load Generator之类的工具来做到这一点。
希望这会有所帮助！