Welcome Guest Search | Active Topics | Members | Log In

Przestrzenie krotek / Globaly Sklad / indeksowanie rozproszone oparte o pamiec asocjacyjna Options · View
mich
Posted: Monday, May 19, 2008 6:17:53 PM

Rank: Member

Joined: 3/21/2007
Posts: 19
Points: 45
Location: UMK Toruń
Byc moze ciekawym problemem bylaby implementacja nowego typu modulu odry jako przestrzeni obiektow przy uzyciu JavaSpaces. Pomysl generalnie powstal w latach 80 (David Gelernter - tuple spaces; implementacja Linda) i polegal na zbudowaniu globalnego skladu opierajacego sie o paradygmat dzielonej, wirtualnej pamieci asocjacyjnej. Na takim skladzie mozliwe bylo wykonanie operacji: read object, write object, take object, eval object. Implementacja w Javie oparta o Jini jest bardzo fajna pod tym wzgledem, ze jest transakcyjna (za darmo z jini) oraz posiada rozproszony indeks (nie dokonca jeszcze wiem jak on dziala ale wlasnie zglebiam problem). Generalnie gdy chcemy jakos obiekt z JavaSpaces nie interesuje nas gdzie on jest i jaka jest jego nazwa, tylko tworzy sie szablon dopasowania obiektow na ktoreym operacja read albo take zwraca list obiektow.

Jest tutaj kilka ciekawych problemow: Jak odwzorowac metamodel na obiekty w JavaSpace aby bylo to ideologicznie oraz efektywnie logiczne? Czy do przestrzeni JavaSpace wrzucac metamodel czy same obiekty (w drugim przypadku optymalizacje selekcji dostaje sie praktycznie za darmo)? A moze warto przyjrzec sie pomyslowi Gelerntera od samego poczatku i tworzyc to samodzielnie?

Chialem jeszcze tylko zauwazyc, ze wykorzystanie jxta do implementacji koncepcji Globalnego Skladu moze byc trzoszke klopotliwe efektywnie, z racji tego, iz wtedy kazdy obiekt trzeba opisywac anosnem xml-owym, a anonsowanie uslugi bazodanowej w platformie jxta moze utrudniac optymalizacje; inaczej: w moim wrazeniu jxta lepiej sie zachowuje przy rozpraszaniu uslug a Tuple Spaces radzi sobie lepiej z dzieleniem i indeksowaniem obiektow.
stencel
Posted: Tuesday, May 20, 2008 12:07:27 AM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Jakos mi ten pomysl do baz danych nie bardzo pasuje. Ale moze jestem zbyt konserwatywny?

Operacje na bazie danych to wstwienie obiektu (linda_put), odczyt-zapytanie (linda_read), modyfikacja (linda_kaput? - bo raczej tylko take i put), usuniecie (linda_take). Jakos mi to wszystko do baz danych nie pasuje. Znowu moze to byc wynik uprzedzen, o czym uprzedzilem wczesniej.

1. Nie wiem, jak w tym takiej przestrzeni obsluzyc transakcje? Kazda modyfikacja obiektu to take/put.

2. Nie wiem, jak zalatwic pointery i ich spojnosc referencyjna.

3. Nie badzo pasuje mi calosc ze wzgledu na duza odleglosc takiej implementacji od modelu pojeciowego bazy danych.


A jakie Pan widzi zalety?
mich
Posted: Tuesday, May 20, 2008 12:28:09 AM

Rank: Member

Joined: 3/21/2007
Posts: 19
Points: 45
Location: UMK Toruń
stencel wrote:
Operacje na bazie danych to wstwienie obiektu (linda_put), odczyt-zapytanie (linda_read), modyfikacja (linda_kaput? - bo raczej tylko take i put), usuniecie (linda_take). Jakos mi to wszystko do baz danych nie pasuje. Znowu moze to byc wynik uprzedzen, o czym uprzedzilem wczesniej.


modyfikacja -> linda_read; program_zrob_cos; linda_put
modyfikacja z blokowaniem do edycji -> linda_take; program_zrob_cos; linda_put

to jest tylko model fizyczny, o czymś takim użytkownik w ogóle nie powinien wiedzieć; moim zdaniem to jest bardzo prosty elegancki i efektywny sposób na stworzenie platformy komunikacyjnej dla Global Stora z interfejsem w SBQL. Podkreślam że chodzi o model fizycznej komunikacji.
Powstaje bardzo dużo implementacji na różne języki do koncepcji TupleSpace, tylko rzadko słyszę o jakiś spektakulranych przypadkach wdrożeń, a z drugiej strony jakoś nie widzę też słusznej krytyki tej koncepcji.

stencel wrote:
1. Nie wiem, jak w tym takiej przestrzeni obsluzyc transakcje? Kazda modyfikacja obiektu to take/put.

transakce załatwia JINI, a poziomy izolacji transakcji są bardzo podobne do tych ze standardu JDO, więc chyba dobra droga;
z drugiej strony można zimplementować to w taki sposób, że robi się take na obiekcie JS reprezentującym obiekt metamodelu SBQL, a put na samych obiektach a potem znowu put na obiekcie metamodelu - jest tutaj wiele możliwości implementacji: ogranicza nas tylko nasza fantazja
stencel wrote:
2. Nie wiem, jak zalatwic pointery i ich spojnosc referencyjna.

fakt... tak na szybko to przecież model danych w TupleSpace można wzbogacić o lokalizacje danych ... no tak i koncepcje ziarna chyba już mamy załatwioną?
stencel wrote:
3. Nie badzo pasuje mi calosc ze wzgledu na duza odleglosc takiej implementacji od modelu pojeciowego bazy danych.

