Welcome Guest Search | Active Topics | Members | Log In

Strumieniowe przetwarzanie SBQL Options · View
stencel
Posted: Sunday, June 14, 2009 10:57:24 AM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
subieta wrote:
ptab wrote:
Wpuściłem to zapytanie w metodę budowania ,,strumieniowego query-planu'' (więcej o tej metodzie tutaj: http://jloxim.mimuw.edu.pl/svn/trunk/docs/our_papers/sbql_streaming/eng/sbql_streaming.pdf):

I wyszła mi taka sieć obliczeniowa: http://jloxim.mimuw.edu.pl/svn/trunk/docs/our_papers/sbql_streaming/imgs/nets/DoubleIndependend.jpg

Sądzę, że ta sieć pracuje prawidłowo i częściwo niezależne podzapytania zostały "wychwycone", ale problem "mixturowy" nie został rozwiązany.

1. (Emp as e) oraz ((`Dept` WHERE (`manager`.(`Emp`.`salary` > 2000))) AS `d`) liczą się na początku zupełnie niezależnie.
2. Komponenty <Merge>[0,3,4], <Struct>, <MakeBag>[0,3] przekształcają na bieżąco wyniki z punktu 1 w bag structów e i d
3. Niestety dla kolejnych structów w tym bagu jest uruchamiane podzapytanie: sum((`d`.(`employs`.(`Emp`.`salary`))))

Wydaje mi się, że oczyszczając tę sieć dało by się przesunąć wiązanie d ponad struct'a (czyli podobnie jak w metodzie martywych podzapytań).

Próbowałem zapoznać sie z metodą strumieniową, wydaje się, ze trzeba jeszcze popracować nad prezentacją materiału. Szczególnie niejasne są motywacje co do wprowadzonych pojęć oraz uwikłanie koncepcji w matematyczne definicje, których celu i znaczenia trudno się doszukać. Potrzebny jest jakis prosty przykład na samym poczatku, ktory wyjaśniałby łopatologicznie o co w tym wszystkim chodzi.

Poniewaz temat posrednio dotyczy systemu ODRA, albo trzeba wyodrebnic oddzielny temat, albo dyskusje przeniesc na forum Loxima.


Piotrze, wrzuc tu prosze przyklad sieci dla

Code:
Prac where Zar > 100


Oczywisce dalej pracujemy nad artykulem, ale dyskusja i ocena koncepcji na tym forum, beda niezwykle cenne.
ptab
Posted: Sunday, June 14, 2009 1:41:43 PM
Rank: Newbie

Joined: 11/26/2008
Posts: 7
Points: 21
Location: Warsaw
stencel wrote:
subieta wrote:

Próbowałem zapoznać sie z metodą strumieniową, wydaje się, ze trzeba jeszcze popracować nad prezentacją materiału. Szczególnie niejasne są motywacje co do wprowadzonych pojęć oraz uwikłanie koncepcji w matematyczne definicje, których celu i znaczenia trudno się doszukać. Potrzebny jest jakis prosty przykład na samym poczatku, ktory wyjaśniałby łopatologicznie o co w tym wszystkim chodzi.

Poniewaz temat posrednio dotyczy systemu ODRA, albo trzeba wyodrebnic oddzielny temat, albo dyskusje przeniesc na forum Loxima.


Piotrze, wrzuc tu prosze przyklad sieci dla

Code:
Prac where Zar > 100


Oczywisce dalej pracujemy nad artykulem, ale dyskusja i ocena koncepcji na tym forum, beda niezwykle cenne.


Sieć dla w/w przykładu umieściłem tutaj: http://jloxim.mimuw.edu.pl/svn/trunk/docs/our_papers/sbql_streaming/imgs/nets/EmpSalGt100.jpg (dopisałem typy Resultset* komunikatów na poszczególnych strumieniach).

Sam nie jestem wielbicielem formalizmów, ale użyte w tej pracy mają na celu zaspokoić ich wielbicieli. Starałem się pisać wszędzie najpierw o co chodzi, a później domykać definicję ,,ścisłą postacią'', by odebrać
argument, że koncepcja jest niespójna.

Aby mieć pewność zrozumienia, rozpiszę szczegółowo co po poszczególnych strumieniach przepłynie (w implementacji komunikat przesyła się jak ciąg zdarzeń SAX i przetwarza w locie, więc nie będą to "ogromne paczki" ):

Dane wejściowe:
Code:

<superroot>
    <Emp><name>Nowak</name><sal>120</sal></Emp>
    <Emp><name>Kowalski</name><sal>50</sal></Emp>
    <Emp><name>Nóżka</name><sal>110</sal></Emp>
</superroot>


Start --> Stamp<0> 1 komunikat:

Code:

[(pusty rekord sterujący)],
<superroot>
    <Emp><name>Nowak</name><sal>120</sal></Emp>
    <Emp><name>Kowalski</name><sal>50</sal></Emp>
    <Emp><name>Nóżka</name><sal>110</sal></Emp>
</superroot>


Stamp<0> --> GetNested<Emp> 1 komunikat:

Code:

[0->1],
<superroot>
    <Emp><name>Nowak</name><sal>120</sal></Emp>
    <Emp><name>Kowalski</name><sal>50</sal></Emp>
    <Emp><name>Nóżka</name><sal>110</sal></Emp>
</superroot>


Stamp<1> --> BreakBag 1 komunikat:

Code:

[0->1,1->1],
bag{
    <Emp><name>Nowak</name><sal>120</sal></Emp>
    <Emp><name>Kowalski</name><sal>50</sal></Emp>
    <Emp><name>Nóżka</name><sal>110</sal></Emp>
}


BreakBag --> Stamp<2> 3 komunikaty:

Code:

[0->1,1->1] <Emp><name>Nowak</name><sal>120</sal></Emp>
[0->1,1->1] <Emp><name>Kowalski</name><sal>50</sal></Emp>
[0->1,1->1] <Emp><name>Nóżka</name><sal>110</sal></Emp>


Stamp<2> --> <GetNested>Sal oraz <Merge>[0,1,2]

Code:

[0->1,1->1,2->1] <Emp><name>Nowak</name><sal>120</sal></Emp>
[0->1,1->1,2->2] <Emp><name>Kowalski</name><sal>50</sal></Emp>
[0->1,1->1,2->3] <Emp><name>Nóżka</name><sal>110</sal></Emp>


Stamp<3> --> <GetNested>Sal oraz <Merge>[0,1,2]

Code:

[0->1,1->1,2->1] <Emp><name>Nowak</name><sal>120</sal></Emp>
[0->1,1->1,2->2] <Emp><name>Kowalski</name><sal>50</sal></Emp>
[0->1,1->1,2->3] <Emp><name>Nóżka</name><sal>110</sal></Emp>


<GetNested>Sal --> <Merge>[0,2]:
Code:

[0->1,1->1,2->1] <sal>120</sal>
[0->1,1->1,2->2] <sal>50</sal>
[0->1,1->1,2->3] <sal>110</sal>


100 --> <Merge>[0,2]:
Code:

[pusty rekord kontrolny] 100



<Merge>[0,2] -> <>>
Code:

[0->1,2->1] (<sal>120</sal>,100)
[0->1,2->2] (<sal>50</sal>,100)
[0->1,2->3] (<sal>110</sal>,100)


<>> --> Merge[0,1,2]
Code:

[0->1,2->1] true
[0->1,2->2] false
[0->1,2->3] true


Merge[0,1,2] -->Select
Code:

[0->1,1->1,2->1] (<Emp><name>Nowak</name><sal>120</sal></Emp>,true)
[0->1,1->1,2->2] (<Emp><name>Kowalski</name><sal>50</sal></Emp>,false)
[0->1,1->1,2->3] (<Emp><name>Nóżka</name><sal>110</sal></Emp>,true)


<Stamp>1 --> <MakeBag>[0,1]
Code:

[0->1,1->1]


Select -->MakeBag[0,1]
Code:

[0->1,1->1] <Emp><name>Nowak</name><sal>120</sal></Emp>
[0->1,1->1] <Emp><name>Nóżka</name><sal>110</sal></Emp>


MakeBag[0,1] --> Result
Code:

[0->1,1->1]  bag{
    <Emp><name>Nowak</name><sal>120</sal></Emp>
    <Emp><name>Nóżka</name><sal>110</sal></Emp>
}


Tą sieć da się automatycznie uprościć (np. <Stamp>0 i <Stamp>1 można złączyć w 1 - bo nie wnoszą wiele do sprawy), ale to tematyka następnego paper'a.
stencel
Posted: Sunday, June 14, 2009 1:53:39 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
subieta wrote:
Szczególnie niejasne są motywacje co do wprowadzonych pojęć oraz uwikłanie koncepcji w matematyczne definicje, których celu i znaczenia trudno się doszukać.


Znam Piotra juz sporo czasu i wiem, ze matematyczne definicje to jest ostatnie co by chcial promowac. Koncepcja i implementacja, tu sie lubi wyzyc.

Calosc jest po to zeby:

1. Zrownoleglic/rozproszyc obliczenia na wielu jednostkach obliczeniowych.

Nie ma na razie po 2 (chyba).

EDIT: /* No tak. Shame on me. Zobaczcie nastepny post */
ptab
Posted: Sunday, June 14, 2009 2:03:23 PM
Rank: Newbie

Joined: 11/26/2008
Posts: 7
Points: 21
Location: Warsaw
Uwagi notacyjne do powyższego przykładu:

1. Oczywiście <Znacznik>...</Znacznik> oznacza element składu, z którym związany jest OID. Więc ściślej należałoby zapisywać <Emp oid="..."></Emp> (w treści pracy takie elementy ResultSet'a to są te nowe objRef'y, czyli referencja do obiektu ze zmaterializowaną zawartością obiektu)

2. Rekordy kontrolen prezentowałem jako [a->x, b->y, c->z], by podkreślić związek pomiędzy parametrem Merge,Stamp,MakeBag a pozycjami. Oczywiście
wygodniejsza jest notacja zaproponowana przez Krzysztofa:

Code:

[1,1,1] <Emp><name>Nowak</name><sal>120</sal></Emp>
[1,1,2] <Emp><name>Kowalski</name><sal>50</sal></Emp>
[1,1,3] <Emp><name>Nóżka</name><sal>110</sal></Emp>

A jak jest pusta pozycja, to -

[1,-,1] (<sal>120</sal>,100)
[1,-,2] (<sal>50</sal>,100)
[1,-,3] (<sal>110</sal>,100)


Quote:

Calosc jest po to zeby:
1. Zrownoleglic/rozproszyc obliczenia na wielu jednostkach obliczeniowych.
Nie ma na razie po 2 (chyba).


Rozdział ,,motywacja'' w pracy ma kilka punktów więcej. Ja wierze, że takie sieci to dobra postać do dalszych (nowych) optymalizacji.
subieta
Posted: Sunday, June 14, 2009 9:07:08 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
ptab wrote:
Sam nie jestem wielbicielem formalizmów, ale użyte w tej pracy mają na celu zaspokoić ich wielbicieli.

Moim zdaniem, zbędny wysiłek. Przypodobanie sie twórczym impotentom, którzy nie widzą nic poza formalizmami, wczesniej czy pozniej skonczy sie mega frustracją, tak jak u mnie. Albo staramy sie zrozumiec problem i go sensownie rozwiązać, albo staramy sie przypodobac informatycznym pasożytom, nazywajacymi siebie "teoretykami informatyki". Niech sami zostaną ze swoimi gównianymi, bezużytecznymi pseudo-teoriami, my na tym terenie nie mamy nic do roboty. W koncu i tak powiedza "no tak, to są definicje, a gdzie są lematy i twierdzenia?". Jakie twierdzenia można udowodnić przy tak złożonym tworze formalnym?
ptab
Posted: Monday, June 15, 2009 12:09:25 PM
Rank: Newbie

Joined: 11/26/2008
Posts: 7
Points: 21
Location: Warsaw
subieta wrote:
Jakie twierdzenia można udowodnić przy tak złożonym tworze formalnym?


Czy jest to pytanie retoryczne?

Możnaby się silić na dowodzenie równoważności sieci przy pewnych jej przekształceniach - ale się zgadzam, że wartości dodanej dla przemysłu to nie przyniesie.
stencel
Posted: Monday, June 15, 2009 12:11:45 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
ptab wrote:
Możnaby się silić na dowodzenie równoważności sieci przy pewnych jej przekształceniach - ale się zgadzam, że wartości dodanej dla przemysłu to nie przyniesie.


Zdecydowanie nie. Wartoscia tych badan jest postep w egzekucji zapytan. Twierdzen nie bedziemy dowodzic raczej. Po prostu udowodnimy inaczej, ze to co proponujemy daje korzysci.
subieta
Posted: Monday, June 15, 2009 12:36:47 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
stencel wrote:
ptab wrote:
Możnaby się silić na dowodzenie równoważności sieci przy pewnych jej przekształceniach - ale się zgadzam, że wartości dodanej dla przemysłu to nie przyniesie.


Zdecydowanie nie. Wartoscia tych badan jest postep w egzekucji zapytan. Twierdzen nie bedziemy dowodzic raczej. Po prostu udowodnimy inaczej, ze to co proponujemy daje korzysci.


Niestety RWMIM UW ma uprawnienia tylko do nauk matematycznych. Brak dowodów matematycznych oznacza przewód poza tą Radą. Natomiast dowody będą durną scholastyczną zabawą. Dobrze byłoby wyjaśnić na wstępie, czy w przypadku tego doktoratu jest możliwe otwarcie przewodu z nauk technicznych.
stencel
Posted: Monday, June 15, 2009 12:45:54 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
subieta wrote:
Dobrze byłoby wyjaśnić na wstępie, czy w przypadku tego doktoratu jest możliwe otwarcie przewodu z nauk technicznych.


Jest. W ogole nie ma co do tego watpliwosci. Przewod doktorski moze byc otwarty przez inna instytucje niz ta ktora prowadzi studium doktoranckie (Piotr studiuje na MIMUW).
rt
Posted: Wednesday, June 17, 2009 3:27:37 PM
Rank: Member

Joined: 6/2/2005
Posts: 24
Points: -46
Location: mokotow
rodzą sie dwa pytania

1) W jakim stopniu przetwarzanie strumieniowe jest nowe dla wykonania zapytań na db. Mam wrażenie ze nie jest to koncepcja całkowicie oryginalna - ale to raczej intuicja niż konkretne fakty. Proszę o komentarz odautorski.

