Purely functional data something

[kika]

Имхо, довольно распространенная задача. Скажем у нас есть множество структур, описывающих некую жызненную ситуацию, скажем мониторинг хостов в сети. Структура содержит имя хоста, адрес, всякие прочие фактически иммутабельные параметры плюс некое количество изменяющихся параметров мониторинга, время пинга, скорость передачи данных, количество HTTP ошибок и теде и тепе. Структуры хранятся, допустим для простоты, в хеше по имени хоста. Все отлично, софтина работает, обмеряет хосты, апдейтит табличку с записями и жизнь прекрасна. Теперь нам надо сделать запросы снаружи - типа а покажи-ка мне список хостов, отсортированных по пингу. Допустим, хостов у нас ровно один газиллион, поэтому сортировать на каждый запрос накладно.
В традиционной культуре мы строим сбалансированные деревья с указателями на структуры (а в структурах указатели на деревья) и организуем синхронное плавание.
А как в функциональной культуре решается такая задача? Pointer trickery тут какбе немного недоступна.

Вкратце: есть структура -record(host, {host_id, speed = 0}). и из нее ETS таблица из одного газиллиона записей. Надо быстро отдавать список хостов, отсортированный по speed. Можно наверное положить это в Мнезию и понадеяться на ее ORDER BY, а если без Мнезии, ручками?

Comments

[kika.livejournal.com]

Ну да знаю. Раскручиваемся с нуля, у всех предыдущая скорость - ноль.

[jsn.livejournal.com]

это же всё никакого отношения не имеет к pure functional, те же проблемы с любым balanced tree у тебя? ну держи нули в отдельном листе, я не знаю? :) или, там, compound key придумай какой?

[109.livejournal.com]

да, правильное решение - composite key (speed, host_id). неуникальные индексы у всех нормальных баз так и устроены (clustered key неявно хранится не только в листьях, но и ветках).

[jsn.livejournal.com]

...а, ну да, no reverse link. ну не знаю.