KOHA OD STRONY INFORMATYCZNEJ I UŻYTKOWEJ. PODSTAWOWE ZAGADNIENIA ZWIĄZANE Z SYSTEMEM. Jacek Ablewicz Rafał Kopaczka

Transkrypt

1

2 KOHA OD STRONY INFORMATYCZNEJ I UŻYTKOWEJ. PODSTAWOWE ZAGADNIENIA ZWIĄZANE Z SYSTEMEM. Jacek Ablewicz Rafał Kopaczka

3 PODSTAWOWE INFORMACJE Architektura: klient-serwer; Wewnętrzny format rekordów bibliograficznych i KHW: MARC (MARC21/.../MARC XML); rekordy egzemplarzy zasobów przechowywane odrębnie, w bazie danych, i w miarę potrzeb podlegające serializacji w locie przy wymianie, imporcie czy eksporcie danych; Interfejs użytkownika: przeglądarka WWW jako podstawowy (w zasadzie jedyny) sposób dostępu zarówno dla użytkownika jak i dla bibliotekarza; Wszystkie programowe komponenty samego systemu bibliotecznego (jak również wszystko to, czego typowo wymaga on do funkcjonowania w praktyce) oparte są na licencjach darmowych i/lub open-source (GPL 2/3, BSD, MIT, apache 2.0, Creative Commons itp.);

4 WYMAGANIA PROGRAMOWE (SERWER) System operacyjny: Unix; w praktyce: Linux, zwykle: Debian albo Ubuntu LTS (najpopularniejsze i najprostsze rozwiązanie pod względem łatwości instalacji i dalszego utrzymywania); Perl w wersji 5.10 lub wyższej + mnóstwo rozmaitych modułów perla 3rd-party (z CPAN); Serwer WWW (Apache, Ngnx, ), z CGI / fastcgi; RDBMS (baza danych): MySQL 5.5+ (ew. MariaDB); IndexData Zebra + YAZ Toolkit (jako silnik wyszukiwawczy oraz opcjonalnie serwer Z39.50); Nie musi to być osobny serwer (wirtualny czy fizyczny, ani dedykowany wyłącznie albo przede wszystkim pod system biblioteczny), ale...

5 TYPOWA ARCHITEKTURA SYSTEMU KOHA (W ZARYSIE)

6 WYMAGANE MODUŁY PERL CPAN (DLA KOHA 3.17.X)

7 WYMAGANIA SPRZĘTOWE (SERWER) Platforma sprzętowa: w teorii, brak ściśle określonych wymagań pod tym względem (= wszystko, na czym działa Linux i daje się skompilować perl i zebra), ale na co bardziej egzotycznych platformach niewykluczone pewne komplikacje, m.in. z modułami perla z CPAN w wariancie XS tj. kompilowalnych z języka C; Wyjściowe (teoretyczne) wymagania serwera Koha co do wydajności, ilości pamięci RAM itp. są raczej minimalne (ale...); W praktyce: wymagania mocno uzależnione od ilości zbiorów, użytkowników oraz charakteru biblioteki (w szczególności dla bibliotek akademickich, w których obciążenie systemu przez 2-3 miesiące w roku może być o rząd wielkości większe niż średnia z całego roku);

8 SERWER (WYMAGANIA), PRZYKŁADOWA KONFIGURACJA Biblioteka PK około 130 tys. opisów, 90 tys. rekordów KHW, 300 tys. rekordów egzemplarzy, 30 tys. rekordów użytkowników (aktywnych około 40-50%); Aktualny rozmiar danych po migracji baza MySQL: około 2.5GB (+ 1GB pliki ib_logfile* InnoDB); spodziewany przyrost rzędu 0.5-1GB rocznie (zależnie od tego jakie, i jak daleko wstecz zamierzamy przechowywać dane archiwalne); indeksy zebry: 4.5GB; Minimalna rozsądna (= w rozumieniu: taka na jakiej dałoby się pracować, ale mało komfortowo w okresie wzmożonego ruchu) konfiguracja: 24-32GB RAM; procesor[y]: 6-8 rdzeni, 2.0+ GHz; W miarę komfortowa / optymalna konfiguracja (z pewnym nieprzesadnie wielkim zapasem na przyszłość ): 48-64GB RAM, CPU 8-10 rdzeni / 2x 4-6 rdzeni, 2.4+ GHz; kontroler dysków z własną, podtrzymywaną bateryjnie pamięcią cache 1GB+ (i/lub dyski SSD);