2) (to ważniejsze pytanie) Czy obecna implementacja jloxim da sie łatwo przenieść do architektury sn (http://en.wikipedia.org/wiki/Shared_nothing_architecture) ; jeśli nie to czy samo przetwarzanie strumieniowe w kontekście stosowych zapytań
da sie wykonać na sn ?

pytam się z powodu prostego. obecnie w firmie dla której pracuje zajmuje sie wybraniem platformy do hurtowni danych (nie. nie myślimy o loxim ;p). nie byłem ekspertem w dziedzinie ale trochę już wiem. wygląda na to ze jedyne sensowne rozwiązania skalujące sie dowolnie to właśnie oparte na sn. dlatego sie pytam
ptab
Posted: Wednesday, June 17, 2009 3:50:19 PM
Rank: Newbie

Joined: 11/26/2008
Posts: 7
Points: 21
Location: Warsaw
rt wrote:
1) W jakim stopniu przetwarzanie strumieniowe jest nowe dla wykonania zapytan na db. Mam wrazenie ze nie jest to koncepcja calkowicie orginalna - ale to raczej intuicja niz konkretne fakty. Prosze o komentarz odautorski


Sama koncepcja przetwarzania strumieniowego jest stara pewnie jak irygacja wzdłuż rzeki Nil. Dla relacyjnych zapytań, query plan zbudowany na podstawie algeby relacyjnej pewnie jest przetwarzany wzdłuż jakiegoś grafu przekształceń (co np. MSSQL ładnie potrafi pokazać na obrazku). Podobnie SAXON przy obsłudze XQuery i XPath używa pipelineing'u i streamingu (http://sites.computer.org/debull/A08dec/saxonica.pdf), ale dość wąsko wykorzystuje te pojącia (streaming => równoległość odczytu i przetwarzania, pipelining => interpretacja zapytania oparta o przechodzenie danych przez kolejne warstwy, ale bardziej jako kolejne wywołania metod ,,w głąb'' niż zostawienie miejsca dla asynchronicznej komunikacji).

