Каковы лучшие методы для ускорения работы блестящего приложения?

Данные:

У меня блестящее приложение на панели инструментов, и мой набор данных имеет размер около 600 МБ. Он набухает на 100 МБ каждый месяц. Мои данные хранятся локально в MySQL.

Пункты меню:

У меня есть 6 - 7 элементов меню боковой панели на моей приборной панели, и у каждого из них есть 10 - 12 различных выходов - диаграммы и таблицы. Каждая из этих вкладок имеет 3 - 6 входов, таких как selectizeInput, ползунок, диапазон дат и т. Д. Для фильтрации данных.

Подмножества данных:

Поскольку я не могу загрузить все данные в память, для каждого пункта меню я создаю подмножество данных на основе диапазона дат, сохраняя диапазон дат только на 2–3 дня от системной даты.

Например:

df1 <- reactive({df[df$date >- dateinput[1] & df$date <- dateinput[2], ]})

Выше приведены данные для моего первого пункта меню, и в зависимости от selectInput или других входов, я дополнительно фильтрую данные. Например, если у меня есть selectInput дляGender (male and female) тогда я далее подмножествоdf1 чтобы:

df2 <- reactive({
       if(is.null(input$Gender)){ 
          df1 
       } else if(input$Gender == "Male") 
          {df1[df1$Gender == "Male",]} 
       )}

Если у меня более 1 входа, я задаю этот df1 и передаю значения в df2. df2 становится реактивным набором данных для всех диаграмм и таблиц в этом MenuItem.

Чем больше количество пунктов меню, тем больше я создаю поднаборов для фильтров и анализа.

Я сталкиваюсь с двумя проблемами:

На старых машинах приложение не загружается. а такжеНа новых машинах приложение загружается очень медленно, иногда 5 - 6 минут

После первого набора данных диаграммы и таблицы обрабатываются быстрее при реактивных изменениях.

Чтобы противостоять этому, я попытался переместить все общие и повторяющиеся параметры и библиотеки в global.R.

У меня есть два вопроса:

1. Существуют ли какие-либо основные гигиенические факторы, которые необходимо учитывать при добыче данных в R, особенно через блестящий режим (Mining in R чрезвычайно быстр).

2. Я читал о параллельной обработке, но почти всегда все примеры говорят о распределении одного более тяжелого вычисления. Можем ли мы распространять через параллельную обработку, подмножество данных или распространение диаграмм / таблиц.

Обратите внимание, что я исследователь, а не программист, но недавно научился использовать блестящие и размещать приложения в облаке или локально.

Руководство по этому вопросу будет очень полезно для многих начинающих пользователей R, таких как я.

 Apricot01 июл. 2016 г., 10:26
@JorisGillis Мое приложение хранит дату как символ в mysql .... и я использую функцию as.Date для преобразования .... и при включении фильтрации в базу данных - в настоящее время я выбираю один большой набор данных для menuItem и манипулирую по всей этой странице. ..Я непременно попробую ... большое спасибо
 Joris Gillis01 июл. 2016 г., 09:46
@Apricot Это зависит от того, как реагирует ваше блестящее приложение. У вас есть элементы управления фильтрами и кнопка «Вычислить» на каждой вкладке. Если это так, вы можете проверить в текущем реактиве набора данных, какая вкладка открыта, обернуть обработку данных для каждой вкладки в отдельную функцию и вызвать соответствующую функцию. Еще один момент: я бы постарался как можно больше протолкнуть этапы фильтрации и подготовки данных в базу данных. Особенно, если вы конвертируете даты из строковых объектов в объекты POSIXct или Date в R. Преобразование дат - довольно дорогая операция, поэтому вы должны минимизировать ее использование.
 Xiongbing Jin29 июн. 2016 г., 20:23
Вам необходимо выяснить, связана ли медлительность с доступом к базе данных или какими-либо R-функциями. Вот несколько идей, которые могут помочьstackoverflow.com/questions/21484115/... Когда вы говорите, что приложение не загружается на старых компьютерах, попробуйте выяснить, связано ли это с ограничением памяти, версией браузера и т. Д. Shiny интенсивно использует Javascript, который может не работать в старых браузерах.
 Joris Gillis30 июн. 2016 г., 10:16
Еще один интересный момент, связанный с этим вопросом, - я не знаю ответа для себя: если у вас есть несколько реактивных значений, все из которых содержат большие (под) наборы данных, такие как df1 и df2 в этом примере, это те кадры данных, которые хранятся в памяти в все время? Я бы догадался, что они есть. Если это так, то хорошей практикой может быть наличие одного df <- реактивного ({...}), чтобы всегда возвращать «текущий» набор данных, над которым вы работаете.
 Apricot30 июн. 2016 г., 14:03
