🚀 go-pugleaf

On 2019-04-26, Kviat <Kviat> wrote:

[...]

>> Ale ja podałem argumenty dlaczego są złe, a nie "bo są złe".
>> Natomiast można założyć, że w świecie o którym mówisz, ze względu
>> na niewielkie rozproszenie i małą skalę są to wady nieistotne.
>
> Ok. Moim zdaniem w pewnych przypadkach w Twoim świecie są to wady.
> A nie, że wady ogólnie.

Ja napisałem, że w dzisiejszym świecie "w którym zapotrzebowanie
na dane", przetwarzane coraz szybciej oraz ich ilość rośnie w zastraszającym 
tempie z roku na rok, to już jest wada.

A Ty jako kontr-przykład podajesz mi architekturę rodem z lat 90-tych,
intranetu i mówisz "u mnie działa". Jasne. Działa. Co nie znaczy
że owa architektura nie ma wad o których pisałem. Po prostu te 
wady są akceptowalne w konkternych rozwiązaniach (jeszcze).

>>> Na drodze: przeglądarka->baza danych, to właśnie php pełni
>>> niejako naturalną rolę api dla aplikacji "przeglądarkowej".
>>> Nie ma innego sposobu.
>> 
>> Nie możesz tego zrobić jedynie dlatego że przeglądarki wprowadzają ograniczenia
>> w komunikacji, a nie dlatego że to niemożliwe w języku 
>
> Tak. To miałem na myśli.

I dlaczego tak jest, jak myślisz?

