EL
Коллеги, добрый день еще раз. Вслед за вопросом об экстрактах появился вопрос о производительности на стороне Tableau Server. У нас есть очень объемный экстракт, который делается из вьюхи в GreenPlum и на стороне Табло к нему джоинится еще несколько справочников. В результате получается простыня в 50 млн строк со множество столбцов. Экстракт этой простыни весит 4 Гб. На основании этой простыни делается табличный дэш, в котором отображается несколько показателей по несокльким аналитикам, а остальные аналитики (порядка 20 шт) вынесены в панель фильтров. Если мы все это дело крутим в дектоп версии, установленной на серверной машине, то все работает сносно. При этом, экстракт лежит отдельным hyper-файлом. А вот когда мы ту же историю закидываем на сервер и пытаемся открыть его под каким-нибудь пользователем из-под веба, то все жестко висит. Невыносимо жестко)
Мы уже провели аналитическую работу и смотрели на несколько возможных причин:
1) Виртуальный/физический сервер - в нашем случае сервер виртуальный, но на нем выделено ядер в 2 раза больше, чем требуется для физического, что в целом должно показывать одинаковую производительность
2) Процессы на табло сервере показывают абсолютно бОльшую загрузку процессом run-vizqlserver. Порядка 40% всей загрузки ОП. В сети говорят, что это тоже в порядке вещей, что этот процесс является самым прожорливым в плане памяти
3) Протестировали разницу в работе книг со встроенным экстрактом и книг, ссылающихся на экстракт в отдельном файле - разницы не заметили
4) Сейчас тестируем экстракт вида multiple tables - но ввиду ограничений для реализации такого подхода (джоины только "=", невозможность использования UserFilter, невозможность инкрементального обновления), то его мы использовать в дальнейшем не сможем, сейчас тестируем просто на предмет проверки гипотезы об увеличении производительности при таком подходе к экстрактам
5) Есть гипотеза о том, что сильное торможение при работе с веб-версией связано с тем, что для каждлго пользователя, который заходит в этот дэш, подгружаются все данные таблицы (50 млн строк), что и сказывается на быстродействии (его отсутствии).
Есть ли у вас дополнения/инсайты по тому, как заставить нашу модель работать на сервере через веб? Буду крайне признателен за любую помощь!
Мы уже провели аналитическую работу и смотрели на несколько возможных причин:
1) Виртуальный/физический сервер - в нашем случае сервер виртуальный, но на нем выделено ядер в 2 раза больше, чем требуется для физического, что в целом должно показывать одинаковую производительность
2) Процессы на табло сервере показывают абсолютно бОльшую загрузку процессом run-vizqlserver. Порядка 40% всей загрузки ОП. В сети говорят, что это тоже в порядке вещей, что этот процесс является самым прожорливым в плане памяти
3) Протестировали разницу в работе книг со встроенным экстрактом и книг, ссылающихся на экстракт в отдельном файле - разницы не заметили
4) Сейчас тестируем экстракт вида multiple tables - но ввиду ограничений для реализации такого подхода (джоины только "=", невозможность использования UserFilter, невозможность инкрементального обновления), то его мы использовать в дальнейшем не сможем, сейчас тестируем просто на предмет проверки гипотезы об увеличении производительности при таком подходе к экстрактам
5) Есть гипотеза о том, что сильное торможение при работе с веб-версией связано с тем, что для каждлго пользователя, который заходит в этот дэш, подгружаются все данные таблицы (50 млн строк), что и сказывается на быстродействии (его отсутствии).
Есть ли у вас дополнения/инсайты по тому, как заставить нашу модель работать на сервере через веб? Буду крайне признателен за любую помощь!
Я бы рассмотрел модель публикации этого источника на сервер и показал как пользователи могут сами отвечать на вопросы используя фильтры, графики