Kepzeld el, hogy ugye sql-ed van, szoval frankon szopsz az ER-diagrammokkal ahelyett, hogy szepen egy json faba tudnad pakolni az adatokat.
Amikor egy tranzakciot inditasz, ami tobb tablat is modosit (n:m kapcsolo tablak pl.), akkor az adatbaziskezelonek 2 lehetosege van:
- row-level lock-ot tesz a modositott rekordokra, es ha egy masik tranzakcio hozza akar ferni, megvarja, amig a tied befejezodik.
- MVCC-t csinal, es remeli, hogy nem fog utkozni.
Az elso esetben _minden_egyes_kurva_sor_modositasara, olvasasara egy cluster-wide lock-ot kell elhelyezni, hogy az osszes tobbi master is tudja, hogy ez most valtozik. Performance -> 0.
A masodik esetben (amit manapsag probalnak tolni a sql-gyartok, mert jol elfedi a hibat a sql design-jaban) esetben barmelyik commit() dobhat hibat. Namost nemtom, te mit lattal, de en nem, vagy alig-alig lattam programozot, aki a commit()-ra hibakezelest, ne adj' isten, retry()-t rakott volna. Mert a retry ugye bonyi.
Ebbol kovetkezik, hogy a tranzakcios adatbaziskezelok SOHA nem fognak skalazodni multi-master modon. Erre csak a document storage es egyeb nosql-ek kepesek, ahol kapasbol egy osszetett dokumentumod van, es azt garantalja, hogy atomic modon update-eli. Na ezt jol megmondtam.
En konkretan le is szalltam a SQL-rol mar par eve, es mongodb-t tolok. Eddig nem volt vele baj, es a sokal hulye DDL es a tobbi marhasagot is frankon el lehet felejteni. A hibernate-rol meg ORM-rol nem is beszelve. El nem hinned, mennyivel egyszerubb az elet igy.