Prac wprost na tamat strumieniowego przetwarzania języków takich jak OQL, SBQL, i XQuery nie znalazłem. Bardzo okrojony podzbiór strumieniowania i tak prostego języka XPath jest opisany tutaj: http://portal.acm.org/citation.cfm?id=1247480.1247512. Trochę też walczy na tym froncie MonetDB ze swoim silnikiem XQuery: http://monetdb.cwi.nl/projects/monetdb/XQuery/index.html - ale tam to tłumaczą na operacje relacyjne.

rt wrote:
2) (to wazniejsze pytania) Czy obecna implementacja jloxim da sie latwo przeniesc do arhitektury sn (http://en.wikipedia.org/wiki/Shared_nothing_architecture) ; jesli nie to czy samo przetwarzanie strumieniowe w kontekscie stosowyh zapytan da sie wykonac na sn ?


Obecna implementacja JLoXiM'a zawiera jak na razie prymitywny egzekutor stosowy. Posiadamy też Query Planer, który tworzy strumieniowe plany zapytań i przedstawia je w formie rysunków. Prawdopodobnie w przyszłym roku
studenci zostaną poproszeni o implementacje podejścia strumieniowego. Postaramy się, żeby te komponenty można było wykorzystać zarówno w ramach przetwarzania w obrębie jednego komputera jak i w modelu wielo-agentowym (czyli pewnie założenie o Shared Nothing but streams) zostanie spełnione.

Sporo zależy też od tego też jak sobie wyobrażamy Store w architekturze SN: Uznajemy, że store jest poza problemem ? Uznajemy, że dane są w kawałkach rozmazane po wszyskich maszynach uczestniczących w obliczeniu ? Uznajemy, że drzewo danych jest spartycjonowane i różne jego fragmenty są na różnych maszynach...

rt wrote:
Pytam sie z powodu prostego. obecnie w firmie gdzie pracuje zajmuje sie wybraniem platformy do dw (nie nie myslimy o loxim ;p). nie bylem ekspertem w dziedzinie ale trohe juz wiem. wyglada na to ze jedyne sensowne rozwiazania skalujace sie dowlonie to wlasnie oparte na sn.


Nie znam klasy problemu, ale moze jakiś partycjonowanie wystarczy, albo Gemius File System (http://www.moosefs.com/)
JLoxim jak na razie zdecydowanie nie... (ten system ma dopiero niecały rok studenckiego dziergania)
rt
Posted: Friday, June 19, 2009 12:09:12 PM
Rank: Member

Joined: 6/2/2005
Posts: 24
Points: -46
Location: mokotow
ptab wrote:

rt wrote:
2) (to wazniejsze pytania) Czy obecna implementacja jloxim da sie latwo przeniesc do arhitektury sn (http://en.wikipedia.org/wiki/Shared_nothing_architecture) ; jesli nie to czy samo przetwarzanie strumieniowe w kontekscie stosowyh zapytan da sie wykonac na sn ?


Obecna implementacja JLoXiM'a zawiera jak na razie prymitywny egzekutor stosowy. Posiadamy też Query Planer, który tworzy strumieniowe plany zapytań i przedstawia je w formie rysunków. Prawdopodobnie w przyszłym roku
studenci zostaną poproszeni o implementacje podejścia strumieniowego. Postaramy się, żeby te komponenty można było wykorzystać zarówno w ramach przetwarzania w obrębie jednego komputera jak i w modelu wielo-agentowym (czyli pewnie założenie o Shared Nothing but streams) zostanie spełnione.


diabeł tkwi w szczegółach. a i pojecie Shared Nothing podlega jakimś tam dyskusjom - a w szczególności podlega użyciu marketingowemu :O)

nie jestem tutaj ekspertem wiec powstrzymam sie od spekulacji

chodzi mi o Twoja analizę jakie elementy w aktualnej wizji przetwarzania strumieniowego (w szczególności będącego ekwiwalentem zapytania w języku stosowym) mogą stanowic potencjalne zagrożenie do sn

ze store to rzecz pewna :O) i nie wiem czy można o nim zapomnieć i rozpatrywać w oderwaniu od niego. ale może są przy pomijaniu kwestii store jakieś ograniczenia dla sn strumieniowej ewaluacji zapytań stosowych ?

