ugrás a tartalomhoz

Jimmy Bogard: Real World Polyglot Persistence

inf · 2014. Ápr. 21. (H), 16.35
Alkalmazás skálázásának bemutatása REST-tel és poliglott perzisztenciával
 ■
1

Érdekes

Hidvégi Gábor · 2014. Ápr. 23. (Sze), 13.07
Érzésem szerint ahhoz, hogy egy relációs adatbázis ne bírja el, hogy a vásárlók a kosárba pakolják a termékeket, óriási forgalommal kell megterhelni. Magyarországon egyelőre nem hiszem, hogy sok cégnek kell ilyen problémával megküzdenie, így az előadás (számomra legalábbis) inkább az érdekes, mint hasznos kategóriába sorolható.
2

Nekem hasznos volt, mármint

inf · 2014. Május. 2. (P), 14.37
Nekem hasznos volt, mármint segített összerakni a képet, hogy hogyan érdemes elindulni egy kis oldallal, amiből a végén akár nagyobb is lehet különösebb áttervezés nélkül. Amit elmond gyakorlatilag teljesen összehangban van a cqrs + event sourcing technikákkal, annyi, hogy read cache-nek több adatbázist használ fel, ami sokkal könnyebbé teszi a modulok tervezését, szóval nagyon logikus...
3

Ezzel két halálos bűnt

Hidvégi Gábor · 2014. Május. 2. (P), 18.12
Ezzel két halálos bűnt elkövetsz a háromból:
- Olyan kódok megírása, amikre valójában nem lesz szükség
- Túl általános kódok írása
(A következmény: meg fogsz halni!)

Szóval én lebeszéllek a használatukról. Jó tudni, hogy vannak ilyen technikák is, de mindent csak a maga idejében. Persze van rá esély, hogy ti legyetek a következő Prezi vagy Ustream, és őszintén remélem, hogy így lesz, de ha mégsem, akkor csak az idődet vesztegeted (a megrendelőét is) és csak a kódot bonyolítod. Ha meg bejön a dolog, az sem egyik napról a másikra lesz, és bőven lesz idő kibővíteni a rendszert, ráadásul addig sok víz lefolyik a Dunán, ki tudja, lehet, hogy kitalálnak valami sokkal jobb elméletet.
4

Egyáltalán nem volt tervben,

inf · 2014. Május. 2. (P), 22.34
Egyáltalán nem volt tervben, hogy több adatbázist tegyek egy kis porjekt alá, viszont architecture megoldásokat kerestem a szokásos tákolás helyett. A ports and adapters, cqrs, ddd és event sourcing meg nagyon jó négyesnek tűnik ilyen szempontból. Bonyolítást egyedül ezek közül az event sourcing hoz, de cserébe tudok automatikus deploy-t csinálni adatbázis változások esetén is, ami meg nagy előny, ha release early, release often szerint akarok fejleszteni.
5

Kérdések

Hidvégi Gábor · 2014. Május. 3. (Szo), 13.42
Olyan sűrűn változik az adatbázis? Én kézzel kigyűjtöm egy txt fájlba az ALTER TABLE parancsokat (meg ami szükséges), aztán élesítéskor ezeket szépen lefuttatom (biztonsági másolat készítése után), így nincs szükség semmilyen plusz szoftverre, logikára, ami bonyolítaná a helyzetet.

Miért akarsz verébre ágyúval lőni? Ez az a projekt, ahol nem volt pénz, csak ftp-s tárhelyszolgáltatóra? Érdemes ilyen munkára ennyi energiát szánni? Ha ennyire érdekelnek a robusztus megoldások, miért nem jössz fel Bp-re, és helyezkedsz el nagy cégeknél, mint például az Ustream vagy a Prezi? Vagy kimehetnél Bécsbe, múltkor láttam, hogy janoszen cége keres embereket; ezek biztosan olyan kaliberű melók, ahol lehet ilyen megoldásokat használni.
6

Olyan sűrűn változik az

inf · 2014. Május. 3. (Szo), 18.17
Olyan sűrűn változik az adatbázis?

Ha minden nap új fícsört fejlesztek hozzá, akkor igen, sűrűn változik... A release early, release often köszönőviszonyban sincs azzal, hogy lefejlesztem, aztán a késznek ítélt kódot adom át egyszer valamikor az ügyfélnek.

Nem szeretnék cégnek dolgozni, és nem is hiszem, hogy felvennének bárhova.

Én kézzel kigyűjtöm egy txt fájlba az ALTER TABLE parancsokat (meg ami szükséges), aztán élesítéskor ezeket szépen lefuttatom (biztonsági másolat készítése után), így nincs szükség semmilyen plusz szoftverre, logikára, ami bonyolítaná a helyzetet.

Az alter table típusú megoldásoknak megvan a maga korlátja. Az event sourcing sokkal nagyobb szabadságot ad, gyakorlatilag nulláról újratervezheted a teljes adatbázist, ha neked úgy tetszik...