ካሳንድራ Oracleን ብቻ ካወቅክ እንዴት አትሞትም።

ሃይ ሀብር።

ስሜ Misha Butrimov እባላለሁ, ስለ ካሳንድራ ትንሽ ልነግርዎ እፈልጋለሁ. የእኔ ታሪክ የ NoSQL የውሂብ ጎታዎችን ላላጋጠሟቸው ጠቃሚ ይሆናል - ብዙ የትግበራ ባህሪያት እና ማወቅ ያለብዎት ወጥመዶች አሉት። እና ከኦራክል ወይም ከማንኛውም ሌላ ተዛማጅ ዳታቤዝ ሌላ ምንም ነገር ካላዩ እነዚህ ነገሮች ህይወትዎን ያድናሉ።

ስለ ካሳንድራ ምን ጥሩ ነገር አለ? ያለ አንድ የውድቀት ነጥብ የተነደፈ የNoSQL ዳታቤዝ ሲሆን በጥሩ ሁኔታ የሚመዝን ነው። ለአንዳንድ የውሂብ ጎታ ሁለት ቴራባይቶችን ማከል ከፈለጉ በቀላሉ ወደ ቀለበት ኖዶችን ይጨምሩ። ወደ ሌላ የውሂብ ማዕከል ይዘርጉ? አንጓዎችን ወደ ክላስተር ያክሉ። የተቀነባበረ RPS ይጨምር? አንጓዎችን ወደ ክላስተር ያክሉ። በተቃራኒው አቅጣጫም ይሠራል.

ሌላስ በምን ጎበዝ ነች? ብዙ ጥያቄዎችን ስለማስተናገድ ነው። ግን ስንት ነው? 10, 20, 30, 40 ሺህ ጥያቄዎች በሰከንድ ብዙ አይደሉም. ለመቅዳት በሰከንድ 100 ሺህ ጥያቄዎች - እንዲሁ። በሰከንድ 2 ሚሊዮን ጥያቄዎችን እንደሚያስቀምጡ የሚናገሩ ኩባንያዎች አሉ። ምናልባት ማመን አለባቸው።

እና በመርህ ደረጃ ካሳንድራ ከግንኙነት መረጃ አንድ ትልቅ ልዩነት አለው - ከነሱ ጋር ተመሳሳይነት የለውም። እና ይህ ለማስታወስ በጣም አስፈላጊ ነው.

ተመሳሳይ የሚመስለው ሁሉም ነገር አንድ አይነት አይሰራም

አንድ ጊዜ አንድ የሥራ ባልደረባዬ ወደ እኔ መጥቶ እንዲህ ሲል ጠየቀኝ፡- “ይሄ የCQL ካሳንድራ መጠይቅ ቋንቋ ነው፣ እና የተመረጠ መግለጫ አለው፣ የት፣ ያለው እና አለው። ደብዳቤ እጽፋለሁ እና አይሰራም. ለምን?". ካሳንድራን እንደ ግንኙነት ዳታቤዝ አድርጎ ማየቱ ኃይለኛ ራስን ለመግደል ፍጹም መንገድ ነው። እና እኔ አላስተዋውቅም, በሩሲያ ውስጥ የተከለከለ ነው. የሆነ ስህተት ብቻ ነው የምትነድፍው።

ለምሳሌ፣ አንድ ደንበኛ ወደ እኛ መጥቶ እንዲህ አለ፡- “ለቲቪ ተከታታይ የቴሌቪዥን ፕሮግራሞች ዳታቤዝ፣ ወይም የምግብ አዘገጃጀት ማውጫ ማውጫ እንገንባ። እዚያ የምግብ ምግቦች ወይም የቲቪ ተከታታዮች እና ተዋናዮች ዝርዝር ይኖረናል። በደስታ “እንሂድ!” እንላለን። ልክ ሁለት ባይት፣ ሁለት ምልክቶችን ላክ እና ጨርሰሃል፣ ሁሉም ነገር በፍጥነት እና በአስተማማኝ ሁኔታ ይሰራል። እና ደንበኞቹ መጥተው የቤት እመቤቶች ተቃራኒውን ችግር እየፈቱ እንደሆነ እስኪናገሩ ድረስ ሁሉም ነገር ጥሩ ነው: የምርት ዝርዝር አላቸው, እና ምን ምግብ ማብሰል እንደሚፈልጉ ማወቅ ይፈልጋሉ. ሞታችኋል።

