🚀 go-pugleaf

Dnia Fri, 26 Apr 2019 17:18:19 +0200, Wojciech Bancer napisał(a):

> Pierwsze sklepy już gdzieś tam się pojawiają. Co będzie za 5-10 lat?
> A może chciałbyś mieć dane o pozycji klienta z telefonem w czasie
> rzeczywistym poprzez urządzenia IoT, by serwować mu dopasowany content
> w sklepie? Albo sterować urządzeniami domowymi/firmowymi w reakcji
> na zdarzenia rzeczywiste?

Ale to nie są zadania dla triggerów czy procedur, skoro już o tym mowa.

> Ale dlaczego potrzebuje? Czyż nie jest wydajniej mieć monolityczny
> serwer z triggerami i wszystko "w jednej maszynie"? Takie można odnieść
> wrażenie po tym jak zachwalałeś triggery oraz ich optymalność.

Zjedź z przykładami z top 10 światowego internetu, bo to trochę mało
reprezentatywne. Inna skala, inne problemy. Choć może weźmy przykład
takiego Instagrama, powinien pasować do załozonej przez Ciebie skali. Ich
bazy korzystają z procedur PL/PGSQL do generowania unikalnych i
bezkolizyjnych identyfikatorów. Bo tak było prościej, niż dopisywać i
utrzymywać kolejną dedykowaną usługę.

> Jeszcze. Ale odpowiedzialne projektowanie *aplikacji webowej* musi
> przewidywać pewien rozwój sytuacji. Inaczej będziesz jak nasza klasa 
> i pan gąbka z błędem typu error 500.

To jest przypadek skrajny, zupełnie oderwany od rzeczywistości. Ile znasz
innych serwisów, które odniosły tak gwałtowny sukces (i jednocześnie tak
bardzo położyły temat od strony technicznej)?

> O ile *koszt* projektowania aplikacji w jeden i drugi sposób jest podobny,

Co najwyżej w średnich i dużych firmach IT, w których siedzą ludzie znający
się na wielu rzeczach, a cena dla klienta końcowego jest i tak za
roboczogodzinę. A wydaje mi się, że cały czas piszesz z takiej właśnie
perspektywy, firmy tworzącej rozwiązania dla dużych klientów, których stać
na wdrożenie za kwoty sześciocyfrowe i większe.

Pomijasz za to ogromną rzeszę mniejszych firm, których potrzeby są na tyle
niskie, że "typowe" rozwiązania są dla nich wytarczające z dużym zapasem.
Oni nie potrzebują automatycznego postawienia dodatkowych podów w trakcie
Black Friday, bo nie wygenerują takiego obciążenia. A jeśli w perspektywie
5-10 lat powiększą swój biznes 10 razy, to rzeczona baza dalej nie będzie
miała z tym problemu.

I to też nie są klienci, którzy będą wdrażać ML / Big Data, bo ich na to
zwyczajnie nie stać, tylko co najwyżej skorzystają z istniejącej usługi.

> Mniejszy jest też koszt optymalizacji konkretnych bottlenecków "na aplikacji"
> niż na bazie (bo masz mnóstwo alternatyw od zapewnienia cache w pamięci,
> rozładowania ruchu poprzez load balancery, kontroli że np. pojedynczy
> użytkownik nie może wykonać > 10 żądań na sekundę (throttling pattern),
> tworzenia kolejek i priorytetów (a nie wyłącznie obsługi fifo).
> 
> a to wszystko możesz stosować na różnych poziomach infrastruktury,
> połączonej w logiczną strukturę z aplikacją (podejście IaaC) i zebrane
> w jednym logicznym miejscu.

Brzmi pięknie i zgodnie ze sztuką, ale dodaj jeszcze ile kostuje stworzenie
takiej aplikacji i utrzymanie na takiej infrastrukturze. Ile jest firm,
które tego potrzebują i za to zapłacą?

> I już teraz te serwisy mają więcej możliwości niż desktopowe aplikacje
> będą miały kiedykolwiek (dla tej grupy). (...)

Co nie znaczy, że z tyłu nie stoi jakiś SQL napędzany procedurami.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl