NewSQL = NoSQL+ACID

මෑතක් වන තුරු, Odnoklassniki විසින් SQL සේවාදායකයේ තථ්‍ය කාලීනව සැකසූ දත්ත 50 TB පමණ ගබඩා කර ඇත. එවැනි පරිමාවක් සඳහා, SQL DBMS භාවිතයෙන් වේගවත් සහ විශ්වාසදායක, සහ දත්ත මධ්‍යස්ථාන අසාර්ථක වීමට ඔරොත්තු දෙන ප්‍රවේශය සැපයීමට නොහැකි තරම්ය. සාමාන්‍යයෙන්, එවැනි අවස්ථාවන්හිදී, NoSQL ගබඩා වලින් එකක් භාවිතා වේ, නමුත් සියල්ල NoSQL වෙත මාරු කළ නොහැක: සමහර ආයතන සඳහා ACID ගනුදෙනු සහතික අවශ්‍ය වේ.

මෙය NewSQL ආචයනය, එනම් NoSQL පද්ධතිවල දෝෂ ඉවසීම, පරිමාණය සහ ක්‍රියාකාරීත්වය සපයන DBMS, නමුත් ඒ සමඟම සම්භාව්‍ය පද්ධති සඳහා හුරුපුරුදු ACID සහතිකයක් පවත්වා ගැනීම සඳහා අපව යොමු කළේය. මෙම නව පන්තියේ ක්‍රියාකාරී කාර්මික පද්ධති ස්වල්පයක් ඇත, එබැවින් අපි එවැනි ක්‍රමයක් අප විසින්ම ක්‍රියාත්මක කර වාණිජ ක්‍රියාකාරිත්වයට පත් කළෙමු.

එය ක්රියා කරන ආකාරය සහ සිදුවූයේ කුමක්ද - කප්පාදුව යටතේ කියවන්න.

අද වන විට Odnoklassniki හි මාසික ප්‍රේක්ෂකයින් මිලියන 70 කට වඩා අද්විතීය අමුත්තන් වේ. අප අපි පළමු පස් දෙනා අතර ඉන්නවා ලෝකයේ විශාලතම සමාජ ජාල, සහ පරිශීලකයින් වැඩි කාලයක් ගත කරන අඩවි විස්සක් අතර. OK යටිතල පහසුකම් ඉතා ඉහළ බරක් හසුරුවයි: HTTP ඉල්ලීම් මිලියනයකට වඩා/තත්පරයකට වඩා. කෑලි 8000 කට වඩා වැඩි සේවාදායක ඇණියක කොටස් එකිනෙකට සමීපව පිහිටා ඇත - මොස්කව් දත්ත මධ්‍යස්ථාන හතරක, ඒවා අතර 1 ms ට වඩා අඩු ජාල ප්‍රමාදයක් සඳහා ඉඩ ලබා දේ.

අපි 2010 සිට කැසැන්ඩ්‍රා භාවිතා කරනවා, 0.6 අනුවාදයෙන්. අද වන විට ක්‍රියාත්මක වන පොකුරු දුසිම් කිහිපයක් ඇත. වේගවත්ම පොකුර තත්පරයකට මෙහෙයුම් මිලියන 4කට වඩා වැඩි ප්‍රමාණයක් ක්‍රියාවට නංවන අතර විශාලතම ගබඩාව 260 TB වේ.

කෙසේ වෙතත්, මේ සියල්ල ගබඩා කිරීම සඳහා භාවිතා කරන සාමාන්ය NoSQL පොකුරු වේ දුර්වල සම්බන්ධීකරණය දත්ත. Odnoklassniki ආරම්භයේ සිට භාවිතා කරන ලද Microsoft SQL Server ප්‍රධාන ස්ථාවර ගබඩාව ප්‍රතිස්ථාපනය කිරීමට අපට අවශ්‍ය විය. ගබඩාව SQL Server Standard Edition යන්ත්‍ර 300කට වැඩි ප්‍රමාණයකින් සමන්විත වූ අතර, එහි 50 TB දත්ත - ව්‍යාපාරික ආයතන අඩංගු විය. මෙම දත්ත ACID ගනුදෙනුවල කොටසක් ලෙස වෙනස් කර ඇති අතර අවශ්‍ය වේ ඉහළ අනුකූලතාවක්.

SQL Server nodes හරහා දත්ත බෙදා හැරීම සඳහා, අපි සිරස් සහ තිරස් යන දෙකම භාවිතා කළෙමු කොටස් කිරීම (බෙලීම). ඓතිහාසික වශයෙන්, අපි සරල දත්ත බෙදා හැරීමේ ක්‍රමයක් භාවිතා කළෙමු: සෑම ආයතනයක්ම ටෝකනයක් සමඟ සම්බන්ධ වී ඇත - ආයතන හැඳුනුම්පතේ ශ්‍රිතයකි. එකම ටෝකනය සහිත ආයතන එකම SQL සේවාදායකයේ තබා ඇත. ප්‍රධාන සහ ළමා වාර්තාවල ටෝකන සැමවිටම ගැලපෙන පරිදි සහ එකම සේවාදායකයේ පිහිටා ඇති පරිදි ප්‍රධාන-විස්තර සම්බන්ධතාවය ක්‍රියාත්මක කරන ලදී. සමාජ ජාලයක, සියලුම වාර්තා පාහේ පරිශීලකයා වෙනුවෙන් ජනනය වේ - එයින් අදහස් කරන්නේ එක් ක්‍රියාකාරී උප පද්ධතියක් තුළ ඇති සියලුම පරිශීලක දත්ත එක් සේවාදායකයක ගබඩා කර ඇති බවයි. එනම්, ව්‍යාපාරික ගනුදෙනුවකට සෑම විටම පාහේ එක් SQL සේවාදායකයකින් වගු ඇතුළත් වන අතර, එමඟින් භාවිතා කිරීමේ අවශ්‍යතාවයකින් තොරව දේශීය ACID ගනුදෙනු භාවිතයෙන් දත්ත අනුකූලතාව සහතික කිරීමට හැකි විය. මන්දගාමී සහ විශ්වාස කළ නොහැකි බෙදා හරින ලද ACID ගනුදෙනු.

බෙදා හැරීමට සහ SQL වේගවත් කිරීමට ස්තූතියි:

• අපි විදේශ යතුරු සීමාවන් භාවිතා නොකරමු, මන්ද යත් බෙදා හැරීමේදී ආයතන හැඳුනුම වෙනත් සේවාදායකයක පිහිටා තිබිය හැක.
• DBMS CPU මත ඇති අමතර බර නිසා අපි ගබඩා කර ඇති ක්‍රියා පටිපාටි සහ ප්‍රේරක භාවිතා නොකරමු.
• ඉහත සියල්ල සහ තැටියෙන් අහඹු කියවීම් රාශියක් නිසා අපි JOINs භාවිතා නොකරමු.
• ගනුදෙනුවකින් පිටත, අපි අවහිරතා අඩු කිරීමට Read Uncommitted හුදකලා මට්ටම භාවිතා කරමු.
• අපි කෙටි ගනුදෙනු පමණක් සිදු කරන්නෙමු (සාමාන්‍යයෙන් 100 ms ට වඩා කෙටි).
• අපි අවහිර කිරීම් විශාල සංඛ්‍යාවක් හේතුවෙන් බහු පේළි යාවත්කාලීන කිරීම සහ මකා දැමීම භාවිතා නොකරමු - අපි වරකට එක් වාර්තාවක් පමණක් යාවත්කාලීන කරන්නෙමු.
• අපි සැමවිටම විමසුම් සිදු කරන්නේ දර්ශක මත පමණි - අපට සම්පූර්ණ වගු ස්කෑන් සැලැස්මක් සහිත විමසුමකින් අදහස් වන්නේ දත්ත සමුදාය අධික ලෙස පැටවීම සහ එය අසාර්ථක වීමට හේතු වීමයි.