ይህ የሆነበት ምክንያት ካሳንድራ ድብልቅ ዳታቤዝ ስለሆነ፡ በአንድ ጊዜ ቁልፍ እሴት ያቀርባል እና መረጃዎችን በሰፊ አምዶች ያከማቻል። በጃቫ ወይም በኮትሊን፣ እሱ እንደሚከተለው ሊገለፅ ይችላል።

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

ይኸውም የተደረደረ ካርታ የያዘ ካርታ ነው። የዚህ ካርታ የመጀመሪያው ቁልፍ የረድፍ ቁልፍ ወይም ክፍልፋይ ቁልፍ - የመከፋፈያ ቁልፍ ነው። ቀድሞ ለተደረደረ ካርታ ቁልፍ የሆነው ሁለተኛው ቁልፍ የክላስተር ቁልፍ ነው።

የውሂብ ጎታውን ስርጭት ለማሳየት, ሶስት አንጓዎችን እንሳል. አሁን ውሂቡን ወደ አንጓዎች እንዴት መበስበስ እንደሚቻል መረዳት ያስፈልግዎታል. ምክንያቱም ሁሉንም ነገር ወደ አንድ ብናጨቅቅ (በነገራችን ላይ አንድ ሺህ፣ ሁለት ሺህ፣ አምስት - የፈለጋችሁትን ያህል ሊኖር ይችላል) ይህ በእውነቱ ስርጭት ላይ አይደለም። ስለዚህ, ቁጥርን የሚመልስ የሂሳብ ተግባር እንፈልጋለን. የተወሰነ ክልል ውስጥ የሚወድቅ አንድ ቁጥር፣ ረጅም int ብቻ። እና ለአንድ ክልል ኃላፊነት ያለው አንድ አንጓ ይኖረናል, ሁለተኛው ለሁለተኛው, ኛ አንድ ለ nth.

ይህ ቁጥር የሚወሰደው የሃሽ ተግባርን በመጠቀም ሲሆን ይህም ክፍልፋይ ቁልፍ በምንለው ላይ ይተገበራል። ይህ በዋና ቁልፍ መመሪያ ውስጥ የተገለጸው አምድ ነው፣ እና ይህ የካርታው የመጀመሪያ እና መሰረታዊ ቁልፍ የሆነው አምድ ነው። የትኛው መስቀለኛ መንገድ የትኛውን ውሂብ እንደሚቀበል ይወስናል. በካሳንድራ ውስጥ አንድ ሠንጠረዥ በSQL ውስጥ ካለው ተመሳሳይ አገባብ ጋር ተፈጠረ።

CREATE TABLE users (
	user_id uu id,
	name text,
	year int,
	salary float,
	PRIMARY KEY(user_id)

)

በዚህ ጉዳይ ላይ ዋናው ቁልፍ አንድ አምድ ያካትታል, እና እሱ ደግሞ የመከፋፈያ ቁልፍ ነው.

ተጠቃሚዎቻችን እንዴት ይሰራሉ? አንዳንዶቹ ወደ አንድ መስቀለኛ መንገድ፣ አንዳንዶቹ ወደ ሌላው፣ እና አንዳንዶቹ ወደ ሶስተኛው ይሄዳሉ። ውጤቱም ተራ ሃሽ ሠንጠረዥ፣ ካርታ በመባልም ይታወቃል፣ በ Python መዝገበ-ቃላት በመባልም ይታወቃል፣ ወይም ሁሉንም እሴቶች የምናነብበት፣ በቁልፍ የምናነብበት እና የምንጽፍበት ቀላል የቁልፍ እሴት መዋቅር ነው።

ይምረጡ፡ ማጣራት ሲፈቀድ ወደ ሙሉ ቅኝት ሲቀየር ወይም ምን ማድረግ እንደሌለበት

