现在,我的第一个优化方法是将数据保持在最小的大小,所以我将行大小减少到平均60个字节,并具有以下列：
[Stock] [int] NOT NULL [Date] [smalldatetime] NOT NULL [Open] [smallmoney] NOT NULL [High] [smallmoney] NOT NULL [Low] [smallmoney] NOT NULL [smallmoney] NOT NULL [Trades] [int] NOT NULL [Quantity] [bigint] NOT NULL [Volume] [money] NOT NULL
现在,第二种优化方法是制作聚类索引.实际上,主索引是自动聚类的,我把它作为具有库存和日期字段的复合索引.这是独一无二的,我在同一天不能有同一股票的两个报价数据.
集群索引确保来自同一股票的报价可以保持在一起,并且可能按日期排序.这第二条信息是真的吗？
现在有50万条记录,大约需要200ms才能从特定的资产中选择700个报价.我相信这个数字会随着表的增长而增加.
现在第三种方法,我正在考虑将表格分成三个表格,分别是针对特定市场(股票,期权和远期).这可能会将桌面尺寸缩小1/3.现在,这种做法有帮助吗？现在桌子的大小是50mb,所以它完全可以在RAM中完成,没有多大的麻烦.
另一种方法是使用sql Server的分区功能.我不太了解它,但是我认为通常在表格很大的情况下使用,您可以跨越多个磁盘来减少I / O延迟,是吗？在这种情况下,分区是否有帮助？我相信我可以在不同的表格中分区最新的值(最新的年份)和最旧的值.寻找最新数据的可能性更高,而小分区可能会更快,对吗？
什么是其他好的方法来使这个最快？主要选择使用表将用于从特定资产(如最近3个月的资产X)中寻找特定范围的记录.将有另一个用法,但这将是最常见的,可能超过3k用户并发.
解决方法
Now,second approach for optimization was to make a clustered index. Actually the primary index is automatically clusted and I made it a compound index with Stock and Date fields. This is unique,I can’t have two quote data for the same stock on the same day.
The clusted index makes sure that quotes from the same stock stay together,and probably ordered by date. Is this second information true?
这在逻辑上是正确的 – 聚集索引定义了磁盘上记录的逻辑顺序,这是您应该关心的. sql Server可能会放弃在物理块内进行排序的开销,但它仍然会像之前一样运行,因此这并不重要.在任何情况下,查询一个库存大概可能是1或2页的读取;并且优化器不会在页面读取中的无序数据中受益匪浅.
Right now with a half million records it’s taking around 200ms to select 700 quotes from a specific asset. I believe this number will get higher as the table grows.
不一定明显表大小与查询速度之间没有线性关系.通常还有更多的考虑因素更重要.我不会在你所描述的范围内担心它.这是你关心的原因吗？似乎对我来说,200毫秒是非常好的,足以使您达到加载桌面的位置,您可以开始进行现实的测试,并更好地了解现实生活中的表现.
Now for a third approach I’m thinking in maybe splitting the table in three tables,each for a specific market (stocks,options and forwards). This will probably cut the table size by 1/3. Now,will this approach help or it doesn’t matter too much? Right now the table has 50mb of size so it can fit entirely in RAM without much trouble.
没有！这种优化太早了,可能还是比较早.
Another approach would be using the partition feature of sql Server.
同样的评论.您将能够坚持长期严格的逻辑,完全规范的模式设计.
What would be other good approachs to make this the fastest possible?
最好的第一步就是集中在股票上.插入速度至关重要,直到您查看每秒插入的多个记录 – 我没有看到任何活动附近的任何地方.这应该使您接近最大的效率,因为它将有效地读取与股票相关的每个记录,这似乎是您最常见的指标.任何进一步的优化需要根据测试来完成.