මෙම පියවර SQL සේවාදායකයන්ගෙන් උපරිම කාර්ය සාධනය මිරිකීමට අපට ඉඩ සලසයි. කෙසේ වෙතත්, ගැටළු එන්න එන්නම වැඩි විය. අපි ඒවා බලමු.

SQL සමඟ ගැටළු

• අපි ස්වයං-ලිඛිත ෂේඩින් භාවිතා කළ බැවින්, නව කැබලි එකතු කිරීම පරිපාලකයින් විසින් අතින් සිදු කරන ලදී. මේ කාලය පුරාම, පරිමාණය කළ හැකි දත්ත අනුරූ සේවා ඉල්ලීම් නොවීය.
• වගුවේ ඇති වාර්තා ගණන වැඩි වන විට, ඇතුළත් කිරීමේ සහ වෙනස් කිරීමේ වේගය අඩු වේ; පවතින වගුවකට දර්ශක එකතු කරන විට, වේගය සාධකයකින් පහත වැටේ; දර්ශක නිර්මාණය කිරීම සහ ප්‍රතිනිර්මාණය කිරීම අක්‍රිය කාලයත් සමඟ සිදු වේ.
• නිෂ්පාදනයේදී SQL Server සඳහා කුඩා Windows ප්‍රමාණයක් තිබීම යටිතල පහසුකම් කළමනාකරණය අපහසු කරයි

නමුත් ප්රධාන ගැටළුව වන්නේ

වැරදි ඉවසීම

සම්භාව්‍ය SQL සේවාදායකය දුර්වල වැරදි ඉවසීමක් ඇත. ඔබ සතුව ඇත්තේ එක් දත්ත සමුදා සේවාදායකයක් පමණක් යැයි කියමු, එය වසර තුනකට වරක් අසමත් වේ. මෙම කාලය තුළ වෙබ් අඩවිය විනාඩි 20 ක් සඳහා පිළිගත හැකි ය. ඔබට සේවාදායකයන් 64 ක් තිබේ නම්, සති තුනකට වරක් වෙබ් අඩවිය ක්‍රියා විරහිත වේ. ඔබට සේවාදායකයන් 200 ක් තිබේ නම්, වෙබ් අඩවිය සෑම සතියකම ක්‍රියා නොකරයි. මෙය ගැටලුවකි.

SQL සේවාදායකයේ දෝෂ ඉවසීම වැඩිදියුණු කිරීමට කුමක් කළ හැකිද? විකිපීඩියාව ගොඩනැගීමට අපට ආරාධනා කරයි ඉතා ඉහලින් ලබා ගත හැකි පොකුර: කිසියම් සංරචකයක් අසාර්ථක වූ විට උපස්ථ එකක් තිබේ.

මේ සඳහා මිල අධික උපකරණ සමූහයක් අවශ්‍ය වේ: බොහෝ අනුපිටපත්, දෘශ්‍ය තන්තු, හවුල් ගබඩා කිරීම සහ සංචිතයක් ඇතුළත් කිරීම විශ්වාසදායක ලෙස ක්‍රියා නොකරයි: මාරුවීම් වලින් 10% ක් පමණ අවසන් වන්නේ ප්‍රධාන නෝඩය පිටුපස දුම්රියක් වැනි උපස්ථ නෝඩය අසමත් වීමෙනි.

නමුත් එවැනි ඉහලින් පවතින පොකුරක ඇති ප්‍රධාන අවාසිය නම් එය පිහිටා ඇති දත්ත මධ්‍යස්ථානය අසමත් වුවහොත් ශුන්‍ය ලබා ගැනීමේ හැකියාවයි. Odnoklassniki සතුව දත්ත මධ්‍යස්ථාන හතරක් ඇති අතර, ඒවායින් එකක සම්පූර්ණ අසාර්ථකත්වයකදී ක්‍රියාත්මක වීම සහතික කළ යුතුය.

මේ සඳහා අපට භාවිතා කළ හැකිය බහු-මාස්ටර් අනුකරණය SQL Server වෙත ගොඩනගා ඇත. මෘදුකාංගයේ පිරිවැය හේතුවෙන් මෙම විසඳුම බෙහෙවින් මිල අධික වන අතර ප්‍රතිනිර්මාණය කිරීමේ ප්‍රසිද්ධ ගැටළු වලින් පීඩා විඳිති - සමමුහුර්ත අනුකරණය සමඟ අනපේක්ෂිත ගනුදෙනු ප්‍රමාදයන් සහ අසමමුහුර්ත ප්‍රතිනිර්මාණය සමඟ අනුරූ යෙදීමේ ප්‍රමාදයන් (සහ, ප්‍රතිඵලයක් ලෙස, නැතිවූ වෙනස් කිරීම්). ඇඟවුම් කර ඇත අතින් ගැටුම් නිරාකරණය මෙම විකල්පය අපට සම්පූර්ණයෙන්ම අදාළ නොවේ.

මෙම සියලු ගැටලු රැඩිකල් විසඳුමක් අවශ්ය වූ අතර, අපි ඒවා විස්තරාත්මකව විශ්ලේෂණය කිරීමට පටන් ගත්තා. මෙහිදී අපි SQL Server ප්‍රධාන වශයෙන් කරන්නේ කුමක්ද යන්න දැනගත යුතුයි - ගනුදෙනු.

සරල ගනුදෙනුවක්

ව්‍යවහාරික SQL ක්‍රමලේඛකයෙකුගේ දෘෂ්ටි කෝණයෙන් සරලම ගනුදෙනුව සලකා බලමු: ඇල්බමයකට ඡායාරූපයක් එක් කිරීම. ඇල්බම සහ ඡායාරූප විවිධ තහඩු වල ගබඩා කර ඇත. ඇල්බමයේ පොදු ඡායාරූප කවුන්ටරයක් ​​ඇත. එවිට එවැනි ගනුදෙනුවක් පහත පියවර වලට බෙදා ඇත:

1. අපි යතුරෙන් ඇල්බමය අගුළු දමමු.
2. ඡායාරූප වගුවේ ඇතුළත් කිරීමක් සාදන්න.
3. ඡායාරූපයට පොදු තත්වයක් තිබේ නම්, ඇල්බමයට පොදු ඡායාරූප කවුන්ටරයක් ​​එක් කරන්න, වාර්තාව යාවත්කාලීන කර ගනුදෙනුව කරන්න.

හෝ ව්යාජ කේතයෙන්:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

