ඔවුන් පවසන්නේ ජීවිතයේ සෑම දෙයක්ම අවම වශයෙන් එක් වරක්වත් උත්සාහ කිරීම වටී. ඔබ සම්බන්ධතා DBMS සමඟ වැඩ කිරීමට පුරුදු වී සිටී නම්, ප්‍රායෝගිකව NoSQL සමඟ දැන හඳුනා ගැනීම වටී, පළමුව, අවම වශයෙන් සාමාන්‍ය සංවර්ධනය සඳහා. දැන්, මෙම තාක්‍ෂණයේ ශීඝ්‍ර දියුණුව හේතුවෙන්, මෙම මාතෘකාව පිළිබඳ පරස්පර අදහස් සහ උණුසුම් විවාද රාශියක් ඇති අතර එය විශේෂයෙන් උනන්දුව වැඩි කරයි.
ඔබ මේ සියලු ආරවුල් වල හරය ගැන ගැඹුරින් සොයා බැලුවහොත්, ඒවා වැරදි ප්‍රවේශය නිසා පැන නගින බව ඔබට පෙනෙනු ඇත. NoSQL දත්ත සමුදායන් අවශ්ය තැනම භාවිතා කරන අය තෘප්තිමත් වන අතර මෙම විසඳුමෙන් සියලු වාසි ලබා ගනී. මෙම තාක්‍ෂණය කිසිසේත්ම අදාළ නොවන කෝකටත් තෛලයක් ලෙස විශ්වාස කරන පරීක්‍ෂකයින් සැලකිය යුතු ප්‍රතිලාභ ලබා නොගෙන සම්බන්ධතා දත්ත සමුදායේ ශක්තීන් අහිමි වීමෙන් බලාපොරොත්තු සුන් වේ.
Cassandra DBMS මත පදනම් වූ විසඳුමක් ක්‍රියාවට නැංවීමේ අපගේ අත්දැකීම් ගැන මම ඔබට කියමි: අපට මුහුණ දීමට සිදු වූ දේ, දුෂ්කර තත්වයන්ගෙන් අප මිදුණු ආකාරය, NoSQL භාවිතා කිරීමෙන් අපට ප්‍රතිලාභ ලබා ගැනීමට හැකි වූයේද සහ අපට අමතර උත්සාහයන්/අරමුදල් ආයෝජනය කිරීමට සිදු වූයේද යන්න ගැන. .
ආරම්භක කාර්යය වන්නේ යම් ආකාරයක ගබඩාවක ඇමතුම් වාර්තා කරන පද්ධතියක් ගොඩනැගීමයි.
පද්ධතියේ මෙහෙයුම් මූලධර්මය පහත පරිදි වේ. ආදානයට ඇමතුමේ ව්යුහය විස්තර කරන විශේෂිත ව්‍යුහයක් සහිත ගොනු ඇතුළත් වේ. යෙදුම පසුව මෙම ව්යුහය සුදුසු තීරු තුළ ගබඩා කර ඇති බව සහතික කරයි. අනාගතයේදී, ග්‍රාහකයින් සඳහා රථවාහන පරිභෝජනය පිළිබඳ තොරතුරු ප්‍රදර්ශනය කිරීමට සුරකින ලද ඇමතුම් භාවිතා කරනු ලැබේ (ගාස්තු, ඇමතුම්, ශේෂ ඉතිහාසය).
ඔවුන් කැසැන්ඩ්‍රා තෝරාගත්තේ ඇයිද යන්න ඉතා පැහැදිලිය - ඇය මැෂින් තුවක්කුවක් මෙන් ලියයි, පහසුවෙන් පරිමාණය කළ හැකි සහ දෝෂ ඉවසයි.
ඉතින්, මෙය අපට අත්දැකීම් ලබා දී ඇත
ඔව්, අසාර්ථක නෝඩයක් ඛේදවාචකයක් නොවේ. කැසැන්ඩ්‍රාගේ වැරදි ඉවසීමේ සාරය මෙයයි. එහෙත් නෝඩයක් සජීවී විය හැකි අතර ඒ සමඟම කාර්ය සාධනයේ දුක් විඳීමට පටන් ගනී. එය සිදු වූ පරිදි, මෙය වහාම සම්පූර්ණ පොකුරේ ක්රියාකාරිත්වයට බලපායි.
ඔරකල් ඔබව එහි සීමාවන් සමඟ බේරාගත් තැන කැසැන්ඩ්‍රා ඔබව ආරක්ෂා නොකරනු ඇත. යෙදුමේ කතුවරයා මෙය කල්තියා තේරුම් නොගත්තේ නම්, කැසැන්ඩ්‍රා සඳහා පැමිණි ද්විත්වය මුල් පිටපතට වඩා නරක නැත. එය පැමිණි පසු, අපි එය ඇතුල් කරන්නෙමු.
නිදහස් Cassandra සඳහා IB දැඩි ලෙස අකමැති විය: පරිශීලක ක්‍රියාවන් ලොග් කිරීමක්, අයිතිවාසිකම් වෙනස් කිරීමක් නොමැත. ඇමතුම් පිළිබඳ තොරතුරු පුද්ගලික දත්ත ලෙස සලකනු ලැබේ, එයින් අදහස් වන්නේ එය ඕනෑම ආකාරයකින් ඉල්ලීමට/වෙනස් කිරීමට දරන සියලු උත්සාහයන් පසුව විගණනය කිරීමේ හැකියාව සමඟ ලොග් විය යුතු බවයි. එසේම, විවිධ පරිශීලකයින් සඳහා විවිධ මට්ටම්වල අයිතිවාසිකම් වෙන් කිරීමේ අවශ්යතාව පිළිබඳව ඔබ දැනුවත් විය යුතුය. සරල මෙහෙයුම් ඉංජිනේරුවෙකු සහ සම්පූර්ණ යතුරු අවකාශය නිදහසේ මකා දැමිය හැකි සුපිරි පරිපාලකයෙකු විවිධ භූමිකාවන්, විවිධ වගකීම් සහ නිපුණතා වේ. ප්‍රවේශ අයිතිවාසිකම්වල එවැනි වෙනස්කම් නොමැතිව, දත්තවල වටිනාකම සහ අඛණ්ඩතාව ඕනෑම අනුකූලතා මට්ටමකට වඩා වේගයෙන් ප්‍රශ්න කරනු ඇත.
විවිධ තත්වයන් සඳහා ඇමතුම් සඳහා බරපතල විශ්ලේෂණ සහ ආවර්තිතා නියැදීම යන දෙකම අවශ්ය බව අපි සැලකිල්ලට නොගත්තෙමු. තෝරාගත් වාර්තා පසුව මකා දමා නැවත ලිවිය යුතු බැවින් (කාර්යයේ කොටසක් ලෙස, දත්ත මුලින් අපගේ ලූපයට වැරදි ලෙස ඇතුළු වූ විට දත්ත යාවත්කාලීන කිරීමේ ක්‍රියාවලියට සහාය විය යුතුය), කැසැන්ඩ්‍රා මෙහි අපගේ මිතුරෙකු නොවේ. කැසැන්ඩ්‍රා පිග්ගි බැංකුවක් වැනි ය - දේවල් තැබීම පහසුය, නමුත් ඔබට එය ගණන් කළ නොහැක.
පරීක්ෂණ කලාප වෙත දත්ත මාරු කිරීමේදී අපට ගැටලුවක් ඇති විය (පරීක්ෂණයේ නෝඩ් 5ක් සහ ප්‍රොම් එකේ 20ක්). මෙම අවස්ථාවේදී, ඩම්ප් භාවිතා කළ නොහැක.
Cassandra වෙත ලියන යෙදුමක දත්ත යෝජනා ක්‍රමය යාවත්කාලීන කිරීමේ ගැටලුව. ආපසු හැරීමක් බොහෝ සොහොන් ගල් ජනනය කරනු ඇත, එය අනපේක්ෂිත ආකාරයෙන් ඵලදායිතා පාඩු ඇති කළ හැකිය.. Cassandra පටිගත කිරීම සඳහා ප්‍රශස්ත කර ඇති අතර, ලිවීමට පෙර බොහෝ දේ සිතන්නේ නැත. දැනට පවතින දත්ත සහිත ඕනෑම මෙහෙයුමක් ද පටිගත කිරීමකි. එනම්, අනවශ්‍ය දේ මකා දැමීමෙන්, අපි ඊටත් වඩා වාර්තා නිෂ්පාදනය කරනු ඇති අතර, ඒවායින් සමහරක් පමණක් සොහොන් ගල් වලින් සලකුණු කරනු ලැබේ.
ඇතුල් කරන විට කල් ඉකුත් වේ. කැසැන්ඩ්‍රා පටිගත කිරීමේදී ලස්සනයි, නමුත් සමහර විට පැමිණෙන ප්රවාහය සැලකිය යුතු ලෙස ප්රහේලිකාවක් විය හැකිය. යෙදුම කිසියම් හේතුවක් නිසා ඇතුළත් කළ නොහැකි වාර්තා කිහිපයක් වටා චක්‍රීය වීමට පටන් ගන්නා විට මෙය සිදු වේ. තවද අපට gc.log, පද්ධති සහ දෝශ නිරාකරණ ලොග, මන්දගාමී විමසුම්, සම්පිණ්ඩන පොරොත්තු පිළිබඳ ප්‍රමිතික නිරීක්ෂණය කරන සැබෑ DBA අවශ්ය වනු ඇත.
පොකුරක් තුළ දත්ත මධ්‍යස්ථාන කිහිපයක්. ලිවිය යුත්තේ කොතැනින්ද සහ කියවිය යුත්තේ කොතැනින්ද?
සමහර විට කියවීමට හා ලිවීමට බෙදිය හැකිද? එසේ නම්, ලිවීමට හෝ කියවීමට අයදුම් කිරීමට ආසන්නව DC එකක් තිබිය යුතුද? අපි වැරදි අනුකූලතා මට්ටමක් තෝරා ගන්නේ නම් අපට සැබෑ බෙදීම් මොළයක් ඇති නොවේද? ඔබට සැබවින්ම ටින්කර් කිරීමට අවශ්ය ප්‍රශ්න රාශියක්, නොදන්නා සැකසුම් රාශියක්, හැකියාවන් ඇත.
අපි තීරණය කළ ආකාරය
නෝඩය ගිලී යාම වැළැක්වීම සඳහා, SWAP අක්‍රීය කරන ලදී. දැන්, මතකයේ අඩුවක් තිබේ නම්, නෝඩය පහළට යා යුතු අතර විශාල gc විරාමයන් නිර්මාණය නොකළ යුතුය.
එබැවින්, අපි තවදුරටත් දත්ත ගබඩාවේ තර්කනය මත රඳා නොසිටිමු. යෙදුම් සංවර්ධකයින් තමන්ව නැවත පුහුණු කරමින් සිටින අතර ඔවුන්ගේම කේතයේ සක්‍රියව පූර්වාරක්ෂාව ගැනීමට පටන් ගෙන ඇත. දත්ත ගබඩා කිරීම සහ සැකසීම සඳහා කදිම පැහැදිලි වෙන් කිරීම.
අපි DataStax වෙතින් සහය මිලදී ගත්තෙමු. කොටු කැසැන්ඩ්‍රා සංවර්ධනය දැනටමත් නතර වී ඇත (අවසාන කැපවීම 2018 පෙබරවාරි මාසයේදීය). ඒ අතරම, Datastax විශිෂ්ට සේවාවක් සහ දැනට පවතින IP විසඳුම් සඳහා නවීකරණය කරන ලද සහ අනුවර්තනය කරන ලද විසඳුම් විශාල ප්‍රමාණයක් ලබා දෙයි.
තේරීම් විමසුම් සඳහා කැසැන්ඩ්‍රා එතරම් පහසු නොවන බව ද සටහන් කිරීමට මට අවශ්‍යය. ඇත්ත වශයෙන්ම, CQL යනු පරිශීලකයින් සඳහා විශාල ඉදිරි පියවරකි (Trift හා සසඳන විට). නමුත් ඔබට එවැනි පහසු සම්බන්ධ වීමට පුරුදු වී ඇති සම්පූර්ණ දෙපාර්තමේන්තු තිබේ නම්, ඕනෑම ක්ෂේත්‍රයකින් නොමිලේ පෙරීම සහ ප්‍රශස්තිකරණ හැකියාවන් විමසුම්, සහ මෙම දෙපාර්තමේන්තු පැමිණිලි සහ අනතුරු විසඳීමට ක්‍රියා කරයි නම්, කැසැන්ඩ්‍රා හි විසඳුම ඔවුන්ට සතුරු හා මෝඩ බවක් පෙනේ. අපගේ සගයන් සාම්පල සෑදිය යුතු ආකාරය අපි තීරණය කිරීමට පටන් ගත්තෙමු.
අපි විකල්ප දෙකක් සලකා බැලුවෙමු.පළමු විකල්පයේදී, අපි C* හි පමණක් නොව, සංරක්ෂිත Oracle දත්ත ගබඩාවේද ඇමතුම් ලියන්නෙමු. C* මෙන් නොව, මෙම දත්ත සමුදාය වත්මන් මාසය සඳහා පමණක් ඇමතුම් ගබඩා කරයි (නැවත ආරෝපණය කිරීම සඳහා ප්‍රමාණවත් ඇමතුම් ගබඩා ගැඹුර). මෙන්න අපි වහාම පහත ගැටලුව දුටුවෙමු: අපි සමමුහුර්තව ලියන්නේ නම්, වේගවත් ඇතුළත් කිරීම හා සම්බන්ධ C* හි සියලුම වාසි අපට අහිමි වේ; අපි අසමමුහුර්තව ලියන්නේ නම්, අවශ්ය සියලුම ඇමතුම් ඔරකල් වෙත ලැබුණු බවට සහතිකයක් නොමැත. එක් ප්ලස් එකක් තිබුනා, නමුත් විශාල එකක්: ක්‍රියාකාරිත්වය සඳහා එකම හුරුපුරුදු PL/SQL සංවර්ධකයා ඉතිරිව ඇත, එනම් අපි ප්‍රායෝගිකව "Faced" රටාව ක්‍රියාත්මක කරමු විකල්ප විකල්පයක්. අපි C* වෙතින් ඇමතුම් බාන යාන්ත්‍රණයක් ක්‍රියාත්මක කරන අතර, Oracle හි අනුරූප වගු වලින් පොහොසත් කිරීම සඳහා දත්ත කිහිපයක් ඇද, ලැබෙන සාම්පලවලට සම්බන්ධ කර ප්‍රති result ලය අපට ලබා දෙයි, එය අපි කෙසේ හෝ භාවිතා කරමු (ආපසු පෙරළන්න, නැවත කරන්න, විශ්ලේෂණය කරන්න, අගය කරන්න). අවාසි: ක්රියාවලිය තරමක් බහු-පියවර වන අතර, ඊට අමතරව, මෙහෙයුම් සේවකයින් සඳහා අතුරු මුහුණතක් නොමැත.
අවසානයේදී, අපි දෙවන විකල්පය මත පදිංචි විය. Apache Spark විවිධ භාජන වලින් නියැදීමට භාවිතා කරන ලදී. යාන්ත්‍රණයේ සාරය ජාවා කේතය දක්වා අඩු කර ඇති අතර, එය නිශ්චිත යතුරු (ග්‍රාහකයා, ඇමතුමේ වේලාව - කොටස් යතුරු) භාවිතා කරමින්, C* වෙතින් දත්ත ඇද ගන්නා අතර, වෙනත් ඕනෑම දත්ත සමුදායකින් පොහොසත් කිරීම සඳහා අවශ්ය දත්ත ද ලබා ගනී. ඉන් පසුව එය එහි මතකයට ඔවුන් එක් කර ප්රතිඵල වගුවේ ප්රතිඵලය පෙන්වයි. අපි ගිනි පුපුරට උඩින් වෙබ් මුහුණුවරක් ඇන්ද අතර එය තරමක් භාවිත කළ හැකි බවට පත් විය.
කාර්මික පරීක්ෂණ දත්ත යාවත්කාලීන කිරීමේ ගැටළුව විසඳන විට, අපි නැවතත් විසඳුම් කිහිපයක් සලකා බැලුවෙමු. Sstloader හරහා මාරු කිරීම සහ පරීක්ෂණ කලාපයේ ඇති පොකුර කොටස් දෙකකට බෙදීමේ විකල්පය යන දෙකම, ඒ සෑම එකක්ම ප්‍රවර්ධනාත්මක එක සමඟ එකම පොකුරට මාරුවෙන් මාරුවට අයත් වන අතර එමඟින් බල ගැන්වේ. පරීක්ෂණය යාවත්කාලීන කිරීමේදී, ඒවා හුවමාරු කිරීමට සැලසුම් කර ඇත: පරීක්ෂණයේ වැඩ කළ කොටස ඉවත් කර නිෂ්පාදනයට ඇතුල් වන අතර අනෙක දත්ත සමඟ වෙන වෙනම වැඩ කිරීමට පටන් ගනී. කෙසේ වෙතත්, නැවත සිතා බැලීමෙන් පසු, අපි මාරු කිරීමට වටින දත්ත වඩාත් තාර්කිකව තක්සේරු කළ අතර, අවශ්ය නම් ඉක්මනින් උත්පාදනය කරන ලද ඇමතුම් පරීක්ෂණ සඳහා නොගැලපෙන ආයතනයක් බව වටහා ගත්තෙමු, එය ප්‍රවර්ධන දත්ත කට්ටලයට මාරු කිරීම සඳහා වටිනාකමක් නැත. පරීක්ෂණය. චලනය කිරීමට වටින ගබඩා වස්තූන් කිහිපයක් ඇත, නමුත් මේවා වචනාර්ථයෙන් වගු කිහිපයක් වන අතර ඉතා බර ඒවා නොවේ. එබැවින් අපි විසඳුමක් ලෙස, ස්පාර්ක් නැවතත් ගලවා ගැනීමට පැමිණියේය, එහි ආධාරයෙන් අපි ලියා ඇති අතර වගු, ප්‍රොම්-ටෙස්ට් අතර දත්ත මාරු කිරීම සඳහා ස්ක්‍රිප්ට් එකක් සක්‍රියව භාවිතා කිරීමට පටන් ගත්තෙමු.
අපගේ වත්මන් යෙදවීමේ ප්‍රතිපත්තිය අපට ආපසු හැරීමකින් තොරව වැඩ කිරීමට ඉඩ සලසයි. ප්‍රවර්ධනයට පෙර, අත්වැරදීමක් එතරම් මිල අධික නොවන අනිවාර්ය පරීක්ෂණ ධාවනයක් ඇත. අසාර්ථක වූ විට, ඔබට සැමවිටම කේස්පේස් අතහැර සම්පූර්ණ යෝජනා ක්‍රමය මුල සිටම පෙරළිය හැක.
Cassandra අඛණ්ඩව ලබා ගැනීම සහතික කිරීම සඳහා, ඔබට ඔහු පමණක් නොව dba එකක් අවශ්ය වේ. යෙදුම සමඟ වැඩ කරන සෑම කෙනෙකුම වර්තමාන තත්වය දෙස බලන්නේ කොතැනද සහ කෙසේද යන්න සහ කාලෝචිත ආකාරයකින් ගැටළු හඳුනා ගන්නේ කෙසේද යන්න තේරුම් ගත යුතුය. මෙය සිදු කිරීම සඳහා, අපි DataStax OpsCenter (වැඩ බර පරිපාලනය සහ අධීක්ෂණය), කැසැන්ඩ්‍රා ධාවක පද්ධති ප්‍රමිතික (C* වෙත ලිවීම සඳහා කල් ඉකුත්වීම් ගණන, C* වෙතින් කියවීම සඳහා කල් ඉකුත්වීම් ගණන, උපරිම ප්‍රමාදය, ආදිය) ක්‍රියාකාරීව භාවිතා කරන්නෙමු, ක්‍රියාකාරිත්වය නිරීක්ෂණය කරන්න. යෙදුමේම, කැසැන්ඩ්‍රා සමඟ වැඩ කිරීම.
පෙර ප්‍රශ්නය ගැන සිතූ විට, අපගේ ප්‍රධාන අවදානම කොතැනද යන්න අපට වැටහුණි. මේවා ස්වාධීන විමසුම් කිහිපයකින් ගබඩාව වෙත දත්ත පෙන්වන දත්ත සංදර්ශක ආකෘති වේ. මේ ආකාරයෙන් අපට තරමක් නොගැලපෙන තොරතුරු ලබා ගත හැකිය. නමුත් අපි එක් දත්ත මධ්‍යස්ථානයක් සමඟ පමණක් වැඩ කළහොත් මෙම ගැටළුව අදාළ වේ. එබැවින් මෙහි ඇති වඩාත්ම සාධාරණ දෙය නම්, ඇත්ත වශයෙන්ම, තෙවන පාර්ශවීය යෙදුමක දත්ත කියවීම සඳහා කණ්ඩායම් ශ්‍රිතයක් නිර්මාණය කිරීමයි, එමඟින් දත්ත එක් කාල සීමාවක් තුළ ලැබෙන බව සහතික කරයි. කාර්ය සාධනය අනුව කියවීමට සහ ලිවීමට බෙදීම සම්බන්ධයෙන් ගත් කල, DC අතර යම් සම්බන්ධතාවක් නැතිවීමත් සමඟ අපට සම්පූර්ණයෙන්ම එකිනෙකට නොගැලපෙන පොකුරු දෙකක් අවසන් විය හැකි අවදානම නිසා අපි නතර විය.
ප්රතිඵලයක් වශයෙන්, දැනට EACH_QUORUM ලිවීම සඳහා අනුකූලතා මට්ටමින් නැවතී ඇත, කියවීම සඳහා - LOCAL_QUORUM
කෙටි හැඟීම් සහ නිගමන
මෙහෙයුම් සහාය සහ වැඩිදුර සංවර්ධනය සඳහා වන අපේක්ෂාවන් පිළිබඳ දෘෂ්ටි කෝණයෙන් ලැබෙන විසඳුම තක්සේරු කිරීම සඳහා, එවැනි සංවර්ධනයක් යෙදිය හැක්කේ කොතැනින්ද යන්න ගැන සිතා බැලීමට අපි තීරණය කළෙමු.
පිත්තෙන් ම, පසුව "පහසු විට ගෙවන්න" වැනි වැඩසටහන් සඳහා දත්ත ලකුණු කිරීම (අපි C* වෙත තොරතුරු පැටවීම, Spark ස්ක්‍රිප්ට් භාවිතයෙන් ගණනය කිරීම), ප්‍රදේශය අනුව එකතු කිරීම සමඟ හිමිකම් සඳහා ගිණුම්කරණය, භූමිකාවන් ගබඩා කිරීම සහ භූමිකාව මත පදනම්ව පරිශීලක ප්‍රවේශ හිමිකම් ගණනය කිරීම matrix.
ඔබට පෙනෙන පරිදි, ප්‍රසංගය පුළුල් හා විවිධාකාර වේ. තවද අපි NoSQL හි ආධාරකරුවන්ගේ/විරුද්ධවාදීන්ගේ කඳවුර තෝරා ගන්නේ නම්, අපගේ වාසි අපට ලැබුණු බැවින් සහ අප බලාපොරොත්තු වූ ස්ථානයෙන් අපි ආධාරකරුවන් සමඟ එකතු වෙමු.
පෙට්ටියෙන් පිටත Cassandra විකල්පය පවා තත්‍ය කාලීනව තිරස් පරිමාණයට ඉඩ සලසයි, පද්ධතියේ දත්ත වැඩි කිරීමේ ගැටළුව නියත වශයෙන්ම වේදනා රහිතව විසඳයි. දත්ත සමුදාය තුළම අභිරුචි රැකියා සහ වස්තු ලිවීමේ නරක පුරුද්දෙන් මිදී, වෙනම පරිපථයකට ඇමතුම් එකතු කිරීම් ගණනය කිරීම සඳහා ඉතා ඉහළ බරක් යාන්ත්‍රණයක් ගෙන යාමට අපට හැකි විය. අපට තෝරා ගැනීමට සහ වින්‍යාස කිරීමට, වේගවත් කිරීමට, අපි ගණනය කිරීම් සිදු කරන්නේ කුමන DC මතද සහ අපි දත්ත සටහන් කරන්නේ කුමන ඒවා මතද යන්න අපට අවස්ථාව ලැබුණි.
අපගේ ගෘහ නිර්මාණ ශිල්පය නව ව්‍යාපෘති සඳහා යොදමින්, දැනටමත් යම් අත්දැකීමක් ඇති බැවින්, ඉහත විස්තර කර ඇති සූක්ෂ්ම කරුණු වහාම සැලකිල්ලට ගැනීමටත්, සමහර වැරදි වළක්වා ගැනීමටත්, මුලින් වළක්වා ගත නොහැකි තියුණු කොන සුමට කිරීමටත් මම කැමැත්තෙමි.
උදාහරණයක් ලෙස, කැසැන්ඩ්‍රාගේ යාවත්කාලීනයන් නියමිත වේලාවට නිරීක්ෂණය කරන්නමක්නිසාද යත් අපට ඇති වූ ගැටළු කිහිපයක් දැනටමත් දැන සිටි අතර ඒවා විසඳා ඇත.
Database එකයි Spark එකයි දෙකම එකම nodes වල දාන්න එපා (හෝ අවසර ලත් සම්පත් භාවිතයේ ප්‍රමාණයෙන් දැඩි ලෙස බෙදන්න), මන්ද ස්පාර්ක්ට බලාපොරොත්තු වූවාට වඩා වැඩි OP ප්‍රමාණයක් අනුභව කළ හැකි අතර, අපගේ ලැයිස්තුවෙන් අපට ගැටළු අංක 1 ඉක්මනින් ලැබෙනු ඇත.
ව්‍යාපෘති පරීක්ෂණ අදියරේදී අධීක්ෂණ සහ මෙහෙයුම් නිපුණතාවය වැඩි දියුණු කිරීම. මුලදී, අපගේ විසඳුමේ විභව පාරිභෝගිකයින් හැකිතාක් දුරට සැලකිල්ලට ගන්න, දත්ත සමුදා ව්යුහය අවසානයේ රඳා පවතින්නේ මෙය වන බැවිනි.
හැකි ප්රශස්තකරණය සඳහා ප්රතිඵල පරිපථය කිහිප වතාවක් කරකවන්න. අනුක්‍රමික කළ හැකි ක්ෂේත්‍ර තෝරන්න. වඩාත් නිවැරදිව හා ප්‍රශස්ත ලෙස සැලකිල්ලට ගැනීම සඳහා අප විසින් සෑදිය යුතු අමතර වගු මොනවාද යන්න තේරුම් ගෙන, ඉල්ලීම මත අවශ්ය තොරතුරු සපයන්න (උදාහරණයක් ලෙස, විවිධ බිඳවැටීම් සැලකිල්ලට ගනිමින්, අපට එකම දත්ත විවිධ වගු වල ගබඩා කළ හැකි යැයි උපකල්පනය කිරීමෙන්. විවිධ නිර්ණායක, කියවීමේ ඉල්ලීම් සඳහා CPU කාලය සැලකිය යුතු ලෙස ඉතිරි කර ගත හැක).
නරක නැහැ TTL ඇමිණීම සහ යල් පැන ගිය දත්ත පිරිසිදු කිරීම සඳහා වහාම සපයන්න.
Cassandra වෙතින් දත්ත බාගත කිරීමේදී යෙදුම් තර්කය FETCH මූලධර්මය මත ක්‍රියා කළ යුතුය, එවිට සියලුම පේළි එකවර මතකයට පටවනු නොලැබේ, නමුත් කණ්ඩායම් වශයෙන් තෝරා ගනු ලැබේ.
විස්තර කරන ලද විසඳුම වෙත ව්යාපෘතිය මාරු කිරීමට පෙර එය යෝග්ය වේ බිඳ වැටීම් පරීක්ෂණ මාලාවක් පැවැත්වීමෙන් පද්ධතියේ දෝෂ ඉවසීම පරීක්ෂා කරන්න, එක් දත්ත මධ්‍යස්ථානයක දත්ත නැතිවීම, යම් කාල සීමාවක් තුළ හානියට පත් දත්ත ප්‍රතිෂ්ඨාපනය කිරීම, දත්ත මධ්‍යස්ථාන අතර ජාල අත්හැරීම වැනි. එවැනි පරීක්ෂණ මඟින් යෝජිත ගෘහනිර්මාණ ශිල්පයේ වාසි සහ අවාසි ඇගයීමට ඉඩ සලසනවා පමණක් නොව, ඒවා මෙහෙයවන ඉංජිනේරුවන්ට හොඳ උණුසුම් කිරීමේ පුහුණුවක් ද ලබා දෙනු ඇත, සහ නිෂ්පාදනයේදී පද්ධති අසාර්ථකත්වය ප්‍රතිනිෂ්පාදනය කළහොත් අත්පත් කරගත් කුසලතාව අතිරික්ත නොවේ.
අපි තීරණාත්මක තොරතුරු සමඟ වැඩ කරන්නේ නම් (බිල්පත් කිරීම සඳහා දත්ත, ග්‍රාහක ණය ගණනය කිරීම වැනි), එවිට DBMS හි විශේෂාංග හේතුවෙන් පැන නගින අවදානම් අවම කරන මෙවලම් කෙරෙහි ද අවධානය යොමු කිරීම වටී. උදාහරණයක් ලෙස, nodesync උපයෝගීතාව (Datastax) භාවිතා කරන්න, එය පිළිවෙලට භාවිතා කිරීම සඳහා ප්‍රශස්ත උපාය මාර්ගයක් සකස් කර ඇත. අනුකූලතාව සඳහා, කැසැන්ඩ්‍රා මත අධික බරක් ඇති නොකරන්න සහ යම් කාල සීමාවක් තුළ ඇතැම් වගු සඳහා පමණක් එය භාවිතා කරන්න.
ජීවිතයේ මාස හයකට පසු කැසැන්ඩ්‍රාට කුමක් සිදුවේද? පොදුවේ, නොවිසඳුණු ගැටළු නොමැත. අපි කිසිදු බරපතල අනතුරු හෝ දත්ත අහිමි වීමට ඉඩ දුන්නේ නැත. ඔව්, මීට පෙර ඇති නොවූ සමහර ගැටළු සඳහා වන්දි ගෙවීම ගැන අපට සිතා බැලිය යුතුව තිබුණි, නමුත් අවසානයේ මෙය අපගේ වාස්තු විද්‍යාත්මක විසඳුම විශාල වශයෙන් වළක්වන්නේ නැත. ඔබට අලුත් දෙයක් උත්සාහ කිරීමට අවශ්ය නම් සහ බිය නොවන්නේ නම් සහ ඒ සමඟම ඕනෑවට වඩා බලාපොරොත්තු සුන් වීමට අවශ්ය නැතිනම්, කිසිවක් නොමිලේ නොවන බව සඳහා සූදානම් වන්න. ඔබට පැරණි උරුම විසඳුමට වඩා තේරුම් ගැනීමට, ලේඛනගත කිරීමට සහ ඔබේම තනි රාක්ක එකලස් කිරීමට සිදුවනු ඇති අතර, ඔබ වෙනුවෙන් බලා සිටින්නේ කුමන රාක්කයද යන්න කිසිදු න්‍යායක් ඔබට කල්තියා නොකියයි.
මූලාශ්රය: www.habr.com