Apache Cassandra

All lectures for HU purposes
Szint , Lecke
Elérhető

4.1 Leírás

Az Apache Cassandra egy elosztott adatbázis-kezelő rendszer, amely a NoSQL-rendszerek osztályába tartozik, és arra készült, hogy rendkívül méretezhető és megbízható tárolókat hozzon létre hash formájában megjelenített hatalmas adattömbökből.

Kezdetben a projektet a Facebook fejében fejlesztették ki, majd 2009-ben az Apache Software Foundation szárnya alá került, ez a szervezet folytatja a projekt fejlesztését. A Cassandra alapú ipari megoldások olyan cégeknek nyújtanak szolgáltatásokat, mint a Cisco, IBM, Cloudkick, Reddit, Digg, Rackspace, Huawei, Netflix, Apple, Instagram, GitHub, Twitter és Spotify. 2011-re a Cassandra alatt egyetlen adatbázist kiszolgáló legnagyobb szerverfürt több mint 400 géppel rendelkezett, és több mint 300 TB adatot tartalmazott.

Java nyelven írva a DynamoDB-hez hasonló elosztott hash rendszert valósít meg, amely szinte lineáris skálázhatóságot biztosít növekvő adatmennyiség mellett. Oszlopcsaládon alapuló adattárolási modellt használ, amely különbözik az olyan rendszerektől, mint a MemcacheDB, amelyek csak egy kulcs-érték párban tárolják az adatokat, mivel képesek több beágyazási szintű hash-ek tárolására.

A hibatűrő DBMS kategóriájába tartozik: az adatbázisban elhelyezett adatok automatikusan replikálódnak egy elosztott hálózat több csomópontjára, vagy akár egyenletesen elosztva több adatközpontban. Ha egy csomópont meghibásodik, annak funkcióit menet közben veszik át más csomópontok, új csomópontok hozzáadása a fürthöz és a Cassandra verzió frissítése menet közben történik, további kézi beavatkozás és más csomópontok újrakonfigurálása nélkül.

A terheléselosztás minőségének megőrzése érdekében azonban erősen ajánlott újra generálni kulcsokat (címkéket) minden csomóponthoz, beleértve a meglévőket is. A meglévő csomópontok kulcsgenerálása elkerülhető a csomópontok számának többszörös növekedése esetén (2-szer, 3-szor stb.).

4.2 Adatmodell

A Cassandra terminológiában egy alkalmazás kulcstérrel működik, ami megfelel a relációs modellben szereplő adatbázisséma fogalmának. Ez a kulcstér több oszlopcsaládot is tartalmazhat, ami megfelel a relációs tábla fogalmának.

Az oszlopcsaládok viszont oszlopokat (oszlopot) tartalmaznak, amelyeket a rekordban (sorban) lévő kulccsal (sorkulcs) kombinálnak. Az oszlop három részből áll: név (oszlop neve), időbélyeg (timestamp) és érték (érték). A rekordon belüli oszlopok sorrendben vannak. A relációs adatbázisokkal ellentétben nincs korlátozás arra vonatkozóan, hogy a rekordok (az adatbázis szempontjából ezek sorok) tartalmaznak-e ugyanolyan nevű oszlopokat, mint a többi rekordban - nem.

Az oszlopcsalád többféle lehet, de ebben a cikkben ezt a részletet elhagyjuk. A Cassandra legújabb verzióiban is lehetővé vált az adatok meghatározására és módosítására vonatkozó lekérdezések (DDL, DML) végrehajtása a CQL nyelv használatával, valamint másodlagos indexek létrehozása.

A cassandrában tárolt konkrét értéket a következők azonosítják:

  • keyspace egy kötés az alkalmazáshoz (domain). Lehetővé teszi különböző alkalmazások adatainak tárolását ugyanabban a fürtben;
  • az oszlopcsalád egy lekérdezéshez való kötés;
  • kulcs egy fürtcsomóponthoz való kötődés. A kulcs határozza meg, hogy a mentett oszlopok mely csomópontokra kerülnek;
  • Az oszlopnév a rekordban lévő attribútumhoz való kötődés. Lehetővé teszi több érték tárolását egy bejegyzésben.