i właśnie to mnie troche dziwi... modele danych w SBQL i w JavaSpaces są praktycznie identyczne; Wykorzystanie takiego GlobalStora, no nie wiem, chociażby w klastrach (Oracle RAC); moim zdaniem z racji modelu danych te koncepcje są tak blisko, że implementacja ich powinna być szalenie prosta, a samo użycie to przecież jest horyzontalny podział danych, redundancje, replikacje...


stencel wrote:
A jakie Pan widzi zalety?

same!
a tak naprawdę to chodzi mi o elegancje koncepcji komunikacji i potencjalne możliwości optymalizacyjne. Gridowcy od nas twierdzą, że indeksacja rozproszonych zasobów to bardzo trudna spraw (no i się zgadzam); Indeks JXTA SRDI jest strasznie xmlowo rozgadany a inne systemy jakoś powstają i jakoś prędko upadają; ostatnio spędziłem dużo czasu na ewaluacje różnych systemów gridowych i dziwi mnie że tak ideologicznie zamknięty i spójny system jest pomijany, więc chyba warty przyjrzeniu się?
subieta
Posted: Tuesday, May 20, 2008 6:54:05 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Pamieci asocjacyjne byly nadzieja baz danych w koncu lat 70-tych i mniej wiecej do polowy 80-tych. Mialy zrewolucjonizowac dziedzine baz danych poprzez bardzo szybkie wyszukiwanie na podstawie klucza wyszukiwawczego, ktory byl ciagiem bitow. Nie bylo adresow, ciag bitow mogl reprezentowac np. nazwisko, zas analogiczny ciag bitow w skladzie dawal mozliwosc uzyskania natychmiastowego wyniku dla calego rekordu z tym nazwiskiem. Cos tam jeszcze bylo z maskowaniem czesci bitow, ale zapomnialem. Pomysl byl realizowany w hardware, ale bylo oczywiscie masa symulatorow software-owych.

Jeden facet z IPI, ktory sie tym zajmowal, przepowiedzial mi publicznie na instytutowym seminarium, ze gdy te pamieci wejda do uzytku, to cala moja dzialalnosc i w ogole cala dziedzina baz danych stracą sens, gdyz te pamieci rozwiazuja wszystkie bazo-danowe problemy. Jak zwykle w podobnych przypadkach, przeszkoda w szerokim wdrozeniu pamieci asocjacyjnych byla ich zbyt waska specjalizacja. Dawaly one wylacznie mozliwość jednoaspektowego wyszukiwania (np. po nazwisku, ale juz nie po zawodzie) i jako takie bylyby swietne jako szybkie indeksy. Byc moze w tej roli jeszcze kiedys wroca, jako szybkie hardware-owe urzadzenia indeksujace. Druga wada polegala na dosc sztywnym formacie klucza wyszukiwawczego. Przypuszczalnie to zadecydowalo, ze mimo wielu prototypow pamieci asocjacyjne nie weszly do powszechnego uzytku i pod koniec lat 80-tych o nich zapomniano.

Trudno mi wyczuc, jaka bylaby zaleta pamieci asocjacyjnej zorganizowanej software-owo. Moim zdaniem, jest to po prostu szybki jednoaspektowy indeks. Metod organizacji szybkich indeksow jest sporo, np. indeksy bazujace na B-drzewach lub na hash coding. Byc moze jakas nowa konfiguracja funkcjonalnosci zaimplementowana w JavaSpaces stwarza istotna nowa jakosc. Postep odbywa sie na poziomie, ktory nie jest widoczny dla uzytkownika, zatem wszystko, co mozna osiagnac, to przyspieszenie dzialania. Jezeli ktos ma chec i czas, to moze to sprawdzic, ale poniewaz efekty moga byc widoczne tylko na duzych aplikacjach, to nie jestem pewien, czy juz nadszedla taki czas dla systemu ODRA. Pozostale zalety, takie jak rozproszenie, transakcyjnosc, itd. sa prawie na pewno przykrojone do poziomu fizycznego, w zwiazku z czym niekoniecznie beda dzialac na poziomie, na ktorym pracuje SBQL.
BrettLee
Posted: Wednesday, December 24, 2008 10:57:23 AM
Rank: Guest

Joined: 12/6/2004
Posts: -20
Points: -2,000
Zakupiono pamięci operacyjne i masowe, CD-ROM-y, karty rozszerzeń do PC. .... Wykazano, że rodziny przestrzeni aproksymacyjnych (indeksowane parametrami).Ostatnio zaczęły powstawać systemy rozproszonych baz danych, tj. takie, ...... wyszukiwanie paradygmatyczne w oparciu o indeksowanie asocjacyjne zapytania.
jacenty
Posted: Thursday, December 25, 2008 4:49:40 AM
Rank: Advanced Member

Joined: 4/11/2006
Posts: 130
Points: -22
Location: Łódź
Przepraszam, ale nie do konca rozumiem przekaz plynacy z postu. Prawde mowiac - w ogole go nie rozumiem :/
subieta
Posted: Thursday, December 25, 2008 7:23:28 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
jacenty wrote:
Przepraszam, ale nie do konca rozumiem przekaz plynacy z postu. Prawde mowiac - w ogole go nie rozumiem :/

Tu nie ma co rozumieć. Pomroczność jasna. Dla nas to argument za tym, aby to forum bylo niedostepne dla trolli i wszelkiego innego plugastwa, ktore albo chce sie popisac albo zaszkodzic.
Users browsing this topic
Guest


Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Main Forum RSS : RSS

Powered by Yet Another Forum.net version 1.9.1.6 (NET v2.0) - 11/14/2007
Copyright © 2003-2006 Yet Another Forum.net. All rights reserved.
This page was generated in 0.096 seconds.