Adatmodellezés Cassandrában

1. Áttekintés

A Cassandra egy NoSQL adatbázis, amely magas rendelkezésre állást és horizontális skálázhatóságot biztosít a teljesítmény romlása nélkül.

A Cassandra legjobb teljesítményének érdekében gondosan meg kell terveznünk a sémát az adott üzleti problémára jellemző lekérdezési minták köré.

Ebben a cikkben áttekintjük a legfontosabb fogalmakat hogyan lehet megközelíteni az adatmodellezést Cassandrában.

A folytatás előtt áttekintheti a Cassandra with Java cikkünket, hogy megismerje az alapokat és a csatlakozást a Cassandra Java használatával.

2. Partíciókulcs

A Cassandra egy elosztott adatbázis, amelyben az adatokat particionálják és egy fürt több csomópontján tárolják.

A partíciókulcs egy vagy több adatmezőből áll, és az a particionáló által kivonatolással létrehozott jogkivonat az adatok egyenletes elosztásához egy fürtön.

3. Klaszterkulcs

A fürtözési kulcs egy vagy több mezőből áll, és segíti az azonos partíciós kulccsal rendelkező csoportok fürtözését vagy csoportosítását, és rendezett sorrendben történő tárolását.

Tegyük fel, hogy idősoros adatokat tárolunk Cassandrában, és időrendben szeretnénk visszakeresni az adatokat. Az idősoros adatmezőket tartalmazó fürtözési kulcs nagyon hasznos lesz az adatok hatékony visszakereséséhez ebben a felhasználási esetben.

Megjegyzés: A partíciókulcs és a fürtözési kulcs kombinációja alkotja az elsődleges kulcsot, és egyedülállóan azonosítja a Cassandra fürt bármely rekordját.

4. Iránymutatások a lekérdezési minták körül

Mielőtt elkezdenénk a Cassandra adatmodellezését, meg kell határoznunk a lekérdezési mintákat, és meg kell győződnünk arról, hogy azok megfelelnek-e a következő irányelveknek:

  1. Minden lekérdezésnek egyetlen partícióról kell beolvasnia az adatokat
  2. Nyomon kell követnünk, hogy mennyi adat tárolódik egy partícióban, mivel a Cassandra korlátozza az egyetlen partícióban tárolható oszlopok számát
  3. Rendben van az adatok dormalizálása és másolása, hogy ugyanazon adatokon keresztül támogassák a különféle lekérdezési mintákat

A fenti irányelvek alapján nézzünk meg néhány valós használati esetet, és azt, hogy miként modelleznénk a Cassandra adatmodelleket hozzájuk.

5. Példák a valós adatok modellezésére

5.1. Facebook bejegyzések

Tegyük fel, hogy különböző felhasználók Facebook-bejegyzéseit tároljuk Cassandrában. Az egyik gyakori lekérdezési minta a legfelső ‘lekérése leszN’Egy adott felhasználó által tett bejegyzések.

Így, nekünk kellegy adott felhasználó összes adatait egyetlen partíción tárolja a fenti irányelvek szerint.

Ezenkívül a poszt időbélyegének fürtödési kulcsként történő használata is hasznos lesz aN„Hatékonyabban posztol.

Határozzuk meg a Cassandra táblasémát ehhez a felhasználási esethez:

CREATE TABLE posts_facebook (user_id uuid, post_id timeuuid, tartalmi szöveg, ELSŐKULCS (user_id, post_id)) CLUSTERING ORDER BY (post_id DESC);

Most írjunk egy lekérdezést, hogy megtaláljuk a felhasználó számára a 20 legnépszerűbb bejegyzést Anna:

Válasszon tartalmat a posts_facebook-ból WHERE user_id = "Anna_id" LIMIT 20

5.2. Edzőtermek egész országban

Tegyük fel, hogy sok partner tornaterem részleteit tároljuk számos ország különböző városaiban és államaiban, és szeretnénk beszerezni az adott város tornatermeit.

Tegyük fel, hogy vissza kell adnunk az eredményeket, ha a tornateremeket a nyitás dátuma szerint rendezzük.

A fenti irányelvek alapján egyetlen partíción kell tárolnunk egy adott állam és egy ország adott városában található edzőtermet, és a nyitás dátumát és a tornaterem nevét kell csoportosító kulcsként használni.

Határozzuk meg a Cassandra táblázat sémáját ehhez a példához:

CREATE TABLE gyms_by_city (country_code text, state text, city text, gym_name text, opening_date timestamp, PRIMARY KEY ((country_code, state_province, city), (opening_date, gym_name)) CLUSTERING ORDER BY (opening_date ASC, gym_name ASC);

Most nézzünk meg egy olyan lekérdezést, amely az első tíz edzőtermet nyitási dátumukra lekéri az Egyesült Államok Arizona államának Phoenix városára:

SELECT * FROM gyms_by_city WHERE country_code = "us" AND state = "Arizona" AND city = "Phoenix" LIMIT 10

Ezután lássunk egy lekérdezést, amely behozza a tíz legutóbb megnyitott edzőtermet Phoenix városában az Egyesült Államok Arizona államában:

SELECT * FROM gyms_by_city WHERE country_code = "minket" és state = "Arizona" és city = "Phoenix" MEGRENDELÉS nyitási_dátum szerint DESC LIMIT 10

Megjegyzés: Mivel az utolsó lekérdezés rendezési sorrendje ellentétes a táblázat létrehozása során meghatározott rendezési sorrenddel, a lekérdezés lassabban fog futni, mivel a Cassandra először beolvassa az adatokat, majd a memóriába rendezi azokat.

5.3. E-kereskedelmi ügyfelek és termékek

Tegyük fel, hogy e-kereskedelmi üzletet működtetünk, és hogy tároljuk a Vevő és Termék információk a Cassandrán belül. Vizsgáljuk meg a használati eset körüli gyakori lekérdezési mintákat:

  1. Kap Vevő info
  2. Kap Termék info
  3. Szerezz be mindent Ügyfelek akik szeretik az adott Termék
  4. Szerezz be mindent Termékek adott Vevő kedveli

Először külön táblázatok használatával tároljuk a Vevő és Termék információ. A fentiekben bemutatott 3. és 4. kérdés támogatásához azonban megfelelő mennyiségű denormalizálást kell bevezetnünk.

Ennek eléréséhez még két táblázatot készítünk -Customer_by_Product”És„Product_by_Customer“.

Nézzük meg a Cassandra táblázat sémáját ebben a példában:

CREATE TABLE Ügyfél (cust_id szöveg, keresztnév szöveg, vezetéknév szöveg, regisztrált_on időbélyeg, PRIMARY KEY (cust_id)); CREATE TABLE Termék (prdt_id szöveg, címszöveg, ELSŐKULCS (prdt_id)); CREATE TABLE Customer_By_Liked_Product (tetszett_prdt_id szöveg, tetszett_időbélyegző, címszöveg, cust_id szöveg, utónév szöveg, vezetéknév szöveg, ELSŐKULCS (prdt_id, tetszett_)); CREATE TABLE Product_Liked_By_Customer (cust_id text, first_name text, last_name text, liked_prdt_id text, liked_on timestamp, title text, PRIMARY KEY (cust_id, likes_on));

Megjegyzés: Az adott ügyfél által a közelmúltban kedvelt termékek és az adott terméket nemrégiben kedvelt ügyfelek támogatásához a „tetszett_on”Oszlop fürtözési kulcsként.

Nézzük meg a lekérdezést, hogy megtaláljuk azt a tíz ügyfelet, akiknek legutóbb tetszett a termék.Pepsi“:

SELECT * FROM Customer_By_Liked_Product WHERE title = "Pepsi" LIMIT 10

Lássuk azt a lekérdezést, amely megtalálja a legutóbb kedvelt termékeket (legfeljebb tíz) egy „Anna“:

SELECT * FROM Product_Liked_By_Customer WHERE first_name = "Anna" LIMIT 10

6. Nem hatékony lekérdezési minták

A Cassandra adatok tárolásának módja miatt egyes lekérdezési minták egyáltalán nem hatékonyak, beleértve a következőket:

  • Adatok lekérése több partícióról - Ehhez egy koordinátornak meg kell kapnia az adatokat több csomópontból, átmenetileg tárolnia kell a kupacban, majd összesítenie kell az adatokat, mielőtt az eredményeket visszaadnák a felhasználónak
  • Csatlakozás alapú lekérdezések - elosztott jellege miatt a Cassandra ugyanúgy nem támogatja a táblázatos csatlakozásokat a lekérdezésekben, mint egy relációs adatbázis, és ennek eredményeként, lekérdezés a következővel:a csatlakozások lassabbak lesznek, és következetlenséghez és rendelkezésre állási problémákhoz is vezethetnek

7. Következtetés

Ebben az oktatóanyagban számos bevált gyakorlatot ismertettünk az adatmodellezés megközelítésével kapcsolatban Cassandrában.

Az alapfogalmak megértése és a lekérdezési minták előzetes azonosítása szükséges egy helyes adatmodell tervezéséhez, amely a legjobb teljesítményt nyújtja a Cassandra fürtből.