ව්‍යාපාරික ගනුදෙනුවක් සඳහා වඩාත් පොදු අවස්ථාව වන්නේ දත්ත සමුදායේ දත්ත යෙදුම් සේවාදායකයේ මතකයට කියවීම, යමක් වෙනස් කිරීම සහ නව අගයන් දත්ත ගබඩාවට සුරැකීම බව අපට පෙනේ. සාමාන්‍යයෙන් එවැනි ගනුදෙනුවකදී අපි ආයතන කිහිපයක්, වගු කිහිපයක් යාවත්කාලීන කරනවා.

ගනුදෙනුවක් සිදු කරන විට, වෙනත් පද්ධතියකින් එකම දත්ත සමගාමීව වෙනස් කිරීම සිදු විය හැක. උදාහරණයක් ලෙස, Antispam විසින් පරිශීලකයා කෙසේ හෝ සැක සහිත බව තීරණය කළ හැකි අතර එබැවින් පරිශීලකයාගේ සියලු ඡායාරූප තවදුරටත් පොදු නොවිය යුතුය, ඒවා මධ්‍යස්ථ කිරීම සඳහා යැවිය යුතුය, එනම් photo.status වෙනත් අගයකට වෙනස් කිරීම සහ අනුරූප කවුන්ටර අක්‍රිය කිරීමයි. පැහැදිලිවම, මෙම මෙහෙයුම සිදුවන්නේ නම්, යෙදුමේ පරමාණුක බව සහ තරඟකාරී වෙනස් කිරීම් හුදකලා කිරීම පිළිබඳ සහතිකයක් නොමැතිව අම්ලය, එවිට ප්රතිඵලය අවශ්ය නොවේ - එක්කෝ ඡායාරූප කවුන්ටරය වැරදි අගය පෙන්වනු ඇත, නැතහොත් සියලු ඡායාරූප මධ්යස්ථ කිරීම සඳහා යවනු නොලැබේ.

Odnoklassniki හි සමස්ත පැවැත්ම පුරාවටම, එක් ගනුදෙනුවක් තුළ විවිධ ව්‍යාපාරික ආයතන හැසිරවීම සඳහා සමාන කේතයක් ලියා ඇත. සිට NoSQL වෙත සංක්‍රමණය වීමේ අත්දැකීම් මත පදනම්ව අවසාන අනුකූලතාව විශාලතම අභියෝගය (සහ කාල ආයෝජනය) පැමිණෙන්නේ දත්ත අනුකූලතාව පවත්වා ගැනීම සඳහා කේතය සංවර්ධනය කිරීමෙන් බව අපි දනිමු. එබැවින්, යෙදුම් තර්කනය සඳහා සැබෑ ACID ගනුදෙනු සඳහා ප්‍රතිපාදන නව ගබඩාව සඳහා වන ප්‍රධාන අවශ්‍යතාවය ලෙස අපි සලකමු.

වෙනත්, අඩු වැදගත්කමක් නැති, අවශ්‍යතා වූයේ:

• දත්ත මධ්‍යස්ථානය අසාර්ථක වුවහොත්, නව ගබඩාව වෙත කියවීම සහ ලිවීම යන දෙකම තිබිය යුතුය.
• වත්මන් සංවර්ධන වේගය පවත්වා ගැනීම. එනම්, නව ගබඩාවක් සමඟ වැඩ කරන විට, කේතයේ ප්රමාණය ආසන්න වශයෙන් සමාන විය යුතුය; ගබඩාවට කිසිවක් එකතු කිරීම, ගැටුම් විසඳීම සඳහා ඇල්ගොරිතම සංවර්ධනය කිරීම, ද්විතියික දර්ශක පවත්වා ගැනීම යනාදිය අවශ්ය නොවේ.
• දත්ත කියවීමේදී සහ ගනුදෙනු සැකසීමේදී නව ගබඩාවේ වේගය තරමක් ඉහළ විය යුතු අතර, එයින් අදහස් කළේ ශාස්ත්‍රීය වශයෙන් දැඩි, විශ්වීය, නමුත් මන්දගාමී විසඳුම්, උදාහරණයක් ලෙස, අදාළ නොවන බවයි. ද්වි-අදියර සිදු කරයි.
• පියාසර කරන ස්වයංක්‍රීය පරිමාණය.
• විදේශීය දෘඩාංග මිලදී ගැනීමේ අවශ්‍යතාවයකින් තොරව සාමාන්‍ය ලාභ සේවාදායක භාවිතා කිරීම.
• සමාගම් සංවර්ධකයින් විසින් ගබඩා සංවර්ධනය කිරීමේ හැකියාව. වෙනත් වචන වලින් කිවහොත්, ප්‍රමුඛත්වය ලබා දී ඇත්තේ හිමිකාර හෝ විවෘත මූලාශ්‍ර විසඳුම් සඳහා, වඩාත් සුදුසු ජාවා හි ය.

තීරණ, තීරණ

හැකි විසඳුම් විශ්ලේෂණය කරමින්, අපි හැකි ගෘහ නිර්මාණ තේරීම් දෙකකට පැමිණියෙමු:

පළමුවැන්න නම් ඕනෑම SQL සේවාදායකයක් ගෙන අවශ්‍ය දෝෂ ඉවසීම, පරිමාණ යාන්ත්‍රණය, අසාර්ථක පොකුර, ගැටුම් නිරාකරණය සහ බෙදා හරින ලද, විශ්වාසදායක සහ වේගවත් ACID ගනුදෙනු ක්‍රියාත්මක කිරීමයි. අපි මෙම විකල්පය ඉතා සුළු නොවන සහ ශ්‍රම-දැඩි ලෙස ශ්‍රේණිගත කළෙමු.

දෙවන විකල්පය නම්, ක්‍රියාත්මක කරන ලද පරිමාණය, අසාර්ථක පොකුරක්, ගැටුම් නිරාකරණය සහ ගනුදෙනු සහ SQL ඔබම ක්‍රියාත්මක කිරීම සහිත සූදානම් NoSQL ගබඩාවක් ගැනීමයි. බැලූ බැල්මට, ACID ගනුදෙනු ගැන සඳහන් නොකර SQL ක්‍රියාත්මක කිරීමේ කාර්යය පවා වසර ගණනාවක් ගත වන කාර්යයක් ලෙස පෙනේ. නමුත් පසුව අපට වැටහුණා අපි ප්‍රායෝගිකව භාවිතා කරන SQL විශේෂාංග කට්ටලය ANSI SQL වලින් බොහෝ දුරස්ථ බව Cassandra CQL ANSI SQL වෙතින් දුරින්. CQL වඩාත් සමීපව බැලීමෙන්, එය අපට අවශ්‍ය දේට බෙහෙවින් ආසන්න බව අපට වැටහුණි.

Cassandra සහ CQL

ඉතින්, කැසැන්ඩ්‍රා ගැන රසවත් වන්නේ කුමක්ද, එයට ඇති හැකියාවන් මොනවාද?

පළමුව, මෙහිදී ඔබට විවිධ දත්ත වර්ග සඳහා සහය දක්වන වගු සෑදිය හැක; ඔබට ප්‍රාථමික යතුර මත SELECT හෝ UPDATE කළ හැක.

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

