Tajemnica sukcesu giganta baz danych

Witaj Forumowiczów

Od kilku miesięcy jestem w trakcie czytania ksiażki biograficznej na temat Pana Ellisona jednego z ojców Oracla i analizuje postęp rozwijania projektu baz danych na tamte czasy nowatorski i cały czas mnie zastanawia jak produkt po 8 latach nawet od momentu pisania i projektowania wciąż nie działał jak powinien. Firmy które kupowały za setki tys. licencje debugowały go w zasadzie. Firma powoli dobijała do 1 bln $ przychodu.
Zawiodły tu wciąż rozwijanie technologie projektowania, komputery na których to uruchamiano. Chyba, że karkołomny pomysł takiej wersji bazy w zasadzie od jednego pracownika IBM który sprawdzał się tylko na papierze :-p

Zgaduję, że po prostu połączenie małej produktywności w tamtych czasach oraz bardzo ambitny projekt. SQL nie był ewolucją tylko rewolucją i do tego bardzo teoretyczną, więc ktoś musiał to wymyślić i zaklepać. W porównaniu do poprzednich hierarchicznych baz danych:

• concurrency: trzeba mieć jakieś dobre MVCC, bo praktycznie każde zapytanie może przeorać bazę. W hierarchicznej bazie zapytania są skorelowane z hierarchią i możesz po prostu założyć locka
• planner: w zasadzie to samo, trzeba napisać ogólny algorytm, który działa dla wszystkich przypadków
• indeksy i wszystkie inne przyśpieszacze, bez których relacyjna baza danych nie ma prawa działać

W dzisiejszych czasach wystarczy przeczytać jak to zrobili inni. Pewnie wtedy było mnóstwo eksperymentów i projekt się ciągnął

Taki był i jest klimat w IT, że jak firma przyzwyczaiła użytkowników do swoich rozwiązań, to ciężko zmienić ich nawyki...
Od dawna dla mnie niepojęte było to, że większość użytkowników "potrzebuje" np. do pisania MS Word.
A pracownik biurowy nie mógłby korzystać z jakiejś dystrybucji Linuksa, zamiast Windowsa.
Zwłaszcza, gdy jego praca opiera się o przeglądarkę internetową.

Oracle tak samo wbiło się w rynek i solidnie zapuściło korzenie.
Z tego co mi się obiło o uszy, to firmy po prostu chcą umywać ręce w przypadku utraty danych itp.
Można zwalić wszystko na Oracle, bo gwarancja jest, czy coś.

42:53 - 53:55

Moim zdaniem jest kilka głównych powodów, dla których Oracle się trzyma:

1. Koszt przerobienia istniejących systemów jest znacznie wyższy niż utrzymanie tego w stanie obecnym - nawet licząc licencje na soft Oracle
2. A czemu są systemy działające na Oracle? Bo w momencie jak powstawał za bardzo nie było alternatywy :/
3. Trochę jak z Java - przyjęło się, że poważne biznesowe apki robi się w Java, mało kto się zastanawia czy to ma sens. Jest coś dużego dla poważnej instytucji, więc automatycznie trzaskamy w Java
4. Typowy dupochron - jeśli zrobimy to na Oracle i coś się wysypie, to nie jest moja wina, bo skorzystałem ze standardu w branży. Jeśli natomiast zrobię eksperymentalną migrację na Postgresa i coś się wywali to będę miał problem, bo po co kombinowałem?
5. Kwestia wymogów: czasem (zwłaszcza przy zamówieniach z budżetówki albo projektach dość dużego kalibru) w warunkach przetargu jest jakiś SLA. Podpisując umowę z Oracle masz to zagwarantowane. A co w przypadku Postgresa? Z kim umowę podpiszesz? Jeśli coś się wywali to masz kogo pozwać. A darmowy Postgres - nie ma gwarancji reakcji w określonym czasie, ani nie ma podmiotu do pozwania w razie fakapu
6. Podobno Oracle potrafi się mścić i naliczać dość konkretne kary za złamanie licencji (np. wykupione na mniej vCPU niż było realnie odpalone na serwerze). I póki jesteś ich klientem to (mimo, że wiedzą i złamaniu licencji) nic nie robią, ale jakbyś chciał odejść to mogą dowalić karę. Nie wiem na ile to prawda, ale widziałem takie opinie w necie.

heh, pamiętam jak w 2015 jeszcze były jakieś problemy iż oracle nie zwracał wszystkich wyników jak nie dodało się sortowania czy sortowanie nie działało i trzeba było sortować podwójnie za pomocą select from select from XD A jaka była wtedy alternatywa? windowsowa baza dopiero zaczynała, IBM nikt nie chciał dotykać. Przemigrowaliśmy na postgre bo prezes kazał jak wyszły licencje per procesor czy core, ale główny ekspert oracle nie był zainteresowany. mimo wszystko, mimo dużej ilości procedur składowanych na początku udało się wszystko przerzucić na postgre i prezes miał wyliczone iż po roku ta migracja się zwróci a potem firma będzie już tylko do przodu. No ale jakby darmowość postgre albo wysokość licencji oracle to dalej pewnie tkwilibyśmy na oracle bo kiedyś był jednak dużo tańszy. Z resztą postgre tak całkiem darmowy nie jest bo trzeba było sporo kodu dopisać samodzielnie. Jakaś firma nawet sprzedawała nakładki które powodowały iż posgre staje się maksymalnie podobny do oracle żeby się szybciej zmigrować. Mieli jakieś takie ładne hasło w stylu: baza enterprise na którą cię stać

