Składowanie i przetwarzanie danych językowych w relacyjnej bazie danych - korpus PELCRA i MySQL Piotr Pęzik

Powszechne formaty składowania danych korpusowych Pliki tekstowe, bez anotacji (najczęściej nieindeksowane) Pliki tekstowe z anotacją linearną (bez zewnętrznie definiowanej hierarchii znaczników) Pliki tekstowe ze sformalizowaną, hierarchiczną strukturą danych opartą na popularnych standardach przenoszenia/składowania danych (np. XML). Specjalnie implementowane struktury danych serializowane do postaci binarnej. Model, na którym oparte są takie struktury zależy od użytej platformy programistycznej. Rozwiązania łączone. Relacyjne bazy danych. (Formaty binarne oparte na szeroko przyjętym modelu relacyjnym, z interfejsami programistycznymi oraz językiem zapytań).

Kryteria wyboru systemu składowania i przetwarzania danych językowych Przejrzystość i łatwość zarządzania/rozbudowy przyjętego modelu danych Zapewnienie dostępności przez Internet (obsługa protokołów i technologii sieciowych) Minimalizacja wymogów sprzętowych i dodatkowego oprogramowania po stronie klienta Dystrybucja aktualizacji Zarządzanie użytkownikami/profilowanie dostępu Skalowalność Możliwości konwersji do innych formatów Zgodność z różnymi platformami programistycznymi

Model RDB – rys historyczny Po raz pierwszy opisany w latach 70-tych w raporcie technicznym IBM (RJ599). Edgar Frank Codd. A Relational Model of Data for Large Shared Data Banks Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377-387. Copyright © 1970, Association for Computing Machinery, Inc. 12 reguł modelu relacyjnego Codda. Czasem spotykana jest też dodatkowa (nieco tautologiczna) reguła: „Dane przechowywane w relacyjnym systemie zarządzania danymi muszą być przetwarzane tylko i wyłącznie zgodnie z zasadami relacyjnego systemu danych.” W praktyce oznacza to, że wiele implementacji baz danych to systemy quasi-relacyjne. 5 reguła Codda podkreśla potrzebę opracowania języka zapytań dla modelu RDB. Mimo, że pierwsza próba wypracowania ścisłego standardu języka SQL miała miejsce w 1992 roku (rewidowana w 1999 roku), to istniejące obecnie wersje języka SQL nie do końca spełniają jego wymogi

Korpus PELCRA w bazie MySQL Systemy RDB brane pod uwagę: POSTGRES, ORACLE, MySQL Ogólna opinia o MySQL – duża szybkość, ale stosunkowo słabo rozbudowana wersja SQL. MySQL 4.1, MySQL 5.0 – 1 milion pobrań w ciągu pierwszych 3 tygodni głównie ze względu na znaczne ulepszenia Korpus PELCRA – ponad 100,000,000 rekordów w 130 tabelach

Model RDB dla danych językowych 1 Podstawowe tabele (wszystkich130) Słowo – Zdanie – Akapit – Tekst Wiązanie przez klucz obcy. Ważne pole pozwalające przywrócić pierwotną strukturę linearną tekstu: sekwencja.

Tabela słowa

Tabela zdania

Tabela akapitu

Tabela tekstu

Przykładowe zapytanie wiążące tabele słowa i zdania select w.word_num, w.word lewe_slowo, w1.word prawe_slowo from pnc_word_token w, pnc_word_token w1, pnc_sentence s where w.word = 'życiowa' # warunek dla słowa w and w1.sentence_num = w.sentence_num # słowo w1 w tym samym zdaniu and w1.sequence = w.sequence + 1 # pierwsze po prawej and w.sentence_num = s.sentence_num # wiązanie z tabelą zdania and s.type_num = 3 # tylko pytania

Wynik

„Płaskie” tabele Czasem ze względów praktycznych warto złamać reguły relacyjne poprzez powtórzenie w różnych tabelach danych, które teoretycznie dałoby się wydobyć poprzez wiązania (na poziomie zdania i akapitu) oraz poprzez użycie tabel „płaskich” (nierelacyjnych), np. tabela corpus_frequency: frequency_num frequency word stop 30 6284418 , y 32 5942163 . 938776 2410016 w 312246 1662997 i 31 1451046 - 796653 1284521 się 1015357 1278529 z

Modelowanie i zarządzanie danymi

Dostępność zasobów przez Internet i wymagania po stronie klienta I Architektura Serwer RDB – Serwer WWW – Przeglądarka. Ograniczenia: Większość operacji formatowania danych (sortowanie, ograniczanie kontekstu – tylko poprzez skrypty) musi być zdefiniowana przed wysłaniem zapytania. Zalety: terminal z najprostszą przeglądarka pozwala na skorzystanie z pełnych możliwości sprzętowych i programistycznych serwera RDB oraz WWW: Serwer RDB (MySQL) Serwer WWW (Linux/Apache/ PHP, ew. JSP) Przeglądarka

