Megosztás a következőn keresztül:

Az Apache Cassandra-hoz készült Azure Cosmos DB-hez való alkalmazkodás, ha az Apache Cassandra-ból származik

  • Cikk

A KÖVETKEZŐKRE VONATKOZIK: Cassandra

Az Apache Cassandra-hoz készült Azure Cosmos DB a meglévő Cassandra SDK-kkal és -eszközökkel biztosít vezetékes protokollkompatibilitást. Az Apache Cassandra-hoz való csatlakozásra tervezett alkalmazásokat a Cassandra API használatával minimális módosításokkal futtathatja.

A Cassandra API használatakor fontos tisztában lenni az Apache Cassandra és az Azure Cosmos DB közötti különbségekkel. Ha ismeri a natív Apache Cassandra-t, ez a cikk segíthet az Apache Cassandra Azure Cosmos DB használatának megkezdésében.

Szolgáltatások támogatása

A Cassandra API számos Apache Cassandra-funkciót támogat. Egyes funkciók nem támogatottak, vagy korlátozások vonatkoznak rájuk. A migrálás előtt győződjön meg arról, hogy a szükséges Azure Cosmos DB for Apache Cassandra-funkciók támogatottak.

Replikáció

A replikáció tervezésekor fontos a migrálás és a konzisztencia is.

Bár a Cassandra API-val a Cassandra Query Language (CQL) bináris protokoll v4 wire protokollon keresztül kommunikálhat, az Azure Cosmos DB saját belső replikációs protokollt implementál. A Cassandra pletykaprotokoll nem használható élő áttelepítéshez vagy replikációhoz. További információ: Live-migrate from Apache Cassandra to the API for Cassandra by using dual writes.

Az offline migrálással kapcsolatos információkért lásd : Adatok migrálása a Cassandra-ból egy Azure Cosmos DB for Apache Cassandra-fiókba az Azure Databricks használatával.

Bár az Apache Cassandra és az Azure Cosmos DB replikációs konzisztenciájának megközelítései hasonlóak, fontos tisztában lenni azzal, hogy miben különböznek. A leképezési dokumentum összehasonlítja az Apache Cassandra és az Azure Cosmos DB replikációs konzisztencia-megközelítéseit. Javasoljuk azonban, hogy kifejezetten tekintse át az Azure Cosmos DB konzisztenciabeállításait , vagy tekintse meg egy rövid videós útmutatót az Azure Cosmos DB platform konzisztenciabeállításainak megismeréséhez.

A Cassandra API használatakor nem kell jelentős kódmódosításokat végeznie az Apache Cassandrát futtató meglévő alkalmazásokon. Az Azure Cosmos DB Cassandra API-jának néhány megközelítését és konfigurációs beállításait javasoljuk. Tekintse át a Java-ra vonatkozó Cassandra-javaslatokhoz készült BLOGBEJEGYZÉS API-t.

Kódminták

A Cassandra API-t úgy tervezték, hogy a meglévő alkalmazáskóddal működjön. Ha kapcsolódással kapcsolatos hibákba ütközik, a gyorsútmutató-mintákkal kiindulópontként felfedezheti a meglévő kódban esetleg szükséges kisebb beállítási módosításokat.

A Java v3 és a Java v4 illesztőprogramok részletesebb mintáival is rendelkezünk. Ezek a kódminták egyéni bővítményeket implementálnak, amelyek az ajánlott ügyfélkonfigurációkat implementálják.

A Java Spring Boot (v3-illesztőprogram) és a Java Spring Boot (v4-illesztőprogram) mintáit is használhatja.

Tárolás

A Cassandra API-t az Azure Cosmos DB, amely egy dokumentumorientált NoSQL-adatbázismotor. Az Azure Cosmos DB metaadatokat tart fenn, ami egy adott számítási feladathoz szükséges fizikai tárterület változását eredményezheti.

