🚀 go-pugleaf

On 2019-04-26, Borys Pogoreło <borys@pl.edu.leszno> wrote:

[...]

>> 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 co konkretnie? Ja pokazuję przykłady zastosowań w których wykorzystujemy
bazy danych.

>> 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.

https://www.forbes.pl/technologie/jak-wiele-danych-produkujemy-kazdego-dnia/4mn4w69

> 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ę.

I korzystają też s Cassandry i redisa, żeby było szybciej.
Twitter korzystał z mysql, a korzysta z Cassandry, bo ten pierwszy
nie wyrobił.

>> 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)?

To jest oczywiście tylko przykład.
Moim podstawowym argumentem dla "małej skali" jest nadal łatwiejsze skalowanie
aplikacji webowych niż db. Skalowanie DB wymaga dużo więcej pracy i wiedzy,
do skalowania aplikacji często wystarczy wprowadzenie.

>> 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.

A o jakich projektach mam pisać? O wdrożeniu gotowego wordpressa, 
czy prestashop?

> 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.

Takie firmy zazwyczaj korzystają z gotowych rozwiazań, a nie piszą własne.

[...]

>> 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ą?

Duże? Coraz częściej. Małe? One *przechodzą* do usług, albo kupują gotowce.
Nie kupują już aplikacji na desktop, tylko subskrybcję. Nie stawiasz lokalnego
serwera poczty. Firmy gromadzą dzisiaj o wiele więcej danych, dużo taniej,
bo tego typu integracje stały się możliwe i tańsze.

A jak poczytasz o problemach wydajnościowych cokolwiek większych wdrożeń,
to zawsze i nieodmiennie jest to związane z bazą danych.

>> 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.

Jeden przypadek znam i wiem że nie korzystają.

I jeszcze kolejny kamyczek do ogródka:

https://www.itprotoday.com/development-techniques-and-management/reasons-avoid-triggers

I moja praktyka to też potwierdza. I tak, miałem już do czynienia z dużą 
ilością aplikacji w której analizując przyczyny bottlenecków, znajdowałem radosne 
triggery, które ktoś włożył bo "założył", że będą szybsze, a to właśnie one kładły 
serwery, nawet przy (wydawałoby się) prostych taskach.

Tak, masz rację że przy wielu zastosowaniach "jeden serwer wystarczy",
ale uważam, że łatwiej położyć ten serwer nieoptymalnym triggerem
(bo ludzie w małych wdrożeniach "nie widzą" i nie wiedzą jak 
analizować takie problemy) niż nieoptymalną aplikacją. To drugie
łatwiej też zobaczyć, zanalizować i poprawić.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com