9 SKALOWALNOŚĆ KOHA Stosunkowo duża (= przynajmniej do pewnego momentu); istnieją instalacje Koha obsługujące w wersjach produkcyjnych setki tysięcy/miliony opisów, dziesiątki/setki tysięcy użytkowników, setki tysięcy/miliony transakcji udostępniania rocznie. Ale: Słaby punkt #1: silnik wyszukiwawczy Zebra w miarę nieźle się skaluje do granicy paru milionów rekordów; powyżej tej ilości pojawiają się komplikacje (m.in. przy modyfikacji indeksów w locie ). Możliwości zrównoleglania operacji w Zebrze są mocno ograniczone (obciążenie da się rozkładać na 2+ serwery Zebra, ale samych atomicznych operacji wyszukiwania itp. nie da się zrównoleglić); Słaby punkt #2: MySQL to obecnie jedyna baza danych z jaką Koha oficjalnie funkcjonuje (z MariaDB: działa, ale nie w 100% bezproblemowo). PostgreSQL - melodia przyszłości ; współpraca z innymi RDBMS-ami melodia jeszcze dalszej przyszłości (via DBIx::Class / DBIC);

10 SKALOWALNOŚĆ I WYDAJNOŚĆ KOHA C.D. Responsywność: w obecnej wersji systemu pozostawia sporo do życzenia (niezależnie od tego jak bardzo wydajnym serwerem byśmy nie dysponowali); Problem: w standardowej konfiguracji systemu Koha (tj. zwykłe, bezstanowe środowisko CGI) średnio nawet ponad 80% czasu wykonania przeciętnego skryptu *.pl jest tracone na każdorazowe wstępne ładowanie i kompilację rozlicznych modułów perla (typowo zajmuje to ponad 500ms, nawet na szybkim procesorze); Dostępne rozwiązania tego problemu (= środowiska uruchomieniowe fastcgi/plack/mod_perl itd., pozwalające na skrócenie o rząd wielkości wstępnego czasu wykonania skryptów *.pl i zasadniczą poprawę responsywności systemu) są w przypadku interfejsu OPAC z powodzeniem już wykorzystywane w wielu produkcyjnych instalacjach Koha, ale jeśli chodzi o interfejs bibliotekarza, postępy w tym temacie nie są jeszcze do końca zadowalające. Prace trwają...

11 WYMAGANIA (KOMPUTERY PRACOWNIKÓW) Interfejs bibliotekarza: jako stacje robocze zalecane są (w miarę współczesne) komputery z zainstalowaną typową przeglądarką WWW (Firefox, Chrome, IE 9.0+, ) w możliwie aktualnej wersji; system operacyjny: obojętnie jaki liczy się wersja przeglądarki i jej zgodność ze standardami W3C; Szybkość działania, ilość pamięci RAM itp. jest nie całkiem bez znaczenia Koha miejscami po stronie klienta dość intensywnie korzysta m.in. z rozmaitych funkcji i bibliotek javascript (JQuery + DataTables,...) i strony WWW, które system generuje. Mogą być potencjalnie dość ciężkie na słabych komputerach takie strony się owszem prędzej czy później wczytają i wyrenderują, ale już filtrowanie, stronicowanie i sortowanie wyników w tabelach generowanych przy pomocy DataTables może działać niezbyt zadowalająco; Istotna sprawa to również rozdzielczość ekranów (e.w. konieczność przewijania stron w przeglądarce zwłaszcza w poziomie znacząco wpływa na komfort pracy); w praktyce dobrze, aby były to monitory o rozdzielczości co najmniej 1680x1050 (WSXGA+), w szczególności w Oddziale Udostępniania;

12 WYMAGANIA (OPAC) OPAC (= w porównaniu z interfejsem bibliotekarza) ma zdecydowanie łagodniejsze wymagania, co do wydajności urządzeń oraz zgodności przeglądarek WWW ze standardami; W obecnej wersji Koha, OPAC funkcjonuje w oparciu o framework bootstrap (zresztą w nienajnowszej wersji 2.3.x?); Bootstrap kładzie duży nacisk na zgodność z możliwie jak największą ilością rozmaitych wersji przeglądarek i wariantów urządzeń klienckich, tradycyjnych czy mobilnych, i nieźle się sprawdza w praktyce w takich zastosowaniach, gdzie rozrzut parametrów sprzętowych czy wersji przeglądarek WWW bywa stosunkowo duży; Czytelnicy używający przeglądarek WWW z wyłączonym JavaScript i/lub zablokowaną obsługą ciasteczek mogą (w najlepszym razie) korzystać z systemu jedynie w bardzo mocno ograniczonym zakresie;