A wracając do głownego pytania jak oracle odniósł sukces? na początku był w miarę tani i nie miał alternatyw, albo alternatywy działały jeszcze gorzej

Ja bym główne zasługi na początku pokładał w Dolinie Krzemowej, tam najpierw się szuka lokalnych rozwiań.
A reszta świata podąża.

Niby taka popularna baza danych, nawet kupiłem sobie kiedyś książkę w okolicy wersji 8/9 i oprócz studiów to w życiu nie widziałem prawdziwej instancji :(

w obecnej firmie siedzimy na oracle'u od początku i raczej nie będzie zmiany na inną bazę sqlową. natomiast mamy też bazy nosql, czyli mongodb i tam jest coraz więcej danych.

problemem z bazami sqlowymi jest sam sql przede wszystkim. mało kto ma dobrą intuicję jak robić sensowne zapytania. z drugiej strony, jak ktoś lubi zaszaleć z sqlem (jak ja) to oracle losowo sobie zapytania przeoptymalizuje (tzn. w zależności od humoru execution plan może być zupełnie inny) i trudno jest przewidzieć czy sprytne (tzn. przekombinowane do pewnego stopnia) zapytanie zacznie masakrycznie zwalniać. do tego dochodzi protokół jdbc, gdzie wiersze z wynikowego zapytania są pobierane batchami domyślnie po 10 wierszy, tzn. dla każdych 10 wierszy mamy roundtrip delay, więc jeśli apka i baza są mocno oddalone to mamy mocno spowolnione wczytywanie wyników żądania. rozwiązaniem jest zwiększenie tego batcha o rzędy wielkości, ale takie rozproszenie apek i baz po różnych regionach świata i tak mamy tylko na środowiskach testowych.

problemów z sqlem jest dużo, ale taki jeden, na który mało kto zwraca uwagę jest to, że ludziom tak mocno wchodzi w głowę problem n+1 zapytań, że mają tendencję do upychania wszystkiego do jednego zapytania. dla przykładu, załóżmy że mamy jedną tabelę z wieloma kolumnami i drugą z zaledwie dwiema, z relacją 1:n między nimi. trzeba je zjoinować. jak to zrobić, żeby nie zaciągać masy zduplikowanych danych z serwera? ja bym zjoinował już po pobraniu danych. tymczasem typowy programista joinuje wszystko jak leci i pobiera masę zduplikowanych danych.

mój sposób to najpierw zaciągnięcie niezduplikowanych danych:

select * from tabela_z_wieloma_kolumnami where <cośtam>;
select * from tabela_z_niewieloma_kolumnami where foreign_id in (select id from... i tutaj reszta powyższego zapytania, tzn. jest id zamiast gwiazdki);

wyciągnięte w ten sposób dane są względnie kompaktowe, bo dane z każdego wiersza wyciągam raz, bez duplikowania danych w wyniku
potem robię joina po stronie apki i wszystko gra
nie ma n+1 zapytań, bo są 2 zapytania, niezależnie od rozmiaru danych w bazie

sposób moich kolegów to natomiast:

select * from tabela_z_wieloma_kolumnami szeroka, tabela_z_niewieloma_kolumnami waska where waska.foreign_id == szeroka.id and <cośtam>;

wyciągnięte w ten sposób dane mają masę duplikatów, jeśli dla typowego wiersza z szerokiej tabeli jest wiele odpowiedników w wąskiej tabeli.

w bazach dokumentowych (nosql, mongodb) generalnie nie ma takich dylematów, więc jest koncepcyjnie prościej.

sqlowe schematy trudniej zaprojektować pod kątem wydajności niż nosqlowe, więc w moim projekcie jest tendencja ku zapisywaniu danych do mongodb, a nie oracle'a. w sumie to lepiej, bo nie mam się nad czym załamywać.

Jeśli chodzi o początki to nikt w tamtych czasach nie miał czegoś takiego.
Z teorii baz jeszcze ze studiów pamiętam jak tłumaczyli nam, że nie było tak dobrych maszyn by po prostu pociągnęły to matematycznie/obliczeniowo. Jednocześnie ważne było możliwie oszczędzać miejsce.
Pomysł baz danych oparty na takiej matematyce nie był nowy. Ale nikomu nie udało się dopiąć dobrze zależności sprzęt - wydajność - optymalizacja miejsca. Akurat Oracle trafił w punkt. Sprzęt zaczął na to pozwalać. Miejsce ciągle się liczyło.
To jak z myszką u Xeroxa czy iPhonem. Były już wcześniej urządzenia typu Palm ale czegoś brakowało. Dopiero iPhone zapoczątkował smyrofony na szeroką skalę.