Сайзинг для QlikView и Qlik Sense

• Насколько требования к оборудованию и ПО для решения QlikView выше/ниже требований предъявляемых к уже существующим у нас системам?
• Как можно сэкономить на оборудовании, приобретя минимальные наборы оборудования?
• Как можно посчитать спецификацию на проект уже сейчас, чтобы правильно обосновать и утвердить бюджет на год вперед?
• А можно ли наши большие объемы данных анализировать в QlikView?
• Какая головная боль в плане инфраструктуры нам предстоит «в целом»?
• Как можно сэкономить на лицензиях, приобретя минимальные наборы лицензий QlikView?

1. Не абстрактные объемы хранящихся/накапливаемых в организации данных, а характеристики данных в конкретном приложении(ях) QlikView (Qlik Sense).
2. Не просто расчетные математические формулы, а способы их применения в приложении QlikView (использование их в конкретных объектах визуализации). Также важны и конкретные выбранные разработчиком способы расчетов, например, использование конструкций If(… Sum()) или конструкций анализа множеств (set analysis).
3. Наличие заказных расширений Extensions (объектов визуализации или бизнес-логики, разработанных под конкретного заказчика).
4. Информация о количестве пользователей которые будут использовать разрабатываемое приложение QlikView. Также необходимо понимать роли этих пользователей, и то, как они будут работать с приложениями. И только на основе этой информации моожно будет предоставить обоснованные рекомендации по количеству и типу лицензий QlikView (Qlik Sense) для пользователей и серверов.
5. Принятые в организации нормативы/требования к безопасности/отказоустойчивости, а также разработке, тестированию и публикации приложений.

Важно понимать, что четкие рекомендации по основным параметрам сайзинга, можно расчитать только опираясь на характеристики конкретного прототипа приложения: Производительность и количество процессоров (CPU), Объем требуемой оперативной памяти (RAM), Количество серверов и тип узлов кластера.

1. Объема данных единовременно загружаемых в оперативную память и анализируемых пользователями. При этом у архитектора QlikView всегда есть степень свободы по загрузке всего объема или требуемой его части. В зависимости от выбранной стратегии может потребоваться либо более мощное оборудование «железо», либо в случае использования нескольких серверов или создания цепочечных приложений — большее количество лицензий QlikView.
2. Выбранной модели данных. Здесь надо отметить, что ассоциативная модель данных Qlik это не реляционная модель, это инструмент для пользователя, а не для разработчика приложения. Исходя из этого, компетентный архитектор обычно использует несколько моделей для решения различных задач пользователя. Более того, в процессе эксплуатации может потребоваться переход от одной модели к другой, что упростит и повысит степень гибкости работы пользователя, но может потребовать дополнительного объема оперативной памяти.
3. Количества полей в модели данных. Очевидно, что большее количество полей потребует большего объема оперативной памяти.
4. Выбранных сценариев работы с данными. Если пользователь использует многопараметрический сравнительный анализ, то памяти будет расходоваться больше по сравнению с тем, если бы пользователь работал в терминах классической отчетности.
5. Специфики конкретных наборов данных. Дело в том, что алгоритм компрессии данных платформы Qlik основан на хранении только уникальных значений данных, встречающихся в полях модели данных. Поэтому эффективность сжатия данных в оперативной памяти  будет существенно зависеть от степени повторяемости загруженных данных. Обычно коэффициент сжатия варьируется в пределах 4–6, но может достигать и 10. Хотя на некоторых наборах данных может не достигать и 2.
6. Степени гибкости сценариев анализа, предоставляемых пользователю. Как правило всегда большая степень гибкости будет требовать большего объема оперативной памяти.
7. Используемого количества и сложности объектов визуализации данных. Большее количество объектов визуализации единовременно отображаемых на экране, требует большего количества оперативной памяти.
8. Количества пользователей, одновременно работающих с приложением. Для каждого пользователя, работающего с приложением резервируется объем оперативной памяти, в котором хранится состояние выборок данных, сделанных пользователем. 

1. Объема данных, анализируемых пользователем.
2. Выбранной модели данных.
3. Количества полей в модели данных.
4. Сложности и количества вычислений, выполняемых на этапах загрузки данных и на этапе работы с приложением конечными пользователями.
5. Количества пользователей работающих с приложением.
6. Возможности кэширования вычислений, выполняемых QlikView. Возможность и степень кэширования зависит от объема оперативной памяти, доступной для кэширования расчетов пользователей. Также эффективность работы кэша зависит от поведения конечных пользователей, т.е. от количества повторных обращений к одним и тем же наборам данных со стороны пользователей.
7. Степени гибкости сценариев анализа, предоставляемых пользователю.
8. Используемого количества и сложности объектов визуализации данных. Большее количество объектов визуализации единовременно отображаемых на экране, требует большего количества оперативной памяти.
9. Выбранная модель безопасности данных, и ряд других характеристик приложения также существенно влияют на объем вычислений, необходимых для обработки процессорами сервера.

1. Существующих стандартов на использование оборудования у заказчика и существующих требований по быстродействию. Т.к. QlikView легко масштабируется, то в зависимости от выбранной стратегии масштабирования, можно увеличивать производительность индивидуальных серверов (Scale-Up), увеличивать количество серверов (Scale-Out) или использовать оба способа одновременно. Например, даже при работе с большими объемами данных, как правило, всегда есть альтернатива одному большому и дорогому серверу. В частности, архитектор имеет возможность разделения приложения на несколько приложений, выполняемых на отдельных, сравнительно недорогих по аппаратному оснащению серверах.
2. Существующих требований к отказоустойчивости решения. Очевидно, что больший уровень отказоустойчивости может потребовать создания кластера серверов QlikView. Кластеризация в свою очередь может быть использована на различных архитектурных уровнях решения: кластеризация на уровне загрузки данных, кластеризация на  уровне обслуживания пользователей, кластеризация веб-сервисов. Возможно использование и любых комбинаций этих кластеров.
3. Существующие требования в плане управления версиями и надежностью решения могут потребовать создания выделенных зон разработки и тестирования приложений перед переносом их в среду эксплуатации. Организация таких зон тестирования и разработки может потребовать использования дополнительных серверов (и серверных лицензий QlikView).
4. Выбранная модель безопасности данных, требуемые направления масштабирования (загрузка данных или обслуживание конечных пользователей), а также ряд других характеристик решения также могут существенно влиять  на количество серверов в составе решения.