A natív Apache Cassandra és az Azure Cosmos DB tárolási követelményeinek különbsége kis sorméretekben a legfeltűnőbb. Bizonyos esetekben a különbség eltolható, mert az Azure Cosmos DB nem implementálja a tömörítést vagy a sírköveket. Ez a tényező jelentősen függ a számítási feladattól. Ha nem biztos a tárolási követelményekben, javasoljuk, hogy először hozzon létre egy megvalósíthatósági igazolást.

Többrégiós üzembe helyezés

A natív Apache Cassandra alapértelmezés szerint egy több főkiszolgálós rendszer. Az Apache Cassandra nem rendelkezik egyetlen főkiszolgálóra többrégiós replikációval csak olvasási célokra. Az Apache Cassandra esetében az alkalmazásszintű feladatátvétel egy másik régióba történő írás esetén redundáns. Minden csomópont független, és nincs egyetlen meghibásodási pont sem. Az Azure Cosmos DB azonban lehetővé teszi az önálló vagy több főkiszolgálós régiók íráshoz való konfigurálását.

Az írások egy fő régiójának előnye, hogy elkerüli a régiók közötti ütközési forgatókönyveket. Lehetővé teszi, hogy több régióban is erős konzisztenciát tartson fenn, miközben magas rendelkezésre állást biztosít.

Feljegyzés

A régiók közötti erős konzisztencia és a nulla értékű helyreállítási pont célkitűzése (RPO) nem lehetséges a natív Apache Cassandra esetében, mert minden csomópont képes írások kiszolgálására. Az Azure Cosmos DB-t egyetlen írási régió konfigurációjában konfigurálhatja a régiók közötti erős konzisztenciához. A natív Apache Cassandra-hoz hasonlóan azonban nem konfigurálhat olyan Azure Cosmos DB-fiókot, amely több írási régióval van konfigurálva az erős konzisztencia érdekében. Az elosztott rendszerek nem tudnak nulla RPO-t és nulla helyreállítási időkorlátot (RTO) biztosítani.

További információ: Terheléselosztási szabályzat a Cassandra api Java-blogra vonatkozó javaslataiban. Tekintse meg a Cassandra Java v4-illesztőprogram hivatalos kódmintájában szereplő feladatátvételi forgatókönyveket is.

Kérelemegységek

A natív Apache Cassandra-fürt futtatása és egy Azure Cosmos DB-fiók kiépítése között az egyik legnagyobb különbség az adatbázis-kapacitás kiépítése. A hagyományos adatbázisokban a kapacitás a processzormagok, a RAM és az IOPS szempontjából van kifejezve. Az Azure Cosmos DB egy több-bérlős platformszolgáltatás-adatbázis. A kapacitást egyetlen normalizált, kérelemegységnek nevezett metrika használatával fejezzük ki. Minden, az adatbázisnak küldött kérelemegység költséggel (RU költség) rendelkezik. Az egyes kérések profilba állíthatók a költség meghatározásához.

A kérelemegységek metrikaként való használatának előnye, hogy az adatbázis-kapacitás determinisztikusan kiépíthető a nagymértékben kiszámítható teljesítmény és hatékonyság érdekében. Az egyes kérések költségeinek profilkészítése után a kérelemegységek használatával közvetlenül társíthatja az adatbázisba küldött kérelmek számát a kiépítendő kapacitással. A kapacitás kiépítésének ezen módjával az a kihívás, hogy szilárd ismeretekkel kell rendelkeznie a számítási feladat átviteli sebességének jellemzőiről.

Erősen javasoljuk, hogy profilozza a kéréseit. Ezekkel az információkkal megbecsülheti a kiépítendő kérelemegységek számát. Íme néhány cikk, amely segíthet a becslés készítésében:

Kapacitáskiépítési modellek

A hagyományos adatbázis-kiépítés során a rendszer előre kiépíti a rögzített kapacitást a várt átviteli sebesség kezeléséhez. Az Azure Cosmos DB egy kiosztott átviteli sebesség nevű kapacitásalapú modellt kínál. Több-bérlős szolgáltatásként az Azure Cosmos DB használatalapú modelleket is kínál automatikus skálázási módban és kiszolgáló nélküli módban. A számítási feladatok kihasználtságának mértéke a számítási feladat átviteli sebességének kiszámíthatóságától függ.

