Purely functional data something

[kika]

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

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

Comments

[kika.livejournal.com]

Да, реально задача отдать topN, где N произвольное, но заранее заданное число. С "нормальной базой" есть одна проблема - на нее нет вычислительного ресурса. Предмет обсуждения - это телеком appliance, живущий в 2U корпусе и чисто конкретно нагруженный своей работой, за которую ему денег платят. Если с процессором там более-менее (пока) свободно, то с памятью полный швах, хотя технически ее от 12Гб в entry level.

[109.livejournal.com]

define "полный швах" :)

вообще, sql server (нормальный, а не компакт) может нормально жить в довольно-таки тесных помещениях - например, 100 мегабайт памяти на всё про всё. зависит от задачи, конечно. rule of thumb is - если all non-leaf index pages влезают в память, то всё в порядке. сравни с самописным решением: в памяти надо держать индексы целиком, а не только их non-leaf части.

также: обязательно ли сервер базы должен бежать на том же самом ящике? round trip через один хоп - это тоже sub-millisecond.

[kika.livejournal.com]

второй ящик - это минимум 2000 долларов на железо, плюс support costs. А полный швах - это буквально, вся доступная память занята приложением, которое готово съесть сколько дадуд. Плюс еще есть проблема с диском - дисковая подсистема заметно busy трафиком от приложения, часто iowait в районе 40-60%. В общем плохо там будет любому сиквелу, кроме разве что sqlite :-)

[109.livejournal.com]

а чем sqlite такой волшебный?

вообще, конечно, если доступаться до базы должен только один процесс с одной машины, то embedded engines лучше.

[kika.livejournal.com]

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