අනුරූ දත්ත අනුකූලතාව සහතික කිරීම සඳහා, Cassandra භාවිතා කරයි ගණපූර්ණ ප්‍රවේශය. සරලම අවස්ථාවෙහිදී, මෙයින් අදහස් කරන්නේ එකම පේළියේ අනුරූ තුනක් පොකුරේ විවිධ නෝඩ් මත තැබූ විට, නෝඩ් බහුතරයක් (එනම් තුනෙන් දෙකක්) මෙම ලිවීමේ මෙහෙයුමේ සාර්ථකත්වය තහවුරු කළහොත් ලිවීම සාර්ථක ලෙස සලකනු ලැබේ. . කියවීමේදී නෝඩ් වලින් බහුතරයක් මත විමසා ඒවා තහවුරු කර ඇත්නම් පේළි දත්ත ස්ථාවර ලෙස සලකනු ලැබේ. මේ අනුව, අනුපිටපත් තුනක් සමඟ, එක් නෝඩයක් අසමත් වුවහොත් සම්පූර්ණ සහ ක්ෂණික දත්ත අනුකූලතාව සහතික කෙරේ. මෙම ප්‍රවේශය අපට වඩාත් විශ්වාසදායක යෝජනා ක්‍රමයක් ක්‍රියාත්මක කිරීමට ඉඩ ලබා දුන්නේය: සෑම විටම අනුපිටපත් තුනටම ඉල්ලීම් යවන්න, වේගවත්ම දෙකෙන් ප්‍රතිචාරයක් බලාපොරොත්තුවෙන්. මෙම අවස්ථාවෙහිදී තුන්වන අනුරුවෙහි ප්‍රමාද ප්‍රතිචාරය ඉවත දමනු ලැබේ. ප්‍රතිචාර දැක්වීමට ප්‍රමාද වන නෝඩයකට බරපතල ගැටළු ඇති විය හැක - තිරිංග, JVM හි කුණු එකතු කිරීම, ලිනක්ස් කර්නලයේ සෘජු මතකය නැවත ලබා ගැනීම, දෘඩාංග අසමත් වීම, ජාලයෙන් විසන්ධි වීම. කෙසේ වෙතත්, මෙය සේවාදායකයාගේ මෙහෙයුම් හෝ දත්ත වලට කිසිදු ආකාරයකින් බලපාන්නේ නැත.

අපි නෝඩ් තුනක් සම්බන්ධ කර දෙකක් ප්රතිචාරයක් ලැබෙන විට ප්රවේශය ලෙස හැඳින්වේ සමපේක්ෂනය: අමතර අනුපිටපත් සඳහා ඉල්ලීමක් "වැටීමට" පෙර පවා යවනු ලැබේ.

Cassandra හි තවත් ප්‍රතිලාභයක් වන්නේ Batchlog, ඔබ විසින් සිදු කරන ලද වෙනස්කම් සමූහයක් සම්පූර්ණයෙන්ම යෙදී ඇති බව හෝ කිසිසේත්ම අදාළ නොවන බව සහතික කරන යාන්ත්‍රණයකි. පෙට්ටියෙන් පිටත පරමාණුක - ACID හි A විසඳීමට මෙය අපට ඉඩ සලසයි.

කැසැන්ඩ්‍රා හි ගනුදෙනු වලට ආසන්නතම දෙය නම් ඊනියා "සැහැල්ලු ගනුදෙනු". නමුත් ඔවුන් "සැබෑ" ACID ගනුදෙනු වලින් ඈත්ව සිටිති: ඇත්ත වශයෙන්ම, මෙය කිරීමට අවස්ථාවක් CAS හෙවිවේට් පැක්සෝස් ප්‍රොටෝකෝලය භාවිතයෙන් සම්මුතිය භාවිතා කරමින් එක් වාර්තාවකින් පමණක් දත්ත මත. එබැවින් එවැනි ගනුදෙනු වල වේගය අඩුය.

කැසන්ඩ්‍රා හි අපට නැතිවූ දේ

ඉතින්, අපිට Cassandra හි සැබෑ ACID ගනුදෙනු ක්රියාත්මක කිරීමට සිදු විය. සම්භාව්‍ය DBMS හි තවත් පහසු විශේෂාංග දෙකක් අපට පහසුවෙන් ක්‍රියාත්මක කළ හැකි ඒවා භාවිතා කිරීමෙන්: ප්‍රාථමික යතුරෙන් පමණක් නොව දත්ත තේරීම් සිදු කිරීමට අපට ඉඩ සලසන ස්ථාවර වේගවත් දර්ශක, සහ ඒකාකාරී ස්වයංක්‍රීය වර්ධක හැඳුනුම්පත්වල නිත්‍ය උත්පාදකයක්.

C*එක

මේ අනුව නව DBMS බිහි විය C*එක, සේවාදායක නෝඩ් වර්ග තුනකින් සමන්විත වේ:

• ගබඩා කිරීම - (පාහේ) දේශීය තැටිවල දත්ත ගබඩා කිරීම සඳහා වගකිව යුතු සම්මත Cassandra සේවාදායකයන්. දත්තවල භාරය සහ පරිමාව වර්ධනය වන විට, ඒවායේ ප්‍රමාණය පහසුවෙන් දස සහ සිය ගණන දක්වා පරිමාණය කළ හැක.
• ගනුදෙනු සම්බන්ධීකාරක - ගනුදෙනු ක්රියාත්මක කිරීම සහතික කිරීම.
• සේවාලාභීන් යනු ව්‍යාපාර මෙහෙයුම් ක්‍රියාත්මක කරන සහ ගනුදෙනු ආරම්භ කරන යෙදුම් සේවාදායකයන් වේ. එවැනි ගනුදෙනුකරුවන් දහස් ගණනක් සිටිය හැකිය.

සියලු වර්ගවල සේවාදායකයන් පොදු පොකුරක කොටසකි, එකිනෙකා සමඟ සන්නිවේදනය කිරීමට අභ්‍යන්තර Cassandra පණිවිඩ ප්‍රොටෝකෝලය භාවිතා කරන්න ඕපාදූප පොකුරු තොරතුරු හුවමාරු කර ගැනීම සඳහා. හෘද ස්පන්දනය සමඟ, සේවාදායකයන් අන්‍යෝන්‍ය අසාර්ථකත්වයන් ගැන ඉගෙන ගනී, තනි දත්ත සැලැස්මක් පවත්වා ගනී - වගු, ඒවායේ ව්‍යුහය සහ අනුකරණය; කොටස් කිරීමේ යෝජනා ක්රමය, පොකුරු ස්ථලකය, ආදිය.

සේවාලාභීන්

සම්මත ධාවකයන් වෙනුවට, Fat Client මාදිලිය භාවිතා වේ. එවැනි නෝඩයක් දත්ත ගබඩා නොකරයි, නමුත් ඉල්ලීම් ක්‍රියාත්මක කිරීම සඳහා සම්බන්ධීකාරක ලෙස ක්‍රියා කළ හැකිය, එනම්, සේවාදායකයාම එහි ඉල්ලීම්වල සම්බන්ධීකාරක ලෙස ක්‍රියා කරයි: එය ගබඩා අනුරූ විමසා ගැටුම් නිරාකරණය කරයි. මෙය දුරස්ථ සම්බන්ධීකාරක සමඟ සන්නිවේදනය අවශ්ය වන සම්මත ධාවකයට වඩා විශ්වාසදායක සහ වේගවත් පමණක් නොව, ඉල්ලීම් සම්ප්රේෂණය පාලනය කිරීමට ඔබට ඉඩ සලසයි. සේවාදායකයා මත විවෘතව ඇති ගනුදෙනුවකින් පිටත, ඉල්ලීම් ගබඩා වෙත යවනු ලැබේ. සේවාදායකයා ගනුදෙනුවක් විවෘත කර ඇත්නම්, ගනුදෙනුව තුළ ඇති සියලුම ඉල්ලීම් ගනුදෙනු සම්බන්ධීකාරක වෙත යවනු ලැබේ.

