Два года назад сделал ставку 100$, что в течении 5-ти лет R обгонит Python по популярности и использованию. Спасибо за графики — пока R идет в нужным темпом :)
Как в любом функциональном интерпретируемом языке, скорость исполнения во львиной доле зависит от качества написания кода.
Но и сам язык не стоит на месте в этом вопросе: есть пакеты / сервисы, соторые специально созданы для поддержки действительно BigData, многопоточности и т.д.
Вы планируете описывать аналитику какого уровня? Только экспертного или будут материалы по статистическим методам классификации, построение стат. поведенческих моделей и т.д. Хочется заранее знать подписываться или нет :)
1. Накладность расходов в том, что при вызове bootstrap генерируется весь компонент ui.R, вы не можете инициализировать вызов по обращению, это специфика реализации в shiny. Если у вас большое приложение даже без сложной логики инициализации, можете просто замерить время между вызовом приложения и загрузкой UI.
Также не совсем понятно, зачем в shiny так сильно порезали функционал AdminLTE. Теоретически, конечно, добраться к нему можно, но через ненужные костыли. Например, попробуйте добавить header right sidebar, который по-умолчанию есть в AdminLTE.
О том, что можно подключать js, css никто не спорит, но это уже не реализация самого shiny.
Я не говорю, что это все не возможно, но реализовано или приходится решать через столько костылей, что возникает вопрос — а стоит ли? Особенно когда система уходит на прод и нужно обеспечить удаленный bug-fixing, распределенную разработку и т.д.
2. Поддержка протокола как таковая и реализация — две большие разницы, имхо. Реактивность shiny обеспечивает односторонний обзервер только ui. Вы видите возможность реализации стандартного паттерна Наблюдатель серверной части в shiny? Например, обновление счетчика и вызов пуш-уведомления при отправке сообщения другим пользователем? Т.е. сам объект, ивент и обсервер за ним полностью на стороне серверной части, а не в ui. Такая задача потребует инициализации нескольких промежуточных reactivalues контейнеров, и нескольких обзерверов для связки, но это костыль, который очень далек от паттерна.
На всякий случай повторюсь, я не говорю, что shiny плох, или его не нужно использовать вообще (у меня самого сейчас на поддержке несколько реализаций с shiny, которые поддерживаются go-live у внешних клиентов). Но с усложнением задачи и архитектуры приложения, все минусы shiny вылазят очень больно и возникает необходимость реализации других вариантов.
Было бы также полезно рассмотреть минусы связки R+Shiny, хотя, возможо, вы нашли свои work-around. На текущий момент основные проблемы берут корни в том, что Shiny является достаточно закрытой библиотекой в части управления backend'ом, соответственно это мешает сделать систему полноценной OLTP (я буду писать «невозможность», но это может быть «сложность», по которой у меня пока нет решения):
1. Невозможность полноценной реализации monopoly access
2. Невозможность реализации расширенной логики авторизации и поддержки ролевых моделей по RBAC
3. Проверка ролевой модели доступа должна быть явно реализована в каждой точке доступа
4. Невозможность реализации горизонтальной масштабируемости
5. Невозможность частичного апдейта back-front end, только через полный апдейт с операционной блокировкой сервера.
6. Однонаправленная транспортировка клиент/сервер по HTTP (невозможность реализации SingnalR или COMMET)
7. Невозможность разделения back|fromt end разработки
8. Тяжелая ресурсная стоимость UI-render Shiny пакета
9. Высокая сложность отладки, зависимость базовых механизмов (логирование, access management, управление представлениями и т.д.)
Реализация R+Shiny идеально подходит для систем, которые разработаны «под одного пользователя». Как только возникает необходимость обеспечить параллельную работу нескольких пользователей на одними и теми же данными — начинается хаос :(
ИМХО — R необходимо использовать для тех вещей, для которых он создан: статистическая backend логика, аналитика и big data; прочая бизнес-логика, UI и тд. должны быть реализованы на других платформах. Благо Micrisoft подарил свет в конце тоннеля внедрив поддержку R в .NET и MS SQL.
В случае если необходимо по тем или иным причинам уменьшить степень вариативности модели без ее структурного изменения, можно использовать регуляризацию, которая накладывает ограничения на параметры модели.
Ridge & Lasso Regression накладывает ограничения не для того, чтобы уменьшить «степень вариативности», а для того, что ввести штраф за мультиколлинеарность, которая является стоп-критерием для линейной регрессии. Т.е. штрафы борются с конкретной проблемой, если она существует в данных.
Как правило, Ridge & Lasso Regression дополняют компонентами отбора переменных на основании дополнительных критериев, которые позволяют исключить ряд мультиколлинеарных переменных, т.е. в итоге таки изменить структуру.
Но и сам язык не стоит на месте в этом вопросе: есть пакеты / сервисы, соторые специально созданы для поддержки действительно BigData, многопоточности и т.д.
Также не совсем понятно, зачем в shiny так сильно порезали функционал AdminLTE. Теоретически, конечно, добраться к нему можно, но через ненужные костыли. Например, попробуйте добавить header right sidebar, который по-умолчанию есть в AdminLTE.
О том, что можно подключать js, css никто не спорит, но это уже не реализация самого shiny.
Я не говорю, что это все не возможно, но реализовано или приходится решать через столько костылей, что возникает вопрос — а стоит ли? Особенно когда система уходит на прод и нужно обеспечить удаленный bug-fixing, распределенную разработку и т.д.
2. Поддержка протокола как таковая и реализация — две большие разницы, имхо. Реактивность shiny обеспечивает односторонний обзервер только ui. Вы видите возможность реализации стандартного паттерна Наблюдатель серверной части в shiny? Например, обновление счетчика и вызов пуш-уведомления при отправке сообщения другим пользователем? Т.е. сам объект, ивент и обсервер за ним полностью на стороне серверной части, а не в ui. Такая задача потребует инициализации нескольких промежуточных reactivalues контейнеров, и нескольких обзерверов для связки, но это костыль, который очень далек от паттерна.
На всякий случай повторюсь, я не говорю, что shiny плох, или его не нужно использовать вообще (у меня самого сейчас на поддержке несколько реализаций с shiny, которые поддерживаются go-live у внешних клиентов). Но с усложнением задачи и архитектуры приложения, все минусы shiny вылазят очень больно и возникает необходимость реализации других вариантов.
1. Невозможность полноценной реализации monopoly access
2. Невозможность реализации расширенной логики авторизации и поддержки ролевых моделей по RBAC
3. Проверка ролевой модели доступа должна быть явно реализована в каждой точке доступа
4. Невозможность реализации горизонтальной масштабируемости
5. Невозможность частичного апдейта back-front end, только через полный апдейт с операционной блокировкой сервера.
6. Однонаправленная транспортировка клиент/сервер по HTTP (невозможность реализации SingnalR или COMMET)
7. Невозможность разделения back|fromt end разработки
8. Тяжелая ресурсная стоимость UI-render Shiny пакета
9. Высокая сложность отладки, зависимость базовых механизмов (логирование, access management, управление представлениями и т.д.)
Реализация R+Shiny идеально подходит для систем, которые разработаны «под одного пользователя». Как только возникает необходимость обеспечить параллельную работу нескольких пользователей на одними и теми же данными — начинается хаос :(
ИМХО — R необходимо использовать для тех вещей, для которых он создан: статистическая backend логика, аналитика и big data; прочая бизнес-логика, UI и тд. должны быть реализованы на других платформах. Благо Micrisoft подарил свет в конце тоннеля внедрив поддержку R в .NET и MS SQL.
Ridge & Lasso Regression накладывает ограничения не для того, чтобы уменьшить «степень вариативности», а для того, что ввести штраф за мультиколлинеарность, которая является стоп-критерием для линейной регрессии. Т.е. штрафы борются с конкретной проблемой, если она существует в данных.
Как правило, Ridge & Lasso Regression дополняют компонентами отбора переменных на основании дополнительных критериев, которые позволяют исключить ряд мультиколлинеарных переменных, т.е. в итоге таки изменить структуру.