Производительность MDX по сравнению с T-SQL
Использование
[[NSURLCache sharedURLCache] removeAllCachedResponses];
ДО выполнения вызова или при загрузке контроллера представления, это статическая функция, которая удаляет все данные кэша для ответов. Только с использованием cachePolicy этого было недостаточно, я вижу, что uiwebview может обновлять HTML-документ, но не связанный документ, такой как CSS, JS или изображения.
Я пробую это решение, и оно работает.
if (lastReq){
[[NSURLCache sharedURLCache] removeCachedResponseForRequest:lastReq];
[[NSURLCache sharedURLCache] removeAllCachedResponses];
}
lastReq=[NSMutableURLRequest requestWithURL:[NSURL URLWithString:localUrl]
cachePolicy:NSURLRequestReloadIgnoringCacheData
timeoutInterval:10000];
[lastReq setCachePolicy:NSURLRequestReloadIgnoringLocalCacheData];
[self.mainWebView loadRequest:lastReq];
- Прежде всего, я удаляю кеш для последнего запроса и призываю удалить весь другой кеш (я думаю, что это не так важно) - Затем я создаю nsurlrequest и ignoringLocalCacheData - наконец, загрузите новый запрос
Я проверяю его, и он перезагружает все файлы (HTML, CSS, JS и изображения).
4 ответа
Яблоки и апельсины: OLAP-куб служб анализа - это принципиально другой тип хранилища, чем база данных SQL Server, и они предназначены для разных задач. Технически MDX не «быстрее», чем T-SQL, и наоборот - это просто языки, но они предназначены для разных нужд.
При этом куб обычно лучше всего подходит для выполнения числового анализа статических данных, например для агрегирования большого числа продаж / транзакций / любых записей с течением времени. Напротив, традиционная реляционная база данных обычно отлично работает, если схема и индексы хорошо построены, для поиска. Простой способ судить: если ваши SQL-запросы должны выполнять много
select grock, sum/min/max/avg( foo )
from bar
group by grock -- Ideal Analysis Services problem
, тогда может помочь куб (он предназначен для агрегатных математических функций - sum () и group by). OTOH, если ваши запросы выполняют много
select cols
from foo
where <complicated search> -- Not so much
, тогда куб, вероятно, не поможет, и я бы вместо этого сосредоточился на настройке схемы, запросов и индексации и, возможно, на разделении таблицы, если данные могут быть соответствующим образом разделены.
Сделайте это. у вас есть кластерный индекс и покрывающие некластеризованные индексы, соответствующие запросам?
Куб MS SSAS OLAP можно использовать в нескольких режимах хранения:
Реляционный (OLAP) - данные и метаданные остаются в вашей БД, и добавляется еще несколько материализованных представлений. Может быть, а может и не быть быстрее.
Гибрид (HOLAP) - метаданные и (предварительно рассчитанные) агрегаты хранятся на новом сервере, на котором запущен экземпляр SSAS. Это должно ускорить выполнение всех запросов с использованием агрегатов, таких как «общее количество часов сотрудников за последний год по месяцам», но запросы, которые позволяют детализировать определенные записи, могут быть такими же, как и раньше.
Многомерный OLAP (MOLAP), где все ваши данные плюс метаданные и агрегаты копируются на сервер SSAS. Обычно это самый быстрый, но дублирует хранилище.
Перед тем, как начать, вам следует подумать об оптимизации макета таблицы для отчетов и аналитики, другими словами, используйте хранилище данных (DW) - поместите свои данные в размерность звезды Кимбалла и таблицы фактов. Затем вы периодически загружаете DW с помощью ETL (SSIS) и направляете свои отчеты и аналитику в DW. Может оказаться, что вам вообще не нужно использовать SSAS - запросы SQL, выполняемые для макетов звездообразной таблицы, обычно значительно быстрее, чем для нормализованной оперативной базы данных БД.
Если это все еще слишком медленно, создайте кубы SSAS поверх DW.
Как только вы начнете загружать свой DW, вы сможете удалить записи из своей оперативной базы данных, что ускорит ее повседневное использование.
Подводя итог, мое практическое правило будет следующим:
1. Создайте DW и настройте свой процесс ETL
2. Попробуйте отчеты T-SQL против DW, может быть достаточно.
3. Если по-прежнему медленно, создайте кубы SSAS (поверх DW) в режиме HOLAP и используйте многомерные выражения для их запроса.
"The performance of the stored procedures is so slow even with suitable indexes"
I'd be surprised if the stored procedure is the real problem, maybe the the way the procedures are used is slow, but a stored procedure by definition doesn't make it slow. Have you found out what about your procedures is slow? Have your profiled them? I would take a deep long look at that route before redesigning my database. Multi-dimensional databases are for OLAP is your database strictly an OLAP database or is it a hybrid of OLAP and OLTP? Maybe you need to de-normalized and replicate data in your OLTP design into the de-normalize d structure? 600 million records in a table is not by any means huge, it's not small but that doesn't lead me to believe that dropping stored procedures will magically make things fast. Profile your stored procs and see where the performance bottlenecks are before jumping into a bigger project to fix the issue.
Рассматривали ли вы PowerPivot (надстройка Excel)? Он использует вертикальное сжатие для локального сжатия данных примерно на 95%, поэтому вы можете анализировать в свое удовольствие.