generalnie sprawa jest myślę dość istotna. podejście stosowe jak wiemy nadaje sie idealnie do biznesowych systemów transakcyjnych online. wszyscy sie tutaj zgodzimy :O) a bez linowo skalującej sie równoległości daleko sie nie zajdzie. inaczej: nie zajdzie sie tam gdzie jest prawdziwa konkurencja.


ptab wrote:
Sporo zależy też od tego też jak sobie wyobrażamy Store w architekturze SN: Uznajemy, że store jest poza problemem ? Uznajemy, że dane są w kawałkach rozmazane po wszyskich maszynach uczestniczących w obliczeniu ? Uznajemy, że drzewo danych jest spartycjonowane i różne jego fragmenty są na różnych maszynach...


:O))))))

no właśnie. są tutaj konkretne odpowiedzi a myślę dużo zależy od reszty - tzn od tego jak jest ona zrobiona. np spotkałem sie z opiniążze w przypadku sn z kilkoma enterprise features typu fault tolerance (chodzi o topowy w biz, engine teradata) najlepsze jest ..równomierne i przypadkowe rozmieszczenie danych....

ptab wrote:

rt wrote:
Pytam sie z powodu prostego. obecnie w firmie gdzie pracuje zajmuje sie wybraniem platformy do dw (nie nie myslimy o loxim ;p). nie bylem ekspertem w dziedzinie ale trohe juz wiem. wyglada na to ze jedyne sensowne rozwiazania skalujace sie dowlonie to wlasnie oparte na sn.


