Używanie client side evaluation jako ułatwienie scalowania?

Odpowiedz Nowy wątek
2019-02-01 19:29

Rejestracja: 4 lata temu

Ostatnio: 42 minuty temu

0

Jeżeli dobrze zrozumiałem, to pomysł jest taki:

Mając X instancji aplikacji, zamiast próbować wycisnąć nie wiadomo jaką wydajność z bazy cięższymi query,
to rozkłada się niektóre query na instancje aplikacji (client side evaluation) i dzięki temu łatwiej jest to skalować, bo

a) większa kontrola nad kodem niż nad db

b) kontrola nad ilościom instancji oraz łatwiej dorzucić instancje aplikacji niż instancje bazy

c) kontrola nad workloadem per instancja

Ktoś coś takiego robił?

edytowany 5x, ostatnio: WeiXiao, 2019-02-01 19:34
pierwsze słyszę o takim skalowaniu bazy danych, jakiś link ? - neves 2019-02-01 21:03
@neves: to był komentarz z którego taki koncept mi wyszedł, więc dlatego pytam :D W skrócie: Doing query execution on the client side is more often than not a good thing. It's much, much, much easier to scale your app than it is to scale your database. (...)Try running a hundred of them on different clients simultaneously and see the Sql start to lock and the client side doesn't. Think about where and how you can cache that work or share that data. - WeiXiao 2019-02-01 21:06
The performance of your code is irrelevant, the performance of the system is what's important. Your code will be slower if you do client side evaluation because it is doing more work, but work in your code is cheap, and work in your code scales out more easily. That doesn't mean you should always do client side evaluation, but avoiding it like the plague is simply wrong. In particular, sorting in Sql is horrifically expensive. - WeiXiao 2019-02-01 21:08

Pozostało 580 znaków

2019-02-01 21:47

Rejestracja: 16 lat temu

Ostatnio: 1 godzina temu

Lokalizacja: Kraków

2

W czasach w których wkładało się wszelką logikę do baz danych to miałoby sens. Obecnie jednak żyjemy w czasach w których w bazie się umieszcza jedynie kod właśnie ze względu na to że szybciej się wykona o rząd wielkości niż po stronie aplikacji. Także jakoś nie widzę wiele przypadków w typowej aplikacji biznesowej korzystającej z relacyjnej bazy danych gdzie by się dało coś z bazy przenieść na aplikację, bo już dawno takiego kodu tam nie powinno być, tyle że nie ze względu na wydajność tylko prostotę utrzymania.

Relacyjną bazę danych się skaluje, do wyboru:

  • korzystając z cache
  • dodając repliki do odczytu (master - slave)
  • dodając inne źródła danych tylko do odczytu zawierające zdenormalizowane dane zasilane na bieżąco z naszej relacyjnej bazy (hurtowanie danych. bazy dokumentowe, różne wyszukiwarki bazujące na Apache Lucene)
  • dzieląc bazę poziomo (sharding), gdzie na wybranych instancjach są określone zakresy danych
  • dzieląc bazę pionowo, czyli tak naprawdę wkraczamy w świat mikroserwisów/soa

It's easy to hate code you didn't write, without an understanding of the context in which it was written.
edytowany 2x, ostatnio: neves, 2019-02-01 22:03
W jednym z projektów mam dużo logiki po stronie bazy danych. Serdecznie odradzam logiki w db. Przypadek z życia : Triger ustawiony na insert, robi insert do innej tabeli, która na insert wywołuje procedurę, która robi insert do tej pierwszej tabeli. w której "naszczescie" jest pętla, która już została zadeklarowana i sypie błąd. 2 godziny żeby rozkminić co go wywołało i lipny kod który obejdzie tego bug'a. XD - Gerappa 2019-02-04 16:44

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0