ආයුබෝවන් සියල්ලටම! මගේ නම Golov Nikolay. මීට පෙර, මම Avito හි සේවය කර වසර හයක් දත්ත වේදිකාව කළමනාකරණය කළෙමි, එනම්, මම සියලුම දත්ත සමුදායන් මත වැඩ කළෙමි: විශ්ලේෂණ (Vertica, ClickHouse), streaming සහ OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). මෙම කාලය තුළ, මම දත්ත සමුදායන් විශාල සංඛ්යාවක් සමඟ කටයුතු කළෙමි - ඉතා වෙනස් සහ අසාමාන්ය, සහ ඒවායේ භාවිතයේ සම්මත නොවන අවස්ථා සමඟ.
මම දැනට ManyChat හි වැඩ කරනවා. සාරාංශයක් ලෙස, මෙය ආරම්භයකි - නව, අභිලාෂකාමී සහ වේගයෙන් වර්ධනය වේ. මම මුලින්ම සමාගමට සම්බන්ධ වූ විට, සම්භාව්ය ප්‍රශ්නයක් මතු විය: “තරුණ ආරම්භයක් දැන් DBMS සහ දත්ත සමුදා වෙළඳපොලෙන් ගත යුත්තේ කුමක්ද?”
මෙම ලිපියේ, මගේ වාර්තාව මත පදනම්ව , මම මේ ප්‍රශ්නයට උත්තර දෙන්නම්. වාර්තාවේ වීඩියෝ අනුවාදයක් මෙහි ඇත .
පොදුවේ දන්නා දත්ත සමුදායන් 2020
එය 2020, මම වටපිට බැලූ විට දත්ත සමුදායන් වර්ග තුනක් දුටුවෙමි.
පළමු වර්ගය - සම්භාව්ය OLTP දත්ත සමුදායන්: PostgreSQL, SQL Server, Oracle, MySQL. ඒවා බොහෝ කලකට පෙර ලියා ඇත, නමුත් ඒවා සංවර්ධක ප්‍රජාවට ඉතා හුරුපුරුදු බැවින් තවමත් අදාළ වේ.
දෙවන වර්ගය - "ශුන්‍ය" සිට පදනම්. ඔවුන් SQL, සාම්ප්‍රදායික ව්‍යුහයන් සහ ACID අතහැර දමා, බිල්ට්-ඉන් ෂර්ඩිං සහ වෙනත් ආකර්ශනීය අංග එකතු කිරීමෙන් සම්භාව්ය රටා වලින් ඉවත් වීමට උත්සාහ කළහ. උදාහරණයක් ලෙස, මෙය Cassandra, MongoDB, Redis හෝ Tarantool වේ. මෙම සියලු විසඳුම් වෙළඳපලට මූලික වශයෙන් අලුත් දෙයක් ඉදිරිපත් කිරීමට අවශ්‍ය වූ අතර ඒවා යම් යම් කාර්යයන් සඳහා අතිශයින්ම පහසු වූ නිසා ඒවායේ ස්ථානය අත්පත් කර ගත්තේය. මම මෙම දත්ත සමුදායන් NOSQL යන කුඩ පදය සමඟින් දක්වන්නෙමි.
“ශුන්‍ය” අවසන්, අපි NOSQL දත්ත සමුදායට පුරුදු වී සිටි අතර, ලෝකය, මගේ දෘෂ්ටි කෝණයෙන්, ඊළඟ පියවර ගත්තේය - කළමනාකරණය කළ දත්ත සමුදායන්. මෙම දත්ත සමුදායන් සම්භාව්ය OLTP දත්ත සමුදායන් හෝ නව NoSQL දත්ත සමුදායන් හා සමාන හරය ඇත. නමුත් ඔවුන්ට DBA සහ DevOps සඳහා අවශ්‍යතාවයක් නොමැති අතර වලාකුළු තුළ කළමනාකරණය කරන ලද දෘඩාංග මත ධාවනය වේ. සංවර්ධකයෙකු සඳහා, මෙය කොතැනක හෝ ක්රියාත්මක වන “පමණක් පදනමක්” වේ, නමුත් එය සේවාදායකයේ ස්ථාපනය කරන්නේ කෙසේද, සේවාදායකය වින්‍යාස කළේ කවුද සහ එය යාවත්කාලීන කරන්නේ කවුරුන්ද යන්න කිසිවෙකු ගණන් ගන්නේ නැත.
එවැනි දත්ත සමුදායන් සඳහා උදාහරණ:
- AWS RDS යනු PostgreSQL/MySQL සඳහා කළමනා කරන ලද එතුමකි.
- DynamoDB යනු Redis සහ MongoDB වලට සමාන ලේඛන පදනම් කරගත් දත්ත ගබඩාවක AWS ප්‍රතිසමයකි.
- Amazon Redshift යනු කළමනාකරණය කළ විශ්ලේෂණ දත්ත ගබඩාවකි.
මේවා මූලික වශයෙන් පැරණි දත්ත සමුදායන් වන නමුත් දෘඩාංග සමඟ වැඩ කිරීමේ අවශ්‍යතාවයකින් තොරව කළමනාකරණය කළ පරිසරයක් තුළ ඇති කර ඇත.
සටහන. උදාහරණ AWS පරිසරය සඳහා ගෙන ඇත, නමුත් ඒවායේ ප්‍රතිසමයන් Microsoft Azure, Google Cloud, හෝ Yandex.Cloud හි ද පවතී.
මේ ගැන අලුත් තොරතුරු මොනවාද? 2020 දී, මේ කිසිවක් නැත.
සේවාදායකය රහිත සංකල්පය
2020 දී වෙළඳපොලේ ඇත්ත වශයෙන්ම අලුත් දෙය නම් සේවාදායකය රහිත හෝ සේවාදායක රහිත විසඳුම් ය.
සාමාන්‍ය සේවාවක හෝ පසුපෙළ යෙදුමක උදාහරණය භාවිතයෙන් මෙයින් අදහස් කරන්නේ කුමක්ද යන්න පැහැදිලි කිරීමට මම උත්සාහ කරමි.
සාමාන්‍ය පසුබිම් යෙදුමක් යෙදවීමට, අපි සේවාදායකයක් මිල දී ගන්නෙමු හෝ කුලියට ගනිමු, කේතය එයට පිටපත් කරන්නෙමු, අන්ත ලක්ෂ්‍යය පිටත ප්‍රකාශ කරන්නෙමු සහ කුලී, විදුලිය සහ දත්ත මධ්‍යස්ථාන සේවා සඳහා නිතිපතා ගෙවන්නෙමු. මෙය සම්මත යෝජනා ක්රමයයි.
වෙනත් මාර්ගයක් තිබේද? සේවාදායක රහිත සේවාවන් සමඟ ඔබට හැක.
මෙම ප්‍රවේශයේ අවධානය කුමක්ද: සේවාදායකයක් නොමැත, වලාකුළෙහි අථත්‍ය අවස්ථාවක් කුලියට ගැනීම පවා නොමැත. සේවාව යෙදවීම සඳහා, කේතය (කාර්යයන්) ගබඩාවට පිටපත් කර එය අවසන් ස්ථානයට ප්රකාශයට පත් කරන්න. එවිට අපි මෙම කාර්යය සඳහා එක් එක් ඇමතුම සඳහා සරලව ගෙවන්නෙමු, එය ක්රියාත්මක වන දෘඪාංග සම්පූර්ණයෙන්ම නොසලකා හරිමු.
මම මෙම ප්රවේශය පින්තූර සමඟ නිරූපණය කිරීමට උත්සාහ කරමි.
සම්භාව්ය යෙදවීම. අපට යම් බරක් සහිත සේවාවක් තිබේ. අපි අවස්ථා දෙකක් මතු කරමු: භෞතික සේවාදායකයන් හෝ AWS හි අවස්ථා. බාහිර ඉල්ලීම් මෙම අවස්ථා වෙත යවා එහි සකසනු ලැබේ.
පින්තූරයේ ඔබට පෙනෙන පරිදි, සේවාදායකයන් සමානව බැහැර නොකෙරේ. එකක් 100% භාවිතා කර ඇත, ඉල්ලීම් දෙකක් ඇත, එකක් 50% ක් පමණි - අර්ධ වශයෙන් අක්‍රියයි. ඉල්ලීම් තුනක් නොවේ නම්, නමුත් 30, එවිට සම්පූර්ණ පද්ධතියට බර සමඟ සාර්ථකව කටයුතු කිරීමට නොහැකි වනු ඇති අතර මන්දගාමී වීමට පටන් ගනී.
සේවාදායක රහිත යෙදවීම. සේවාදායකයක් නොමැති පරිසරයක් තුළ, එවැනි සේවාවක් සඳහා අවස්ථා හෝ සේවාදායකයන් නොමැත. රත් වූ සම්පත් වල නිශ්චිත සංචිතයක් ඇත - යොදන ලද ක්රියාකාරී කේතය සහිත කුඩා සකස් කරන ලද ඩොකර් බහාලුම්. පද්ධතියට බාහිර ඉල්ලීම් ලැබෙන අතර ඒ සෑම එකක් සඳහාම සේවාදායකය රහිත රාමුව කේතය සහිත කුඩා බහාලුමක් මතු කරයි: එය මෙම විශේෂිත ඉල්ලීම ක්‍රියාවට නංවා කන්ටේනරය මරා දමයි.
එක් ඉල්ලීමක් - එක් කන්ටේනරයක් ඉහළට, ඉල්ලීම් 1000 ක් - බහාලුම් 1000 ක්. තවද දෘඪාංග සේවාදායකයන් මත යෙදවීම දැනටමත් වලාකුළු සපයන්නාගේ කාර්යයකි. එය සර්වර් රහිත රාමුව මගින් සම්පූර්ණයෙන්ම සඟවා ඇත. මෙම සංකල්පය තුළ අපි සෑම ඇමතුමක් සඳහාම ගෙවන්නෙමු. උදාහරණයක් ලෙස, දිනකට එක් ඇමතුමක් පැමිණියේය - අපි එක් ඇමතුමකට ගෙවා, විනාඩියකට මිලියනයක් ආවා - අපි මිලියනයකට ගෙවමු. නැත්නම් තත්පරයකින් මේකත් වෙනවා.
සේවාදායක රහිත ශ්‍රිතයක් ප්‍රකාශනය කිරීමේ සංකල්පය රාජ්‍ය රහිත සේවාවක් සඳහා සුදුසු වේ. ඔබට (රාජ්‍ය) රාජ්‍ය පූර්ණ සේවාවක් අවශ්‍ය නම්, අපි සේවාවට දත්ත සමුදායක් එක් කරන්නෙමු. මෙම අවස්ථාවෙහිදී, රාජ්‍යය සමඟ වැඩ කිරීමේදී, එක් එක් රාජ්‍ය පූර්ණ ශ්‍රිතය දත්ත සමුදායෙන් ලිවීම සහ කියවීම සරලව සිදු කරයි. එපමණක් නොව, ලිපියේ ආරම්භයේ විස්තර කර ඇති වර්ග තුනෙන් ඕනෑම දත්ත ගබඩාවකින්.
මෙම සියලු දත්ත සමුදායන් වල පොදු සීමාව කුමක්ද? මේවා නිරන්තරයෙන් භාවිතා කරන ක්ලවුඩ් හෝ දෘඪාංග සේවාදායකයක (හෝ සේවාදායක කිහිපයක) පිරිවැය වේ. අපි සම්භාව්ය හෝ කළමනාකරණය කළ දත්ත සමුදායක් භාවිතා කළත්, අපට Devops සහ පරිපාලකයෙකු සිටියත් නැතත්, අපි තවමත් දෘඩාංග, විදුලිය සහ දත්ත මධ්‍යස්ථාන කුලියට 24/7 ගෙවන්නෙමු. අපට සම්භාව්ය පදනමක් තිබේ නම්, අපි ස්වාමියා සහ වහලුන් සඳහා ගෙවන්නෙමු. එය අධික ලෙස පටවන ලද ෂර්ඩ් දත්ත ගබඩාවක් නම්, අපි සේවාදායක 10, 20 හෝ 30 සඳහා ගෙවන අතර, අපි නිරන්තරයෙන් ගෙවන්නෙමු.
පිරිවැය ව්‍යුහය තුළ ස්ථිරවම වෙන් කර ඇති සේවාදායකයන් තිබීම අත්‍යවශ්‍ය නපුරක් ලෙස කලින් හඳුනාගෙන ඇත. සාම්ප්‍රදායික දත්ත සමුදායන් හට සම්බන්ධතා සංඛ්‍යාවේ සීමාවන්, පරිමාණ සීමා කිරීම්, භූ-බෙදාහැරුණු සම්මුතිය වැනි වෙනත් දුෂ්කරතා ද ඇත - ඒවා කෙසේ හෝ ඇතැම් දත්ත සමුදායන් තුළ විසඳිය හැකි නමුත්, එකවර නොව ඉතා මැනවින් නොවේ.
සේවාදායක රහිත දත්ත සමුදාය - න්‍යාය
2020 ප්‍රශ්නය: දත්ත සමුදායක් සර්වර් රහිත බවට පත් කළ හැකිද? serverless backend එක ගැන හැමෝම අහල ඇතිනේ... database serverless කරන්න බලමුද?
මෙය අමුතු දෙයක් ලෙස පෙනේ, මන්ද දත්ත සමුදාය රාජ්‍ය පූර්ණ සේවාවක් වන අතර සේවාදායක රහිත යටිතල පහසුකම් සඳහා එතරම් සුදුසු නොවේ. ඒ අතරම, දත්ත සමුදායේ තත්වය ඉතා විශාල වේ: ගිගාබයිට්, ටෙරාබයිට් සහ විශ්ලේෂණාත්මක දත්ත සමුදාය තුළ පෙටාබයිට් පවා. සැහැල්ලු ඩොකර් බහාලුම්වල එය නැංවීම එතරම් පහසු නැත.
අනෙක් අතට, සෑම නවීන දත්ත සමුදායකම පාහේ තාර්කික සහ සංරචක විශාල ප්‍රමාණයක් අඩංගු වේ: ගනුදෙනු, අඛණ්ඩතාව සම්බන්ධීකරණය, ක්රියා පටිපාටි, සම්බන්ධතා පරායත්තතා සහ බොහෝ තර්ක. බොහෝ දත්ත සමුදා තර්කනය සඳහා, කුඩා තත්වයක් ප්රමාණවත්ය. ගිගාබයිට් සහ ටෙරාබයිට් සෘජුවම භාවිතා කරන්නේ විමසුම් සෘජුවම ක්රියාත්මක කිරීමට සම්බන්ධ දත්ත සමුදා තර්කනයේ කුඩා කොටසකි.
ඒ අනුව, අදහස වන්නේ: තර්කයේ කොටසක් රාජ්‍ය රහිත ක්රියාත්මක කිරීමට ඉඩ දෙන්නේ නම්, පදනම රාජ්‍ය හා අස්ථායී කොටස්වලට බෙදන්නේ නැත්තේ ඇයි?
OLAP විසඳුම් සඳහා සේවාදායකය රහිත
ප්‍රායෝගික උදාහරණ භාවිතා කරමින් දත්ත සමුදායක් Stateful සහ Stateless කොටස් වලට කැපීම කෙබඳුදැයි බලමු.
උදාහරණයක් ලෙස, අපට විශ්ලේෂණාත්මක දත්ත සමුදායක් ඇත: බාහිර දත්ත (වමේ රතු සිලින්ඩරය), දත්ත සමුදාය වෙත දත්ත පූරණය කරන ETL ක්‍රියාවලියක් සහ දත්ත සමුදාය වෙත SQL විමසුම් යවන විශ්ලේෂකයෙකි. මෙය සම්භාව්ය දත්ත ගබඩා මෙහෙයුම් යෝජනා ක්‍රමයකි.
මෙම යෝජනා ක්රමය තුළ, ETL එක් වරක් කොන්දේසි සහිතව සිදු කරනු ලැබේ. එවිට ETL පුරවා ඇති දත්ත සමඟ දත්ත සමුදාය ක්රියාත්මක වන සේවාදායකයන් සඳහා ඔබ නිරන්තරයෙන් ගෙවිය යුතුය, එවිට විමසුම් යැවීමට යමක් තිබේ.
AWS Athena Serverless හි ක්රියාත්මක කරන ලද විකල්ප ප්රවේශයක් දෙස බලමු. බාගත කළ දත්ත ගබඩා කර ඇති ස්ථිරවම කැප වූ දෘඪාංග නොමැත. මේ වෙනුවට:
- පරිශීලකයා Athena වෙත SQL විමසුමක් ඉදිරිපත් කරයි. Athena optimizer SQL විමසුම විශ්ලේෂණය කරන අතර විමසුම ක්රියාත්මක කිරීමට අවශ්‍ය නිශ්චිත දත්ත සඳහා පාරදත්ත ගබඩාව (Metadata) සොයයි.
- ප්‍රශස්තකරණය, එකතු කරන ලද දත්ත මත පදනම්ව, අවශ්‍ය දත්ත බාහිර මූලාශ්‍රවලින් තාවකාලික ගබඩාවට (තාවකාලික දත්ත ගබඩාව) බාගත කරයි.
- පරිශීලකයාගෙන් SQL විමසුමක් තාවකාලික ආචයනය තුළ ක්රියාත්මක වන අතර ප්රතිඵලය පරිශීලකයා වෙත ලබා දෙනු ලැබේ.
- තාවකාලික ගබඩාව ඉවත් කර සම්පත් මුදා හරිනු ලැබේ.
මෙම ගෘහ නිර්මාණ ශිල්පය තුළ, අපි ඉල්ලීම ක්රියාත්මක කිරීමේ ක්රියාවලිය සඳහා පමණක් ගෙවන්නෙමු. ඉල්ලීම් නැත - වියදම් නැත.
මෙය ක්රියාකාරී ප්රවේශයක් වන අතර Athena Serverless හි පමණක් නොව, Redshift Spectrum (AWS හි) ක්රියාත්මක වේ.
Athena උදාහරණයෙන් පෙන්නුම් කරන්නේ Serverless දත්ත සමුදාය දස සහ ටෙරාබයිට් සිය ගණනක දත්ත සහිත සැබෑ විමසුම් මත ක්රියා කරන බවයි. ටෙරාබයිට් සිය ගණනකට සේවාදායකයන් සිය ගණනක් අවශ්‍ය වනු ඇත, නමුත් අපට ඒවා සඳහා ගෙවීමට අවශ්‍ය නැත - අපි ඉල්ලීම් සඳහා ගෙවන්නෙමු. Vertica වැනි විශේෂිත විශ්ලේෂණ දත්ත සමුදායන් හා සසඳන විට එක් එක් ඉල්ලීමේ වේගය (ඉතා) අඩුය, නමුත් අපි අක්‍රීය කාල සීමාවන් සඳහා ගෙවන්නේ නැත.
එවැනි දත්ත සමුදායක් දුර්ලභ විශ්ලේෂණාත්මක තාවකාලික විමසුම් සඳහා අදාළ වේ. උදාහරණයක් ලෙස, අපි ස්වයංසිද්ධව යම් යෝධ දත්ත ප්‍රමාණයක් මත උපකල්පනයක් පරීක්ෂා කිරීමට තීරණය කරන විට. මෙම අවස්ථා සඳහා Athena පරිපූර්ණයි. නිතිපතා ඉල්ලීම් සඳහා, එවැනි පද්ධතියක් මිල අධික වේ. මෙම අවස්ථාවේදී, යම් විශේෂිත විසඳුමක් තුළ දත්ත හැඹිලිගත කරන්න.
OLTP විසඳුම් සඳහා සේවාදායකය රහිත
පෙර උදාහරණය OLAP (විශ්ලේෂණාත්මක) කාර්යයන් දෙස බලයි. දැන් අපි බලමු OLTP කාර්යයන්.
පරිමාණය කළ හැකි PostgreSQL හෝ MySQL සිතමු. අපි අවම සම්පත් සමඟ නිතිපතා කළමනාකරණය කරන ලද PostgreSQL හෝ MySQL මතු කරමු. අවස්ථාවට වැඩි බරක් ලැබෙන විට, අපි කියවීමේ බරෙන් කොටසක් බෙදා හරින අමතර අනුපිටපත් සම්බන්ධ කරමු. ඉල්ලීම් හෝ පැටවීමක් නොමැති නම්, අපි අනුපිටපත් නිවා දමමු. පළමු අවස්ථාව ස්වාමියා වන අතර ඉතිරිය අනුරූ වේ.
මෙම අදහස Aurora Serverless AWS නම් දත්ත සමුදාය තුළ ක්රියාත්මක වේ. මූලධර්මය සරලයි: බාහිර යෙදුම් වලින් ඉල්ලීම් ප්‍රොක්සි බලඇණිය විසින් පිළිගනු ලැබේ. බර වැඩිවීම දැකීමෙන්, එය පෙර-උණුසුම් කළ අවම අවස්ථාවන්ගෙන් පරිගණක සම්පත් වෙන් කරයි - සම්බන්ධතාවය හැකි ඉක්මනින් සිදු කෙරේ. ආබාධිත අවස්ථා එකම ආකාරයකින් සිදු වේ.
Aurora තුළ Aurora Capacity Unit, ACU යන සංකල්පය ඇත. මෙය (කොන්දේසි සහිතව) උදාහරණයක් (සේවාදායකය) වේ. එක් එක් විශේෂිත ACU ස්වාමියෙකු හෝ වහලෙකු විය හැකිය. සෑම ධාරිතා ඒකකයකටම තමන්ගේම RAM, ප්‍රොසෙසරය සහ අවම තැටිය ඇත. ඒ අනුව, එකක් මාස්ටර්, ඉතිරිය කියවන්නේ අනුරූ පමණි.
මෙම Aurora Capacity Units ක්රියාත්මක වන සංඛ්‍යාව වින්‍යාස කළ හැකි පරාමිතියකි. අවම ප්රමාණය එකක් හෝ ශුන්‍ය විය හැකිය (මෙම අවස්ථාවේදී, ඉල්ලීම් නොමැති නම් දත්ත සමුදාය ක්රියා නොකරයි).
පදනමට ඉල්ලීම් ලැබුණු විට, ප්‍රොක්සි සමූහය Aurora CapacityUnits ඉහළ නංවයි, පද්ධතියේ කාර්ය සාධන සම්පත් වැඩි කරයි. සම්පත් වැඩි කිරීමට සහ අඩු කිරීමට ඇති හැකියාව පද්ධතියට සම්පත් "ජංගල්" කිරීමට ඉඩ සලසයි: ස්වයංක්‍රීයව තනි ACU (ඒවා නව ඒවා සමඟ ප්‍රතිස්ථාපනය කිරීම) සහ ඉවත් කරන ලද සම්පත් වෙත සියලුම වත්මන් යාවත්කාලීන කිරීම් ප්‍රචාරණය කරයි.
Aurora Serverless පදනමට කියවීමේ බර පරිමාණය කළ හැක. නමුත් ලේඛනවල මෙය සෘජුව පවසන්නේ නැත. ඔවුන්ට බහු-මාස්ටර් ඔසවා තැබිය හැකි බව හැඟෙන්නට පුළුවන. මායාවක් නැත.
අනපේක්ෂිත ප්රවේශයක් සහිත පද්ධති සඳහා විශාල මුදල් ප්‍රමාණයක් වැය නොකිරීමට මෙම දත්ත සමුදාය හොඳින් ගැලපේ. උදාහරණයක් ලෙස, MVP නිර්මාණය කිරීමේදී හෝ ව්‍යාපාරික කාඩ්පත් අඩවි අලෙවි කිරීමේදී, අපි සාමාන්යයෙන් ස්ථාවර බරක් අපේක්ෂා නොකරමු. ඒ අනුව, ප්රවේශයක් නොමැති නම්, අපි අවස්ථා සඳහා ගෙවන්නේ නැත. අනපේක්ෂිත පැටවීමක් සිදු වූ විට, උදාහරණයක් ලෙස සම්මන්ත්‍රණයකින් හෝ වෙළඳ ප්‍රචාරණ ව්‍යාපාරයකින් පසුව, විශාල පිරිසක් වෙබ් අඩවියට පැමිණෙන අතර බර නාටකාකාර ලෙස වැඩි වේ, Aurora Serverless ස්වයංක්‍රීයව මෙම භාරය ගෙන ඉක්මනින් නැතිවූ සම්පත් (ACU) සම්බන්ධ කරයි. එවිට සම්මන්ත්‍රණය සමත් වේ, සෑම කෙනෙකුටම මූලාකෘතිය අමතක වේ, සේවාදායකයන් (ACU) අඳුරු වේ, සහ පිරිවැය බිංදුවට වැටේ - පහසුය.
මෙම විසඳුම ලිඛිත බර පරිමාණය නොකරන නිසා ස්ථායී හයිලෝඩ් සඳහා සුදුසු නොවේ. මෙම සියලු සම්බන්ධතා සහ සම්පත් විසන්ධි කිරීම් සිදු වන්නේ ඊනියා "පරිමාණ ලක්ෂ්‍යයේ" - දත්ත සමුදාය ගනුදෙනුවක් හෝ තාවකාලික වගු මගින් සහාය නොදක්වන කාලයකි. උදාහරණයක් ලෙස, සතියක් ඇතුළත පරිමාණ ලක්ෂ්‍යය සිදු නොවිය හැකි අතර, පදනම එකම සම්පත් මත ක්රියා කරන අතර සරලව පුළුල් කිරීමට හෝ හැකිලීමට නොහැකිය.
මැජික් නොමැත - එය සාමාන්‍ය PostgreSQL ය. නමුත් යන්ත්‍ර එකතු කිරීම සහ ඒවා විසන්ධි කිරීමේ ක්රියාවලිය අර්ධ වශයෙන් ස්වයංක්‍රීය වේ.
නිර්මාණය අනුව සේවාදායකය රහිත
Aurora Serverless යනු Serverless හි සමහර ප්‍රතිලාභ වලින් ප්‍රයෝජන ගැනීම සඳහා Cloud සඳහා නැවත ලියන ලද පැරණි දත්ත සමුදායකි. සේවාදායකය රහිත ප්රවේශය සඳහා මුලින් වලාකුළු සඳහා ලියා ඇති පදනම ගැන දැන් මම ඔබට කියමි - Serverless-by-design. එය භෞතික සේවාදායකයන් මත ක්රියාත්මක වේ යැයි උපකල්පනය නොකර එය වහාම සංවර්ධනය කරන ලදී.
මෙම පදනම හිම පියල්ල ලෙස හැඳින්වේ. එය ප්රධාන කොටස් තුනක් ඇත.
පළමුවැන්න පාරදත්ත බ්ලොක් එකකි. මෙය ආරක්‍ෂාව, පාරදත්ත, ගනුදෙනු සහ විමසුම් ප්‍රශස්තකරණය (වමේ ඇති නිදර්ශනයේ පෙන්වා ඇති) සමඟ ගැටලු විසඳන වේගවත් මතක සේවාවකි.
දෙවන කොටස ගණනය කිරීම් සඳහා අතථ්‍ය පරිගණන පොකුරු සමූහයකි (නිදර්ශනයේ නිල් කව කට්ටලයක් ඇත).
තුන්වන කොටස S3 මත පදනම් වූ දත්ත ගබඩා පද්ධතියකි. S3 යනු AWS හි මාන රහිත වස්තු ගබඩාවකි, ව්‍යාපාර සඳහා මාන රහිත Dropbox වැනි.
සීතල ආරම්භයක් උපකල්පනය කරමින් හිම පියල්ල ක්රියා කරන්නේ කෙසේදැයි බලමු. එනම්, දත්ත සමුදායක් ඇත, දත්ත එයට පටවනු ලැබේ, ධාවන විමසුම් නොමැත. ඒ අනුව, දත්ත සමුදායට ඉල්ලීම් නොමැති නම්, අපි වේගයෙන් මතකයේ ඇති පාර-දත්ත සේවාව (පළමු කොටස) මතු කර ඇත. තවද අපට S3 ආචයනය ඇත, එහිදී වගු දත්ත ගබඩා කර ඇත, ඊනියා micropartition වලට බෙදා ඇත. සරල බව සඳහා: වගුවේ ගනුදෙනු තිබේ නම්, ක්ෂුද්‍ර කොටස් යනු ගනුදෙනු වල දින වේ. හැමදාම වෙනම micropartition එකක්, වෙනම file එකක්. තවද දත්ත සමුදාය මෙම ප්‍රකාරයේදී ක්රියාත්මක වන විට, ඔබ ගෙවන්නේ දත්ත විසින් අල්ලාගෙන සිටින ඉඩ සඳහා පමණි. එපමණක් නොව, ආසනයකට අනුපාතය ඉතා අඩුය (විශේෂයෙන් සැලකිය යුතු සම්පීඩනය සැලකිල්ලට ගනිමින්). පාරදත්ත සේවාව ද නිරන්තරයෙන් ක්රියා කරයි, නමුත් විමසුම් ප්‍රශස්ත කිරීමට ඔබට විශාල සම්පත් අවශ්‍ය නොවන අතර, සේවාව shareware ලෙස සැලකිය හැකිය.
දැන් අපි හිතමු පරිශීලකයෙක් අපේ දත්ත ගබඩාවට ඇවිත් SQL විමසුමක් යැව්වා කියලා. SQL විමසුම වහාම සැකසීම සඳහා පාරදත්ත සේවාව වෙත යවනු ලැබේ. ඒ අනුව, ඉල්ලීමක් ලැබීමෙන් පසු, මෙම සේවාව ඉල්ලීම, පවතින දත්ත, පරිශීලක අවසරයන් විශ්ලේෂණය කරන අතර, සියල්ල හොඳින් නම්, ඉල්ලීම සැකසීම සඳහා සැලැස්මක් සකස් කරයි.
ඊළඟට, සේවාව පරිගණක පොකුරේ දියත් කිරීම ආරම්භ කරයි. පරිගණක පොකුරක් යනු ගණනය කිරීම් සිදු කරන සේවාදායක සමූහයකි. එනම්, මෙය ඔබට අවශ්‍ය ප්‍රමාණයට සර්වර් 1ක්, සර්වර් 2ක්, 4, 8, 16, 32 අඩංගු විය හැකි පොකුරකි. ඔබ ඉල්ලීමක් විසි කරන අතර මෙම පොකුරේ දියත් කිරීම වහාම ආරම්භ වේ. ඇත්තටම තත්පර ගානක් යනවා.
ඊළඟට, පොකුර ආරම්භ වූ පසු, ඔබේ ඉල්ලීම සැකසීමට අවශ්‍ය මයික්‍රොපාටිෂන් S3 වෙතින් පොකුරට පිටපත් කිරීමට පටන් ගනී. එනම්, SQL විමසුමක් ක්රියාත්මක කිරීමට ඔබට එක් වගුවකින් කොටස් දෙකක් සහ දෙවන කොටසින් කොටස් දෙකක් අවශ්‍ය වේ යැයි සිතමු. මෙම අවස්ථාවේදී, අවශ්‍ය කොටස් තුන පමණක් පොකුරට පිටපත් කරනු ලබන අතර, සියලුම වගු සම්පූර්ණයෙන්ම නොවේ. එබැවින්, හරියටම සෑම දෙයක්ම එක් දත්ත මධ්‍යස්ථානයක් තුළ පිහිටා ඇති අතර ඉතා වේගවත් නාලිකා මගින් සම්බන්ධ වී ඇති නිසා, සම්පූර්ණ හුවමාරු ක්රියාවලිය ඉතා ඉක්මනින් සිදු වේ: තත්පර කිහිපයකින්, ඉතා කලාතුරකින් මිනිත්තු කිහිපයකින්, අපි සමහර බිහිසුණු ඉල්ලීම් ගැන කතා කරන්නේ නම් මිස . ඒ අනුව, ක්ෂුද්‍ර කොටස් පරිගණක පර්ෂදයට පිටපත් කරනු ලබන අතර, අවසන් වූ පසු, SQL විමසුම මෙම පරිගණක පොකුර මත ක්රියාත්මක වේ. මෙම ඉල්ලීමේ ප්රතිඵලය එක් පේළියක්, පේළි කිහිපයක් හෝ වගුවක් විය හැක - ඒවා පරිශීලකයාට බාගැනීමට, ඔහුගේ BI මෙවලමෙහි ප්‍රදර්ශනය කිරීමට හෝ වෙනත් ආකාරයකින් භාවිතා කිරීමට හැකි වන පරිදි බාහිරව යවනු ලැබේ.
සෑම SQL විමසුමකටම කලින් පටවන ලද දත්තවල එකතු කිරීම් කියවීමට පමණක් නොව, දත්ත සමුදායේ නව දත්ත පැටවීමට/ජනනය කිරීමටද හැකිය. එනම්, එය විමසුමක් විය හැකිය, උදාහරණයක් ලෙස, වෙනත් වගුවකට නව වාර්තා ඇතුළත් කරන අතර, එය පරිගණක පොකුරේ නව කොටසක් දිස්වීමට තුඩු දෙයි, එය ස්වයංක්‍රීයව තනි S3 ගබඩාවක සුරකිනු ලැබේ.
ඉහත විස්තර කර ඇති දර්ශනය, පරිශීලකයාගේ පැමිණීමේ සිට පොකුර ඉහළ නැංවීම, දත්ත පැටවීම, විමසුම් ක්රියාත්මක කිරීම, ප්‍රතිඵල ලබා ගැනීම දක්වා, ඉහළ නැංවූ අතථ්‍ය පරිගණක පොකුර, අතථ්‍ය ගබඩාව භාවිතා කිරීමේ අනුපාතයට මිනිත්තු ගණනක් ගෙවනු ලැබේ. AWS කලාපය සහ පොකුරු ප්රමාණය අනුව අනුපාතය වෙනස් වේ, නමුත් සාමාන්යයෙන් එය පැයකට ඩොලර් කිහිපයක් වේ. යන්ත්‍ර හතරක පොකුරක් යන්ත්‍ර දෙකක පොකුරක් මෙන් දෙගුණයක් මිල අධික වන අතර යන්ත්‍ර අටකින් යුත් පොකුරක් තවමත් දෙගුණයක් මිල අධික වේ. ඉල්ලීම්වල සංකීර්ණත්වය අනුව 16, 32 යන්ත්‍රවල විකල්ප තිබේ. නමුත් ඔබ ගෙවන්නේ පොකුර සැබවින්ම ක්රියාත්මක වන විට එම මිනිත්තු සඳහා පමණි, මන්ද ඉල්ලීම් නොමැති විට, ඔබ යම් ආකාරයකට ඔබේ දෑත් ඉවත් කරන අතර, විනාඩි 5-10 ක් බලා සිටීමෙන් පසු (වින්‍යාසගත කළ හැකි පරාමිතියක්) එය තනිවම පිටව යනු ඇත. සම්පත් නිදහස් කර නිදහස් වන්න.
සම්පූර්ණයෙන්ම යථාර්ථවාදී සිදුවීමක් නම්, ඔබ ඉල්ලීමක් යවන විට, පොකුර උත්පතන වේ, සාපේක්ෂ වශයෙන්, මිනිත්තුවකින්, එය තවත් විනාඩියක් ගණන් කරයි, පසුව වසා දැමීමට මිනිත්තු පහක්, සහ ඔබ මෙම පොකුරේ ක්‍රියාකාරීත්වය සඳහා මිනිත්තු හතක් ගෙවා අවසන් කරයි, සහ මාස සහ අවුරුදු සඳහා නොවේ.
තනි-පරිශීලක සැකසුමක Snowflake භාවිතා කිරීම විස්තර කරන ලද පළමු අවස්ථාව. දැන් අපි සිතමු බොහෝ පරිශීලකයින් සිටින බව, එය සැබෑ තත්වයට සමීප වේ.
සරල විශ්ලේෂණාත්මක SQL විමසුම් විශාල සංඛ්යාවක් සමඟ අපගේ දත්ත සමුදාය නිරන්තරයෙන් බෝම්බ හෙලන විශ්ලේෂකයින් සහ වගු වාර්තා රාශියක් අප සතුව ඇතැයි කියමු.
ඊට අමතරව, දත්ත සමඟ බිහිසුණු දේවල් කිරීමට උත්සාහ කරන, ටෙරාබයිට් දස ගණනකින් ක්රියා කරන, බිලියන ගණනක් සහ ට්‍රිලියන ගණනක දත්ත පේළි විශ්ලේෂණය කරන නව නිපැයුම් දත්ත විද්‍යාඥයින් අප සතුව සිටින බව කියමු.
ඉහත විස්තර කර ඇති වැඩ බර වර්ග දෙක සඳහා, Snowflake ඔබට විවිධ ධාරිතාවන්ගෙන් ස්වාධීන පරිගණක පොකුරු කිහිපයක් මතු කිරීමට ඉඩ සලසයි. එපමණක් නොව, මෙම පරිගණක පොකුරු ස්වාධීනව, නමුත් පොදු ස්ථාවර දත්ත සමඟ ක්රියා කරයි.
සැහැල්ලු විමසුම් විශාල සංඛ්යාවක් සඳහා, ඔබට කුඩා පොකුරු 2-3ක්, දළ වශයෙන් යන්ත්‍ර 2 බැගින් ඉහළ නැංවිය හැක. මෙම හැසිරීම වෙනත් දේ අතර ස්වයංක්‍රීය සැකසුම් භාවිතයෙන් ක්රියාත්මක කළ හැක. ඉතින් ඔබ කියනවා, "හිම පියල්ල, කුඩා පොකුරක් ඔසවන්න. එය මත පැටවීම යම් පරාමිතියකට වඩා වැඩි නම්, සමාන දෙවන, තෙවනුව ඔසවන්න. බර අඩු වීමට පටන් ගත් විට, අතිරික්තය නිවා දමන්න. ඉතින් විශ්ලේෂකයෝ කී දෙනෙක් ඇවිත් රිපෝට් බලන්න පටන් ගත්තත් හැමෝටම ඇති තරම් සම්පත් තියෙනවා.
ඒ සමගම, විශ්ලේෂකයින් නිදාගෙන සිටින අතර කිසිවෙකු වාර්තා දෙස නොබලයි නම්, පොකුරු සම්පූර්ණයෙන්ම අඳුරු විය හැකි අතර, ඔබ ඔවුන් සඳහා ගෙවීම නතර කරයි.
ඒ අතරම, බර විමසුම් සඳහා (දත්ත විද්‍යාඥයින්ගෙන්), ඔබට යන්ත්‍ර 32ක් සඳහා ඉතා විශාල පොකුරක් මතු කළ හැක. මෙම පොකුර ද ගෙවනු ලබන්නේ ඔබේ යෝධ ඉල්ලීම එහි ක්රියාත්මක වන මිනිත්තු සහ පැය සඳහා පමණි.
ඉහත විස්තර කර ඇති අවස්ථාව ඔබට 2 පමණක් නොව, තවත් වැඩ බරක් පොකුරු වලට බෙදීමට ඉඩ සලසයි (ETL, අධීක්ෂණය, වාර්තා ද්‍රව්‍යකරණය,...).
අපි Snowflake සාරාංශ කරමු. පදනම ලස්සන අදහසක් සහ ක්රියාත්මක කළ හැකි ක්රියාත්මක කිරීමක් ඒකාබද්ධ කරයි. ManyChat හිදී, අප සතුව ඇති සියලුම දත්ත විශ්ලේෂණය කිරීමට අපි Snowflake භාවිතා කරමු. උදාහරණයේ මෙන් අපට පොකුරු තුනක් නැත, නමුත් 5 සිට 9 දක්වා විවිධ ප්‍රමාණවලින්. සමහර කාර්යයන් සඳහා අප සතුව සාම්ප්‍රදායික යන්ත්‍ර 16, යන්ත්‍ර 2, සහ සුපිරි කුඩා 1 යන්ත්‍ර ඇත. ඔවුන් බර පැටවීම සාර්ථකව බෙදා හරින අතර අපට බොහෝ දේ ඉතිරි කර ගැනීමට ඉඩ සලසයි.
දත්ත සමුදාය කියවීමේ සහ ලිවීමේ භාරය සාර්ථකව පරිමාණය කරයි. කියවීමේ බර පමණක් රැගෙන ගිය එකම “අරෝරා” හා සසඳන විට මෙය විශාල වෙනසක් සහ විශාල ඉදිරි ගමනකි. Snowflake ඔබට මෙම පරිගණන පොකුරු සමඟින් ඔබේ ලිවීමේ කාර්ය භාරය පරිමාණය කිරීමට ඉඩ සලසයි. එනම්, මා සඳහන් කළ පරිදි, අපි ManyChat හි පොකුරු කිහිපයක් භාවිතා කරමු, කුඩා සහ සුපිරි කුඩා පොකුරු ප්රධාන වශයෙන් ETL සඳහා දත්ත පැටවීම සඳහා භාවිතා කරයි. විශ්ලේෂකයින් දැනටමත් මධ්‍යම පොකුරු මත ජීවත් වන අතර ඒවා ETL භාරයට කිසිසේත්ම බලපාන්නේ නැත, එබැවින් ඒවා ඉතා ඉක්මනින් ක්රියා කරයි.
ඒ අනුව, දත්ත සමුදාය OLAP කාර්යයන් සඳහා හොඳින් ගැලපේ. කෙසේ වෙතත්, අවාසනාවකට මෙන්, එය OLTP වැඩ බර සඳහා තවමත් අදාළ නොවේ. පළමුව, මෙම දත්ත සමුදාය ස්ථම්භය වන අතර, පසුව ඇතිවන සියලු ප්රතිවිපාක ඇත. දෙවනුව, සෑම ඉල්ලීමක් සඳහාම, අවශ්‍ය නම්, ඔබ පරිගණක පොකුරක් ඔසවා දත්ත සමඟ ගංවතුර ඇති විට, ප්‍රවේශයම, අවාසනාවකට, OLTP පැටවීම සඳහා තවමත් වේගවත් නොවේ. OLAP කාර්යයන් සඳහා තත්පර ගණනක් රැඳී සිටීම සාමාන්‍ය දෙයකි, නමුත් OLTP කාර්යයන් සඳහා එය පිළිගත නොහැකිය; 100 ms වඩා හොඳ වනු ඇත, නැතහොත් 10 ms ඊටත් වඩා හොඳ වනු ඇත.
ප්රතිඵලය
දත්ත සමුදාය Stateless සහ Stateful කොටස් වලට බෙදීමෙන් serverless database එකක් ලබාගත හැක. ඉහත උදාහරණ සියල්ලෙහිම, Stateful කොටස යනු, සාපේක්ෂ වශයෙන්, S3 හි ක්ෂුද්‍ර කොටස් ගබඩා කිරීම වන අතර, Stateless යනු ප්‍රශස්තකරණය, පාර-දත්ත සමඟ ක්රියා කිරීම, ස්වාධීන සැහැල්ලු රාජ්‍ය රහිත සේවා ලෙස මතු කළ හැකි ආරක්ෂක ගැටළු හැසිරවීම බව ඔබ දැක ඇති.
SQL විමසුම් ක්රියාත්මක කිරීම Snowflake computing Clusters වැනි, අවශ්‍ය දත්ත පමණක් බාගත කිරීම, විමසුම ක්රියාත්මක කිරීම සහ "පිටතට යන්න" වැනි සේවාදායක රහිත ප්‍රකාරයේ උත්පතන ආලෝක රාජ්‍ය සේවා ලෙස ද සැලකිය හැකිය.
සේවාදායක රහිත නිෂ්පාදන මට්ටමේ දත්ත සමුදායන් දැනටමත් භාවිතය සඳහා තිබේ, ඒවා ක්රියාත්මක වේ. මෙම සර්වර් රහිත දත්ත සමුදායන් දැනටමත් OLAP කාර්යයන් හැසිරවීමට සූදානම්ය. අවාසනාවකට, OLTP කාර්යයන් සඳහා, සීමාවන් ඇති බැවින්, සූක්ෂ්මතාවයන් සමඟ ඒවා භාවිතා වේ. එක් අතකින් මෙය අවාසියකි. එහෙත්, අනෙක් අතට, මෙය අවස්ථාවක්. Aurora හි සීමාවන් නොමැතිව OLTP දත්ත සමුදායක් සම්පූර්ණයෙන්ම සර්වර් රහිත බවට පත් කිරීමට සමහර විට පාඨකයන්ගෙන් එක් අයෙකු ක්‍රමයක් සොයා ගනු ඇත.
ඔබ එය සිත්ගන්නාසුළු වූ බව මම විශ්වාස කරමි. සර්වර් නැති අනාගතයයි :)
මූලාශ්රය: www.habr.com