Bevezetés

van egy jól ismert Számítástechnika tétel által javasolt Eric Brewer, hogy azt mondja, egy adatbázis elosztott adatok csak akkor ígérnek két a következő három tulajdonság:

• következetesség
• elérhetőség
• partíció tolerancia

Ez nagyon elvont, és a terminológia nem éppen intuitív, így ebben a cikkben mi mindent megteszünk, hogy lebontják ezt az elméletet le az absztrakttól a valóságosabb Beszédekig és példákig. Ez a tétel arra készteti Önt, hogy gondolkodjon az adatbázis-architektúráról abban a tekintetben, hogy mire van szüksége az alkalmazásnak, és milyen áldozatokat kell tennie ezek elérése érdekében.

A CAP terminológia meghatározása

tegyünk néhány alapvető meghatározást az útból, hogy ugyanazon az oldalon legyünk, ahogy haladunk előre erről a tételről.

CAP – konzisztencia, elérhetőség, partíció tolerancia

• konzisztencia – minden adatkiszolgáló ugyanazokkal az adatokkal rendelkezik, így a rendszer bármely szerverét lekérdezheti, és pontosan ugyanazokat az adatokat kaphatja meg.
• elérhetőség – az adatszerverekhez intézett minden kérés választ kap. Ha az egyik szerver foglalt, akkor átirányítják egy másikra, amely képes válaszolni.
• Partition Tolerance – a rendszer azon képessége, hogy továbbra is működjön, még akkor is, ha hálózati hibák vannak, és néhány szerver nem tud kommunikálni.

alapfeltevés-P lehetetlen

egy elosztott adatbázis rendszerben az adatok különböző szerverekre vannak felosztva, és ezek a szerverek hálózaton keresztül beszélnek egymással, hogy ugyanazt az adathalmazt fenntarthassák. A probléma az, hogy a hálózatok megszakadnak, ezért feltételezzük, hogy mindig kommunikálni fog, azaz nem lehet tökéletes hálózatunk. Ezen elmélet szempontjából ez azt jelenti, hogy a Való Világban fel kell áldoznia a partíciós toleranciát. Ha a tökéletes, kifogyhatatlan hálózat létezne, akkor nem lenne problémánk a következetesség és a rendelkezésre állás elérésével, de ez a valós világ, amely fizikai vezetékekre épül, amelyek meghibásodnak, ezért feltételezzük, hogy kudarcot vall.

ha P lehetetlen, mi a választásunk?

mivel feladtuk a partíciós toleranciát, a tétel azt mondja, hogy most választanunk kell a konzisztencia és a rendelkezésre állás között.

választhat, hogy rendelkezésre áll-e, ahol az alkalmazás kielégíti az összes bejövő kérést, de nem garantálja, hogy az adatok a legfrissebbek.

mire van szüksége az alkalmazásnak?

Ha az alkalmazás egy közösségi oldal, és nem kell, hogy a legfrissebb adatokat minden alkalommal, akkor érdemes választani elérhetőség. Számít, hogy a felhasználók 30 másodperc késés után látnak egy bejegyzést? Ha nem, akkor előnyben részesítheti a rendelkezésre állást, mert prioritásként kezeli, hogy a felhasználók akkor is hozzáférhessenek az adatokhoz, ha azok nem a legfrissebb adatok.

Ha viszont az alkalmazás megköveteli, hogy az adatbázis minden olvasása abszolút legfrissebb adat legyen, akkor fel kell áldoznia a rendelkezésre állást és a következetességet kell választania. Egyes kéréseknek hibásnak kell lenniük, mivel az információ nem garantálható, hogy ez az abszolút legfrissebb.

A döntéseket a relációs és NoSQL

Adatbázis tech, mint az SQL és más relációs adatbázis rendszerek tervezett ACID előtérbe következetesség. Másrészt a legtöbb NoSQL adatbázis a rendelkezésre állást helyezi előtérbe.

következtetés

úgy gondoljuk, hogy ennek a tételnek az alkalmazása szempontjából történő vizsgálata kiváló gyakorlat, és segít az alkalmazás prioritásainak értékelésében. Ha van egy elosztott adatrendszered, vizsgáld meg az architektúrádat, és értsd meg, milyen áldozatot hozol.

a MongoDB, a CockroachDB és a Postgres ma mind nagyszerű adatbázis-technológiák, amelyek az adatbázis-architektúránkat rendkívül robusztusvá teszik, de ahogy megbeszéltük, nem tökéletesek. Nincs tökéletes hálózatunk, és mindig van “felhasználói hiba”. Ha termelési környezetbe költözik, és meg akarja vitatni az alkalmazásának legjobb lehetőségeit, kérjük, ne habozzon kapcsolatba lépni velünk az Object Rocket címen.