C*එක් ගනුදෙනු සම්බන්ධීකාරක

සම්බන්ධීකාරකය යනු අපි මුල සිටම C* One සඳහා ක්‍රියාත්මක කළ දෙයකි. ගනුදෙනු කළමනාකරණය කිරීම, අගුලු දැමීම සහ ගනුදෙනු යෙදෙන අනුපිළිවෙල සඳහා එය වගකිව යුතුය.

සේවා සපයන සෑම ගනුදෙනුවක් සඳහාම, සම්බන්ධීකාරක විසින් කාල මුද්‍රාවක් ජනනය කරයි: එක් එක් පසු ගනුදෙනු පෙර ගනුදෙනුවට වඩා වැඩි වේ. කැසැන්ඩ්‍රාගේ ගැටුම් නිරාකරණ පද්ධතිය වේලා මුද්‍රා මත පදනම් වී ඇති බැවින් (පටහැනි වාර්තා දෙකකින්, නවතම වේලා මුද්‍රාව සහිත එක වත්මන් ලෙස සලකනු ලැබේ), ගැටුම සෑම විටම ඊළඟ ගනුදෙනුවට පක්ෂව විසඳනු ඇත. ඒ අනුව අපි ක්‍රියාත්මක කළා ලාම්පු ඔරලෝසුව - බෙදා හරින ලද පද්ධතියක ගැටුම් නිරාකරණය කිරීමට ලාභදායී ක්රමයකි.

අගුල්

හුදකලා වීම සහතික කිරීම සඳහා, අපි සරලම ක්රමය භාවිතා කිරීමට තීරණය කළෙමු - වාර්තාවේ ප්රාථමික යතුර මත පදනම් වූ අශුභවාදී අගුල්. වෙනත් වචන වලින් කිවහොත්, ගනුදෙනුවකදී, වාර්තාවක් පළමුව අගුළු දැමිය යුතුය, පසුව පමණක් කියවීම, වෙනස් කිරීම සහ සුරැකිය යුතුය. තරඟකාරී ගනුදෙනුවලට එය භාවිතා කළ හැකි වන පරිදි වාර්තාවක් අගුළු හැරිය හැක්කේ සාර්ථක කැපවීමකින් පසුව පමණි.

එවැනි අගුලු දැමීම ක්රියාත්මක කිරීම බෙදා නොහරින පරිසරයක් තුළ සරලයි. බෙදා හරින ලද පද්ධතියක, ප්‍රධාන විකල්ප දෙකක් තිබේ: එක්කෝ පොකුරේ බෙදා හරින ලද අගුලු දැමීම ක්‍රියාත්මක කරන්න, නැතහොත් එකම වාර්තාව සම්බන්ධ ගනුදෙනු සෑම විටම එකම සම්බන්ධීකාරක විසින් සේවා සපයනු ලබන පරිදි ගනුදෙනු බෙදාහරින්න.

අපගේ නඩුවේ දත්ත දැනටමත් SQL හි දේශීය ගනුදෙනු කණ්ඩායම් අතර බෙදා හැර ඇති බැවින්, දේශීය ගනුදෙනු කණ්ඩායම් සම්බන්ධීකාරක වෙත පැවරීමට තීරණය කරන ලදී: එක් සම්බන්ධීකාරක 0 සිට 9 දක්වා ටෝකන සමඟ සියලුම ගනුදෙනු සිදු කරයි, දෙවැන්න - 10 සිට 19 දක්වා ටෝකන සමඟ, සහ යනාදි. එහි ප්‍රතිඵලයක් වශයෙන්, එක් එක් සම්බන්ධීකාරක අවස්ථා ගනුදෙනු කණ්ඩායමේ ප්‍රධානියා බවට පත්වේ.

එවිට සම්බන්ධීකාරකගේ මතකයේ ඇති බැනල් HashMap ආකාරයෙන් අගුල් ක්රියාත්මක කළ හැකිය.

සම්බන්ධීකාරක අසමත්වීම්

එක් සම්බන්ධීකාරකයෙකු ගනුදෙනු සමූහයකට පමණක් සේවය කරන බැවින්, ගනුදෙනුව ක්‍රියාත්මක කිරීමේ දෙවන උත්සාහය කල් ඉකුත් වන පරිදි එහි අසාර්ථකත්වය පිළිබඳ කාරණය ඉක්මනින් තීරණය කිරීම ඉතා වැදගත් වේ. මෙය වේගවත් සහ විශ්වාසදායක කිරීමට, අපි සම්පුර්ණයෙන්ම සම්බන්ධිත ගණපූර්ණ ශ්‍රවණ ස්පන්දන ප්‍රොටෝකෝලය භාවිතා කළෙමු:

සෑම දත්ත මධ්‍යස්ථානයක්ම අවම වශයෙන් සම්බන්ධීකාරක නෝඩ් දෙකක්වත් පවත්වයි. කාලානුරූපව, සෑම සම්බන්ධීකාරකයෙකුම අනෙකුත් සම්බන්ධීකාරකවරුන්ට හෘද ස්පන්දන පණිවිඩයක් යවා එහි ක්‍රියාකාරිත්වය පිළිබඳව මෙන්ම අවසන් වරට පොකුරේ සිටි සම්බන්ධීකාරකවරුන්ගෙන් ලැබුණු හෘද ස්පන්දන පණිවිඩ මොනවාද යන්න ඔවුන්ට දන්වයි.

ඔවුන්ගේ හෘද ස්පන්දන පණිවිඩවල කොටසක් ලෙස අන් අයගෙන් සමාන තොරතුරු ලබා ගනිමින්, එක් එක් සම්බන්ධීකාරක ගණපූර්ණ මූලධර්මය මගින් මෙහෙයවනු ලබන පොකුරු නෝඩ් ක්‍රියා කරන්නේ සහ ක්‍රියාත්මක නොවන ඒවා තමාටම තීරණය කරයි: නෝඩය X පොකුරේ ඇති බොහෝ නෝඩ් වලින් සාමාන්‍ය තොරතුරු ලබාගෙන තිබේ නම් නෝඩ් Y වෙතින් පණිවිඩ ලැබීම, පසුව , Y ක්‍රියා කරයි. සහ අනෙක් අතට, බහුතරයක් නෝඩ් Y වෙතින් නැතිවූ පණිවිඩ වාර්තා කළ වහාම, Y ප්‍රතික්ෂේප කර ඇත. ගණපූරණය node X වෙත තවදුරටත් පණිවිඩ නොලබන බව දන්වන්නේ නම්, node X විසින්ම තමන් අසාර්ථක වූ බව සලකනු ඇති බව කුතුහලයට කරුණකි.