Nie znam klasy problemu, ale moze jakiś partycjonowanie wystarczy, albo Gemius File System (http://www.moosefs.com/)
JLoxim jak na razie zdecydowanie nie... (ten system ma dopiero niecały rok studenckiego dziergania)


problem zupełnie typowy. transakcyjny system nie daje rady jako store dla narzędzi raportowych. transakcyjny to stojący na aixie orakl. narzędzie analityczne to na razie sas ale może zrobimy cos sami (za dużo data mining ;ppp)

rozwiązania takie jak monet odpadają z prostego powodu - nie maja konektorów do sas ani nawet wsparcia dla czegoś generycznego ale standardowego (ole db/odbc)

jeśli chodzi o hurtownie to ms ma super narzędzia i jest super tani ale ma problemy z skalowalnością powyżej pewnych granic. fajny jest ibm (true sn) no i teradata tez ma sn tyle ze jest nie życiowa w utrzymaniu (np założenie indeksu wymaga drop table)
stencel
Posted: Friday, June 19, 2009 12:14:45 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Bardzo prosze o uzywanie spell-checkera. Zeby mnie bola po tej lekturze. Ew. dysortografia nie ma tu nic do rzeczy, skoro sa przeciez dostepne narzedzia do poprawiania pisowni.
rt
Posted: Friday, June 19, 2009 12:37:08 PM
Rank: Member

Joined: 6/2/2005
Posts: 24
Points: -46
Location: mokotow
stencel wrote:
Bardzo prosze o uzywanie spell-checkera. Zeby mnie bola po tej lekturze. Ew. dysortografia nie ma tu nic do rzeczy, skoro sa przeciez dostepne narzedzia do poprawiania pisowni.


jak hcesz moge Ci przerobic powyzsze na polski. prosze o decyzje

jestem tu aby rozmawiac a nie wzniecac kolejny flame (w kturym i tak nie wziol bym udzialu ;p)
stencel
Posted: Friday, June 19, 2009 12:45:56 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
rt wrote:
stencel wrote:
Bardzo prosze o uzywanie spell-checkera. Zeby mnie bola po tej lekturze. Ew. dysortografia nie ma tu nic do rzeczy, skoro sa przeciez dostepne narzedzia do poprawiania pisowni.


jak hcesz moge Ci przerobic powyzsze na polski. prosze o decyzje

jestem tu aby rozmawiac a nie wzniecac kolejny flame (w kturym i tak nie wziol bym udzialu ;p)


Please, please, spell check. Naprawde to przeszkadza w odbiorze tekstu. Bardzo prosze o EDIT tej dluzszej wypowiedzi i usuniecie bledow.
rt
Posted: Friday, June 19, 2009 12:54:52 PM
Rank: Member

Joined: 6/2/2005
Posts: 24
Points: -46
Location: mokotow
stencel wrote:
rt wrote:
stencel wrote:
Bardzo prosze o uzywanie spell-checkera. Zeby mnie bola po tej lekturze. Ew. dysortografia nie ma tu nic do rzeczy, skoro sa przeciez dostepne narzedzia do poprawiania pisowni.


jak hcesz moge Ci przerobic powyzsze na polski. prosze o decyzje

jestem tu aby rozmawiac a nie wzniecac kolejny flame (w kturym i tak nie wziol bym udzialu ;p)


Please, please, spell check. Naprawde to przeszkadza w odbiorze tekstu. Bardzo prosze o EDIT tej dluzszej wypowiedzi i usuniecie bledow.


ok. za jakies 2h poprawie

w kazdym razie mysle ze kwestia strumieniowa dla sba jest wazna - zeby nie powiedziec: bardzo wazna

w kazdym razie multicore to rzeczywistosc i nie ma od niej odwrotu jesli mowa o industry use
subieta
Posted: Friday, June 19, 2009 3:21:24 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
rt wrote:
generalnie sprawa jest mysle dosc istotna. podejscie stosowe jak wiemy nadaje sie idealnie do biznesowyh systemuw tranzakcyjnyh online. wszyscy sie tutaj zgodzimy :O) a bez linjowo skalujacej sie ruwnoleglosci daleko sie nie zajdzie. inaczej: nie zajdzie sie tam gdzie jest prawdziwa konkurencja.