አንዳንድ የተመረጠ መግለጫ እንጻፍ፡- select * from users where, userid = . በ Oracle ውስጥ እንደሚታየው: እኛ ምረጥ እንጽፋለን, ሁኔታዎችን እንገልፃለን እና ሁሉም ነገር ይሰራል, ተጠቃሚዎች ያገኙታል. ነገር ግን ለምሳሌ አንድ የተወሰነ የትውልድ ዓመት ተጠቃሚ ከመረጡ ካሳንድራ ጥያቄውን ማሟላት እንደማይችል ቅሬታ ያሰማል። ምክንያቱም ስለ ልደት አመት መረጃን እንዴት እንደምናከፋፍል ምንም ስለማታውቅ - እንደ ቁልፍ የተመለከተው አንድ አምድ ብቻ አላት ። ከዚያም “እሺ፣ አሁንም ይህን ጥያቄ ማሟላት እችላለሁ። ፍቀድ ማጣራት ጨምር።" መመሪያውን እንጨምራለን, ሁሉም ነገር ይሰራል. እና በዚህ ጊዜ አንድ አስፈሪ ነገር ተከሰተ.

በሙከራ ውሂብ ላይ ስናሄድ ሁሉም ነገር ጥሩ ነው። እና በምርት ውስጥ ጥያቄን ሲፈጽሙ, ለምሳሌ, 4 ሚሊዮን መዝገቦች አሉን, ከዚያ ሁሉም ነገር ለእኛ በጣም ጥሩ አይደለም. ምክንያቱም ፍቀድ ማጣራት ካሳንድራ ሁሉንም መረጃዎች ከዚህ ሰንጠረዥ ከሁሉም መስቀለኛ መንገዶች፣ ሁሉንም የመረጃ ማዕከሎች (በዚህ ክላስተር ውስጥ ብዙዎቹ ካሉ) እንዲሰበስብ እና ከዚያ ብቻ እንዲያጣራ የሚያስችል መመሪያ ነው። ይህ የሙሉ ቅኝት አናሎግ ነው፣ እና ማንም ሰው አያስደስተውም።

ተጠቃሚዎችን በመታወቂያ ብቻ የምንፈልግ ከሆነ፣ በዚህ ጥሩ እንሆን ነበር። ግን አንዳንድ ጊዜ ሌሎች ጥያቄዎችን መጻፍ እና በምርጫው ላይ ሌሎች ገደቦችን መጫን አለብን። ስለዚህ, እናስታውሳለን-ይህ ሁሉ የመከፋፈያ ቁልፍ ያለው ካርታ ነው, ነገር ግን በውስጡ የተደረደረ ካርታ ነው.

እና እሷም ቁልፍ አላት፣ እሱም ክላስተር ቁልፍ የምንለው። ይህ ቁልፍ, በተራው, የምንመርጣቸውን አምዶች ያካትታል, በእሱ እርዳታ ካሳንድራ መረጃው በአካል እንዴት እንደሚደረደር እና በእያንዳንዱ መስቀለኛ መንገድ ላይ እንደሚቀመጥ ይገነዘባል. ያም ማለት ለአንዳንድ ክፍልፋይ ቁልፍ የክላስተር ቁልፉ ውሂቡን ወደዚህ ዛፍ በትክክል እንዴት እንደሚገፋ ይነግርዎታል, እዚያ ምን ቦታ እንደሚወስድ ይነግርዎታል.

ይህ በእውነቱ ዛፍ ነው ፣ ኮምፓሬተር በቀላሉ እዚያ ይባላል ፣ ወደ እሱ የተወሰኑ የአምዶች ስብስብ በቁስ መልክ እናልፋለን ፣ እና እንደ ዓምዶች ዝርዝርም ይገለጻል።