හෘද ස්පන්දන පණිවිඩ ඉහළ සංඛ්‍යාතයකින් යවනු ලැබේ, තත්පරයට 20 වතාවක් පමණ, 50 ms කාල සීමාවක් ඇත. Java හි, කසළ එකතු කරන්නා විසින් ඇති කරන ලද විරාමවල සංසන්දනාත්මක දිග හේතුවෙන් 50 ms ඇතුළත යෙදුම් ප්‍රතිචාරය සහතික කිරීම අපහසු වේ. G1 කසළ එකතු කරන්නා භාවිතයෙන් මෙම ප්‍රතිචාර කාලය ලබා ගැනීමට අපට හැකි විය, එය GC විරාම කාල සීමාව සඳහා ඉලක්කයක් නියම කිරීමට අපට ඉඩ සලසයි. කෙසේ වෙතත්, සමහර විට, ඉතා කලාතුරකිනි, එකතු කරන්නා 50 ms ඉක්මවන අතර, එය වැරදි දෝෂයක් හඳුනා ගැනීමට හේතු විය හැක. මෙය සිදු වීම වලක්වා ගැනීම සඳහා, සම්බන්ධීකාරක විසින් රිමෝට් නෝඩයේ පළමු හෘද ස්පන්දන පණිවිඩය අතුරුදහන් වූ විට එය අසාර්ථක වීමක් වාර්තා නොකරයි, කිහිපයක් එක දිගට අතුරුදහන් වී ඇත්නම් පමණි. 200 දී සම්බන්ධීකාරක නෝඩයේ අසමත් වීමක් හඳුනා ගැනීමට අප සමත් වූයේ එලෙසිනි. මෙනෙවිය.

නමුත් කුමන නෝඩය ක්රියා කිරීම නතර කර ඇත්දැයි ඉක්මනින් තේරුම් ගැනීමට ප්රමාණවත් නොවේ. අපි මේ ගැන යමක් කළ යුතුයි.

වෙන් කිරීම

සම්භාව්‍ය යෝජනා ක්‍රමයට, ප්‍රධාන අසාර්ථක අවස්ථාවකදී, එකක් භාවිතයෙන් නව මැතිවරණයක් ආරම්භ කිරීම ඇතුළත් වේ විලාසිතාමය විශ්ව ඇල්ගොරිතම. කෙසේ වෙතත්, එවැනි ඇල්ගොරිතමවලට කාලය අභිසාරී වීම සහ මැතිවරණ ක්‍රියාවලියේම දිග පිළිබඳ ප්‍රසිද්ධ ගැටලු තිබේ. සම්පුර්ණයෙන්ම සම්බන්ධිත ජාලයක සම්බන්ධීකාරක ප්‍රතිස්ථාපන ක්‍රමයක් භාවිතයෙන් එවැනි අමතර ප්‍රමාදයන් වළක්වා ගැනීමට අපට හැකි විය:

50 කාණ්ඩයේ ගනුදෙනුවක් ක්‍රියාත්මක කිරීමට අපට අවශ්‍ය යැයි කියමු. ප්‍රතිස්ථාපන යෝජනා ක්‍රමය කල්තියා තීරණය කරමු, එනම් ප්‍රධාන සම්බන්ධීකාරක අසාර්ථක වූ විට 50 කාණ්ඩයේ ගනුදෙනු ක්‍රියාත්මක කරන්නේ කුමන නෝඩ්ද යන්නයි. අපගේ ඉලක්කය වන්නේ දත්ත මධ්‍යස්ථානයක් අසාර්ථක වූ විට පද්ධතියේ ක්‍රියාකාරීත්වය පවත්වා ගැනීමයි. පළමු සංචිතය වෙනත් දත්ත මධ්‍යස්ථානයකින් නෝඩයක් වනු ඇති බවත්, දෙවන සංචිතය තුනෙන් එකක් වන නෝඩයක් බවත් අපි තීරණය කරමු. මෙම යෝජනා ක්රමය එක් වරක් තෝරාගෙන ඇති අතර පොකුරේ ස්ථලකය වෙනස් වන තුරු, එනම්, නව නෝඩ් එයට ඇතුල් වන තුරු (ඉතා කලාතුරකින් සිදු වන) වෙනස් නොවේ. පැරණි එක අසාර්ථක වුවහොත් නව සක්‍රීය මාස්ටර් තෝරා ගැනීමේ ක්‍රියා පටිපාටිය සෑම විටම පහත පරිදි වේ: පළමු සංචිතය ක්‍රියාකාරී ස්වාමියා බවට පත් වන අතර එය ක්‍රියාත්මක වීම නතර කර ඇත්නම්, දෙවන සංචිතය ක්‍රියාකාරී ස්වාමියා බවට පත්වේ.

මෙම යෝජනා ක්‍රමය විශ්වීය ඇල්ගොරිතමයට වඩා විශ්වාසදායක ය, මන්ද නව මාස්ටර් සක්‍රිය කිරීම සඳහා පැරණි එකෙහි අසාර්ථකත්වය තීරණය කිරීම ප්‍රමාණවත් වේ.

නමුත් දැන් වැඩ කරන්නේ කුමන ස්වාමියාද ​​යන්න සේවාදායකයින් තේරුම් ගන්නේ කෙසේද? 50 ms වලදී සේවාදායකයින් දහස් ගණනකට තොරතුරු යැවීම කළ නොහැක. සේවාදායකයකු ගනුදෙනුවක් විවෘත කිරීමට ඉල්ලීමක් යවන විට තත්වයක් ඇතිවිය හැකි අතර, මෙම මාස්ටර් තවදුරටත් ක්‍රියාත්මක නොවන බව තවමත් නොදැන, ඉල්ලීම කල් ඉකුත් වනු ඇත. මෙය සිදුවීම වලක්වා ගැනීම සඳහා, ගනුදෙනුකරුවන් සමූහ ප්‍රධානියාට සහ ඔහුගේ සංචිත දෙකටම එකවර ගනුදෙනුවක් විවෘත කරන ලෙස ඉල්ලීමක් යවන නමුත්, මේ මොහොතේ ක්‍රියාකාරී ස්වාමියා පමණක් මෙම ඉල්ලීමට ප්‍රතිචාර දක්වනු ඇත. ගණුදෙණුව තුළ සේවාලාභියා සියලු පසුකාලීන සන්නිවේදනයන් ක්‍රියාකාරී ස්වාමියා සමඟ පමණක් සිදු කරයි.

උපස්ථ ප්‍රධානීන්ට නූපන් ගනුදෙනු පෝලිමට ඔවුන්ගේ නොවන ගනුදෙනු සඳහා ඉල්ලීම් ලැබී ඇති අතර එහිදී ඒවා යම් කාලයක් ගබඩා කර ඇත. ක්‍රියාකාරී ස්වාමියා මිය ගියහොත්, නව මාස්ටර් එහි පෝලිමේ සිට ගනුදෙනු විවෘත කිරීමට ඉල්ලීම් ක්‍රියාවට නංවා සේවාදායකයාට ප්‍රතිචාර දක්වයි. සේවාදායකයා දැනටමත් පැරණි ස්වාමියා සමඟ ගනුදෙනුවක් විවෘත කර ඇත්නම්, දෙවන ප්රතිචාරය නොසලකා හරිනු ලැබේ (සහ, පැහැදිලිවම, එවැනි ගනුදෙනුවක් සම්පූර්ණ නොකරන අතර සේවාදායකයා විසින් නැවත නැවතත් සිදු කරනු ඇත).