Samo podejscie stosowe nie wypowiada sie na temat rownoleglosci, jest to po prostu metoda specyfikacji semantyki. Kiedys rownoległością w SBA probowal sie zajmowac Prof.Catriel Beeri, moj partner z Izraela, ale niewiele z tego wyszlo, nie powstala nawet żadna praca. Oczywiscie w ramach nurtu optymalizacji zapytań powstało kilka koncepcji na masową rownoległość in-query oraz out-query. Metody in-query probują zrobic rownoleglowsc dla okreslonej fragmentacji danych oraz dla okreslonych zapytań SBQL. Sa prowadzone przeze mnie dwie prace doktorskie w tym zakresie: 1sza nt pipelining (p.Sobczuk), 2ga nt kolorowania drzew syntaktycznych kolorami serwerów (p.Murlewski). Jezeli chodzi o metody out-query, mozliwosci jest znacznie wiecej, poniewaz nie zaklada się równoległości w ramach jednego zapytania, lecz różne zapytania są wykonywane równolegle. Tutaj właściwie siedzi nasza konkurencja, gdyż tego rodzaju metod dla relacyjnych baz danych powstało trochę. Do tego nurtu pasuje również architektura rozproszona shared nothing. Raczej nie zdecydujemy się na inną architekturę, gdyż wymagałoby to istotnych zmian w hardware, co nie wchodzi w grę (np. dostęp do tego samego dysku ze strony wielu procesorów). Zatem pozostaniemy przy architekturze multi-client/multi-serwer, która jest klasyczną architekturą shared nothing. W tym nurcie jest rozwijany obecnie najnowszy grant na temat deklaratywnego workflow, gdzie zaproponowałem podejście do masowej równoległości przy pomocy pojęcia aktywnego obiektu. Poczatkowy raport jest na ukonczeniu, powstaly rowniez dwa lub trzy studenckie prototypy. Jest to poligon dla bardzo wielu prac magisterskich i doktorskich, gdyż w gruncie rzeczy to co proponuję jest odejsciem od klasycznej VonNeumanowskiej architektury komputera.