13 MOŻLIWE WARIANTY INSTALACJI I POSADOWIENIA SYSTEMU Własny serwer, fizyczny albo wirtualny (w miarę możliwości, optymalnie, dedykowany pod system biblioteczny) może być utrzymywany lokalnie, zdalnie, dzierżawiony (np. VPS) itp.; Wspólny serwer (lub serwery w szczególności, MySQL i Zebra mogą być posadowione na innych maszynach niż sam system), współdzielony przez wiele osobnych jednostek organizacyjnych, instytucji itp. (w różnych wariantach: osobne / wspólne / częściowo wspólne poszczególne komponenty systemu w przypadku różnych instytucji: bazy danych raczej osobne); Wykupiona na zewnątrz usługa całościowo obejmująca wszystkie kwestie związane z zapewnieniem dostępu, bieżącego utrzymania, aktualizacji i obsługi informatycznej systemu bibliotecznego; Inne rozmaite warianty i kombinacje trzech wyżej wymienionych rozwiązań Jeśli dysponujemy wyłącznie serwerami / komputerami z MS Windows, instalacja systemu Koha w obrębie maszyny wirtualnej jest w takim środowisku w zasadzie jedynym (sensownym, w praktyce dostępnym) rozwiązaniem;

14 PROTOKOŁY OBSŁUGIWANE PRZEZ KOHA Protokoły autoryzacji, centralnego logowania: LDAP CAS Shibboleth Mozilla Persona

15 PROTOKOŁY OBSŁUGIWANE PRZEZ KOHA Protokoły obsługi użytkowników i wypożyczeń: ILS-DI (ILS Discovery Interface) SIP2 Self-check RFID Propozycje rozwiązania: Propozycja biblioteki publicznej z Oslo (RFC): Działające rozwiązanie stworzone przez: Dobrica Pavlinusic:

16 PROTOKOŁY OBSŁUGIWANE PRZEZ KOHA Protokoły obsługi baz bibliograficznych jako klient (pobieranie): SRU Z39.50 Protokoły obsługi baz bibliograficznych jako serwer (udostępnianie): OAI-PMH bezpośrednio Z39.50 oraz SRU za pomocą usługi Zebra

17 ROZWIJANIE SYSTEMU KOHA System kontroli wersji GIT Opiekunowie repozytorium GIT (Relase Managers) wybierani co 6 miesięcy Dodawanie poprawek błędów i rozszerzeń, wymaga przejścia zgłoszenia przez procedurę formalną

18 ROZWIJANIE SYSTEMU KOHA 1. Zgłoszenie błędu, na stronie śledzenia błędów, Bugzilla ( Kroki niezbędne do odtworzenia błędu Informację o błędzie wyświetloną przez system Załącznik w formie obrazu lub filmu Przy zgłaszaniu rozszerzenia: Opis funkcji Nowe preferencje

19 ROZWIJANIE SYSTEMU KOHA 2. Dodanie poprawki (patch) do zgłoszenia: Musi zawierać numer błędu nadanego przez Bugzillę Krótkie podsumowanie i opis błędu ew. zastosowanego rozwiązania Powinien zawierać plan testów ( test plan )

20 ROZWIJANIE SYSTEMU KOHA 3. Podpisywanie poprawki (sign-off): Musi być wykonane przez inną osobę niż autor poprawki Preferowane, aby była to osoba z innej insytucji Wykonanie planu testów, sprawdzenie ogólnej funkcjonalności

21 ROZWIJANIE SYSTEMU KOHA 4. Akceptacja przez zespół ds. jakości (QA Quality assurance): QA wybierany na tych samych zasadach co RM. Sprawdzenie formalnej poprawności dołączonego kodu (narzędziem koha-qa.pl) Weryfikacja poprawki za pomocą testów jednostkowych Sprawdzenie ogólnej jakości kodu (konwencja nazw, procedury w odpowiednich modułach) Akceptacja lub odrzucenie poprawki W przypadku odrzucenia, informacja co należy poprawić Jeżeli są wątpliwości co do poprawki, status błędu może zostać ustawiony jako do dyskusji

22 ROZWIJANIE SYSTEMU KOHA 5. Po akceptacji: Włączenie kodu do repozytorium przez menadżera wersji: Do wersji master (wersja rozwojowa) w przypadku rozszerzeń i błędów Do wcześniejszych wersji (najczęściej 2 wersje wstecz) jeżeli poprawiony błąd również w nich występuje

23 PERSPEKTYWY NA PRZYSZŁOŚĆ Ważniejsze zmiany spodziewane w wersjach 3.20/3.22 (nadchodzący rok): Obsługa nowego silnika wyszukiwawczego Elastic Search Dodanie interfejsu profesjonalnego katalogera Dodanie obsługi RDA Dodanie obsługi protokołu OAI-PMH w formie klienta Uruchamianie interfejsu bibliotekarza poprzez PLACK, mod_perl Długoterminowe na najbliższe lata: Zmiana paradygmatu programowania z proceduralnego na obiektowy

24 DZIĘKUJEMY ZA UWAGĘ. Jacek Ablewicz Rafał Kopaczka