@Joris Gillis Да ... наборы данных находятся в памяти. Я попытался отложить загрузку набора данных, но это не сработало ... Я попытался иметь один единственный реактивный набор ... но, поскольку у каждого элемента меню есть несколько фильтров, я обязательно создаю подмножества, с которыми будет работать элемент меню. Например, мой первый элемент menuItem - это «Верхние линии», в которых я отображаю только сводку данных, а в качестве фильтра используется дата. Мой следующий пункт меню - табулирование, где я позволяю пользователям табулировать данные на основе фильтров ... теперь в этом случае, если я не разрешаю фильтр даты, тогда все фильтры, примененные в menuItem 1, переносятся в menuItem 2.
 Christophe D.29 июн. 2016 г., 09:34
Действительно интересный вопрос, я думаю, что через несколько месяцев я столкнусь с этой проблемой с моей приборной панелью. Вы отправляете запрос в базу данных SQL каждый раз или загружаете его в Rdata после запуска приложения? Затем с помощьюdf1[df1$Gender == "Male",] для подмножества ваших данных очень медленно, вы пытаетесь использоватьfilter функция из пакетаdplyr это действительно быстрее, когда у вас есть большой набор данных

Ответы на вопрос(1)

правильный ответы, а не комментарии. Я хотел бы поделиться своим опытом и мыслями. Я построил рекламный роликR+shiny приложение с Shiny Server Pro, используя базы данных и множество других приемов.

Задержка загрузки интерфейса
Моему приложению требуется более 30 секунд для загрузки, то есть, чтобы вернуть контроль пользователю.

Проблема

Shiny это одностраничное приложение Поэтому на сложное приложение, с множеством вкладок, данными, загруженными для заполнения некоторых меню и селекторов и т. Д., Это влияет с начального времени загрузки.

UI возможные смягчения

Используйте динамические компоненты пользовательского интерфейса (мудро), чтобы добавить сложности после запуска. Например, конкретное меню может начаться очень просто с нескольких элементов, а затем добавить дополнительные элементы на более позднем этапе.Джо Ченг предложилinsertUI а такжеremoveUI когда мое приложение было почти закончено, я не мог их использовать, но они также могли помочь в создании более простой страницы для запуска.

Использование базы данных

Мое приложение используетсяMonetDB и позжеPostgreSQL, ПроизводительностьMonetDB было хорошо, но у меня был конфликт с несколькими пользователями (сложная проблема, которую я не могу здесь подробно описать), и это заставило меня перейти кPostgreSQL как альтернатива.PostgreSQL было хорошо, но потребовалось значительное время для запуска из-за проблемы с прогревом кеша. Конструкция, необходимая для загрузки загружаемых данных в БД: плохой дизайн.

СУБД задерживает возможные меры по смягчению

Я думаю, что я попробовал большинство трюков с переменным успехом.

Ограничить использование СУБД. Как я решил с самого начала использоватьdata.table чтобы ускорить манипуляции с данными без ограничений при копировании, я также использовалfread для любого типа чтения CSV. В это времяfwrite (еще изdata.table) даже не было на горизонте, иначе это стоило бы серьезных соображений.Редизайн приложения. архитектура приложения во многом зависит от степени интенсивности использования СУБД. Я убежден, что время может быть сэкономлено с помощью дизайна, который мог бы учитыватьR+shiny (в основномR) ограничения.СейчасMonetDB имеетR Функции встроены в код, поэтому он должен быть еще быстрее, чем раньше. Это, безусловно, заслуживает хорошего взгляда. С другой стороны, многопользовательские функции должны быть тщательно протестированы: большинствоR Код базы данных не учитывает использование в многопользовательской среде, как это предлагаетсяshiny, Может бытьRStudio должен делать что-то еще об этом. Честно говоря, они уже начали с экспериментального внедренияconnection pools и это здорово.

Чрезмерное использование реактивности

Я думаю, что здорово играть с такими продвинутыми фреймворками, какshinyи реактивность очень интересно учиться. С другой стороны, широкое и сложное применение может легко выйти из-под контроля.

Чрезмерная реактивность возможные смягчения

Отладка каждой функции дает точное представление о том, сколько раз конкретныйshiny функция вызывается, и любая реактивная функция вызывается обычно более одного раза. Конечно, все это сжигает процессорное время и требует, по крайней мере, держать его под контролем.Конструирует какobserveEvent теперь есть такие параметры, какignoreInitразумное использование этих параметров может сохранить как минимум цикл пустоты во время инициализации.

По моему опыту мы только поцарапали поверхность того, что можно сделать сshiny, С другой стороны, существует ограничение из-за единойR, СShiny Server Pro можно предусмотреть использование балансировщиков нагрузки и распределение нескольких пользователей на разных серверах. С другой стороны, чтобы попасть на эти территории, нам понадобится какая-то система обмена сообщениями между различными инстанциями. Уже знаю, что вижу необходимость в этом комплексеShiny Server Pro приложения (например, когда необходимо управлять различными классами пользователей, но в то же время осуществлять связь между ними). Но это выходит за рамки этого вопроса.

 Enzo29 нояб. 2017 г., 01:42
уверен: enzo в smartinsightsfromdata точка ком

Ваш ответ на вопрос