ගනුදෙනුව ක්‍රියාත්මක වන ආකාරය

එවැනි සහ එවැනි මූලික යතුරක් සහිත එවැනි සහ එවැනි ආයතනයක් සඳහා ගනුදෙනුවක් විවෘත කිරීමට සේවාදායකයෙකු සම්බන්ධීකාරක වෙත ඉල්ලීමක් යැවූ බව කියමු. සම්බන්ධීකාරක මෙම ආයතනය අගුළු දමා මතකයේ අගුළු වගුවේ තබයි. අවශ්‍ය නම්, සම්බන්ධීකාරක විසින් මෙම ආයතනය ගබඩාවෙන් කියවා එහි ප්‍රතිඵලය වන දත්ත සම්බන්ධීකාරකගේ මතකයේ ගණුදෙණු තත්ත්වයක ගබඩා කරයි.

සේවාදායකයකුට ගනුදෙනුවක දත්ත වෙනස් කිරීමට අවශ්‍ය වූ විට, එය ආයතනය වෙනස් කිරීමට සම්බන්ධීකාරක වෙත ඉල්ලීමක් යවන අතර, සම්බන්ධීකාරක විසින් ගනුදෙනු තත්ව වගුවේ නව දත්ත මතකයේ තබයි. මෙය පටිගත කිරීම සම්පූර්ණ කරයි - ගබඩාවට පටිගත කිරීමක් සිදු නොවේ.

සක්‍රීය ගනුදෙනුවක කොටසක් ලෙස සේවාලාභියෙකු තමන්ගේම වෙනස් කළ දත්ත ඉල්ලා සිටින විට, සම්බන්ධීකාරක පහත පරිදි ක්‍රියා කරයි:

• හැඳුනුම්පත දැනටමත් ගනුදෙනුවේ තිබේ නම්, දත්ත මතකයෙන් ගනු ලැබේ;
• මතකයේ හැඳුනුම්පතක් නොමැති නම්, අතුරුදහන් වූ දත්ත ගබඩා නෝඩ් වලින් කියවනු ලැබේ, දැනටමත් මතකයේ ඇති ඒවා සමඟ ඒකාබද්ධ කර ප්‍රති result ලය සේවාදායකයාට ලබා දේ.

මේ අනුව, සේවාදායකයාට තමන්ගේම වෙනස්කම් කියවිය හැකිය, නමුත් අනෙකුත් සේවාදායකයින්ට මෙම වෙනස්කම් නොපෙනේ, මන්ද ඒවා ගබඩා කර ඇත්තේ සම්බන්ධීකාරකගේ මතකයේ පමණි; ඒවා තවමත් කැසැන්ඩ්‍රා නෝඩ් වල නොමැත.

සේවාදායකයා කැපවීම යවන විට, සේවාවේ මතකයේ තිබූ තත්වය සම්බන්ධීකාරක විසින් ලොග් වූ කණ්ඩායමක සුරකින අතර, ලොග් වූ කණ්ඩායමක් ලෙස කැසැන්ඩ්‍රා ගබඩාවට යවනු ලැබේ. මෙම පැකේජය පරමාණුක වශයෙන් (සම්පූර්ණයෙන්ම) යෙදී ඇති බව සහතික කිරීමට අවශ්‍ය සෑම දෙයක්ම ගබඩා විසින් සිදු කරයි, සහ සම්බන්ධීකාරක වෙත ප්‍රතිචාරයක් ලබා දෙයි, ඔහු අගුලු මුදා හරින අතර ගනුදෙනුවේ සාර්ථකත්වය සේවාදායකයාට තහවුරු කරයි.

සහ ආපසු හැරවීමට, සම්බන්ධීකාරකවරයාට අවශ්‍ය වන්නේ ගණුදෙණු තත්ත්වය විසින් අල්ලාගෙන සිටින මතකය නිදහස් කිරීම පමණි.

ඉහත වැඩිදියුණු කිරීම් හේතුවෙන්, අපි ACID මූලධර්ම ක්‍රියාත්මක කළෙමු:

• පරමාණුකත්වය. පද්ධතිය තුළ කිසිදු ගනුදෙනුවක් අර්ධ වශයෙන් වාර්තා නොවන බවට මෙය සහතිකයකි; එක්කෝ එහි සියලුම උප මෙහෙයුම් සම්පූර්ණ කරනු ඇත, නැතහොත් කිසිවක් සම්පූර්ණ නොකරනු ඇත. කැසැන්ඩ්‍රා හි ලොග් කළ කණ්ඩායම හරහා අපි මෙම මූලධර්මය පිළිපදින්නෙමු.
• අනුකූලතාව. සෑම සාර්ථක ගනුදෙනුවක්ම, නිර්වචනය අනුව, වලංගු ප්රතිඵල පමණක් වාර්තා කරයි. ගනුදෙනුවක් විවෘත කර මෙහෙයුම් වලින් කොටසක් සිදු කිරීමෙන් පසුව, ප්රතිඵලය වලංගු නොවන බව අනාවරණය වුවහොත්, ආපසු හැරීමක් සිදු කරනු ලැබේ.
• ඒකලනය. ගනුදෙනුවක් සිදු කරන විට, සමගාමී ගනුදෙනු එහි ප්‍රතිඵලයට බල නොපායි. තරඟකාරී ගනුදෙනු සම්බන්ධීකාරකයේ අශුභවාදී අගුලු භාවිතයෙන් හුදකලා වේ. ගනුදෙනුවකින් පිටත කියවීම් සඳහා, හුදකලා මූලධර්මය කියවීම කැපවූ මට්ටමින් නිරීක්ෂණය කෙරේ.
• තිරසාර බව. පහත මට්ටම්වල ගැටළු නොතකා-පද්ධතිය අවහිර වීම, දෘඪාංග අසාර්ථක වීම- සාර්ථකව නිම කරන ලද ගනුදෙනුවකින් සිදු කරන ලද වෙනස්කම් මෙහෙයුම් නැවත ආරම්භ වන විට සංරක්ෂණය කළ යුතුය.

දර්ශක අනුව කියවීම

අපි සරල වගුවක් ගනිමු:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

එහි ID (ප්‍රාථමික යතුර), හිමිකරු සහ වෙනස් කිරීමේ දිනය ඇත. ඔබ ඉතා සරල ඉල්ලීමක් කළ යුතුය - "අවසන් දිනය සඳහා" වෙනස් කිරීමේ දිනය සමඟ හිමිකරු පිළිබඳ දත්ත තෝරන්න.

SELECT *
WHERE owner=?
AND modified>?

එවැනි විමසුමක් ඉක්මනින් ක්‍රියාවට නැංවීම සඳහා, සම්භාව්‍ය SQL DBMS තුළ ඔබට තීරු (හිමිකරු, වෙනස් කරන ලද) අනුව දර්ශකයක් ගොඩනගා ගත යුතුය. අපට දැන් ACID සහතික ඇති බැවින් අපට මෙය ඉතා පහසුවෙන් කළ හැකිය!

