Bazy NoSQL jako implementacje wzorców struktur informacji

Dane nie­struk­tu­ral­ne sta­no­wią ponad 80% skła­do­wa­nych danych, to ozna­cza, że model rela­cyj­ny pozwa­la opi­sać i prze­twa­rzać tyl­ko uła­mek posia­da­nej infor­ma­cji (UNSTRUCTURED DATA AND THE 80 PERCENT RULE)

Wstęp

W pod­su­mo­wa­niu nie­daw­ne­go arty­ku­łu o NoSQL w chmu­rze, napisałem: 

Problem pro­jek­to­wa­nia struk­tur doku­men­tów, tak­że w bazach doku­men­to­wych, to osob­ne i trud­ne zagad­nie­nie. Opisałem go w naj­now­szym arty­ku­le, któ­ry uka­że się za nie­dłu­go w wydaw­nic­twie IGI Global: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation. (Repozytorium w chmu­rze – NoSQL – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Artykuł sie wła­śnie uka­zał. We wstę­pie napisałem:

Dokumenty czę­sto zawie­ra­ją dużą ilość róż­nych danych two­rzą­cych wspól­nie wie­le kon­tek­sto­wych zbio­rów danych (agre­ga­tów). Zastosowanie mode­lu rela­cyj­ne­go do orga­ni­za­cji takich danych pro­wa­dzi do wyge­ne­ro­wa­nia roz­bu­do­wa­ne­go sys­te­mu powią­za­nych rela­cyj­nie tabel, przy czym usu­nię­cie redun­dan­cji czę­sto powo­du­je utra­tę kon­tek­stu tre­ści poszcze­gól­nych pól w tabe­lach. Rodzi to koniecz­ność sto­so­wa­nia wyso­ce zło­żo­nych zapy­tań SQL, aby doku­men­ty te mogły być zapi­sy­wa­ne w tej bazie danych i z niej pobie­ra­ne. W ten spo­sób sama baza danych zawie­ra wyłącz­nie dane pozba­wio­ne kon­tek­stu obec­ne­go w tabe­lach, a nie dokumenty.

Wielu auto­rów zwra­ca­ło uwa­gę na pro­blem zło­żo­no­ści i utra­ty jed­no­li­te­go kon­tek­stu mode­lu rela­cyj­ne­go (Ślęzak i in., 2018). Autorzy ci suge­ro­wa­li, że kon­tek­sty powin­ny być sepa­ro­wa­ne w dużych rela­cyj­nych mode­lach danych. Jednak zale­ce­nie sepa­ra­cji kon­tek­stów (Evans, 2003; Fowler, 1997; Fowler & Rice, 2005), przy zacho­wa­niu mode­lu rela­cyj­ne­go, nie poma­ga w cał­ko­wi­tym roz­wią­za­niu pro­ble­mu (Awang et al., 2012, 2012, 2012).

Zmiana kon­tek­stu czę­sto zmie­nia zna­cze­nie danych (Danesi, 2004). Podejmowane pró­by zacho­wa­nia zna­cze­nia danych czę­sto pro­wa­dzą do two­rze­nia roz­bu­do­wa­nych rela­cyj­nych mode­li danych, gene­ru­jąc tym samym dodat­ko­we kosz­ty. Dlatego też wyko­rzy­sta­nie jed­ne­go rela­cyj­ne­go mode­lu danych do zapi­su zawar­to­ści wie­lu róż­nych doku­men­tów może uczy­nić z takie­go sys­te­mu ogrom­ny i nie­po­dziel­ny mono­lit, któ­ry jest kosz­tow­ny zarów­no w roz­wo­ju, jak i w utrzy­ma­niu. (Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases)

Rodzaje baz danych NoSQL na rynku

Praktyka poka­zu­je, że bazy te to odpo­wiedź na stan­dar­do­we obec­nie wyma­ga­nia wobec sys­te­mów infor­ma­cyj­nych, jaki­mi są zmien­ność struk­tur danych, ich ogra­ni­czo­na struk­tu­ra­li­za­cja lub nawet jej cał­ko­wi­ty brak .

Akronim NoSQL został po raz pierw­szy uży­ty w 1998 roku przez Carlo Strozzi’ego jako nazwa jego lek­kiej, open­so­ur­ce rela­cyj­nej” bazy danych, któ­ra nie uży­wa­ła SQL. Nazwa ta poja­wi­ła się ponow­nie w 2009 roku, kie­dy Eric Evans i Johan Oskarsson uży­li jej do opi­sa­nia nie­re­la­cyj­nych baz danych. Relacyjne bazy danych są czę­sto okre­śla­ne jako sys­te­my SQL. Termin NoSQL może ozna­czać zarów­no Nierelacyjna SQL” lub bar­dziej popu­lar­ne tłu­ma­cze­nie Nie tyl­ko SQL” (Not only SQL), aby pod­kre­ślić fakt, że nie­któ­re sys­te­my mogą obsłu­gi­wać języ­ki zapy­tań podob­ne do SQL. (źr.: A Brief History of Non-Relational Databases – DATAVERSITY)

Jeden z moim zda­niem cie­kaw­szych arty­ku­łów o NoSQL napi­sał Fowler 10 lat temu .

Bazy danych «key-value».

Bazy te są naj­prost­szym typem bazy NoSQL. Każdy ele­ment (wiersz) w takiej bazie to para klucz i war­tość (dane prze­cho­wy­wa­ne), tu zawar­tość (dane prze­cho­wy­wa­ne) to zawsze jakiś plik” (podob­nie jak pole typu BLOB: Binary Large OBject). Zawartość ta może być pobra­na wyłącz­nie poprzez odwo­ła­nie się do jej iden­ty­fi­ka­to­ra (klu­cza) . Bazy te są dosko­na­łe do prze­cho­wy­wa­nia dużych ilo­ści róż­no­rod­nych danych, gdzie nie trze­ba prze­twa­rzać tre­ści tych danych w samej bazie (np. wyszu­ki­wa­nie zawar­to­ści na pod­sta­wie jej okre­ślo­nych cech). Służą one wyłącz­nie do zacho­wy­wa­nia i odzy­ski­wa­nia pli­ków. Praktycznie jest to pła­ski sys­tem plików. 

model repo­zy­to­rium key-value (opra­co­wa­nie wła­sne autora) 
meto­da zapi­su w repo­zy­to­rium key-value (opra­co­wa­nie wła­sne autora) 

Dokumentowe bazy danych. 

To odmia­na bazy key-value. Przechowuje dane w posta­ci okre­ślo­nej struk­tu­ral­nej tre­ści: doku­men­tów (np. JSON czy XML). Struktury te mają swo­je defi­ni­cje, a ich typów może być dowol­na licz­ba . Jedna baza może więc zawie­rać doku­men­ty o dowol­nie wybra­nej, okre­ślo­nej struk­tu­rze. Dostępne na ryn­ku bazy tego typu maja tak­że bar­dzo dobre i szyb­kie moto­ry zapy­tań, są coraz czę­ściej sto­so­wa­ne jako bazy danych ogól­ne­go przeznaczenia. 

Baza doku­men­to­wa. Dokument to czy­tel­na dla czło­wie­ka treść, w bazach doku­men­to­wych ma on okre­ślo­na ale nie sztyw­ną struk­tu­rę: może to być JSON, XML. Dokument (jego treść) jest prze­twa­rza­ny poza bazą danych (kom­po­nent Logika biz­ne­so­wa). (opra­co­wa­nie wła­sne autora) 

Bazy zmieno-kolumnowe.

Przechowują dane w posta­ci agre­ga­tów o zmien­nych liściach”. Bazy tego typu zapew­nia­ją dużą ela­stycz­ność w sto­sun­ku do rela­cyj­nych baz danych, ponie­waż nie jest wyma­ga­ne, aby każ­dy wiersz agre­gat posia­dał tyle samo i te same ele­men­ty (kolum­ny) . Bazy tego typu są powszech­nie sto­so­wa­ne do prze­cho­wy­wa­nia danych np. danych pro­fi­lo­wych użyt­kow­ni­ków. Są czę­sto opi­sy­wa­ne w poniż­szy sposób:

Diagram of a column family in a wide column store database.
Model archi­tek­tu­ry kom­po­nen­tu z bazą zmien­no-kolum­no­wą (powyż­sze wyra­żo­ne jako model dzie­dzi­ny kom­po­nen­tu z uży­ciem UML)

Jak widać, bazy te prze­cho­wu­ją agre­ga­ty. Nazwanie agre­ga­tu wier­szem” jest nie­for­tun­ne bo to jed­nak nie są pła­skie tabe­le, jed­nak poję­cia wier­szy i kolumn zrzu­cam tu jed­nak na karb ste­reo­ty­pu zaczerp­nię­te­go z mode­lu relacyjnego.

Grafowe bazy danych. 

Przechowują dane w posta­ci węzłów i kra­wę­dzi (aso­cja­cje mię­dzy węzła­mi). Węzły zazwy­czaj prze­cho­wu­ją infor­ma­cje o obiek­tach (ludzie, miej­sca, przed­mio­ty) kra­wę­dzie zaś prze­cho­wu­ją infor­ma­cje o moż­li­wych związ­kach mię­dzy węzła­mi . Grafowe bazy danych dosko­na­le spraw­dza­ją się w przy­pad­kach gdy trze­ba zapi­sy­wać i śle­dzić związ­ki mię­dzy obiek­ta­mi i ana­li­zo­wać je, np. sie­ci spo­łecz­no­ścio­we czy wykry­wa­nie oszustw. Tak są naj­czę­ściej opi­sy­wa­ne gra­fo­we bazy danych, a przed­sta­wia­ne są np. tak:

(źr.

Uważam, że powyż­sze to try­wial­na i naiw­na meto­da przed­sta­wia­nia baz tego typu. Istotą sys­te­mu prze­twa­rza­nia infor­ma­cji jest tu (w takim mode­lu) jest prze­cho­wy­wa­nie infor­ma­cji o obiek­tach i o fak­tach je łączą­cych takich jak zda­rze­nia doty­czą­ce pary obiek­tów . Mogą to być typo­we fak­ty, np. Samochód miał koli­zje w Mieście, gdzie Samochód i Miasto to węzły, a koli­zja to zda­rze­nie. Ważne jest to, że Samochód i Miasto moż­na opi­sać okre­ślo­nym cech, sama koli­zje tak­że, waż­ne jest to, że fak­tów łączą­cych dwa obiek­ty może być wie­le (w czasie). 

Związki mię­dzy obiek­ta­mi opi­sy­wa­ne są też meto­dą RDF (Resource Description Framework) jako zda­nia: Subject – Predicate – Object .

O każ­dym obiek­cie będzie jeden rekord w bazie danych, o każ­dym fak­cie też, ale róż­nych fak­tów, któ­rych cecha­mi są te obiek­ty może być wie­le (cechą stłucz­ki jest mię­dzy inny­mi miej­sce stłucz­ki i samo­chód, któ­ry miał tę stłucz­kę). Cechami obiek­tów są nazwa, data powsta­nia i ewen­tu­al­na data usu­nię­cia (znisz­cze­nia), tak­że cechy defi­niu­ją­ce takie jak np. kolor, typ czy wyda­wa­ne dźwię­ki. Cechami fak­ty są czas zaist­nie­nia oraz obiek­ty (ich nazwy), któ­rych okre­ślo­ny fakt doty­czy. Ważne jest to, że poło­że­nie obiek­tu nie jest jego cechą defi­niu­ją­cą. Graf jest defi­nio­wa­ny jako nazwa­ne związ­ki mię­dzy obiek­ta­mi, są nimi wła­śnie fak­ty (a sze­rzej: pre­dy­ka­ty). Warto też zazna­czyć, że w kon­tek­ście np. zda­rzeń gospo­dar­czych, fak­tem jest fak­tu­ra opi­su­ją­ca trans­ak­cje do jakiej doszło. Jednak w archi­wum doku­men­tów fak­tu­ra jest obiek­tem archi­wal­nym .

Tak więc bar­dziej sfor­ma­li­zo­wa­na struk­tu­ra danych w bazie gra­fo­wej mogła by wyglą­dać tak:

Struktura infor­ma­cyj­na gra­fo­wej bazy danych (opra­co­wa­nie wła­sne autora)

Diagram powyż­szy jest kolo­ro­wa­ny dla popra­wy czy­tel­no­ści. W tej posta­ci widać obiek­ty i łączą­ce je fak­ty: w bazach gra­fo­wych są to for­mal­nie tak zwa­ne związ­ki seman­tycz­ne (zna­cze­nio­we), ale jest to jed­nak duże uprosz­cze­nie. Systemy zapi­su infor­ma­cji w posta­ci tró­jek: poję­cie-pre­dy­kat-poję­cie mają szer­sze uza­sad­nie­nie (pla­nu­ję publi­ka­cję z wyni­ka­mi szer­szych badań). Metamodel sys­te­mu zapi­su infor­ma­cji o obiek­tach i związ­kach mię­dzy nimi wyglą­da tak:

Metamodel gra­fo­wej bazy danych (opra­co­wa­nie wła­sne autora) 

Warto zauwa­żyć, że zarów­no Obiekt jak i Związek seman­tycz­ny mogą być prze­cho­wy­wa­ne w bazie doku­men­to­wej lub kolumnowej…

Podsumowanie

To co dzi­siaj nazy­wa­my baza­mi danych NoSQL to tyl­ko natu­ral­ne mode­le infor­ma­cyj­ne. Kiedy odkry­te? Nie wiem, ale wiem, że w tym wszyst­kim naj­bar­dziej nie­na­tu­ral­ny jest model rela­cyj­ny. Dlaczego? Bo nie wystę­pu­je w natu­rze i spra­wia same pro­ble­my. Celowo zapre­zen­to­wa­łem sfor­ma­li­zo­wa­ne dia­gra­my UML dla każ­de­go typu, by poka­zać, że NoSQL to tyl­ko i aż mode­le infor­ma­cyj­ne spo­ty­ka­ne w rze­czy­wi­sto­ści życia czło­wie­ka. Konstrukcje jak te wyżej opi­sa­ne, to tak na praw­dę mode­le infor­ma­cji wyni­ka­ją­ce z dzie­dzi­ny pro­ble­mu, nie jest tak że są uży­wa­ne z powo­du wyna­le­zie­nia” baz NoSQL, jest dokład­nie odwrotnie. 

Obecne bazy NoSQL rozu­mia­ne jako moto­ry baz danych”, to imple­men­ta­cje infor­ma­cyj­nych wzor­ców pro­jek­to­wych. Diagramy UML powy­żej to meta­mo­de­le tych wzorców. 

Na temat baz danych i baz NoSQL pole­cam kom­plek­so­we opra­co­wa­nie Joe Celko: Complete guide to NoSQL: what eve­ry SQL pro­fes­sio­nal needs to know abo­ut non­re­la­tio­nal data­ba­ses .

Podsumowanie 2

Pojawiają się tezy że to się nie nada­je do ERP, że nikt tak nie robi… Otóż:

Systemy ERP budo­wa­ne w opar­ciu o cen­tral­ne bazy danych RDBMS ewo­lu­ują­ce do chmu­ry są nie­ja­ko ska­za­ne na bazy NoSQL (zna­ko­mi­ta więk­szość chmu­ro­wych repo­zy­to­riów chmu­ro­wych to bazy NoSQL).

Ewolucja Architektury tak zwa­nych stan­dar­do­wych ERP 

Podstawowym pro­ble­mem sys­te­mów zbu­do­wa­nych w opar­ciu o bazy RDBMS/SQL jest to, że nie ma w nich doku­men­tów, a jedy­nie dane roz­ło­żo­ne w tabe­lach. Uzyskanie doku­men­tu (np. fak­tu­ry) wyma­ga każ­do­ra­zo­wo dyna­micz­ne­go zebra­nia danych z wie­lu tabel, ich złą­cze­nia i sfor­ma­to­wa­nia, czy­li uży­cia języ­ka SQL. Dlatego ewo­lu­cja nowo­cze­snych sys­te­mów ERP idzie w kie­run­ku sys­te­mów, w któ­rych funk­cje kal­ku­la­cyj­ne oraz doku­men­ty są roz­dzie­lo­ne, a doku­men­ty są prze­cho­wy­wa­ne w posta­ci zmaterializowanej: 

Zarządzanie doku­men­ta­mi w sys­te­mach ERP 

Podsumowanie 3

Od dłuż­sze­go cza­su sto­su­je w pro­jek­tach struk­tu­ry infor­ma­cyj­ne nazy­wa­ne NoSQL. Sa to prak­tycz­nie wszyst­kie opi­sa­ne wyżej struk­tu­ry. Projekt dla agen­cji foto­gra­ficz­nej BE&W (archi­wum zdjęć), pro­jekt dla Biura Polonii Kancelarii Senatu (obsłu­ga wnio­sków o dofi­nan­so­wa­nie o zmien­nej struk­tu­rze), pro­jekt dla Żandarmerii Wojskowej (zarzą­dza­nie spra­wa­mi docho­dze­nio­wo-śled­czy­mi w całej Polsce), pro­jekt dla KGHM (stan­da­ry­za­cja sys­te­mu utrzy­ma­nia ruchu, zarzą­dza­nie infra­struk­tu­rą produkcyjną).

Więcej już nie­dłu­go… Zachęcam do zada­wa­nia pytań o NoSQL pod tym wpisem. 

Źródła

Bouhali, R., & Laurent, A. (2015). Exploiting RDF Open Data Using NoSQL Graph Databases. In R. Chbeir, Y. Manolopoulos, I. Maglogiannis, & R. Alhajj (Eds.), Artificial Intelligence Applications and Innovations (Vol. 458, pp. 177 – 190). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 23868-5_13
Besta, M., Peter, E., Gerstenberger, R., Fischer, M., Podstawski, M., Barthels, C., Alonso, G., & Hoefler, T. (2020). Demystifying Graph Databases: Analysis and Taxonomy of Data Organization, System Designs, and Graph Queries. ArXiv:1910.09017 [Cs]. http://​arxiv​.org/​a​b​s​/​1​9​1​0​.​0​9​017
Harley Vera, Wagner Boaventura, Maristela Holanda, Valeria Guimaraes, & Fernanda Hondo. (2015). Data Modeling for NoSQL Document-Oriented Databases. CEUR Workshop Proceedings, 1478, 129 – 135.
Celko, J. (2014). Joe Celko’s Complete guide to NoSQL: what eve­ry SQL pro­fes­sio­nal needs to know abo­ut non­re­la­tio­nal data­ba­ses. Elsevier/Morgan Kaufmann.
Garba, M. (2020). A Comparison of NoSQL and Relational Database Management Systems (RDBMS). 1(2), 9.
Karnitis, G., & Arnicans, G. (2015). Migration of Relational Database to Document-Oriented Database: Structure Denormalization and Data Transformation. 2015 7th International Conference on Computational Intelligence, Communication Systems and Networks, 113 – 118. https://​doi​.org/​1​0​.​1​1​0​9​/​C​I​C​S​y​N​.​2​0​1​5​.30
Gyorödi, C., Gyorödi, R., & Sotoc, R. (2015). A Comparative Study of Relational and Non-Relational Database Models in a Web- Based Application. International Journal of Advanced Computer Science and Applications, 6(11). https://​doi​.org/​1​0​.​1​4​5​6​9​/​I​J​A​C​S​A​.​2​0​1​5​.​0​6​1​111
Guimaraes, V., Hondo, F., Almeida, R., Vera, H., Holanda, M., Araujo, A., Walter, M. E., & Lifschitz, S. (2015). A stu­dy of geno­mic data pro­ve­nan­ce in NoSQL docu­ment-orien­ted data­ba­se sys­tems. 2015 IEEE International Conference on Bioinformatics and Biomedicine (BIBM), 1525 – 1531. https://​doi​.org/​1​0​.​1​1​0​9​/​B​I​B​M​.​2​0​1​5​.​7​3​5​9​902

Inne artykuły na podobny temat

image_print(wydruk PL)

Komentarze

  1. Marek Kozlowski 3 czerwca 2021 at 11:21

    Bardot to cie­ka­we. Moją uwa­gę przy­ku­ło, w szcze­gól­no­ści stwier­dze­nie, że bazy danych NoSQL, są bli­żej natu­ry czło­wie­ka. Być może bazy SQL cze­ka ten sam los co płyt CD lub raczej winy­lo­wych. To zna­czy nie wypad­ną w cało­ści z ryn­ku, ale prze­sta­ną być domi­nu­ją­ce w użyciu.

    • Jarosław Żeliński 3 czerwca 2021 at 11:32

      Model rela­cyj­ny i sys­tem zapy­tań SQL to bar­dzo spe­cja­li­stycz­na for­ma zarzą­dza­nia dany­mi, nie­ste­ty takie poję­cia jak treść” czy doku­ment”, natu­ral­ne dla czło­wie­ka, nie wystę­pu­ją w tym mode­lu… Stąd od ok. 2000 roku sta­le trwa­ją pra­ce nad inny­mi mode­la­mi (NoSQL to skrót od Not only SQL”). Wygląda na to, że tak zwa­ny para­dyg­mat zorien­to­wa­ny na doku­men­ty” wygra, trwa­ją pra­ce nad jego formalizacją.

  2. Piotr Różnicki 6 grudnia 2021 at 22:46

    Nierelacyjne bazy danych są sto­so­wa­ne od daw­na (ich histo­ria się­ga dalej niż sys­te­mów rela­cyj­nych). Moim zda­niem obec­nie sta­ły się w koń­cu popu­lar­ne i sto­so­wa­ne na sze­ro­ką ska­lę z uwa­gi na dostęp­ność w mia­rę tanich zaso­bów. Niestety ich pię­tą achil­le­so­wą jest wła­śnie zaso­bo­żer­ność. Bazy rela­cyj­ne nadal będą wyko­rzy­sty­wa­ne ze wzglę­du na spój­ność, któ­rą gwa­ran­tu­ją, brak redun­dan­cji i moż­li­wo­ści stan­da­ry­zo­wa­ne­go języ­ka SQL. Właśnie tych cech bra­ku­je bazom NoSQL. Obecnie cie­ka­wym tren­dem jest łącze­nie moż­li­wo­ści obu świa­tów – imple­men­ta­cja funk­cjo­nal­no­ści baz NoSQL w ramach rela­cyj­nych baz danych (co cie­ka­we odwrot­na sytu­acja nie ma miej­sca). Te dwa uzu­peł­nia­ją­ce się narzę­dzia nale­ży wyko­rzy­stać do odpo­wia­da­ją­cych im zadań. W więk­szo­ści pro­jek­tów ide­al­nym roz­wią­za­niem jest uży­cie moc­nych stron każ­de­go z rozwiązań.

    • Jarosław Żeliński 7 grudnia 2021 at 01:40

      Owszem, model relacyjny/SQL powstał w 1972 roku, wcze­śniej były inne. Kluczowym pro­ble­mem mode­lu rela­cyj­ne­go bez redun­dan­cji jest jest strat­ność: bez zapy­tań SQL rela­cyj­ne tabe­le danych to śmiet­nik a nie doku­men­ty. To jakieś dane. Co do zaso­bo­żer­no­ści baz NoSQL to testy wydaj­no­ści poka­zu­ją coś zupeł­nie odwrot­ne­go: pobra­nie doku­men­tu z bazy doku­men­to­wej jest nawet 1000 (tysiąc razy) szyb­sze niz na tej samej maszy­nie z SQL. Zorganizowanie nie­rel­zyj­ne­go mode­lu na moto­rze np. MS SQL itp. nie jest żad­nym pro­ble­mem, wie­le sys­te­mów uży­wa tych moto­rów do zarzą­dza­nia nie­po­wią­za­ny­mi tabe­la­mi. Stare wzor­ce obiek­to­we utrwa­la­nia takie jak Active Table czy Active Records są uży­wa­ne od wie­lu lat. Jednak takie sys­te­my jak sklep Amazon czy eBay na mode­lu rela­cyj­nym nie mają racji bytu. Osobiście nie widzę dzi­siaj żad­nej prze­wa­gi baz rela­cyj­nych: są sztyw­ne i beto­nu­ją struk­tu­ry danych. Po dru­gie nie ma tam doku­men­tów a tyl­ko dane i zapy­ta­nia SQL, któ­re osią­ga­ją mon­stru­al­ne dłu­go­ści już przy śred­nio zło­żo­nych doku­men­tach o zmien­nej w cza­sie struk­tu­rze i słownikach.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.