Dostępność zasobów przez Internet i wymagania po stronie klienta II Architektura Serwer RDB – Aplikacja Klienta (np. MySQL - Java JDBC). Wady: większe wymagania po stronie klienta. Zalety: szerokie możliwości przetwarzania wyników zapytań po stronie klienta. Serwer RDB MySQL Aplikacja klienta (np. Java)

Dystrybucja aktualizacji Centralny system serwowania danych. Natychmiastowa aktualizacja. Wady: problemy z serwerem są odczuwane przez wszystkich użytkowników systemu. MySQL – replikowanie bazy.

Zarządzanie dostępem Poprzez tabelę user w bazie mysql Z wykorzystaniem warstwy aplikacji

Skalowalność I Zapytanie na tabeli word_token (93+ miliony rekordów. 1 serwer PENTIUM 4 3.0 GHz, 2 GB RAM): select * from pnc_word_token WHERE word = 'woda' # 3876 wierszy w 0.91s

Skalowalność II select * from pnc_word_token WHERE word like 'wodn%' # 3138 wierszy w 1.19s pnc_sentence sentence like '% woda %' # 2168 wierszy w 1.09s (6 millionów rekordów w tabeli).

Skalowalność III Efektywność spada znacznie przy: Stosowaniu skomplikowanych wiązań (szczególnie tzw. left-joins/outer-joins) . Warto wiązać z możliwie najwyższego poziomu (stąd płaskie tabele i powtórzenie danych w różnych polach na różnych poziomach – ale nie chaotycznie). Grupowaniu na całej tabeli. Zastosowaniu złożonych wyrażeń regularnych na tabelach niskiego poziomu (REGEX i LIKE na word_token). Dużo zależy od stopnia przetworzenia przechowywanych w bazie danych.

Skalowalność IV Wykorzystanie indeksów typu FULL TEXT select * from pnc_sentence s where match(s.sentence) against('woda' in boolean mode) # 3834 rekordy w 0.5 sekundy (6 millionów rekordów w tabeli). pnc_paragraph p match(p.paragraph) against('woda' in boolean mode) # 3800 rekordów w 0.4 sekundy (2,5 milliona rekordów w tabeli

Skalowalność V Architektura rozproszona w MySQL 5.0 (klaster)

Konwersja do innych formatów, interfejsy programistyczne Wszelkie formaty tekstowe z poziomu SQL Do formatów binarnych przez interfejsy programistyczne, np. JDBC Szeroka kompatybilność, interfejsy dostarczane przez producentów bazy i platform programistycznych

Ograniczenia systemów RDB Ładowanie danych Centralizacja modelu: bezpieczeństwo danych, ograniczenia liczby jednoczesnych użytkowników (ale: możliwości automatycznego replikowania bazy) Ograniczenia implementacji języka SQL. Np. wbudowane funkcje wyrażeń regularnych zwracają jedynie wartości prawda/fałsz, a nie na przykład indeksy pasującego podłańcucha. Ewolucja MySQL: 4.0 sub-selects 4.1 group_concat() 5.0 własne (choć ograniczone) funkcje definiowane z poziomu SQL, formalnie definiowane klucze obce, tabele dynamiczne (tzw. widoki), wyzwalacze, definiowanie funkcji, procedury składowane, np.:

CREATE PROCEDURE `get_st_tt_ratio`() # Możliwe argumenty BEGIN BEGIN DECLARE v INT; DECLARE lim INT; DECLARE s_tt_r DOUBLE; SET v = 0; SET s_tt_r = 0; select 0 into @last_min; select count(*)/1000 from pnc_word_token into lim; WHILE v < lim DO select count(distinct(word))/1000 into @curr_s_tt_rr from (select word_num, word from pnc_word_token where word_num > @last_min limit 1000) mee; select max(word_num) into @last_min from (select * from pnc_word_token where word_num > @last_min limit 1000) sss; SET v = v + 1; SET s_tt_r = s_tt_r + @curr_s_tt_rr; END WHILE; SET s_tt_r = (s_tt_r/lim); select s_tt_r; END; END;

Wnioski końcowe Bazy RDB wydają się szczególnie interesującym rozwiązaniem w sytuacji, gdy zachodzi potrzeba składowania i zarządzania dużą ilością wysoko przetworzonych danych językowych. Oferują one bardzo wysoką przejrzystość struktur danych i relacji między nimi, a także kompatybilność z każdą liczącą się platformą programowania aplikacji WWW oraz aplikacji typu Desktop. Na uwagę zasługuje również ich skalowalność, szczególnie w architekturze rozproszonej. Nieco gorzej systemy RDB wypadają w projektach o charakterze mocno eksperymentalnym, w których struktura modelu podlega wielokrotnym modyfikacjom i w których zachodzi potrzeba analizy niskoprzetworzonych danych.