Спасибо за описание решения.
Но есть дополнительный интерес: «Встречалась ли необходимости в использовании стандартов WBEM или о них в практике ни слуху ни духу?»
Если кто не в курсе WBEM развивается как развитие и замена snmp и других протоколов управления и мониторинга.
Вершины можно считать справа-налево сверху вниз. Аналогично рациональным дробям, которых счетное количество. Если непонятно вечером рисунком подкреплю.
Отрезок не дает представления о структуре и связи между несчетным множеством и счетным. Дерево же в одной «фигуре» сочетает счетное число уровней и несчетное число путей.
>Правда, оба эти представления хорошо подходят для конечных, счетных и континуальных множеств, а все остальные — увы, за бортом.
Сразу три :) уже не мало.
Если же говорить о любопытстве, то кроме множеств с дробным кардинальным числом, неплохо было бы иметь средства для представления множеств с кардинальным числом больше единицы.
По мне, так дерево лучше чем ничего. Натуральный ряд можно представить (визуализировать) в виде ряда «с одной степенью свободы» (начинается сверху и растет вниз). Дерево позволяет использовать аналогичную же фразу (начинается сверху и выросло вниз) для континуального множества. Хоть какая-то конкретика.
>При моих объемах она росла на гигабайт в 4 часа.
Росла?
А можно ли поподробнее?
Какая там СУБД? Использовался/используется что-нибудь для анализа таких объемов данных? OLAP — какой нибудь?
Количество серверов, метрик, период опроса?
Да, пожалуй. Но чтобы оценить возможную «поражающую силу» удобно простую рекурсию задействовать. А это даже компилировать как-то боязно.:) Хотя не — вылетела по памяти как и остальные.
Думаю получится тоже самое — компилятуру не хватит памяти. Весь ресур экспоненциальной функции не выбран — до 263 инстанциорванных функций ещё далеко. Да и кода там побольше будет. Хотя если у Вас получится — с удовольствием полюбопытствую. ;)
Безусловно они хорошо сжимаются. Там большое количество операций add(addsd, addq ...) или nop для первого раздела. Bzip сжал самый большой бинарник c 53MB до 6.6.
Но есть дополнительный интерес: «Встречалась ли необходимости в использовании стандартов WBEM или о них в практике ни слуху ни духу?»
Если кто не в курсе WBEM развивается как развитие и замена snmp и других протоколов управления и мониторинга.
>Правда, оба эти представления хорошо подходят для конечных, счетных и континуальных множеств, а все остальные — увы, за бортом.
Сразу три :) уже не мало.
Если же говорить о любопытстве, то кроме множеств с дробным кардинальным числом, неплохо было бы иметь средства для представления множеств с кардинальным числом больше единицы.
Росла?
А можно ли поподробнее?
Какая там СУБД? Использовался/используется что-нибудь для анализа таких объемов данных? OLAP — какой нибудь?
Количество серверов, метрик, период опроса?
g++ и icpc выдали одинаковый размер в 783MB
clang++ — засегфолтился.
Суммарный рамер массивов — (10240*8*10000)/(1024*1024) == 781MB.
400МБ — наверное, для 32-битной машины.
Вот здесь пример брал