Duże aplikacje i load balancing, Czyli co i jak zrobic jak maszyna nie daje rady Opcje

[kwiateusz]

Temat założony na prośbę SHIPa oraz normanosa traktujący o rozkładaniu obciążenia na wiele maszyn

[Krolik]

Rashid, porównujesz z MySQLem i słusznie zauważyłeś, że MySQL w wielu przypadkach najszybszy nie jest.
Jeśli masz wybór jedynie BDB vs MySQL, to faktycznie BDB może w wielu sytuacjach byc lepzym rozwiązaniem i tu się calkowicie zgadzam.

Natomiast w poprzednich postach pisałem bardziej ogólnie, chodziło mi po prostu o RDBMS, jako taki, nie jakąś konkretną implementację, jak MySQL,
który jest jedną z gorszych implementacji systemu relacyjnego na rynku. No, a skoro mówimy o load-balancingu, to rozumiem, że wchodzą w grę nie tlylko rozwiązania niskobudżetowe.

- przetwarzanie SQL

Realnie kosztuje 0, plany wykonania zapytań w dobrych RDBMSach są buforowane.
A nawet jeśli nie są domyślnie, to są, gdy się użyje prepared statement.

- zarzadzanie indeksami

Utrzymania indeksów nie unikniesz też w BDB jeśli gdziekolwiek masz aktualizacje.
Każdy hash w BDB jest indeksem.

- zarzadzanie sesjami i transakcjami

Nie ma żadnego powodu, aby transakcje w BDB kosztowały mniej niż w RDBMS.
Można ręcznie określić poziom izolacyjności transakcji. Nie potrzebujesz, ustawiasz
na "NONE" lub 0, narzut znika.

- rozbudowane operacje w pamieci

Ogólnik. Konkrety?

- posrednia warstwa sieciowa

Jaka warstwa sieciowa? Oracle Embedded, H2, JavaDB, SQLite nie potrzebują warstwy sieciowej.
A nawet jeśli - od czego jest GigaBit Ethernet?

- przenoszenie danych pomiedzy przestrzenia adresowa serwera bazy a programem przetwarzajacym dane

W RDBMSach wbudowanych, podobnie jak punkt poprzedni - problem nie występuje.
W rozwiązaniach klient-serwer, też rzadko jest to problemem. Tu są szybkości rzędu kilku, kilkunastu GB/s.
No i jeszcze stosuje się buforowanie wyników zapytań po stronie klienta.

[rashid]

Realnie kosztuje 0, plany wykonania zapytań w dobrych RDBMSach są buforowane. A nawet jeśli nie są domyślnie, to są, gdy się użyje prepared statement.

Nic w przetwarzaniu danych nie kosztuje 0. Zawsze bedzie odwolanie do managera zapytan, sprawdzenie czy prepared statement jest gotowy, wczytanie wewnetrznych instrukcji bazy dla danego zapytania, zaalokowanie pamieci na wynik itd. Google projektuje swoje bazy danych w taki sposob, zeby kolumny wczytywaly sie w pelni do pojedynczych rejestrow procesora albo w obrebie stron pamieci, a ty mowisz, ze przetwarzanie SQL nic nie kosztuje (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Kosztowac moze wzglednie malo w porownaniu z samym przetwarzaniem danych, ale darmowe nie jest.

Utrzymania indeksów nie unikniesz też w BDB jeśli gdziekolwiek masz aktualizacje.
Każdy hash w BDB jest indeksem.

Tutaj trafiasz w sedno - hash (chyba najpopularniejsza struktura danych dla BDB) jest indeksem sam w sobie. Zlozonosc dostepu O(1). W RDBMS indeks moze byc przechowywany w BDB. Indeks - element, ktory ma przyspieszac wczytywanie danych z tabeli, moze byc przechowywany w BDB! Jesli BDB byloby wolniejsze od RDBMS to jaki sens mialoby uzywanie go do przyspieszania?

Nie ma żadnego powodu, aby transakcje w BDB kosztowały mniej niż w RDBMS.
Można ręcznie określić poziom izolacyjności transakcji. Nie potrzebujesz, ustawiasz
na "NONE" lub 0, narzut znika.

Zakladajac, ze mozna tez wlaczyc tryb jednouzytkownikowy, z pojedyncza sesja i bez sprawdzania uprawnien do tabel, to pewnie RDBMS zacznie sie zblizac wydajnosciowo do BDB.

Ogólnik. Konkrety?

(zarzadzanie pamiecia) Indeksy, uprawnienia, prepared statements. Sa tony rzeczy, ktore musisz powylaczac w RDBMS, zeby wyciagnac z niej maksimum wydajnosci. Zgadzam sie, ze to ogolnik, bo nie czuje sie na silach dyskutowac szczegolowo o technicznych aspektach Oracle. Opieram sie na pobieznym zapozaniu sie z architektura.

Jaka warstwa sieciowa? Oracle Embedded, H2, JavaDB, SQLite nie potrzebują warstwy sieciowej.
A nawet jeśli - od czego jest GigaBit Ethernet?
W RDBMSach wbudowanych, podobnie jak punkt poprzedni - problem nie występuje.
W rozwiązaniach klient-serwer, też rzadko jest to problemem. Tu są szybkości rzędu kilku, kilkunastu GB/s.
No i jeszcze stosuje się buforowanie wyników zapytań po stronie klienta.

Jasne, ze mozna RDBMS osadzic i powylaczac mu wszystkie funkcje, zeby wycisnac maksimum. Tylko po co, skoro BDB ma to od razu?

Ciekawostka jest, ze jednym z elementow Oracle Embedded jest Oracle Berkeley DB - dlaczego skoro zwykly Oracle Embeddable powinien byc szybszy? (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Mozemy sie spierac, ale najlepiej byloby to oczywiscie przetestowac. Ja ze swojej strony moge powiedziec, ze w jednym projekcie, ktory polozyl na lopatki MySQL ze wzgledu na duza ilosc insert'ow i delete'ow po przejsciu na BDB praktycznie nie odczuwamy istnienia bazy. Oczywiscie musze tu podkreslic, ze baza jest z gruntu nierelacyjna - taki urok przetwarzanych w niej danych.

Chcialbym zauwazyc, ze troche mozemy miec rozne spojrzenie na ten watek. Wydaje mi sie, ze ty odnosisz sie do skalowalnosci ogolnie (co w zasadzie wynika z tematu watku), a ja do konkretnego problemu, ktory zostal w tym watku opisany.