- « Poprzednia
- 1
- 2
- 3
Marcin Przepiórowski Oracle ACE
Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]
Mariusz Masewicz:
Przy okazji - pamietaj, ze SQl Server nie jest produktem M$ tylko Sybase'a ktory podczas rozwiazywania krotkiego malzenstwa obu tych korporacji zostal przywlaszczony przez M$ - Ale to juz osobna historia i pewnie obecnie kodu zrodlowego po przodkach niewiele znajdzie sie w SQlServer 2008.
Z tym bym sie nie zgodzil - dalej wiele rzeczy nazywa sie
sp_blabla a to do zludzenia przypomina mi procedury z Sybase
(co prawda nie widzialem go od 9 lat ale to pamietam)
Mysle ze duzo bebechow zostalo - wkoncu nie kazdy ma ambicje wynalesc kolo od poczatku ;)
Mariusz
Masewicz
Prawie wszysko o
bazach danych Oracle
:-)
Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]
Marcin Przepiórowski:
Mariusz Masewicz:
Przy okazji - pamietaj, ze SQl Server nie jest produktem M$ tylko Sybase'a ktory podczas rozwiazywania krotkiego malzenstwa obu tych korporacji zostal przywlaszczony przez M$ - Ale to juz osobna historia i pewnie obecnie kodu zrodlowego po przodkach niewiele znajdzie sie w SQlServer 2008.
Z tym bym sie nie zgodzil - dalej wiele rzeczy nazywa sie
sp_blabla a to do zludzenia przypomina mi procedury z Sybase
(co prawda nie widzialem go od 9 lat ale to pamietam)
Mysle ze duzo bebechow zostalo - wkoncu nie kazdy ma ambicje wynalesc kolo od poczatku ;)
Czlowieku - sylwester za kilka godzin, wiec ja tu o % mowie. "Core" systemu to ciagle od sybasa odziedziczone, ale do tego doszlo mnooooostwo nowej funkcjonalnosci. tak wiec w tej chwili kod Sybasa to niewielki % calosci. I tym sposobem M$ coraz smielej moze mowic, ze to "ich" produkt :)
Zacheusz Siedlecki Programista Java
Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]
Może wróćmy do tematu ;)Rafał Wardas:Pierwszy test wykonałem na małej ilości danych, ale tak, że i tak przeciażyły I/O w komputerze.
Ustawiłem partycje HASH dla 100 elementów, założyłem lokalne indeksy i z tego co Zacheusz mówił to było to szybsze przy małej ilości danych i założeniu, że nie czyści się cache. Przy zrównolegleniu lub zwiększeniu ilości danych wydajność spadała ;)
W ciągu ostatnich dni wykonałem test większej liczby możliwości.
Przygotowałem program, który zadaje 718 zapytań dokładnie takich jakie zadaje jedna strona systemu na testowym zestawie danych. Zestaw danych zawiera 200k różnych TID przy czym dla jednego TID jest co najwyżej 30 różnych ITEM. Program był uruchomiony na osobnym komputerze połączonym z bazą przez jdbc przez ethernet i miał możliwość zadania tej serii zapytań z jednego wątku lub po rozdzieleniu ich na więcej. Do testu użyłem dwóch komputerów - jeden dla bazy i jeden dla programu zadającego zapytania. Obydwa miały parametry:
Intel Core 2 Quad 2.66GHz
2 GB RAM
pojedynczy dysk SATA2 7200rpm
Testowałem dwa typy zapytań (we wstępnych testach okazały się najszybsze). Pokazuję przykłady dla zbiorów 4-elementowych:
1.
SELECT count(*)
FROM
(SELECT tid
FROM TRANSACTIONS_G8
WHERE item IN (:1,:2,:3,:4) group by tid having count(*)=:5 ) subtable
2.
select count(*) from
(select tid from transactions_G8 where item=:1
intersect select tid from transactions_G8 where item=:2
intersect select tid from transactions_G8 where item=:3
intersect select tid from transactions_G8 where item=:4 )
Wypróbowałem to na trzech tabelach, które przy wstępnych próbach wydały się najszybsze:
1. IOT PARALLEL 4
2. IOT NOPARALLEL
3. PARTITION BY HASH(ITEM)PARTITIONS 100 PARALLEL 4
Każdy z testów uruchomiłem zadając zapytania z od 1 do 4 wątków.
Dokładne DDL-e oraz plany zapytań udostępniłem tutaj.
Wyniki testu znajdują się w powyższym dokumencie, ale także tutaj.
Tak więc odpowiednio:
1.1 tabela 1, zapytanie 1
1.2 tabela 1, zapytanie 2
itd.
Wyniki wydają mi się interesujące:
Marcin Przepiórowski Oracle ACE
Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]
Mariusz Masewicz:
Czlowieku - sylwester za kilka godzin, wiec ja tu o % mowie.
No to tak trzeby bylo od razu ;)
Faktycznie % mniej ale za to mozna dluzej ;)
Szczesliwego Nowego Roku dla Wszystkich ;)
Marcin
Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]
Zacheusz Siedlecki:
Tak więc odpowiednio:
1.1 tabela 1, zapytanie 1
1.2 tabela 1, zapytanie 2
itd.
Ten ostry spadek masz z powodu niedostosowania sprzętu do operacji równoległych - czyli głównie z powodu pojedynczego dysku SATA. Gdybyś dołożył jeszcze z 4 dyski i zrobił na tym RAID0 z strippingiem to spadek byłby dużo niższy.
Zacheusz Siedlecki Programista Java
Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]
Krzysztof Pułapa:To wiele tłumaczy. Dzięki. W takim razie okazuje się, że rozpartycjonowanie tej tabeli zwiększa możliwości zrównoleglenia dla takiego sprzętu (te dwie poziome linie są dla rozpartycjonowanej na 100 partycji IOT). Co ciekawe tylko w przypadku partycjonowanej tabeli drugie zapytanie (z intersect) jest szybsze niż pierwsze.Zacheusz Siedlecki edytował(a) ten post dnia 02.01.10 o godzinie 13:06
Ten ostry spadek masz z powodu niedostosowania sprzętu do operacji równoległych - czyli głównie z powodu pojedynczego dysku SATA. Gdybyś dołożył jeszcze z 4 dyski i zrobił na tym RAID0 z strippingiem to spadek byłby dużo niższy.
Zacheusz Siedlecki Programista Java
Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]
Umieszczam odpowiedź na wypowiedź Michała w tym temacie która jednak dotyczyła bieżącego wątku.Michał Z.:Dokładniej na początku był pomysł i szczegółowy projekt algorytmów, potem koncepcja i dość dokładny projekt systemu.
Na początku był pomysł na system. Potem pojawił się projekt, albo nie ;) W czasie projektowania, pracy nad nim zostały podjęte konkretne decyzje - świadomie, bądź nie. Po zakodowniu, przetestowaniu, naniesieniu poprawek, doprowadzeniu do tego co faktycznie było do zrobienia... i tak dalej i tak dalej.
Nie działa / działa wolno. Dlaczego? No... raczej nikt nie udzieli odpowiedzi. Raczej, bo można strzelać i trafić.Działa ale baza działała wolniej niż tego oczekiwałem. Chodziło o porównanie kliku algorytmów, które traciło sens gdy całość czekała na odpowiedzi z bazy.
Może baza jest ok, a system zamula?Działały wolno konkretne zapytania - to zostało na początku tematu jasno wyrażone.
Jeżeli baza chodzi na jednej maszynie, dostęp jest z jednej aplikacji to najsensowniej jest zastosować rozwiązanie desktopowe. W ten sposób uniknie się narzutu na IPC. Ja bym wypróbował SQLite. Jak słabo wyjdzie MySQL z dużym buforem wyników zapytań.Baza musiała być na osobnej maszynie ze względu na obciążenie procesorów (sam system średnio na poziomie ok 85% dla wszystkich 4 rdzeni).
Czepiam się? Jest baza danych - Oracle. Dlaczego Oracle? Optymalizować zapytania, czy zmienić bazę? Dostając konkretne explainy za diabła nie jestem w stanie powiedzieć, czy decyzja o wyborze bazy była podyktowana konkretnymi względami, czy tym, że instalka leżała na biurku.Między innymi rozważania na temat zgodności zapytań ze standardami (tuta) wynikają z tego, że system jest przenośny. Zostały przeprowadzone testy funkcjonalne na takich bazach danych:
• Apache Derby 10
• MySQL 5.1
• Oracle 10g
• Oracle 11g
• SQL Server 2005
• SQL Server 2008
• DB2 9.7
(akurat te instalki jak to mówisz "leżały na biurku")
Przy tych testach system był skonfigurowany tak, że tworzył zapytania podobne do nr. 1 na początku tego tematu.
Oracle została wybrana dla konkretnego "wdrożenia" do testów wydajnościowych. Wybór padł na Oracle ze względu na duże możliwości optymalizacji i obecność indeksu bitmapowego, który wydawał się najlepszy dla takiej reprezentacji zbioru. Dodam, że w fazie rozwojowej system korzystał z bazy Derby (także embeded) oraz MySQL. Oracle we wstępnych testach okazał się znacznie szybszy.
No i właśnie kolejne zapytania oraz różne rodzaje tabel wynikały z pracy nad optymalizacją w Oracle. Stąd też doszły dwa nowe rodzaje zapytań dające taki sam wynik. Próbuję ustalić ich zgodność ze standardami, aby podać ją w dokumentacji dotyczącej konfiguracji.
Optymalizować zapytania, czy zmienić bazę? Dostając konkretne explainy za diabła nie jestem w stanie powiedzieć, czy decyzja o wyborze bazy była podyktowana konkretnymi względami, czy tym, że instalka leżała na biurku."Decyzja o wyborze bazy" została dokonana i ja nie prosiłem o optymalizację systemu czy znalezienie w nim wąskich gardeł bo z tym sobie świetnie radzę a jedynie właśnie o optymalizację bazy z czym radziłem sobie gorzej :) Uzyskałem bardzo dużą pomoc w tym temacie (za co dziękuję) i myślę, że sporo się przy tej okazji nauczyłem o Oracle.
Skąd mam wiedzieć na jakim sprzęcie to chodzi?Z jednego z moich poprzednich postów w którym podałem konfigurację :)
Albo takie pytanie - czy system musi przewalać się po tych danych,Musi, ale nawet jakby nie musiał to to pytanie nie dotyczy już optymalizacji bazy. Ja prosiłem o pomoc w konkretnej sprawie. Wydaje mi się, że w idealnym przypadku nie jest zadaniem DBA optymalizacja samego systemu a jedynie rzeczy związanych bezpośrednio z bazą danych.
żeby oddać wyniki? Może da się to jakoś zebrać? Oczywiście mogę założyć, że to pierwsze, ale... takie podejście nie ma sensu - kompletnie.
Może prościej odpalić na takiej maszynie, żeby całość weszła do ramu? Jaki system operacyjny?Niestety nie mam dostępu do takich maszyn zwłaszcza, że niektóre zestawy danych mają 50 mln rekordów. (System Windows XP Proffesional - wybór nie zależał ode mnie.)
- skoro już drążę temat... No - mam nadzieję, że naświetliłem problem od strony osoby, która niby chciałaby pomóc, ale nie bardzo się da.Dziękuję za Twoją wypowiedź. Pomóc dało się - uzyskałem bardzo skuteczną w tym temacie i baza chodzi już z dopuszczalną prędkością (pewnie znacznie by przyspieszyła jakby dyski wyglądały inaczej).
EDIT: zapomniałem podać, że testy funkcjonalne były też na DB2 9.7 ;)Zacheusz Siedlecki edytował(a) ten post dnia 09.01.10 o godzinie 18:27
Michał Z. ɐʇsıɯɐɹƃoɹd
Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]
Zacheusz Siedlecki:
Umieszczam odpowiedź na wypowiedź Michała w tym temacie która jednak dotyczyła bieżącego wątku.Michał Z.:Dokładniej na początku był pomysł i szczegółowy projekt algorytmów, potem koncepcja i dość dokładny projekt systemu.
Na początku był pomysł na system. Potem pojawił się projekt, albo nie ;) W czasie projektowania, pracy nad nim zostały podjęte konkretne decyzje - świadomie, bądź nie. Po zakodowniu, przetestowaniu, naniesieniu poprawek, doprowadzeniu do tego co faktycznie było do zrobienia... i tak dalej i tak dalej.Nie działa / działa wolno. Dlaczego? No... raczej nikt nie udzieli odpowiedzi. Raczej, bo można strzelać i trafić.Działa ale baza działała wolniej niż tego oczekiwałem. Chodziło o porównanie kliku algorytmów, które traciło sens gdy całość czekała na odpowiedzi z bazy.
Baza danych to nie czarna skrzynka, czy też samotna wyspa. Można zrobić tak, żeby dane filtrował, łączył kod w Javie, tak, żeby baza będzie śmigała, a problem był z kodem w Javie.
Co do samego problemu systemu używającego różnych baz danych... Ogólnie to zwykle robi się DAO, które odseparowuje aplikację od konkretnego sposobu przechowywania danych. Z punktu widzenia DBA - po to robi się projekt, żeby ustalić kontrakt na ten interfejs. ;) Bardziej poważnie - z tego wynika jak aplikacja odwołuje się do danych. Na podstawie tego kontraktu można też rozmawiać z kimś kto robi DAO, żeby poprawił zapytania, bo np. to samo można uzyskać wydajniej.
Może baza jest ok, a system zamula?Działały wolno konkretne zapytania - to zostało na początku tematu jasno wyrażone.
To jest cały mechanizm. Maszyna serwerowa, system operacyjny, silnik bazy danych, zapytania, i cała reszta do UI. To, że długo trwa select - wcale nie musi oznaczać, że z nim jest problem... Wszystkie zadania walczą o te same zasoby - dużo drobnych zapytań może skutecznie przybić bazę, a optymalizacja tych, co długo trwają wiele nie zmieni. Wiadomo - ze wszystkim można sobie radzić. Mam nadzieję, że też się jasno wyrażam ;)
Może w ten sposób: Jak odpalę serwer aplikacji na tym samym serwerze co bazę danych to muszę rozpatrywać bazę i serwer jako całość. Tak wiem - oczywiste. Tak samo nie da się mówić o bazie danych, bez mówienia o systemie operacyjnym, choć w przypadku Oracle'a... jest to stosunkowo łatwe. Więcej - to, że serwer aplikacji chodzi obok jedynie komplikuje sytuację, ale jej nie zmienia. Kwestia tylko polega na tym, gdzie jest kreska określająca interfejs który ma być optymalizowany. Czasem nie da się inaczej, bo system jest zamknięty, ale tutaj?
Stawianie sprawy w ten sposób przypomina mi złe podejście korporacyjne (ponoć bywa i dobre ;). Polega to na tym, że jest armia ludzi, którzy coś tam robią - każdy ma swoje poletko i tylko ono go interesuje. Potem tylko przerzucają kamyczki między poletkami i wszystko stoi w miejscu. Każdy z nich jest zły, sfrustrowany, bo "ORM to jest zło" i tak dalej. Tak to jest nad-interpretacja, ale warto się zastanowić co się robi.
Jeżeli baza chodzi na jednej maszynie, dostęp jest z jednej aplikacji to najsensowniej jest zastosować rozwiązanie desktopowe. W ten sposób uniknie się narzutu na IPC. Ja bym wypróbował SQLite. Jak słabo wyjdzie MySQL z dużym buforem wyników zapytań.Baza musiała być na osobnej maszynie ze względu na obciążenie procesorów (sam system średnio na poziomie ok 85% dla wszystkich 4 rdzeni).
OK. Czyli jest tak, że na osobnej maszynie z jednym dyskiem 7200 i 2GB ramu stoi baza danych. Jak wygląda sieć? Czy nie jest wąskim gardłem, czy to jest IPv4, bo jak IPv6 to proszę wziąć pod uwagę narzut na nagłówki.
Czepiam się? Jest baza danych - Oracle. Dlaczego Oracle? Optymalizować zapytania, czy zmienić bazę? Dostając konkretne explainy za diabła nie jestem w stanie powiedzieć, czy decyzja o wyborze bazy była podyktowana konkretnymi względami, czy tym, że instalka leżała na biurku.Między innymi rozważania na temat zgodności zapytań ze standardami (tuta) wynikają z tego, że system jest przenośny.
O DAO już wspominałem. Zwykle sprawdza się zrobienie kilku implementacji jednego interfejsu i wpinanie aktualnie potrzebnej. Spring, inversion of control... Tak, wprowadza się dodatkowe zależności, ale można to samo osiągnąć odpowiednimi skryptami do anta. Roboty sporo, w utrzymaniu fatalne, ale za to zależności brak.
Czyli projekt zakłada wrzucenie wszystkiego do jednego worka, i dłubanie się z każdą konkretną bazą - osobno? Ja bym zrobił tak, że algorytmy są serwisami, każdy ma jakieś swoje własne parametry, do tego dao. Na koniec zrobiłbym serwis testujący, który jako pole ma serwis kodujący. Wszystko da się zapisać w kontekście springa.
Zostały przeprowadzone testy funkcjonalne na takich bazach danych:
• Apache Derby 10
• MySQL 5.1
• Oracle 10g
• Oracle 11g
• SQL Server 2005
• SQL Server 2008
• DB2 9.7
(akurat te instalki jak to mówisz "leżały na biurku")
Przy tych testach system był skonfigurowany tak, że tworzył zapytania podobne do nr. 1 na początku tego tematu.
Oracle została wybrana dla konkretnego "wdrożenia" do testów wydajnościowych. Wybór padł na Oracle ze względu na duże możliwości optymalizacji i obecność indeksu bitmapowego, który wydawał się najlepszy dla takiej reprezentacji zbioru. Dodam, że w fazie rozwojowej system korzystał z bazy Derby (także embeded) oraz MySQL. Oracle we wstępnych testach okazał się znacznie szybszy.
Oracle to kobyła - to, że jest masa dokumentacji to nie przypadek. To prawda, że ma ogromne możliwości optymalizacji. Tyle, że na 2GB ramu i jednym dysku 7200... ja bym minimalizował straty a nie pchał się w stronę używania dużych narzędzi.
No i właśnie kolejne zapytania oraz różne rodzaje tabel wynikały z pracy nad optymalizacją w Oracle. Stąd też doszły dwa nowe rodzaje zapytań dające taki sam wynik. Próbuję ustalić ich zgodność ze standardami, aby podać ją w dokumentacji dotyczącej konfiguracji.
Celem jest umieszczenie czegoś w dokumentacji, czy zrobienie optymalnego rozwiązania... To co piszę idzie w stronę tego pierwszego.
Optymalizować zapytania, czy zmienić bazę? Dostając konkretne explainy za diabła nie jestem w stanie powiedzieć, czy decyzja o wyborze bazy była podyktowana konkretnymi względami, czy tym, że instalka leżała na biurku."Decyzja o wyborze bazy" została dokonana i ja nie prosiłem o optymalizację systemu czy znalezienie w nim wąskich gardeł bo z tym sobie świetnie radzę a jedynie właśnie o optymalizację bazy z czym radziłem sobie gorzej :) Uzyskałem bardzo dużą pomoc w tym temacie (za co dziękuję) i myślę, że sporo się przy tej okazji nauczyłem o Oracle.
System to niestety całość... Wydaje mi się, że odbieranie danych w częściach przyniosłoby wzrost wydajności. W tej chwili część systemu czeka aż ktoś inny przemieli swój kawałek. Takie rozwiązanie nie jest optymalizacją bazy danych, bo dotyczy kontraktu na DAO, czyli wymaga odpowiedniej wiedzy od komponentów z niego korzystających. A skoro baza miele, a cała reszta czeka to może prościej odsyłać dane w paczkach, albo chodzić po nich kursorem? Czy to ma sens? A no właśnie trzeba wiedzieć gdzie jest wąskie gardło - dla całego systemu. Jak wąskim gardłem jest io dla serwera na którym stoi baza danych - to można spróbować. Jak nie - to problem jest w innym miejscu. Optymalizacja zapytań jest ok, ale z każdego silnika trzeba korzystać tak jak autorzy to przewidzieli. Inaczej... nie będzie śmigać.
>Skąd mam wiedzieć na jakim sprzęcie to chodzi?Z jednego z moich poprzednich postów w którym podałem konfigurację :)
Rzeczywiście. Sporo tego było i przeoczyłem... Nie wygląda to dobrze, ale jak rozumiem to głównie odczyt? Czy każde przeliczenie powoduje zwrotny strzał w bazę...
Albo takie pytanie - czy system musi przewalać się po tych danych,Musi, ale nawet jakby nie musiał to to pytanie nie dotyczy już optymalizacji bazy. Ja prosiłem o pomoc w konkretnej sprawie. Wydaje mi się, że w idealnym przypadku nie jest zadaniem DBA optymalizacja samego systemu a jedynie rzeczy związanych bezpośrednio z bazą danych.
żeby oddać wyniki? Może da się to jakoś zebrać? Oczywiście mogę założyć, że to pierwsze, ale... takie podejście nie ma sensu - kompletnie.
Z serwera aplikacji wypadają koszmarki i rolą DBA jest optymalizacja tego? No nie - tak lekko to nie ma :) Optymalizacja całości jest o wiele trudniejsza, ale daje lepsze wyniki.
Może prościej odpalić na takiej maszynie, żeby całość weszła do ramu? Jaki system operacyjny?Niestety nie mam dostępu do takich maszyn zwłaszcza, że niektóre zestawy danych mają 50 mln rekordów. (System Windows XP Proffesional - wybór nie zależał ode mnie.)
Przykro mi, ale nie pomogę. Nie mam pojęcia jak administrować tym systemem. Jest takie coś sys-internals, może tam będą jakieś pomocne narzędzia, ale od dość dawna nie tykam.
- skoro już drążę temat... No - mam nadzieję, że naświetliłem problem od strony osoby, która niby chciałaby pomóc, ale nie bardzo się da.Dziękuję za Twoją wypowiedź. Pomóc dało się - uzyskałem bardzo skuteczną w tym temacie i baza chodzi już z dopuszczalną prędkością (pewnie znacznie by przyspieszyła jakby dyski wyglądały inaczej).
EDIT: zapomniałem podać, że testy funkcjonalne były też na DB2 9.7 ;)
Z opisu wydawało mi się to oczywiste ;)
Rozumiem, że system stoi, ma się +/- dobrze.
Zwykle część rzeczy piszę dla porządku / uspójnienia.
Postaram się przejrzeć te zapytania, dla PG powinno się dać dostosować. Co nie zmienia faktu, że paginacja powinna się sprawdzić lepiej.
Zacheusz Siedlecki Programista Java
Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]
Michale, dziękuję za Twoją obszerną wypowiedź.Michał Z.:Niestety cały czas zakładasz, że źle rozpoznałem problem. Problem rozpoznałem dobrze zwłaszcza, że styk aplikacja - baza danych jest w tym przypadku trywialny a kwestia tego jakie informacje pobierać z bazy bardzo szczegółowo opracowana.
Baza danych to nie czarna skrzynka, czy też samotna wyspa. Można zrobić tak, żeby dane filtrował, łączył kod w Javie, tak, żeby baza będzie śmigała, a problem był z kodem w Javie.
Co do samego problemu systemu używającego różnych baz danych... Ogólnie to zwykle robi się DAO, które odseparowuje aplikację od konkretnego sposobu przechowywania danych.Ogólnie rzecz biorąc tak też jest to zrobione - jest pewna warstwa abstrakcji nad przechowywaniem danych, ale nie w tym rzecz. Jest IoC, możliwość własnej implementacji dla interfejsu i wyspecyfikowanie jej w konfiguracji. Staram się o wyspecyfikowanie przenośności zapytań, żeby tą sprawę ułatwić.
To jest cały mechanizm. Maszyna serwerowa, system operacyjny, silnik bazy danych, zapytania, i cała reszta do UI. To, że długo trwa select - wcale nie musi oznaczać, że z nim jest problem... Wszystkie zadania walczą o te same zasoby - dużo drobnych zapytań może skutecznie przybić bazę, a optymalizacja tych, co długo trwają wiele nie zmieni.Ale w przypadku gdy to jest hurtownia danych mająca (w bardzo dużym uogólnieniu) takie fazy działania:
1. Ładowanie danych, różne zapytania, powolne inserty itd.
2. Eksploracja danych - baza w trybie tylko do odczytu i tylko jeden typ zapytań co zostało podkreślone w tym temacie. Nie ma żadnych dodatkowych zapytań o których piszesz - nie trzeba tu nic dodawać. Sprawa wygląda tak jak przedstawiłem.
Może w ten sposób: Jak odpalę serwer aplikacji na tym samym serwerze co bazę danych to muszę rozpatrywać bazę i serwer jako całość. Tak wiem - oczywiste. Tak samo nie da się mówić o bazie danych, bez mówienia o systemie operacyjnym, choć w przypadku Oracle'a... jest to stosunkowo łatwe. Więcej - to, że serwer aplikacji chodzi obok jedynie komplikuje sytuację, ale jej nie zmienia. Kwestia tylko polega na tym, gdzie jest kreska określająca interfejs który ma być optymalizowany. Czasem nie da się inaczej, bo system jest zamknięty, ale tutaj?Tutaj właśnie "da się" określić kreskę. Jest to jeden z tych nielicznych przypadków ;)
Stawianie sprawy w ten sposób przypomina mi złe podejście korporacyjne (ponoć bywa i dobre ;). Polega to na tym, że jest armia ludzi, którzy coś tam robią - każdy ma swoje poletko i tylko ono go interesuje. Potem tylko przerzucają kamyczki między poletkami i wszystko stoi w miejscu. Każdy z nich jest zły, sfrustrowany, bo "ORM to jest zło" i tak dalej. Tak to jest nad-interpretacja, ale warto się zastanowić co się robi.
Czasem takie podejście okazuje się bardzo dobre :] Trzeba tylko wtedy uwierzyć w kompetencje drugiej osoby i trochę zaufać, że wykonuje swój element dobrze. Patologie z "przerzucaniem kamyczków" pewnie się zdarzają, ale co innego gdy wykonawcom zależy nie na wykonaniu jednostkowego zadania, lecz na całości.
W tym przypadku na prawdę nie ma sensu, żebym przedstawiał zastosowane algorytmy dataminingowe zawierające bardzo zaawansowaną kryptografię. Sama implementacja ma ponad 30k lini kodu w Javie co w jakimś tam stopniu oddaje jej złożoność. Na szczęście zdołałem wyizolować problem z bazą danych tak, żeby nie musieć przedstawiać zbędnych szczegółów.
OK. Czyli jest tak, że na osobnej maszynie z jednym dyskiem 7200 i 2GB ramu stoi baza danych. Jak wygląda sieć? Czy nie jest wąskim gardłem, czy to jest IPv4, bo jak IPv6 to proszę wziąć pod uwagę narzut na nagłówki.Problem nie leży w sieci. Baza danych jest podłączona poprzez LAN o przepustowości 80.0 Mbits/sec.
Czyli projekt zakłada wrzucenie wszystkiego do jednego worka, i dłubanie się z każdą konkretną bazą - osobno? Ja bym zrobił tak, że algorytmy są serwisami, każdy ma jakieś swoje własne parametry, do tego dao. Na koniec zrobiłbym serwis testujący, który jako pole ma serwis kodujący. Wszystko da się zapisać w kontekście springa.A skąd takie stwierdzenie, że zakłada? To co piszesz jest dosyć oczywiste i mniej więcej tak to wygląda w zaimplementowanym systemie.
Oracle to kobyła - to, że jest masa dokumentacji to nie przypadek. To prawda, że ma ogromne możliwości optymalizacji. Tyle, że na 2GB ramu i jednym dysku 7200... ja bym minimalizował straty a nie pchał się w stronę używania dużych narzędzi.No możliwe, że tu masz rację. Chętnie poznałbym na ten temat opinię specjalistów od Oracle obecnych w tej grupie.
Celem jest umieszczenie czegoś w dokumentacji, czy zrobienie optymalnego rozwiązania... To co piszę idzie w stronę tego pierwszego.Przez to, że właśnie istnieją różne implementacje odpowiedzialne za przechowywanie danych nie muszę wybierać między tym i tym ;)
A no właśnie trzeba wiedzieć gdzie jest wąskie gardło - dla całego systemu. Jak wąskim gardłem jest io dla serwera na którym stoi baza danych - to można spróbować. Jak nie - to problem jest w innym miejscu. Optymalizacja zapytań jest ok, ale z każdego silnika trzeba korzystać tak jak autorzy to przewidzieli. Inaczej... nie będzie śmigać.No i ja właśnie wiem gdzie to wąskie gardło jest ;) Dlatego prosiłem o pomoc przy optymalizacji tego konkretnego zapytania.
Nie wygląda to dobrze, ale jak rozumiem to głównie odczyt? Czy każde przeliczenie powoduje zwrotny strzał w bazę...Tak jak parę razy już pisałem. Rozmawiamy o fazie działania całości w której baza pracuje w trybie tylko do odczytu i zadawane są jedynie omawiane zapytania.
Rozumiem, że system stoi, ma się +/- dobrze.Tak. Wydajność całości po tym jak uzyskałem pomoc w optymalizacji tych zapytań wzrosła do dopuszczalnego poziomu i system działa zgodnie z oczekiwaniami. Potwierdza to, że problem został dobrze rozpoznany i optymalizacja bazy danych bez wgłębiania się w szczegóły implementacji systemu dała wymierne rezultaty.
Zwykle część rzeczy piszę dla porządku / uspójnienia.Dziękuję za komentarze, wszystkie są dla mnie bardzo cenne niemniej jednak trochę odbiegłeś od tematu :) Mam nadzieję, że wyczerpująco wyjaśniłem dlaczego optymalizacja samej bazy i samych zapytań w tym przypadku jest rozwiązaniem właściwym.
Adam
Michalski
Projektant/Programis
ta freelancer
Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]
Zacheusz Siedlecki:Oracle to kobyła - to, że jest masa dokumentacji to nie przypadek. To prawda, że ma ogromne możliwości optymalizacji. Tyle, że na 2GB ramu i jednym dysku 7200... ja bym minimalizował straty a nie pchał się w stronę używania dużych narzędzi.No możliwe, że tu masz rację. Chętnie poznałbym na ten temat opinię specjalistów od Oracle obecnych w tej grupie.
A sprawdzałeś to na mysqlu np.?
Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]
Adam Michalski:
A sprawdzałeś to na mysqlu np.?
Nareszcie jakaś krótka i zrozumiała wypowiedź :))))))))
Zacheusz Siedlecki Programista Java
Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]
Adam Michalski:Tak - nawet chyba gdzieś w tych 'długich wypowiedziach' napisałem, że MySQL działał wolniej przy większych zbiorach danych. Podobnie Apache Derby.No możliwe, że tu masz rację. Chętnie poznałbym na ten temat opinię specjalistów od Oracle obecnych w tej grupie.
A sprawdzałeś to na mysqlu np.?
Adam
Michalski
Projektant/Programis
ta freelancer
Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]
Zacheusz Siedlecki:
Adam Michalski:Tak - nawet chyba gdzieś w tych 'długich wypowiedziach' napisałem, że MySQL działał wolniej przy większych zbiorach danych. Podobnie Apache Derby.No możliwe, że tu masz rację. Chętnie poznałbym na ten temat opinię specjalistów od Oracle obecnych w tej grupie.
A sprawdzałeś to na mysqlu np.?
A próbowałeś go tune'ować? Nie znajdziesz oczywiście tylu możliwości co w Oracle'u, ale też można.
Zacheusz Siedlecki Programista Java
