Składowanie i przetwarzanie danych językowych w relacyjnej bazie

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
word_num lewe_slowo prawe_slowo
3794492 życiowa
stabilizacja
5132549 życiowa
sytuacja
5842184 życiowa
przygoda
5991461 życiowa
pasja
6309181 życiowa
decyzja
6784503 życiowa
Pasja
...
...
...
„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
.
y
938776
2410016
w
y
312246
1662997
i
y
31
1451046
-
y
796653
1284521
się
y
1015357
1278529
z
y
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
select
*
from
pnc_sentence
WHERE
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).
select
*
from
pnc_paragraph p
where
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.