Wracając do zasadniczego wątku, jeszcze nie jestem przekonany, że matoda strumieniowa umożliwi masową równoległość. Moim zdaniem tak, ale tylko dla struktur danych i zapytań podlegających regułom pipeliningu. Na razie brakuje mi wyobraźni, czy w ramach tej metody da się osiągnąć coś więcej.
ptab
Posted: Monday, June 22, 2009 4:34:41 PM
Rank: Newbie

Joined: 11/26/2008
Posts: 7
Points: 21
Location: Warsaw
subieta wrote:

Sa prowadzone przeze mnie dwie prace doktorskie w tym zakresie: 1sza nt pipelining (p.Sobczuk), 2ga nt kolorowania drzew syntaktycznych kolorami serwerów (p.Murlewski).


Nie odnalazłem publikacji w tym zakresie. Jeśli byłyby jakieś wyniki to jestem nimi zainteresowany.

subieta wrote:

Wracając do zasadniczego wątku, jeszcze nie jestem przekonany, że matoda strumieniowa umożliwi masową równoległość. Moim zdaniem tak, ale tylko dla struktur danych i zapytań podlegających regułom pipeliningu. Na razie brakuje mi wyobraźni, czy w ramach tej metody da się osiągnąć coś więcej.


Jakie zapytania i struktury danych podlegają regułom ,,pipeliningu''? Chętnie się zmierzę z przykładowym zapytaniem spoza tego zbioru.

