VN
Все верно… но это не значит что все за один раз и в один файл :)
Это значит что данные на первом слое должны совпадать с источником…
Это значит что данные на первом слое должны совпадать с источником…
Size: a a a
2021 July 05
IK
Т.е за один раз такого плана табличку с таким кол-вом строк загрузить будет проблемно-невозможно и остается только вариант загрузки ее только по частям? И далее использовать ее целиком тоже будет проблематично в отчетности?
EL
Ребят, не могу найти в QS настройки виуализции для моб устройств
В PBI явно можно прописывать
а в QS можно?
В PBI явно можно прописывать
а в QS можно?
VN
Безусловно… это теоретический порог движка в части количества значений…
Более того вам не нужна такая детализация для отчетности в одном приложении :)
Более того вам не нужна такая детализация для отчетности в одном приложении :)
IK
А вообще какой рекомендуемый объем ОЗУ для работы с такого рода таблицами если таких таблиц несколько и объем в них пока только за 1 год и постоянно растет?
МГ
Я тоже выступаю за загрузку предрасчетных данных, но руководство настаивает, что считать нужно в клике
Детализация нужна - но в четыре раза меньше (а по иным таблицам и в десятки раз). Для списочной отчётности.
Детализация нужна - но в четыре раза меньше (а по иным таблицам и в десятки раз). Для списочной отчётности.
VN
Здесь другие подходы к архитектуре и они в целом не связаны напрямую с ОЗУ… так как разные предметные области имеют разные структуры и особенности данных
VN
Я не говорил где надо предрассчитывать, я говорил о том что такая детализация не нужна в конечном приложении…
МГ
Нужна в конечном приложении
VN
Все таки боюсь вы ошибаетесь… и здесь в целом вопрос в том сколько должно быть приложений и с какой минимальной детализацией в каждом
IK
Это понятно что напрямую не связаны с ОЗУ, просто порядок Гб интересует при работе с такими объемами данных хотя бы ориентировочный, пока сказали 256Гб ОЗУ. Вот интересует вопрос хватит или мало и можно ли обойтись меньшим кол-вом?
AK
Ну зависит от вычислений, кол-ва пользователей
VN
Насколько широкие данные? Вообще жмётся хорошо, но есть затрату на каждого пользователя
ИШ
Нет такого
VN
Это вам к вендор - пусть считают разные сценарии
IK
Детальный лог за месяц-квартал например детализация максимальна объем тоже может быть большой, пользователей много особенно в отчетный период 01 числа например, 50-60 отчетов одновременно запущено сейчас бывает по БД.
VN
Я к тому что я плохо представляю человека, которому нужна минимальная детализация по всем разрезам… там либо по географии будет фильтрация либо по орг структуре
IK
Вопрос кто работал с такими объемами сколько ОЗУ обычно на сервере с qlik у вас? Просто цифра для понимания не более того? Например 10 юзеров активных - 128Гб макс, или 50юзеров активных-256Гб Озу...
ЕС
определенно вам нужно будет использовать ее с функционалом ODAG. Создать агрегированное представление данных как отдельный QVD, и догружать из детального QVD только данные, ограниченные выборкой
МГ
Тоже думали об этом, но архитектурно не подойдёт