а за счет чего достигалась скорость?

А нет, я обманываю. Там вместе с BLOB

Не полная обработка массива данных. Распределение нагрузки по времени

Например - Разносить по партиям можно после транзакции которая создает движение. Если этого нет то пересчитывать по ночам можно не все а кусочек последний

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

да не, у меня работало то что я делал на 16Гб ОЗУ, 4 проца Xeon 2007 года сервер

Данных там было правда не много - около 500 чеков в день

4 проца - это 4 физических процессора, по 4 ядра в каждом. Тогда не было на них еще технологии с волшебным псевдо-удвоением ядер. Работало все это на Linux

Ну да, 500 чеков норм должно быть.

100 тыс чеков уже хуже

)) это надо делать после каждого чека обработку без блокировки записей, за ночь не посчитается уже я думаю

почему таки вопросы - потому что клик ентерпрайз достаточно  дорогой сам по себе, он для крупных компаний, где поток данных может быть очень большой.

и я знаю, что топ-ритейлеры используют решения на клике-таки.

используют, и считают не в Qlik такие вещи как FIFO

да, понимаю. как я понял, проблема с ним в сложности алгоритма, который плохо ложится на sql

у нас в одной из систем что на MSSQL эта задача решалась двумя доп таблицам:
1. Таблица с остатками в разрезе партий "на сейчас"
2. Таблица со списанием где указано какой расход откуда  списал, какой приход куда добавил

Была написана ХП которая при движении товара создает или меняет записи в этих двух таблицах. Было много нюансов, но в целом полнота данных соблюдалась. Тупо повесили эту ХП триггерами на таблицы с проводками и все

если меняет записи то это да, не про клик.

в другой системе где 500 чеков в день. Ежемесячное закрытие периода было. Там 1 месяц считался по партиям примерно часа 4-5

Ну ясно. Вообще я ярый противник бизнес-логики на триггерах. Приходилось разгребать чудовищные системы.

Да, но там система была закрытая. Доработки стоили очень дорого