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]

Nie będę wchodził w szczególy, bo odeszliśmy od tematu.
Faktycznie BDB służy do przyspieszania i może być wykorzystywane w niższych warstwach RDBMSa. Jednak nie wynika z tego wcale, że RDBMS w praktyce nie może być szybszy. Głównym powodem jest to, że b. dużą częścią dobrych RDBMSów jest optymalizator zapytań. Czyli takie coś, co na podstawie zapytania SQL pisze jakby program wykorzystujący niskopoziomowe polecenia BDB (lub coś innego), aby wykonać zapytanie. Jeśli używasz BDB, program musisz napisać sam. Fajnie, jak musisz wybrać dane z jednej tabeli z jakimś prostym filrem - do tego BDB jest idealne.

Gorzej, jeśli masz złączenia, grupowanie. Wtedy po pierwsze - liczba możliwych sposobów wykonania takiego zapytania bardzo szybko rośnie (wykładniczo z liczbą warunków, złączeń, liczbą dostępnych indeksów). Optymalny plan zależy również od rozkładu danych w bazie, liczby rekordów w tabelach itp. A wiadomo, że w trakcie działania te rzeczy mogą się zmieniać. Czyli nie dość, że musisz być naprawdę niezłym specem, żeby ręcznie zoptymalizować każde zapytanie, to jeszcze na dodatek po pewnym czasie może się okazać, że będziesz musiał przepisywać niektóre części programu, bo zaczną działać za wolno itp. Wystarczy, że gdzieś się pojawi więcej danych i przestanie obowiązywać jakieś założenie, że np. dane zmieszczą się w pamięci. RDBMS jest sobie w stanie poradzić z takimi sytuacjami często niemal bez udziału użytkownika albo z bardzo niewielkim nakładem pracy - typu wydanie jednego czy dwóch poleceń (np. ANALYZe w PostgreSQL, albo RUNSTAT w DB/2). I tu jest właśnie siła - teoretycznie jesteś w stanie w BDB uzyskać szybszy system, ale w praktyce przy złożonym systemie jest to b. trudne, a przy złożonych zapytaniach (np. hurtownianych ala TPC-H) jesteś praktycznie bez szans.