Minden értékhez tartozik egy időbélyeg, egy felhasználó által megadott szám, amelyet a rögzítés során felmerülő ütközések feloldására használnak: minél nagyobb a szám, annál újabb oszlopot vesz figyelembe, és összehasonlításkor felülírja a régi oszlopokat.

4.3 Adattípusok

Adattípusok szerint: a kulcstér és az oszlopcsalád karakterláncok (nevek); az időbélyeg egy 64 bites szám; és a kulcs, az oszlop neve és az oszlop értéke egy bájtok tömbje. Cassandra is rendelkezik az adattípusok fogalmával. Ezeket a típusokat (opcionálisan) a fejlesztő megadhatja az oszlopcsalád létrehozásakor.

Az oszlopnevek esetében ezt összehasonlítónak, az értékek és kulcsok esetében pedig érvényesítőnek nevezik. Az első meghatározza, hogy milyen bájtértékek engedélyezettek az oszlopnevekhez, és hogyan rendezheti őket. A második az, hogy milyen bájtértékek érvényesek az oszlop- és kulcsértékekre.

Ha ezek az adattípusok nincsenek beállítva, akkor a cassandra tárolja az értékeket, és bájtkarakterláncként (BytesType) hasonlítja össze, mivel valójában belső tárolásra kerülnek.

Az adattípusok a következők:

  • BytesType : bármilyen bájt karakterlánc (nincs érvényesítés)
  • AsciiType : ASCII karakterlánc
  • UTF8Típus : UTF-8 karakterlánc
  • IntegerType : tetszőleges méretű szám
  • Int32Type : 4 bájtos szám
  • LongType : 8 bájtos szám
  • UUIDType : UUID típusú 1 vagy 4
  • TimeUUIDType : 1. típusú UUID
  • DateType : 8 bájtos időbélyeg érték
  • BooleanType : két érték: igaz = 1 vagy hamis = 0
  • FloatType : 4 bájtos lebegőpontos szám
  • DoubleType : 8 bájtos lebegőpontos szám
  • DecimalType : tetszőleges méretű és lebegőpontos szám
  • CounterColumnType : 8 bájtos számláló

A cassandrában minden adatírási művelet mindig átírási művelet, vagyis ha egy már létező, azonos kulcsú és nevű oszlop kerül az oszlopcsaládba, és az időbélyeg nagyobb, mint a mentett, akkor az érték felülíródik. . A rögzített értékek soha nem változnak, csak az újabb oszlopok érkeznek új értékekkel.

Cassandrának írni gyorsabb, mint olvasni. Ez megváltoztatja a tervezésben alkalmazott megközelítést. Ha a cassandrát az adatmodell tervezése szempontjából tekintjük, akkor könnyebb egy oszlopcsaládot nem táblázatként, hanem materializált nézetként elképzelni - olyan struktúrát, amely valamilyen összetett lekérdezés adatait reprezentálja, de tárolja korong.

Ahelyett, hogy valamilyen módon lekérdezések segítségével próbálnánk meg összeállítani az adatokat, jobb, ha megpróbálunk mindent a célcsaládban tárolni, ami ehhez a lekérdezéshez szükséges lehet. Vagyis nem az entitások vagy objektumok közötti kapcsolatok oldaláról kell megközelíteni, hanem a lekérdezések oldaláról: mely mezőket kell kiválasztani; milyen sorrendben haladjanak a nyilvántartások; a főbbekhez kapcsolódó milyen adatokat kell együtt kérni - mindezt már az oszlopcsaládban kell tárolni.

Egy rekordban lévő oszlopok száma elméletileg 2 milliárdra van korlátozva. Ez egy rövid kitérő, és további részletek a tervezési és optimalizálási technikákról szóló cikkben találhatók. És most ássuk be az adatok cassandra mentésének és olvasásának folyamatát.

Hozzászólások
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION