Temat: R w tle jako unixowy demon?

Ktoś z was stosował może takie rozwiązanie? Czy to w ogóle jest możliwe?

Mam skrypcik oparty na jednej nieskończonej pętli, który cały czas monitoruje pewną bazę danych i kiedy znajdzie w niej coś dla siebie, wykonuje odpowiednie obliczenia po czym zwraca wyniki. Na razie działa na konsoli, ale myślałem nad bardziej eleganckim rozwiązaniem pt. demon i odpowiedni wpis w /etc/init.d. Co o tym sądzicie?
Michał Bojanowski

Michał Bojanowski socjolog, analityk

Temat: R w tle jako unixowy demon?

Podobny temat pojawiał się swego czasu na Rhelp czy Rdevel. Teraz nie byłem w stanie wykopać tych wątków, ale może tobie się uda.

Do tej pory wystarczały rozwiązania zapewne podobne do twojego ("nasłuch" pipe/socket/stdin itd.).

Nie wiem czy ktoś już coś takiego jak R daemon napisał. Jak ktoś z tego forum znajdzie, to niech się tu pochwali. Jeżeli jeszcze coś takiego nie istnieje, to może ty będziesz pierwszy. :) Jest Rowy serwer TCP/IP (http://www.rforge.net/Rserve/), może to dobra inspiracja. Jak programujesz w C[++] to http://developer.r-project.org/embedded.html też się może przydać.
Wojciech Sobala

Wojciech Sobala Redaktor
statystyczny,
biostatystyk,
Instytut Medycyny
Pr...

Temat: R w tle jako unixowy demon?

Może cron. Cron przeszukuje pliki "crontab" (plik-tabela).

Wpisy w plikach crontab zbudowane są z 6 pól. Pierwsze 5 pól określa czas wykonania, natomiast 6 pole czynność.

Znaczenie pól:
- Minuta (zakres 0-59)
- Godzina (zakres 0-23)
- Dzień (zakres 0-31)
- Miesiąc (zakres 0-12 lub nazwa, pierwsze 3 litery nazwy angielskiej)
- Dzień_Tygodnia (zakres 0-7 lub nazwa, pierwsze 3 litery nazwy angielskiej)
- Polecenie (reszta linii)

Pole może mieć gwiazdkę (*), czyli wykonuj zawsze.

Dozwolone są zakresy liczb. Zakresy są dwiema liczbami, oddzielonymi myślnikiem. Zakres ten jest domknięty.
np. 8-11 dla godzin oznacza wywoływanie w godzinach 8, 9, 10, 11.

Dozwolone są też listy. Lista jest zbiorem liczb (lub zakresów), oddzielonych przecinkami.
np. 1,2,5,9 albo 0-4,8-12
mozna równiez dzielić okresy czasu... np. */2 - wykonanie co 2 jednostki czasu

Przykładowy wpis w crontab:

*/2 * * * * echo "ten napis pojawia sie w pliku cos.txt co 2 minuty" >> cos.txt

Temat: R w tle jako unixowy demon?

Myślałem już nad Cronem ale problem polega na tym, że wszystko odbywa się w czasie rzeczywistym - często liczą się ułamki sekund.
Wojciech Sobala

Wojciech Sobala Redaktor
statystyczny,
biostatystyk,
Instytut Medycyny
Pr...

Temat: R w tle jako unixowy demon?

Paweł Sopel:
Myślałem już nad Cronem ale problem polega na tym, że wszystko odbywa się w czasie rzeczywistym - często liczą się ułamki sekund.

Przypuszczam, że nie masz bezpośredniego dostępu do bazy danych bo wtedy najłatwiej byłoby zapewnić obsługę pewnych zdarzeń.

Tak dla kompletności listy serwerów opartych na R to jest jeszcze: http://rapache.net/.Wojciech Sobala edytował(a) ten post dnia 21.02.11 o godzinie 08:10

Temat: R w tle jako unixowy demon?

Mam bezpośredni dostęp do bazy danych. Baza jest w SQLite, ale myślę nad przeniesieniem się na Postgresa. Myślisz o rozwiązaniu opartym o triggery?

Temat: R w tle jako unixowy demon?

Gdyby to był Windows, można by napisać usługę w .NETcie, która monitoruje zmiany w bazie za pomocą specjalnego powiadomienia (np. MS SQL Express, Oracle) i łączy się przez (D)COM z R, wykonując żądane obliczenia. W ten sposób implementowałem właśnie coś takiego.

Być może coś takiego dałoby się zaprogramować pod Linuksem w C++/Javie (np. dla darmowego Oracle XE lub innej darmowej bazy, która wspiera takie powiadamianie i pozwala się do niego "podpiąć" z kodu) i komunikować się z R przez TCP/IP czy jakimiś innymi kanałami.

Może tutaj coś?
http://stackoverflow.com/questions/1396632/asynchronou...Adrian Olszewski edytował(a) ten post dnia 21.02.11 o godzinie 12:44
Michał Bojanowski

Michał Bojanowski socjolog, analityk

Temat: R w tle jako unixowy demon?

Paweł Sopel:
Mam bezpośredni dostęp do bazy danych. Baza jest w SQLite, ale myślę nad przeniesieniem się na Postgresa. Myślisz o rozwiązaniu opartym o triggery?

Nie znam postgresa, ale np. w mysql chyba jedynym sposobem żeby trigger uruchamiał coś na zewnątrz bazy (np eRowy skrypt) jest napisanie własnego UDFa. Inna sprawa, że nie jest to specjalnie bezpieczne rozwiązanie. Jeżeli jest jakiś inny sposób, to chętnie go poznam.

Obejrzyj sobie Rserve. Pod linuxem domyślnie pracuje w "daemon mode". A pakiet zawiera kod przykładowych klientów w java, C, C++. Może można napisać programik w np C++, który kiedy dostanie powiadomienie z bazy (lub będzie ją monitorował w jakiś sposób) uruchomi odpowiednie procedury na Rserve.
Michał Bojanowski

Michał Bojanowski socjolog, analityk

Temat: R w tle jako unixowy demon?

Adrian Olszewski:
Może tutaj coś?
http://stackoverflow.com/questions/1396632/asynchronou...Adrian Olszewski edytował(a) ten post dnia 21.02.11 o godzinie 12:44


Dzięki, świetne linki.
Wojciech Sobala

Wojciech Sobala Redaktor
statystyczny,
biostatystyk,
Instytut Medycyny
Pr...

Temat: R w tle jako unixowy demon?

Tak myślałem o trigerach. SQLite od kilku wersji też je obsługuje. Postgres może mieć pewną zaletę bo obsługuje funkcje napisane w R (http://www.postgresonline.com/journal/archives/188-plr....

Temat: R w tle jako unixowy demon?

Ogólniejszy mechanizm, jeśli danych nie jest dużo, a nie chcemy z bazy wywoływać żadnego "third party" kodu, czy poleceń systemowych. W triggerze (ale ostrzegam, że przy częstym wstawianiu danych i ich updacie triggery mogą znacznie spowolnić te operacje, zależnie od tego, co w nich będzie wykonywane!) generujemy plik z danymi (chyba wszystkie bazy pozwalają pisać do wybranego katalogu, w formacie np. CSV) o unikalnej nazwie. Następnie albo implementujemy skrypt, który monitoruje nam filesystem, albo korzystamy z gotowych rozwiązań tutaj lub tutaj, albo piszemy własne w oparciu np. na platformę MONO (.NET dla systemów *ksowych), gdzie mamy klasę FileSystemWatcher, która pozwala monitorować wybrany katalog(i). Jak wpadną dane, zostanie wywołany R (jakimś kanałem) z poleceniem ich przeanalizowania.

Wady: dodatkowe "warstwy", które położą rozwiązanie przy dużych ilościach danych, a dodatkowo nie pozwalają na prawdziwy "real time processing". RDBMS -> plik -> FSwatcher (MONO) -> R (wczytanie danych z pliku, bądź komunikacja na poziomie serwera TCP/IP czy wreszcie bezpośrednia komunikacja w C). Trzeba też obsłużyć "kolejkę" danych, bo przecież baza może "pluć" plikami z danymi równolegle z tym, jak R będzie je kolejno przetwarzał.

Zalety: dodatkowe warstwy :) Innymi słowy oddzielenie dostawcy danych od systemu analitycznego dzięki serwisowi, który monitoruje FS i wywołuje odpowiednie polecenia danego pakietu statystycznego. W każdej chwili można wymienić bazę, która w dodatku nie musi się umieć komunikować z R, a także R zastąpić innym systemem. No i nie musimy w R instalować jakichś "cudów". Czasem taka izolacja warstwami to wysoce pożądana cecha. Czasem zaś wydajność jest kluczem za cenę ścisłej integracji.

O tym, czy to wada, czy zaleta, zdecyduje konkretne zastosowanie.

Już teraz widzimy, że coś nam nie gra - z jednej strony potrzebujemy jak najszybszego przetwarzania, a z drugiej... 'dowalamy' triggery. Taki trigger albo musi połączyć się z R (a nawiązanie połączenia może potrwać) czy też wywołać sam R z parametrami (co też potrwa), albo zrzucić nowe dane do pliku. Trzeba sobie odpowiedzieć na pytanie - jak częste będą operacje zapisu do bazy danych, jak dużo będzie tych danych, jak szybko musimy otrzymać wyniki.

Kto wie, czy nie szybciej będzie z poziomu bazy wywołać jakąś gotową bibliotekę do np. algebry liniowej optymalizacji, jeśli potrzebujemy np. PCA, SVM, LDA.....Adrian Olszewski edytował(a) ten post dnia 22.02.11 o godzinie 13:42

Następna dyskusja:

Regresja logistyczna jako k...




Wyślij zaproszenie do