1. Я про рилтайм вообще ни слова не сказал. Прошу не приписывать, то чего не говорилось.
2. На счёт инмемори и ассоциативной модели, я же не предлагаю от неё отказаться,  просто предлагаю дать возможность разработчику тюнить модель, позволяя держать колонки для расчёта некоторых мер в ужатом виде на диске: там ассоциативка не особо нужна ибо айдишникм там все равно хешированные и полезной информации кроме своей уникальности не несут.
3. Возможно вероятностные методы на основе блюм фильтров могут решить проблему. Но пользователи зачастую пока не готовы к вероятостным алгоритмам.
4. Почему предложение сделать фичу (не обязательно в том же виде,  в п. 2 и 3 уже в иную бд лазить не нужно), вызывает такой негатив? Это предложение к улучшению хорошей платформы, а не призыв перейти на другую.
5. Держим пальчики за qbdi 😊 .
6. Кейс вполне конкретный в геоаналитике при выборке пересчитывать уникальные айдишники (бизнес просит). Но это на постоянной основе сжирает большой объем оперативы, хотя для целей ассоциативки сам столбец не требуется.
7. У меня все 😁

Я знаю, у меня был проект биг да а уровня небольшой целом страны в ЕС, там базовое клик приложение имело 15 млрд строк в фактах. На этом же проекте был и лайв мониторинг, но именно мониторинг, два контура. В первом юзер мониторит определенных набор показателей, например средний битрейт стриминг видео сейчас, и подобные метрики quality of service. Но вот если что-то не так, то уже шёл в клик и искал, что же там не так, почему где-то что-то поломалось. Это уже все было на клике, так как данные тянулись из логово стопицот систем и баз данных и тп. Кроме того, я знаком с запросами на тему лайв коннекта, прямых запросов в бд, но это все частные кейсы. Опять же вопрос, лайв коннект для анализа данных? Что пользователь будет анализировать в связанном виде? Отдельные отчеты и отдельные метрики? Так получается он не анализирует, а снимает показатели.

Аналогично, бигдата уровня страны и десятка два миллиарда строк

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

1. Это пример подходящий по смыслу. Задача, которая лежит вне фокуса платформы.

И негатива на фичу нет, вы просто дополнили запрос фичи ссылкой на "конкурентов у которых это есть". На что вам также подсказали, что этот функционал не имеет ключевой значимости для задач, под которые заточен Qlik

А базовое 15 млрдное приложение потом байнари лоадом через одагом дёргается?

В тот момент там был QlikView, сенс был параллельно, базовое приложение использовали 400 юзеров, и оно было хитро сделано, отключены все табу, то есть листы, переходы между ними по кнопкам, сами фильтры на кнопки также помещены, то есть юзер не может просто так войти и накликать в фильтрах чего угодно, плюс делался прогрев приложения после перезагрузки.

Зачет👍

А я тут как раз думал о варианте анализа больших данных в Qlik Sense Без выделения супер-компьютера под это, и без сверх-мощного DWH бэкграунда. Давайте обсудим) https://www.youtube.com/watch?v=O8AGS3I5xO0

А текстом есть такое?

неа

Ты предлагаешь сканировать qvd и на них накладывать dynamic views?

не знаю) посмотри

А mpp будет?

Так то раскладывая в отдельный qvd продажи одного месяца - шардирование )

Ну как я и предположил, скан qvd и динамик вьюс. Полностью поддерживаю концепцию.

Погоди, ты как-то напрямую сразу из qvd находясь в дешборде считываешь ?

ты про что?

Да я тут запутался похоже в мультитаскинге))

Посмотрел видео - разница такого подхода и ODAG только в удобстве? Основная логика как я понял одинаковая - пользователю дают только кусочек данных который ему нужен.