Mam też wątpliwości, gdzie leży granica pomiędzy potokiem/rurociągiem (pipeline) a strumieniem (stream)?
Moje rozumienie jest takie, że przez pipelining rozumiem ciąg czynności połączonych szeregowo, gdzie kolejna korzysta na bieżąco z efektów poprzedniej, a streaming pozwala budować bardziej skomplikowane struktury,
zawierające rozgałęzienia i złączenia.
ptab
Posted: Monday, June 22, 2009 6:14:17 PM
Rank: Newbie

Joined: 11/26/2008
Posts: 7
Points: 21
Location: Warsaw
rt wrote:
chodzi mi o Twoja analizę jakie elementy w aktualnej wizji przetwarzania strumieniowego (w szczególności będącego ekwiwalentem zapytania w języku stosowym) mogą stanowic potencjalne zagrożenie do sn
ze store to rzecz pewna :O)


Jedynym problemem ,,ideologicznym'' jaki widzę - jest efektywna implementacja przejścia po referencji. W tej sytuacji albo jesteśmy purystami i realizujemy to też strumieniowo (czyli zgodnie z SN, co pociąga często niestety duże koszta), albo zgadzamy się na odwołanie do store'a / indeksu i w ten sposób naruszamy zasadę SN.

Swoją drogą, SBQL - dzięki temu, że posiada jawny typ obiektu "pointerowego" i żadnych więcej ,,skoków'' to jest świetnym językiem w sensie przetwarzania strumieniowego. W językach takich jak XPath i związanych mamy osie (axis), które są takimi automatycznymi referencjami od każdego obiektu do innych obiektów (parent, sibling, ancestor,...) i każdy obiekt ma ich całą masę. A więc analiza tego, kiedy możemy się obawiać przejścia po referencji jest o wiele trudniejsza.
subieta
Posted: Monday, June 22, 2009 10:03:09 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
ptab wrote:
Jakie zapytania i struktury danych podlegają regułom ,,pipeliningu''? Chętnie się zmierzę z przykładowym zapytaniem spoza tego zbioru.

Mam też wątpliwości, gdzie leży granica pomiędzy potokiem/rurociągiem (pipeline) a strumieniem (stream)?
Moje rozumienie jest takie, że przez pipelining rozumiem ciąg czynności połączonych szeregowo, gdzie kolejna korzysta na bieżąco z efektów poprzedniej, a streaming pozwala budować bardziej skomplikowane struktury,
zawierające rozgałęzienia i złączenia.

Pipelining jest metodą optymalizacyjną, a nie innym spojrzeniem na semantykę, które oferuje streaming. Pipelining oznacza odwrócenie sytuacji przy przetwarzaniu zapytań. W klasycznym przetwarzaniu kolejno wykonują się operatory zapytania na kolejnych bagach bedacych początkowymi i pośrednimi argumentami operatorów. Pipelining odwraca tę sytuację: dla małego podzbioru wejściowego bagu wykonują sie wszystkie operatory zapytania, a cząstkowe wyniki sumuje się dla wszystkich takich podzbiorów wg pewnej reguły. Pipelining zapobiega więc wielokrotnemu pobieraniu tej samej danej z dysku lub sieci, co ma szczególne znaczenie w przetwarzaniu baz rozproszonych.

Aby tego rodzaju założenia mogły być spełnione, zarówno struktury danych jak i zapytania muszą podlegać ograniczeniom. Te ograniczenia sa właśnie przedmiotem badań. Jak rozdzielać zapytania na kawałki odnoszące się do poszczególnych fragmentów danych i jak sumować ich wyniki? Przykladowo, zapytanie:
Code:
(Prac where Nazw = "Kowalski").pracujeW.Dział.boss.Prac.Nazw

mozna potraktować jako spełniajace warunki pipelining, gdyż to samo zapytanie można wysłać na wszystkie rozproszone serwery, a następnie zsumować mnogościowo jego wyniki. Dla kwantyfikatora uniwersalnego regula jest inna: to samo zapytanie wysylamy do wszystkich serwerów, ale wynik jest koniunkcją ich odpowiedzi. Generalnie, reguły pipeliningu odnoszą się zarówno do organizacji struktur danych, zapytań i sposobów ich dekompozycji i sumowania wyników, co tworzy nietrywialny problem badawczy.
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.176 seconds.