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.