按用途划分的SQL Server数据库
数据库通常是大多数应用程序的存储空间。我们公司每天都会对这些数据进行大量的计算和数据处理。按用途划分的SQL Server数据库
只要我们获得越来越多的数据,数据生成就成了一个问题原因花费太长时间。我认为将数据库分成至少两个是有意义的:
用于存储数据,重点是读/写性能;
用于计算重点是数据聚合性能。
有没有人有类似的经验,可以告诉如果这个想法是好的,什么是设计差异提到的两点?
也许有必要寻找一个用于计算数据的noSQL解决方案,例如内存数据库?
它可以是有意义的独立的数据库中至少两个
如果数据库在不同的磁盘(使用不同的主轴),它可以帮助否则你就没有收获,因为磁盘IO之间共享这些数据库。
对于最佳实践,阅读Storage Top 10 Best Practices
也许这是值得寻找的NoSQL解决方案,例如计算数据内存数据库?
没有必要去的NoSQL解决方案,您可以使用内存中的表 在内存OLTP可以显著提高交易处理,数据加载和瞬态数据方案的性能。
有关详细信息,In-Memory OLTP (In-Memory Optimization)
其它策略
1)调tempdb的
Tempdb中是很常见的所有数据库和计算中大量使用。
更实用的方法是在文件和逻辑CPU(核心)之间建立1:1的映射,最多为8个。
了解更多详情:SQL Server TempDB Usage, Performance, and Tuning Tips
2)评估寿命(PLE)计数器,并采取措施对增强
评估数据缓存,运行以下查询
SELECT [object_name],
[counter_name],
[cntr_value] FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%Manager%'
AND [counter_name] = 'Page life expectancy'
的推荐值的PLE计数器(以秒为单位)大于:
total_memory_dedicated_for_sql_server/4 * 300
页面预期寿命是页面将保留在没有引用的缓冲池中的秒数。简单地说,如果你的页面在缓冲池(内存缓存的区域)中的停留时间更长,那么你的PLE就会更高,因为每次请求到达时都会有更高的性能,所以它有可能在缓存本身中找到它的数据,而不是去读取数据的硬盘。
如果PLE不够增加内存并调整索引和统计。
3)使用SSD磁盘
随着固态盘(SSD)的下降的成本,使用固态硬盘作为高速缓存的第二层。
4)使用RAID 5作为数据库;和用于事务日志和tempdb的RAID 10。
通常,SQL优化器游戏正在将数据从磁盘(低速)移动到缓存(内存高速)。
增加内存和提高diskIo速度,您将获得高性能
谢谢M.Hassan给出了这么大的答案!将尝试所有的建议。正在接受检查 – Almazini
欢迎和快乐的一天。 –
看一看SQL SSAS进行计算和aggragation – RegBes
@RegBes你说的是添加度量计算?它快吗?我可以尝试... – Almazini
@RegBes不知道它是否会工作..因为没有太多的经验。我们这一代有几十个计算步骤。那么我需要创建一个依赖前一个的计算方法链吗? – Almazini