>> (patrz https://github.com/sindresorhus/awesome-nodejs#database ).
>> Jakby consensus środowiska był taki, że bezpośrednia praca z DB "to jest to",
>> to przeglądarki nie miałyby takich ograniczeń.
>
> Ale mają i nie chciałem drążyć tego tematu, dlatego posłużyłem się 
> skrótem myślowym.

A zastanowiłeś się dlaczego nie mają? Dlaczego model "otwarci 
do świata" się nie sprawdził?

>>> Przykład podałem w poprzednim poście. Najprostszy z możliwych z
>>> aktualizacją pola stanu magazynowego po dodaniu/zmianie/skasowaniu
>>> rekordu z towarem.
>> I jak myślisz, jak Ci to zadziała na sklepie wielkości Amazona?
> A ile jest sklepów wielkości Amazona?

Dobrze. Czy myślisz, że wystarczy w sklepie pokroju żabki, jak ten będzie
zautomatyzowany i będzie *musiał* wiedzieć że klient wychodzący przez
kasę automatyczną nosi to i to, zabrane z półki tamtej i siamtej,
dokonać rozliczenia tego klienta i ewentualnie dokonać korekty jak
klient postanowi się rozmyślić?

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?

Do tego wszystkiego model "centralny serwer + triggery" klęknie.
Po prostu. 

>> Dlaczego google używa baz nierelacyjnych do swoich wyszukiwarek (bigtable)
>> https://cloud.google.com/bigtable/
>
> Bo takich potrzebuje.

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

>> We wszystkich przypadkach odpowiedź jest taka sama: tradycyjne serwery sql
>> "nie wyrabiają" i nie potrafią sprostać potrzebom.
>
> Nie we wszystkich przypadkach.
> W większości przypadków tradycyjne serwery sql bez problemu wyrabiają.

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.

Architektura oparta o monolityczne serwery i triggery jest zwyczajnie zamknięta 
do małej skali. _Zmiana_ wymaga przepisania logiki. Architektura oparta o 
ORM (i zdarzenia), może i jest jednostkowo wolniejsza, ale w razie potrzeby 
w łatwy sposób zostać rozbudowana "w bok", by spełnić nagłe wymagania 
obciążeniowe. I równie szybko może być ściągnięta w dół (bo się zapotrzebowanie
skończyło).

Weź takie obciążenie np. na black friday. Ja dostawię 3-4, 10, 15 maszyn
i się wyrobię. Jak przestanąć być potrzebne, to zejdą w dół. A storage mam
stosunkowo tani i niezwykle szybki (bo nie pilnuje wszystkiego czego nie musi
sam robić).

A jaką Ty masz wizję? Dostawimy 10 serwerów, zrobimy migrację, a jak przestanie
być potrzebne, to migrujemy ponownie? Wszystko ręcznie, z olbrzymim wysiłkiem
czasowym Bez żadnej automatyki?

O ile *koszt* projektowania aplikacji w jeden i drugi sposób jest podobny,
to poprzez ograniczanie logiki siedzącej na bazie masz potem dużo istotnych 
korzyści - mniejszy jest koszt przepisania aplikacji z ORM do ODM niż koszt 
przeniesienia logiki z bazy do aplikacji.

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.

>> Tam gdzie naprawdę musisz mieć skalowalne rozwiązanie, to właśnie
>> tak jest. I nie jedna "maszyna z API". Wrzucę kod na:
> Zgada. Tam gdzie naprawdę musisz.

Właśnie odwrotnie. Tam *gdzie nie musisz* żyłować wydajności pojedynczej
maszyny, nie stosujesz niepotrzebnej optymalizacji (takiej która potem blokuje
ewentualne drogi do przodu), ale projektujesz system tak by był na potencjalne 
potrzeby otwarty.

*Nie oznacza to*, że musisz od razu zakładać że będziesz miał ruch 100k userów
godzinę. Ale w miarę możliwości powinieneś projektować system tak, żeby
niewielkim kosztem zmian móc to zrobić.

>> Tego wszystkiego nie zrealizujesz w tracydyjnym modelu SQL,
>> nie dlatego że pojedyncze bajtowe operacje są mniej/bardziej
>> wydajne, tylko dlatego że jest to narzędzie o niewielkiej
>> skalowalności.
>>
> Ale przecież to nie jest tak, że teraz wszyscy nagle powinni porzucić 
> triggery/sp, bo stały się złe, bo Amazon i google z nich nie korzysta.

Ale (poza desktopami), to wszyscy chyba się przerzucili z triggerów/sp,
na inplementacje w aplikacjach. Nie tylko Amazon i Google.

> Borys Pogoreło już o tym wspomniał. Wdrażanie na siłę takich rozwiązań, 
> tam gdzie nie są konieczne, to jest rozwiązywanie problemów, których 
> większość nie ma i nigdy mieć nie będzie.

Oczywiście że ma i będzie (bo apetyt na dane rośnie). Zobacz sobei IoT,
ML, segmenty Big Data.

A tak swoją drogą, to zauważ, że te wszystkie klasyczne aplikacje księgowe
o których mówisz "ostały się" głównie w większych przedsiębiorstwach,
bo tam koszty zmian są znaczące, a ludzie do tych systemów są już
przyzwyczajeni i przeszkoleni.

Ale w takim sektorze mikro-przedsiębiorstw, jedno-osobowych DG,
zamiast instalowanej wypaśnie aplikacji z serwerem bazy masz coraz
bardziej popularne serwisy typu infakt, wfirma, itp.

I już teraz te serwisy mają więcej możliwości niż desktopowe aplikacje
będą miały kiedykolwiek (dla tej grupy). Masz więc i odczytywanie/procesowanie 
faktur z PDF (rozpoznawanie obrazów), masz automatyczne wysyłanie przypomnień 
na maila, integracje z allegro/ceneo/magazynami *różnych* sklepów po API, 
systemami płatności, bankami, wysyłaniem maili do klientów, zarządzaniem 
windykacją, automatycznym przeliczaniem kursów walut, CRM, aplikacje/wersje 
mobilne, automatyzacją wystawiania i wysyłka faktur seryjnych (Rachmistrz 
to już potrafi?) i bardzo szybkie wprowadzanie nowinek dostępnych 
*u wszystkich na raz* (np. weryfikacja numerów VAT kontrahentów). 
A i masz możliwość integracji z własnymi systemami, np. by sklep XYZ
wystawiał sam fakturę, nawet jeśli ten XYZ jest Twoim własnym i autorskim
rozwiązaniem (bo jest dostępne proste API i nie trzeba się zagłębiać
w rozwiązywanie zależności na > 100 tabelach w bazie). I to wszystko 
dużo szybciej i taniej niż desktopowe wersje oferowały kiedykolwiek.

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