C* One හි දර්ශක

වාර්තා හැඳුනුම්පත මූලික යතුර වන ඡායාරූප සහිත මූලාශ්‍ර වගුවක් ඇත.

දර්ශකයක් සඳහා, C*One මුල් පිටපතේ පිටපතක් වන නව වගුවක් නිර්මාණය කරයි. යතුර දර්ශක ප්‍රකාශනයට සමාන වන අතර එයට මූලාශ්‍ර වගුවෙන් වාර්තාවේ ප්‍රාථමික යතුර ද ඇතුළත් වේ:

දැන් "අවසන් දිනය සඳහා හිමිකරු" සඳහා වන විමසුම වෙනත් වගුවකින් තෝරාගත් එකක් ලෙස නැවත ලිවිය හැක:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

මූලාශ්‍ර වගු ඡායාරූපවල සහ i1 දර්ශක වගුවේ දත්තවල අනුකූලතාව සම්බන්ධීකාරක විසින් ස්වයංක්‍රීයව පවත්වාගෙන යනු ලැබේ. දත්ත යෝජනා ක්‍රමය මත පදනම්ව, වෙනසක් ලැබුණු විට, සම්බන්ධීකාරක විසින් ප්‍රධාන වගුවේ පමණක් නොව, පිටපත්වලද වෙනසක් ජනනය කර ගබඩා කරයි. දර්ශක වගුවේ අමතර ක්‍රියා සිදු නොකෙරේ, ලඝු-සටහන් කියවා නැත, සහ අගුලු භාවිතා නොකෙරේ. එනම්, දර්ශක එකතු කිරීම සම්පත් පාහේ පරිභෝජනය නොකරන අතර වෙනස් කිරීම් යෙදීමේ වේගය කෙරෙහි ප්රායෝගිකව කිසිදු බලපෑමක් නැත.

ACID භාවිතයෙන්, අපට SQL වැනි දර්ශක ක්‍රියාත්මක කිරීමට හැකි විය. ඒවා ස්ථාවර, පරිමාණය කළ හැකි, වේගවත්, සංයුක්ත කළ හැකි සහ CQL විමසුම් භාෂාවට ගොඩනගා ඇත. දර්ශක සඳහා සහය දැක්වීමට යෙදුම් කේතයේ කිසිදු වෙනසක් අවශ්‍ය නොවේ. සෑම දෙයක්ම SQL හි මෙන් සරල ය. සහ වඩාත්ම වැදගත් දෙය නම්, මුල් ගනුදෙනු වගුවේ වෙනස් කිරීම් ක්‍රියාත්මක කිරීමේ වේගයට දර්ශක බලපාන්නේ නැත.

සිදුවුයේ කුමක් ද

අපි මීට වසර තුනකට පෙර C* One සංවර්ධනය කර එය වාණිජ මෙහෙයුම් සඳහා දියත් කළෙමු.

අවසානයේ අපට ලැබුණේ කුමක්ද? සමාජ ජාලයක වැදගත්ම දත්ත වර්ගවලින් එකක් වන ඡායාරූප සැකසුම් සහ ගබඩා උප පද්ධතියේ උදාහරණය භාවිතා කර මෙය ඇගයීමට ලක් කරමු. අපි කතා කරන්නේ ඡායාරූපවල සිරුරු ගැන නොව, සියලු වර්ගවල මෙටා තොරතුරු ගැන ය. දැන් Odnoklassniki සතුව එවැනි වාර්තා බිලියන 20 ක් පමණ ඇත, පද්ධතිය තත්පරයකට කියවීමේ ඉල්ලීම් 80 ක්, දත්ත වෙනස් කිරීම හා සම්බන්ධ තත්පරයකට ACID ගනුදෙනු 8 ක් දක්වා ක්‍රියා කරයි.

අපි අනුකරණ සාධකය = 1 සමඟ SQL භාවිතා කළ විට (නමුත් RAID 10 හි), ඡායාරූප metainformation ගබඩා කර ඇත්තේ Microsoft SQL Server (එමෙන්ම 32 උපස්ථ) ධාවනය වන යන්ත්‍ර 11 ක ඉතා ඉහළ පොකුරක් මත ය. උපස්ථ ගබඩා කිරීම සඳහා සේවාදායක 10 ක් ද වෙන් කරන ලදී. මිල අධික මෝටර් රථ 50 ක්. ඒ අතරම, පද්ධතිය සංචිතයකින් තොරව ශ්‍රේණිගත බරකින් ක්‍රියාත්මක විය.

නව පද්ධතියට සංක්‍රමණය වීමෙන් පසුව, අපට ප්‍රතිවර්තන සාධකය = 3 - එක් එක් දත්ත මධ්‍යස්ථානයේ පිටපතක් ලැබුණි. පද්ධතිය Cassandra ගබඩා නෝඩ් 63 කින් සහ සම්බන්ධීකාරක යන්ත්‍ර 6 කින් සමන්විත වන අතර, සම්පූර්ණ සේවාදායක 69 ක් ඇත. නමුත් මෙම යන්ත්‍ර බෙහෙවින් ලාභදායී වේ, ඒවායේ මුළු පිරිවැය SQL පද්ධතියක පිරිවැයෙන් 30% ක් පමණ වේ. ඒ සමගම, බර 30% ක් තබා ඇත.

C*One හඳුන්වාදීමත් සමඟ ප්‍රමාදය ද අඩු විය: SQL හි, ලිවීමේ මෙහෙයුමක් ms 4,5 ක් පමණ ගත විය. C* One හි - 1,6 ms පමණ. ගනුදෙනු කාලසීමාව සාමාන්‍යයෙන් 40 ms ට වඩා අඩුය, කැපවීම 2 ms කින් අවසන් වේ, කියවීමේ සහ ලිවීමේ කාලය සාමාන්‍යයෙන් 2 ms වේ. 99 වැනි ප්‍රතිශතය - 3-3,1 ms පමණි, කාල සීමාවන් ගණන 100 ගුණයකින් අඩු වී ඇත - සියල්ල සමපේක්ෂනයේ පුලුල් භාවිතය නිසා.

මේ වන විට, SQL Server nodes බොහොමයක් ඉවත් කර ඇත; C*One භාවිතයෙන් පමණක් නව නිෂ්පාදන සංවර්ධනය වෙමින් පවතී. අපි C* One අපගේ වලාකුළෙහි වැඩ කිරීමට අනුවර්තනය කළෙමු එක්-වලාකුළු, එමඟින් නව පොකුරු යෙදවීම වේගවත් කිරීමට, වින්‍යාසය සරල කිරීමට සහ ක්‍රියාකාරිත්වය ස්වයංක්‍රීය කිරීමට හැකි විය. මූලාශ්‍ර කේතය නොමැතිව, මෙය කිරීම වඩාත් අපහසු සහ අපහසු වනු ඇත.

දැන් අපි අපගේ අනෙකුත් ගබඩා පහසුකම් වලාකුළට මාරු කිරීමට කටයුතු කරමින් සිටිමු - නමුත් එය සම්පූර්ණයෙන්ම වෙනස් කතාවකි.

මූලාශ්රය: www.habr.com