CREATE TABLE users_by_year_salary_id (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY((year), salary, user_id)

ለዋና ቁልፍ መመሪያው ትኩረት ይስጡ፤ የመጀመሪያው መከራከሪያው (በእኛ ሁኔታ፣ ዓመቱ) ምንጊዜም የክፋይ ቁልፍ ነው። አንድ ወይም ከዚያ በላይ አምዶችን ሊያካትት ይችላል, ምንም አይደለም. ብዙ ዓምዶች ካሉ፣ የቋንቋ ቀዳሚው ቁልፍ ይህ ዋና ቁልፍ መሆኑን እንዲረዳ እንደገና በቅንፍ ውስጥ መወገድ አለበት፣ እና ከኋላው ያሉት ሁሉም አምዶች የክላስተር ቁልፍ ናቸው። በዚህ ሁኔታ, በሚታዩበት ቅደም ተከተል በንፅፅር ውስጥ ይተላለፋሉ. ያም ማለት, የመጀመሪያው ዓምድ የበለጠ ጉልህ ነው, ሁለተኛው ደግሞ ትንሽ ትርጉም ያለው ነው, ወዘተ. እንዴት እንደጻፍን, ለምሳሌ, ለመረጃ ክፍሎች እኩል የሆኑ መስኮችን: መስኮቹን እንዘረዝራለን, እና ለእነሱ የትኛው ትልቅ እና ትንሽ እንደሆነ እንጽፋለን. በካሳንድራ እነዚህ በአንጻራዊ ሁኔታ ሲታይ የውሂብ ክፍል መስኮች ናቸው, ለእሱ የተጻፉት እኩልታዎች ተግባራዊ ይሆናሉ.

እኛ መደርደር እና ገደቦችን እናስቀምጣለን

ቁልፉ በሚፈጠርበት ጊዜ የመደርደር ቅደም ተከተል (መውረድ ፣ መውጣት ፣ ማንኛውም) እንደተዘጋጀ እና በኋላ ላይ መለወጥ እንደማይቻል ማስታወስ ያስፈልግዎታል። ውሂቡ እንዴት እንደሚደረደር እና እንዴት እንደሚከማች በአካል ይወስናል። የክላስተር ቁልፉን መቀየር ወይም ቅደም ተከተል መደርደር ከፈለጉ አዲስ ሠንጠረዥ መፍጠር እና ውሂብ ወደ እሱ ማስተላለፍ ይኖርብዎታል። ይህ ከነባር ጋር አይሰራም።

ጠረጴዛችንን በተጠቃሚዎች ሞላን እና መጀመሪያ በተወለዱበት አመት ቀለበት ውስጥ እንደወደቁ እና ከዚያም በእያንዳንዱ መስቀለኛ መንገድ በደመወዝ እና በተጠቃሚ መታወቂያ ሲወድቁ አይተናል። አሁን ገደቦችን በመጫን መምረጥ እንችላለን.

የእኛ ሥራ እንደገና ይታያል where, and, እና ተጠቃሚዎችን እናገኛለን, እና ሁሉም ነገር እንደገና ደህና ነው. ነገር ግን የክላስተር ቁልፍን የተወሰነ ክፍል ብቻ ለመጠቀም ከሞከርን እና ትንሽ ትርጉም ያለው ከሆነ ካሳንድራ ወዲያውኑ በካርታችን ውስጥ ይህ ነገር ለኑል ማነፃፀሪያው እና ለኑል ማነፃፀሪያው ያለው ይህ ነገር ያለበትን ቦታ ማግኘት አልቻለም ሲል ቅሬታ ያሰማል። ብቻ ተዘጋጅቷል - እሱ የሚተኛበት. ከዚህ መስቀለኛ መንገድ ሁሉንም ውሂብ እንደገና ማንሳት እና ማጣራት አለብኝ። እና ይህ በመስቀለኛ መንገድ ውስጥ ያለው የሙሉ ቅኝት አናሎግ ነው፣ ይህ መጥፎ ነው።

በማንኛውም ግልጽ ያልሆነ ሁኔታ, አዲስ ጠረጴዛ ይፍጠሩ

ተጠቃሚዎችን በመታወቂያ፣ ወይም በእድሜ፣ ወይም በደመወዝ ኢላማ ማድረግ መቻል ከፈለግን ምን ማድረግ አለብን? መነም. ሁለት ጠረጴዛዎችን ብቻ ይጠቀሙ. ተጠቃሚዎችን በሶስት የተለያዩ መንገዶች ማግኘት ከፈለጉ ሶስት ጠረጴዛዎች ይኖራሉ. በመጠምዘዣው ላይ ቦታ ያስቀመጥንበት ጊዜ አልፏል። ይህ በጣም ርካሹ ሀብት ነው። ዋጋው ከምላሽ ጊዜ በጣም ያነሰ ነው, ይህም ለተጠቃሚው ጎጂ ሊሆን ይችላል. ለተጠቃሚው በ10 ደቂቃ ውስጥ ከነበረው ነገር በሰከንድ ውስጥ መቀበል የበለጠ አስደሳች ነው።

በደንብ ለመለካት እና በአስተማማኝ ሁኔታ ለመስራት አላስፈላጊ ቦታ እና መደበኛ ያልሆነ መረጃ እንገበያያለን። ደግሞም ፣ በእውነቱ ፣ ሶስት የመረጃ ማእከሎች ፣ እያንዳንዳቸው አምስት አንጓዎች ያሉት ፣ ተቀባይነት ያለው የመረጃ ጥበቃ ደረጃ (ምንም በማይጠፋበት ጊዜ) አንድ ክላስተር ከአንድ የመረጃ ማእከል ሞት ሙሉ በሙሉ በሕይወት ሊተርፍ ይችላል። እና በቀሪዎቹ ሁለት እያንዳንዳቸው ሁለት ተጨማሪ አንጓዎች. እና ከዚህ በኋላ ብቻ ችግሮቹ ይጀምራሉ. ይህ በጣም ጥሩ ድግግሞሽ ነው፣ ሁለት ተጨማሪ የኤስኤስዲ ድራይቮች እና ፕሮሰሰር ዋጋ አለው። ስለዚህ, Cassandra ን ለመጠቀም, በጭራሽ SQL, ምንም ግንኙነቶች የሌሉበት, የውጭ ቁልፎች, ቀላል ደንቦችን ማወቅ ያስፈልግዎታል.

በጥያቄዎ መሰረት ሁሉንም ነገር ዲዛይን እናደርጋለን. ዋናው ነገር መረጃው አይደለም, ነገር ግን አፕሊኬሽኑ ከእሱ ጋር እንዴት እንደሚሰራ ነው. የተለያዩ መረጃዎችን በተለያዩ መንገዶች ወይም ተመሳሳይ መረጃዎችን በተለያዩ መንገዶች መቀበል ከፈለገ ለመተግበሪያው ምቹ በሆነ መንገድ ማስቀመጥ አለብን። ያለበለዚያ በ Full Scan ውስጥ እንወድቃለን እና ካሳንድራ ምንም ጥቅም አይሰጠንም።

መረጃን መደበኛ ማድረግ መደበኛ ነው። ስለ መደበኛ ቅጾች እንረሳለን, ከአሁን በኋላ ተዛማጅ የውሂብ ጎታዎች የሉንም. አንድን ነገር 100 ጊዜ ብናስቀምጥ 100 ጊዜ ይተኛል. አሁንም ከማቆም የበለጠ ርካሽ ነው።

በመደበኛነት እንዲሰራጩ ለመከፋፈል ቁልፎችን እንመርጣለን. የቁልፎቻችን ሃሽ በአንድ ጠባብ ክልል ውስጥ እንዲወድቅ አንፈልግም። ከላይ በምሳሌው ላይ ያለው የልደት ዓመት መጥፎ ምሳሌ ነው. ይበልጥ በትክክል ተጠቃሚዎቻችን በተለምዶ በተወለዱበት አመት ቢከፋፈሉ ጥሩ ነው, እና ስለ 5 ኛ ክፍል ተማሪዎች እየተነጋገርን ከሆነ መጥፎ - እዚያ ያለው ክፍፍል በጣም ጥሩ አይሆንም.

መደርደር በክላስተር ቁልፍ የፍጥረት ደረጃ አንድ ጊዜ ይመረጣል። መቀየር ካስፈለገ ጠረጴዛችንን በተለየ ቁልፍ ማዘመን አለብን።

እና በጣም አስፈላጊው ነገር: ተመሳሳዩን ውሂብ በ 100 የተለያዩ መንገዶች ማምጣት ካስፈለገን 100 የተለያዩ ጠረጴዛዎች ይኖሩናል.

ምንጭ: hab.com