|
A Redis-szel történő alkalmazások fejlesztése kellemes folyamat, de mint minden technológiában, van néhány dolgot szem előtt tartani Redis-alapú alkalmazások tervezésekor. Lehet, hogy már korábban is ismerted a relációs adatbázis-fejlesztés egész rutinját, és a Redis alapú alkalmazásfejlesztésnek sok hasonlósága van, de szem előtt kell tartani a következő két dolgot – a Redis egy memórián belüli adatbázis, és egyszálú. Ezért a Redis használatakor a következő pontokra kell figyelni: 1. Irányítsd az összes Redisben tárolt kulcsot Az adatbázis fő funkciója az adatok tárolása, de normális, hogy a fejlesztők figyelmen kívül hagynak néhány adatot az alkalmazáskövetelmények vagy adathasználati módszerek változása miatt, és ugyanez igaz a Redis-re is. Előfordulhat, hogy bizonyos lejáró kulcsokat figyelmen kívül hagyhatsz, vagy elfelejtheted az adatokat, mert az alkalmazásod egyik modulja elavult. Akárhogy is, a Redis olyan adatot tárol, amelyek már nem használatban vannak, és ok nélkül foglalnak helyet. A Redis gyengén strukturált adatmintája megnehezíti annak megállapítását, mi van központi szinten tárolva, hacsak nem használunk egy nagyon érett kulcsnévsort. A helyes elnevezési módszer leegyszerűsíti az adatbázis-kezelést, és amikor létrehozol névteret a kulcsoknak az alkalmazáson vagy szolgáltatásodon keresztül (általában kolonokkal osztod a kulcsneveket), könnyen azonosíthatod az adatokat áthelyezés, átalakítás vagy törlés során. Egy másik gyakori felhasználási eset a Redis második adattárolójaként a forró adatelemek számára, ahol az adatok nagy része más adatbázisokban tárolódik, például PostgreSQL-ben vagy MongoDB-ben. Ezekben a felhasználási esetekben a fejlesztők gyakran elfelejtik törölni a megfelelő adatokat a Redisben, amikor az adatokat eltávolítják az elsődleges tárolóból. Ebben az esetben általában kaszkád törlésre van szükség, amely során az összes azonosítót elmenti egy adott adatelemhez a Redis konfigurációban, hogy biztosítsák, hogy az adatok törlése után a fő adatbázisból egy tisztító hívja az összes releváns másolatot és információt törölni. 2. Szabályozzuk az összes kulcsnév hosszát Ahogy fentebb is említettük, megfelelő elnevezési konvenciókat használtunk és előtagokat adtunk hozzá, hogy azonosítsuk, hová kerülnek az adatok, így ez ennek ellenére áll. Azonban ne feledd, hogy a Redis egy memórián belüli adatbázis, és minél rövidebb a kulcsok, annál kevesebb helyre van szükség. Természetesen, ha egy adatbázisban milliók vagy milliárdok kulcsok vannak, a kulcsnév hossza nagy hatással lesz. Például egy 32 bites Redis szerveren, ha egymillió kulcsot tárolsz 32 karakteres hosszúsággal, akkor körülbelül 96MB helyet foglal el 6 karakteres kulcsnév esetén, de ha 12 karakteres kulcsnevet használsz, a helyigény körülbelül 111MB-ra nő. Ha több kulcs van, a további 15%-os többletköltség jelentős hatással lesz. 3. Használd a megfelelő adatstruktúrát Legyen szó memóriahasználatról vagy teljesítményről, néha az adatstruktúrák nagy hatással lehetnek, íme néhány legjobb gyakorlat, amire hivatkozhatsz: Ahelyett, hogy több ezer (vagy milliónyi) különálló stringként tárolnánk adatokat, fontold meg hashelt adatstruktúrák használatát a kapcsolódó adatok csoportosítására. A hash táblák nagyon hatékonyak, és csökkenthetik a memóriahasználatot; Ugyanakkor a hashing előnyösebb a részletek absztrakciója és a kód olvashatósága szempontjából is. Ha megfelelő, használj listát a set helyett. Ha nem kell használni a beállított funkciót, a List gyorsabb sebességet biztosít, mint a beállított, miközben kevesebb memóriát használ. A rendezett halmazok a legdrágább adatstruktúrák, mind memóriafogyasztás, mind az alapvető műveletek összetettsége szempontjából. Ha csak egy módra van szükséged a rekordok lekérdezésére, és nem érdekeled az ilyen tulajdonságok rendezése, akkor erősen ajánlott hash táblákat használni. A Redisben gyakran elfeledett funkció a bitmapek vagy bithalmazok (a V2.2 után). A bitsetek lehetővé teszik, hogy több bitszintű műveletet végezz Redis értékekkel, például néhány könnyű elemzéssel. 4. Ne használd a billentyűt SCAN használat közben A Redis v2.8-tól már elérhető a SCAN parancs, amely lehetővé teszi a kulcstérből lekérést a kurzorral. A KEYS parancshoz képest, bár a SCAN nem tudja egyszerre visszaadni az összes egyező eredményt, elkerüli a rendszer blokkolásának nagy kockázatát, így néhány művelet végrehajtható a fő csomóponton. Fontos megjegyezni, hogy a SCAN parancs kurzor-alapú iterátor. Minden alkalommal, amikor a SCAN parancsot hívják, egy új kurzor kerül vissza a felhasználóhoz, és a felhasználónak ezt az új kurzort kell használnia a következő iterációban a SCAN parancs kurzorparamétereként, hogy folytassa az előző iterációs folyamatot. Ugyanakkor a SCAN-szel a felhasználók kulcsnév mód és szám opciókkal is módosíthatják a parancsokat. A SCAN-hoz kapcsolódó parancsok közé tartoznak az SSCAN parancsok, HSCAN parancsok és ZSCAN parancsok, amelyeket gyűjteményekhez, hash kulcsokhoz és folytatásokhoz használnak. 5. Használj szerveroldali Lua szkripteket A Redis használata során a Lua szkriptek támogatása kétségtelenül nagyon barátságos fejlesztői környezetet biztosít a fejlesztőknek, így jelentősen felszabadítva a felhasználók kreativitását. Ha helyesen használják, a Lua szkriptek jelentős javulást hozhatnak a teljesítményben és az erőforrás-fogyasztásban. Ahelyett, hogy adatokat továbbítanának a CPU-nak, a szkriptek lehetővé teszik, hogy a logikát az adathoz legközelebb végezz, csökkentve a hálózati késlést és a redundáns adatátvitelt. A Redisben a Lua nagyon klasszikus felhasználási esete az adatszűrés vagy az adatok összegyűjtése egy alkalmazásba. Ha a feldolgozási folyamatot egy szkriptbe foglalod, egyszerűen hívhatod azt, hogy kevesebb erőforrással kevesebb idő alatt kisebb választ kapj. Profi tipp:A Lua nagyszerű, de vannak problémái is, például a hibajelentések és kezelés nehézségei vannak. Egy okos megközelítés, ha a Redis Pub/Sub funkcióját használod, és a szkript egy dedikált csatornán keresztül továbbítja a naplóüzeneteket. Ezután hozz létre egy előfizetői folyamatot, és ennek megfelelően dolgozza fel.
| 
Közzétéve 2015. 12. 29. 12:22:28
|
|
|