Általában a kiszámítható átviteli sebességgel rendelkező állandó állapotú számítási feladatok élvezik a legtöbbet a kiosztott átviteli sebességből. A nagy alvóidőt igénylő számítási feladatok kihasználják a kiszolgáló nélküli módot. Azok a számítási feladatok, amelyek folyamatos minimális átviteli sebességgel rendelkeznek, de kiszámíthatatlan csúcsokkal rendelkeznek, leginkább az automatikus skálázási mód előnyeit élvezhetik. Javasoljuk, hogy tekintse át az alábbi cikkeket, hogy egyértelmű képet találjon az átviteli sebesség igényeinek leginkább megfelelő kapacitásmodellről:

Particionálás

Az Azure Cosmos DB particionálása hasonló az Apache Cassandra particionálásához. Az egyik fő különbség az, hogy az Azure Cosmos DB horizontális méretezésre van optimalizálva. Az Azure Cosmos DB-ben a korlátok a fizikai partíciókban elérhető függőleges átviteli sebesség kapacitására vonatkoznak. Ennek az optimalizálásnak a hatása akkor a legfigyelmesebb, ha egy meglévő adatmodell jelentős átviteli sebességeltéréssel rendelkezik.

Tegyen lépéseket annak biztosítására, hogy a partíciókulcs kialakítása viszonylag egységes kéréselosztást eredményezzen. A logikai és fizikai particionálás működéséről és a partíciónkénti átviteli sebesség korlátairól további információt az Apache Cassandra Azure Cosmos DB-ben található particionálás című témakörben talál.

Méretezés

A natív Apache Cassandra-ban a kapacitás és a skálázás növeléséhez új csomópontokat kell hozzáadni egy fürthöz, és gondoskodni kell arról, hogy a csomópontok megfelelően legyenek hozzáadva a Cassandra-gyűrűhöz. Az Azure Cosmos DB-ben a csomópontok hozzáadása átlátható és automatikus. A skálázás annak függvénye, hogy hány kérelemegység van kiépítve a kulcstérhez vagy a táblához. A fizikai gépek skálázása akkor történik, ha a fizikai tároló vagy a szükséges átviteli sebesség eléri a logikai vagy fizikai partíciók számára engedélyezett korlátokat. További információ: Particionálás az Apache Cassandra-hoz készült Azure Cosmos DB-ben.

Sebességkorlátozás

A kérelemegységek kiépítésének kihívása, különösen ha kiosztott átviteli sebességet használ, a sebességkorlátozás. Az Azure Cosmos DB korlátozott mértékű hibákat ad vissza, ha az ügyfelek több erőforrást használnak fel, mint amennyit kiépített. Az Azure Cosmos DB Cassandra API-ja ezeket a kivételeket a Cassandra natív protokoll túlterhelt hibáira fordítja. Az alkalmazás sebességkorlátozásának elkerüléséről további információt az Apache Cassandra-műveletekhez készült Azure Cosmos DB sebességkorlátozó hibáinak megakadályozása című témakörben talál.

Apache Spark-összekötő

Számos Apache Cassandra-felhasználó használja az Apache Spark Cassandra-összekötőt az adataik elemzési és adatáthelyezési igényeinek lekérdezéséhez. A Cassandra API-hoz ugyanúgy és ugyanazzal az összekötővel is csatlakozhat. Mielőtt csatlakozik a Cassandra API-hoz, tekintse át a Csatlakozás az Apache Cassandra-hoz készült Azure Cosmos DB-hez a Sparkból. Lásd különösen a Spark-összekötő átviteli sebességének optimalizálása című szakaszt.

Gyakori problémák megoldása

A gyakori problémák megoldását az Apache Cassandra azure Cosmos DB-jében előforduló gyakori problémák elhárítása című témakörben találja.

Következő lépések