පහත දත්ත සමුදායන් සඳහා Yandex හි දායකත්වය සමාලෝචනය කෙරේ.
- නිවස ක්ලික් කරන්න
- වීර චාරිකාවක්
- නියමිත වේලාවට ප්‍රකෘතිමත් වීම (WAL-G)
- PostgreSQL (logerrors, Amcheck, heapcheck ඇතුළුව)
- ග්රීන්ප්ලම්
වීඩියෝ:
හෙලෝ වර්ල්ඩ්! මගේ නම Andrey Borodin. මම Yandex.Cloud හි කරන්නේ Yandex.Cloud සහ Yandex.Cloud සේවාදායකයින්ගේ අවශ්‍යතා සඳහා විවෘත සම්බන්ධතා දත්ත සමුදායන් සංවර්ධනය කිරීමයි.
මෙම කතාවේදී අපි විවෘත දත්ත සමුදායන් පරිමාණයෙන් මුහුණ දෙන අභියෝග ගැන කතා කරමු. එය වැදගත් වන්නේ ඇයි? මන්ද, මදුරුවන් මෙන් පසුව අලි බවට පත්වන කුඩා, කුඩා ගැටළු. ඔබට බොහෝ පොකුරු ඇති විට ඒවා විශාල වේ.
නමුත් ප්රධාන දෙය එය නොවේ. ඇදහිය නොහැකි දේවල් සිදු වේ. මිලියනයකට එකකට සිද්ධ වෙන දේවල්. වලාකුළු පරිසරයක් තුළ, ඔබ ඒ සඳහා සූදානම් විය යුතුය, මන්ද යමක් පරිමාණයෙන් පවතින විට ඇදහිය නොහැකි දේවල් බොහෝ දුරට සම්භාවිතාවක් ඇති කරයි.
එහෙත්! විවෘත දත්ත සමුදායේ වාසිය කුමක්ද? කාරණය නම් ඔබට ඕනෑම ගැටලුවක් සමඟ කටයුතු කිරීමට න්යායික අවස්ථාවක් තිබේ. ඔබට ප්‍රභව කේතය ඇත, ඔබට ක්‍රමලේඛන දැනුම ඇත. අපි එය ඒකාබද්ධ කර එය ක්රියා කරයි.
විවෘත කේත මෘදුකාංග මත වැඩ කිරීමේදී ඇති ප්‍රවේශයන් මොනවාද?
- වඩාත්ම සරල ප්රවේශය වන්නේ මෘදුකාංග භාවිතා කිරීමයි. ඔබ ප්‍රොටෝකෝල භාවිතා කරන්නේ නම්, ඔබ ප්‍රමිති භාවිතා කරන්නේ නම්, ඔබ ආකෘති භාවිතා කරන්නේ නම්, ඔබ විවෘත මූලාශ්‍ර මෘදුකාංගවල විමසුම් ලියන්නේ නම්, ඔබ දැනටමත් එයට සහය දක්වයි.
- ඔබ එහි පරිසර පද්ධතිය විශාල කරනවා. ඔබ දෝෂයක් කලින් හඳුනාගැනීමේ සම්භාවිතාව වැඩි කරයි. ඔබ මෙම පද්ධතියේ විශ්වසනීයත්වය වැඩි කරයි. ඔබ වෙළඳපොලේ සංවර්ධකයින් ලබා ගැනීමේ හැකියාව වැඩි කරයි. ඔබ මෙම මෘදුකාංගය වැඩිදියුණු කරන්න. ඔබ මෝස්තරයක් ලබා ගැනීම සහ එහි යමක් සමඟ සම්බන්ධ වී ඇත්නම් ඔබ දැනටමත් දායකයෙකි.
- තවත් තේරුම් ගත හැකි ප්‍රවේශයක් වන්නේ විවෘත කේත මෘදුකාංගයට අනුග්‍රහය දැක්වීමයි. උදාහරණයක් ලෙස, සුප්‍රසිද්ධ Google Summer of Code වැඩසටහන, Google ලොව පුරා සිටින සිසුන් විශාල සංඛ්‍යාවකට තේරුම් ගත හැකි මුදල් ගෙවන විට, ඔවුන් යම් බලපත්‍ර අවශ්‍යතා සපුරාලන විවෘත මෘදුකාංග ව්යාපෘති සංවර්ධනය කරයි.
- මෙය ඉතා සිත්ගන්නා ප්‍රවේශයක් වන්නේ එය ප්‍රජාවෙන් අවධානය වෙනතකට යොමු නොකර මෘදුකාංගය පරිණාමය වීමට ඉඩ සලසන බැවිනි. Google, තාක්ෂණික දැවැන්තයෙකු ලෙස, අපට මෙම විශේෂාංගය අවශ්ය බව නොකියයි, අපට මෙම දෝෂය නිවැරදි කිරීමට අවශ්ය බව සහ අප හාරා ගත යුතු ස්ථානය මෙයයි. ගූගල් පවසන්නේ: "ඔබ කරන දේ කරන්න. ඔබ වැඩ කළ ආකාරයටම දිගටම වැඩ කරන්න, එවිට සියල්ල හොඳින් වනු ඇත. ”
- විවෘත මූලාශ්‍රවලට සහභාගී වීමේ ඊළඟ ප්රවේශය වන්නේ සහභාගීත්වයයි. ඔබට විවෘත කේත මෘදුකාංගවල ගැටලුවක් ඇති විට සහ සංවර්ධකයින් සිටින විට, ඔබේ සංවර්ධකයින් ගැටළු විසඳීමට පටන් ගනී. ඔවුන් ඔබේ යටිතල ව්‍යුහය වඩාත් කාර්යක්ෂම කිරීමටත්, ඔබේ වැඩසටහන් වේගවත් හා විශ්වාසදායක කිරීමටත් පටන් ගනී.
විවෘත මූලාශ්‍ර මෘදුකාංග ක්ෂේත්‍රයේ වඩාත් ප්‍රසිද්ධ Yandex ව්යාපෘති වලින් එකක් වන්නේ ClickHouse ය. මෙය Yandex.Metrica මුහුණ දෙන අභියෝගවලට ප්‍රතිචාරයක් ලෙස බිහි වූ දත්ත සමුදායකි.
දත්ත සමුදායක් ලෙස, එය පරිසර පද්ධතියක් නිර්මාණය කිරීම සහ අනෙකුත් සංවර්ධකයින් සමඟ (Yandex තුළ පමණක් නොව) එය සංවර්ධනය කිරීම සඳහා විවෘත මූලාශ්‍රයෙන් සාදන ලදී. දැන් මෙය විවිධ සමාගම් රාශියක් සම්බන්ධ වන විශාල ව්‍යාපෘතියකි.
Yandex.Cloud හි, අපි Yandex Object Storage මත ක්ලික් හවුස් නිර්මාණය කළෙමු, එනම් වලාකුළු ගබඩාව මත.
වලාකුළෙහි මෙය වැදගත් වන්නේ ඇයි? මොකද ඕනෑම දත්ත සමුදායක් ක්රියා කරන්නේ මේ ත්‍රිකෝණයේ, මේ පිරමීඩයේ, මේ මතක වර්ග වල ධුරාවලියේ. ඔබට වේගවත් නමුත් කුඩා රෙජිස්ටර් සහ ලාභ විශාල නමුත් මන්දගාමී SSD, දෘඪ තැටි සහ වෙනත් අවහිර උපාංග තිබේ. ඔබ පිරමීඩයේ මුදුනේ කාර්යක්ෂම නම්, ඔබට වේගවත් දත්ත ගබඩාවක් ඇත. ඔබ මෙම පිරමීඩයේ පතුලේ කාර්යක්ෂම නම්, ඔබට පරිමාණ දත්ත ගබඩාවක් ඇත. මේ සම්බන්ධයෙන්, පහතින් තවත් ස්ථරයක් එකතු කිරීම දත්ත සමුදායේ පරිමාණය වැඩි කිරීම සඳහා තාර්කික ප්රවේශයකි.
එය කළ හැක්කේ කෙසේද? මෙය මෙම වාර්තාවේ වැදගත් කරුණකි.
- අපට MDS හරහා ClickHouse ක්රියාත්මක කළ හැක. MDS යනු අභ්යන්තර Yandex වලාකුළු ගබඩා අතුරුමුහුණතකි. එය පොදු S3 ප්රොටෝකෝලය වඩා සංකීර්ණ වේ, නමුත් එය බ්ලොක් උපාංගයක් සඳහා වඩාත් සුදුසු වේ. දත්ත පටිගත කිරීම සඳහා වඩා හොඳය. එය වැඩි වැඩසටහන් අවශ්ය වේ. වැඩසටහන්කරුවන් වැඩසටහන් කරනු ඇත, එය පවා හොඳයි, එය රසවත්.
- S3 යනු වඩාත් පොදු ප්‍රවේශයක් වන අතර එමඟින් ඇතැම් ආකාරයේ වැඩ බරට අඩු අනුවර්තනය වීමේ පිරිවැයෙන් අතුරු මුහුණත සරල කරයි.
ස්වාභාවිකවම, සමස්ත ClickHouse පරිසර පද්ධතියට ක්‍රියාකාරීත්වය සැපයීමට සහ Yandex.Cloud තුළ අවශ්ය කාර්යය කිරීමට අවශ්ය වන අතර, සමස්ත ClickHouse ප්‍රජාවටම එයින් ප්‍රතිලාභ ලැබෙන බවට වග බලා ගැනීමට අපි තීරණය කළෙමු. අපි ක්ලික්හවුස් එම්ඩීඑස් හරහා ක්ලික්හවුස් නොව S3 හරහා ක්රියාත්මක කළෙමු. අනික මේක වැඩ ගොඩයි.
ආශ්රිත:
"ගොනු පද්ධති වියුක්ත ස්තරය"
"AWS SDK S3 ඒකාබද්ධ කිරීම"
"S3 සඳහා IDisk අතුරුමුහුණත මූලික ක්රියාත්මක කිරීම"
"IDisk අතුරුමුහුණත සමඟ ලොග් ගබඩා එන්ජින් ඒකාබද්ධ කිරීම"
"S3 සහ SeekableReadBuffer සඳහා ලොග් එන්ජින් සහාය"
"ගබඩා තීරු ලොග් S3 සහාය"
"S3 සඳහා Storage MergeTree මූලික සහාය"
"S3 සඳහා MergeTree පූර්ණ සහාය"
"S3 හරහා ReplicatedMergeTree සඳහා සහය දක්වන්න"
"s3 ආචයනය සඳහා පෙරනිමි අක්තපත්‍ර සහ අභිරුචි ශීර්ෂ එක් කරන්න"
"ගතික ප්‍රොක්සි වින්‍යාසය සහිත S3"
"ප්‍රොක්සි විසදුම සහිත S3"
මෙය ClickHouse හි අතථ්‍ය ගොනු පද්ධතියක් ක්රියාත්මක කිරීම සඳහා වන ඇදීමේ ඉල්ලීම් ලැයිස්තුවකි. මෙය ඇදීමේ ඉල්ලීම් විශාල ප්‍රමාණයකි.
ආශ්රිත:
"DiskS3 Hardlinks ප්‍රශස්ත ක්රියාත්මක කිරීම"
"S3 HTTP සේවාදායකයා - ප්‍රතිචාර ප්‍රවාහය මතකයට පිටපත් කිරීමෙන් වළකින්න"
“S3 HTTP හි සම්පූර්ණ ප්‍රතිචාර ප්‍රවාහයම මතකයට පිටපත් කිරීමෙන් වළකින්න
සේවාදායකයා"
"S3 තැටිය සඳහා හැඹිලි සලකුණු සහ දර්ශක ගොනු කිරීමේ හැකියාව"
"කොටස් DiskLocal සිට DiskS3 වෙත සමාන්තරව ගෙන යන්න"
නමුත් කාර්යය එතැනින් අවසන් වූයේ නැත. විශේෂාංගය සෑදූ පසු, මෙම ක්‍රියාකාරීත්වය ප්‍රශස්ත කිරීම සඳහා තවත් වැඩ කිහිපයක් අවශ්ය විය.
ආශ්රිත:
"තෝරාගත් පේළි සහ තෝරාගත් බයිට් සිදුවීම් එක් කරන්න"
"S3 ඉල්ලීමේ සිට system.events වෙත පැතිකඩ සිදුවීම් එක් කරන්න"
"QueryTimeMicroseconds, SelectQueryTimeMicroseconds සහ InsertQueryTimeMicroseconds එකතු කරන්න"
ඉන්පසුව එය රෝග විනිශ්චය කළ හැකි බවට පත් කිරීම, නිරීක්ෂණ සකස් කිරීම සහ කළමනාකරණය කළ හැකි බවට පත් කිරීම අවශ්ය විය.
මේ සියල්ල සිදු කරන ලද්දේ සමස්ත ප්‍රජාවට, සමස්ත ClickHouse පරිසර පද්ධතියට මෙම කාර්යයේ ප්‍රතිඵලය ලැබෙන පරිදි ය.
මට පුද්ගලිකව වඩාත් සමීප ගනුදෙනු දත්ත සමුදායන් වෙත, OLTP දත්ත සමුදායන් වෙත යමු.
මෙය විවෘත මූලාශ්‍ර DBMS සංවර්ධන අංශයයි. මේ ගොල්ලෝ ට්‍රාන්සැක්සැනල් ඕපන් ඩේටාබේස් දියුණු කරන්න ස්ට්‍රීට් මැජික් කරනවා.
අපි කරන්නේ කෙසේද සහ කුමක් ගැන කතා කළ හැකි උදාහරණයක් භාවිතා කරමින් ව්යාපෘති වලින් එකක් වන්නේ Postgres හි සම්බන්ධතා සංචිතයයි.
Postgres යනු ක්‍රියාවලි දත්ත ගබඩාවකි. මෙයින් අදහස් කරන්නේ දත්ත සමුදාය ගනුදෙනු හසුරුවන ජාල සම්බන්ධතා හැකි තරම් අඩුවෙන් තිබිය යුතු බවයි.
අනෙක් අතට, වලාකුළු පරිසරයක, සාමාන්‍ය තත්වයක් වන්නේ එක් පොකුරකට සම්බන්ධතා දහසක් එකවර පැමිණීමයි. සම්බන්ධතා සංචිතයේ කාර්යය වන්නේ සේවාදායක සම්බන්ධතා කුඩා සංඛ්‍යාවකට සම්බන්ධතා දහසක් ඇසුරුම් කිරීමයි.
සම්බන්ධතා සංචිතය යනු දත්ත සමුදායට කාර්යක්ෂමව ළඟා වන පරිදි බයිට් නැවත සකස් කරන දුරකථන ක්‍රියාකරු බව අපට පැවසිය හැකිය.
අවාසනාවකට, සම්බන්ධතා සංචිතය සඳහා හොඳ රුසියානු වචනයක් නොමැත. සමහර විට එය බහුකාර්ය සම්බන්ධතා ලෙස හැඳින්වේ. සම්බන්ධතා සංචිතය ලෙස හැඳින්විය යුත්තේ කුමක් දැයි ඔබ දන්නේ නම්, මට කියන්නට වග බලා ගන්න, නිවැරදි රුසියානු තාක්ෂණික භාෂාව කතා කිරීමට මම ඉතා සතුටු වනු ඇත.
අපි කළමනාකරණය කළ postgres පොකුරක් සඳහා සුදුසු සම්බන්ධතා තටාක විමර්ශනය කළෙමු. තවද PgBouncer අපට හොඳම තේරීම විය. නමුත් අපි PgBouncer සමඟ ගැටලු රාශියකට මුහුණ දුන්නා. මීට වසර ගණනාවකට පෙර, Volodya Borodin වාර්තා ලබා දුන්නේ අපි PgBouncer භාවිතා කරන බවයි, අපි සෑම දෙයකටම කැමතියි, නමුත් සූක්ෂ්මතා ඇත, වැඩ කිරීමට යමක් තිබේ.
ඒ වගේම අපි වැඩ කළා. අපි මුහුණ දුන් ගැටළු අපි විසඳා, අපි බවුන්සර් පැච් කර, සහ ඇදීමේ ඉල්ලීම් ඉහළට තල්ලු කිරීමට උත්සාහ කළෙමු. නමුත් මූලික තනි නූල් සමග වැඩ කිරීමට අපහසු විය.
පැච් කරන ලද බවුන්සර් වලින් අපට කඳුරැල්ල එකතු කිරීමට සිදු විය. අපට තනි නූල් සහිත බවුන්සර් රාශියක් ඇති විට, ඉහළ ස්ථරයේ සම්බන්ධතා බවුන්සර්වල අභ්යන්තර ස්ථරයට මාරු කරනු ලැබේ. මෙය දුර්වල ලෙස කළමනාකරණය කරන ලද පද්ධතියක් වන අතර එය ගොඩනැගීමට සහ නැවත පරිමාණය කිරීමට අපහසු වේ.
අපි Odyssey ලෙස හැඳින්වෙන අපගේම සම්බන්ධතා සංචිතයක් නිර්මාණය කළ බව අපි නිගමනය කළෙමු. අපි එය මුල සිට ලිව්වෙමු.
2019 දී, PgCon සමුළුවේදී, මම මෙම සංචිතය සංවර්ධක ප්‍රජාවට ඉදිරිපත් කළෙමි. දැන් අපට GitHub හි තරු 2 කට වඩා ටිකක් අඩුයි, එනම් ව්‍යාපෘතිය ජීවමානයි, ව්‍යාපෘතිය ජනප්‍රියයි.
තවද ඔබ Yandex.Cloud හි Postgres පොකුරක් නිර්මාණය කරන්නේ නම්, එය ගොඩනඟන ලද Odyssey සමඟ පොකුරක් වනු ඇත, එය පොකුර ඉදිරියට හෝ පසුපසට පරිමාණය කිරීමේදී නැවත සකස් කරනු ලැබේ.
මෙම ව්යාපෘතියෙන් අප ඉගෙනගත්තේ කුමක්ද? තරඟකාරී ව්‍යාපෘතියක් දියත් කිරීම සැමවිටම ආක්‍රමණශීලී පියවරකි, ප්‍රමාණවත් තරම් ඉක්මනින් නොවිසඳෙන, අපට ගැලපෙන කාල පරාසයන් තුළ නොවිසඳෙන ගැටළු ඇති බව අප පවසන විට එය ආන්තික පියවරකි. නමුත් මෙය ඵලදායී පියවරකි.
PgBouncer වේගයෙන් වර්ධනය වීමට පටන් ගත්තේය.
දැන් වෙනත් ව්යාපෘති දර්ශනය වී ඇත. උදාහරණයක් ලෙස, Red Hat සංවර්ධකයින් විසින් සංවර්ධනය කරන ලද pgagroal. ඔවුන් සමාන ඉලක්ක ලුහුබඳින අතර සමාන අදහස් ක්රියාත්මක කරයි, නමුත්, ඇත්ත වශයෙන්ම, pgagroal සංවර්ධකයින්ට සමීප වන ඔවුන්ගේම විශේෂතා සමඟ.
පශ්චාත් ග්‍රේස් ප්රජාව සමඟ වැඩ කිරීමේ තවත් අවස්ථාවක් වන්නේ කාල සීමාවකට යථා තත්ත්වයට පත් වීමයි. මෙය අසාර්ථක වීමෙන් පසු යථා තත්ත්වයට පත්වීම, මෙය උපස්ථයකින් ප්‍රතිසාධනය වේ.
බොහෝ උපස්ථ ඇති අතර ඒවා සියල්ලම වෙනස් වේ. සෑම Postgres වෙළෙන්දෙකුටම පාහේ තමන්ගේම උපස්ථ විසඳුමක් ඇත.
ඔබ සියලුම උපස්ථ පද්ධති රැගෙන විශේෂාංග න්‍යාසයක් සාදා මෙම න්‍යාසයේ නිර්ණායකය විහිළුවට ගණනය කළහොත් එය ශුන්‍ය වේ. මෙමගින් කුමක් වෙයිද? ඔබ නිශ්චිත උපස්ථ ගොනුවක් ගන්නේ නම්, එය අනෙක් සියලුම කොටස් වලින් එකලස් කළ නොහැක. එය ක්‍රියාවට නැංවීමේදී එය අද්විතීයයි, එහි අරමුණෙහි අද්විතීයයි, එහි තැන්පත් වී ඇති අදහස්වල අද්විතීයයි. තවද ඒවා සියල්ලම විශේෂිත වේ.
අපි මෙම ගැටලුව සම්බන්ධයෙන් කටයුතු කරන අතරතුර, CitusData WAL-G ව්‍යාපෘතිය දියත් කරන ලදී. මෙය ක්ලවුඩ් පරිසරයට ඇස යොමු කර සාදන ලද උපස්ථ පද්ධතියකි. දැන් CitusData දැනටමත් Microsoft හි කොටසකි. ඒ මොහොතේ, අපි WAL-G හි මුල් නිකුතු වල දක්වා ඇති අදහස් වලට ඇත්තෙන්ම කැමතියි. ඒ වගේම අපි මේ ව්‍යාපෘතියට දායක වෙන්න පටන් ගත්තා.
දැන් මෙම ව්‍යාපෘතියේ සංවර්ධකයින් දුසිම් ගණනක් ඇත, නමුත් WAL-G සඳහා ඉහළම දායකයින් 10 දෙනා අතර Yandexoids 6 ක් ඇතුළත් වේ. අපි අපේ අදහස් ගොඩක් එතනට ගෙනාවා. තවද, ඇත්ත වශයෙන්ම, අපි ඒවා අප විසින්ම ක්රියාත්මක කර, ඒවා අප විසින්ම පරීක්ෂා කර, ඒවා අප විසින්ම නිෂ්පාදනයට පෙරළා ගත්තෙමු, අපි ඒවා අප විසින්ම භාවිතා කරමු, විශාල WAL-G ප්රජාව සමඟ අන්තර් ක්රියා කරන අතරතුර ඊළඟට යා යුත්තේ කොතැනටද යන්න අපිම සොයා ගනිමු.
අපගේ දෘෂ්ටි කෝණයෙන්, දැන් අපගේ උත්සාහයන් සැලකිල්ලට ගැනීම ඇතුළුව මෙම උපස්ථ පද්ධතිය වලාකුළු පරිසරයක් සඳහා ප්‍රශස්ත වී ඇත. වලාකුළු තුළ Postgres උපස්ථ කිරීමේ හොඳම පිරිවැය මෙයයි.
එයින් අදහස් කරන්නේ කුමක් ද? අපි තරමක් විශාල අදහසක් ප්‍රවර්ධනය කරමින් සිටියෙමු: උපස්ථය ආරක්ෂිත විය යුතුය, ක්රියා කිරීමට ලාභදායී විය යුතු අතර ප්‍රතිසාධනය කිරීමට හැකි තරම් වේගවත් විය යුතුය.
එය ක්රියාත්මක කිරීමට ලාභදායී විය යුත්තේ ඇයි? කිසිවක් කැඩී නැති විට, ඔබට උපස්ථ ඇති බව ඔබ නොදැන සිටිය යුතුය. සෑම දෙයක්ම හොඳින් ක්රියාත්මක වේ, ඔබ හැකි තරම් කුඩා CPU නාස්ති කරයි, ඔබ ඔබේ තැටි සම්පත් හැකිතාක් අඩුවෙන් භාවිතා කරයි, සහ ඔබේ වටිනා සේවාවන් ගෙවීමට බාධා නොවන පරිදි හැකි තරම් බයිට් කිහිපයක් ජාලයට යවන්න.
සෑම දෙයක්ම කැඩී ගිය විට, උදාහරණයක් ලෙස, පරිපාලකයා දත්ත අතහැර දමා, යමක් වැරදී ඇත, සහ ඔබට ඉක්මනින් අතීතයට යාමට අවශ්ය වේ, ඔබට ඔබේ දත්ත ඉක්මනින් හා නොවෙනස්ව ආපසු අවශ්ය බැවින් ඔබ සියලු මුදල් සමඟ නැවත යථා තත්ත්වයට පත් වේ.
ඒ වගේම අපි මේ සරල අදහස ප්‍රවර්ධනය කළා. තවද, අපට පෙනෙන පරිදි, අපි එය ක්රියාත්මක කිරීමට සමත් විය.
නමුත් එය පමණක් නොවේ. අපිට තව පොඩි දෙයක් ඕන උනා. අපට විවිධ දත්ත සමුදායන් අවශ්ය විය. අපගේ සියලුම ගනුදෙනුකරුවන් Postgres භාවිතා නොකරයි. සමහර අය MySQL, MongoDB පාවිච්චි කරනවා. ප්රජාව තුළ, අනෙකුත් සංවර්ධකයින් FoundationDB වෙත සහාය දක්වා ඇත. තවද මෙම ලැයිස්තුව නිරන්තරයෙන් පුළුල් වේ.
වලාකුළෙහි කළමනාකරණය කළ පරිසරයක දත්ත සමුදාය ක්රියාත්මක කිරීම පිළිබඳ අදහසට ප්රජාව කැමතියි. තවද සංවර්ධකයින් ඔවුන්ගේ දත්ත සමුදායන් පවත්වා ගෙන යන අතර, අපගේ උපස්ථ පද්ධතිය සමඟ Postgres සමඟ ඒකාකාරව උපස්ථ කළ හැක.
මෙම කතාවෙන් අප ඉගෙනගත්තේ කුමක්ද? අපගේ නිෂ්පාදනය, සංවර්ධන අංශයක් ලෙස, කේත රේඛා නොවේ, එය ප්රකාශයන් නොවේ, එය ගොනු නොවේ. අපගේ නිෂ්පාදනය ඇදීමේ ඉල්ලීම් නොවේ. මේවා අපි සමාජයට කියන අදහස්. මෙය තාක්ෂණික විශේෂඥතාව සහ වලාකුළු පරිසරයක් දෙසට තාක්ෂණයේ චලනයයි.
Postgres වැනි එවැනි දත්ත ගබඩාවක් තිබේ. මම ගොඩක්ම කැමති Postgres core එකට. මම ප්රජාව සමඟ Postgres හරය සංවර්ධනය කිරීමට බොහෝ කාලයක් ගත කරමි.
නමුත් මෙහිදී Yandex.Cloud කළමනාකරණය කළ දත්ත සමුදායේ අභ්යන්තර ස්ථාපනයක් ඇති බව පැවසිය යුතුය. තවද එය බොහෝ කලකට පෙර Yandex.Mail හි ආරම්භ විය. පෝස්ට්ග්‍රෙස් කළමනාකරණය කිරීමට හේතු වී ඇති විශේෂඥ දැනුම තැපෑලට පෝස්ට්ග්‍රෙස් වෙත යාමට අවශ්ය වූ විට රැස් කර ගන්නා ලදී.
තැපෑලට වලාකුළට බොහෝ සමාන අවශ්‍යතා ඇත. ඔබගේ දත්තවල ඕනෑම අවස්ථාවක අනපේක්ෂිත ඝාතීය වර්ධනයකට පරිමාණය කිරීමට ඔබට හැකි වීම එයට අවශ්ය වේ. නිරන්තරයෙන් බොහෝ ඉල්ලීම් කරන පරිශීලකයින් විශාල සංඛ්‍යාවකගේ තැපැල් පෙට්ටි මිලියන සිය ගණනක් සමඟ තැපෑලට දැනටමත් බරක් තිබුණි.
Postgres සංවර්ධනය කරමින් සිටි කණ්ඩායමට මෙය තරමක් බරපතල අභියෝගයක් විය. ඒ කාලේ අපි මුහුණ දෙන ඕනෑම ගැටලුවක් සමාජයට වාර්තා කළා. තවද මෙම ගැටළු නිවැරදි කරන ලද අතර, ප්රජාව විසින් සමහර ස්ථානවල වෙනත් දත්ත සමුදායන් සඳහා ගෙවන ලද ආධාරක මට්ටමින් සහ ඊටත් වඩා හොඳින් නිවැරදි කරන ලදී. එනම්, ඔබට PgSQL හැකර් වෙත ලිපියක් යැවිය හැකි අතර මිනිත්තු 40ක් ඇතුළත ප්‍රතිචාරයක් ලැබිය හැක. සමහර දත්ත සමුදායන්හි ගෙවන ලද සහාය ඔබේ දෝෂයට වඩා ප්‍රමුඛතා දේවල් ඇති බව සිතිය හැක.
දැන් Postgres හි අභ්යන්තර ස්ථාපනය දත්ත පෙටාබයිට් කිහිපයක් වේ. මේවා තත්පරයකට ඉල්ලීම් මිලියන ගණනකි. මේවා පොකුරු දහස් ගණනකි. එය ඉතා විශාල පරිමාණයකි.
නමුත් සූක්ෂ්මතාවයක් තිබේ. එය විසිතුරු ජාල ධාවකයන් මත නොව, තරමක් සරල දෘඪාංග මත ජීවත් වේ. රසවත් නව දේවල් සඳහා විශේෂයෙන් පරීක්ෂණ පරිසරයක් ඇත.
පරීක්ෂණ පරිසරයේ එක්තරා මොහොතක දත්ත සමුදා දර්ශකවල අභ්යන්තර වෙනස්වීම් උල්ලංඝනය වී ඇති බවට පණිවිඩයක් අපට ලැබුණි.
වෙනස් නොවන දෙයක් යනු අප සැමවිටම පැවැත්වීමට බලාපොරොත්තු වන යම් ආකාරයක සම්බන්ධතාවයකි.
අපට ඉතා තීරණාත්මක තත්වයක්. එයින් පෙන්නුම් කරන්නේ සමහර දත්ත නැති වී ඇති බවයි. ඒ වගේම දත්ත නැතිවීම යනු විනාශකාරී දෙයක්.
කළමනාකරණය කරන ලද දත්ත සමුදායන්හි අප අනුගමනය කරන සාමාන්‍ය අදහස නම් උත්සාහයෙන් වුවද දත්ත නැතිවීම දුෂ්කර වනු ඇති බවයි. ඔබ හිතාමතාම ඒවා ඉවත් කළත්, දිගු කාලයක් තිස්සේ ඔවුන් නොපැමිණීම නොසලකා හැරීමට ඔබට අවශ්ය වනු ඇත. දත්ත ආරක්ෂාව යනු අප ඉතා උනන්දුවෙන් අනුගමනය කරන ආගමකි.
තවද මෙහි දී අප සූදානම් නැති තත්ත්වයක් ඇති විය හැකි බව හඟවන තත්ත්වයක් මතු වේ. අපි මෙම තත්වය සඳහා සූදානම් වීමට පටන් ගත්තෙමු.
අපි මුලින්ම කළේ මේ දහස් ගණන් පොකුරුවලින් කඳන් වළ දැමීමයි. දත්ත පිටු යාවත්කාලීන කිරීම් අහිමි වන ගැටළුකාරී ස්ථිරාංග සහිත තැටි මත පිහිටා ඇති පොකුරු මොනවාදැයි අපි සොයා ගත්තෙමු. සියලුම Postgres දත්ත කේතය සලකුණු කරන ලදී. තවද අපි දත්ත දූෂණය හඳුනා ගැනීමට නිර්මාණය කර ඇති කේතය සමඟ අභ්යන්තර විචල්‍යයන් උල්ලංඝනය කිරීම් පෙන්නුම් කරන එම පණිවිඩ සලකුණු කළෙමු.
මෙම පැච් වැඩි සාකච්ඡාවකින් තොරව ප්රජාව විසින් ප්‍රායෝගිකව පිළිගත්තේය, මන්ද එක් එක් විශේෂිත අවස්ථාවන්හිදී නරක දෙයක් සිදුවී ඇති බව පැහැදිලිව පෙනෙන අතර එය ලොගයට වාර්තා කිරීමට අවශ්ය විය.
මෙයින් පසු, අපි ලොග් පරිලෝකනය කරන අධීක්ෂණයක් ඇති බවට අපි පැමිණියෙමු. සැක සහිත පණිවිඩ වලදී, ඔහු රාජකාරි නිලධාරියා අවදි කරන අතර, රාජකාරි නිලධාරියා එය අලුත්වැඩියා කරයි.
එහෙත්! ලඝු-සටහන් පරිලෝකනය කිරීම එක් පොකුරක් මත ලාභදායී මෙහෙයුමක් වන අතර පොකුරු දහසක් සඳහා ව්යසනකාරී ලෙස මිල අධික වේ.
නමින් දිගුවක් ලිව්වෙමු . එය දත්ත සමුදායේ දර්ශනයක් නිර්මාණය කරයි, එමඟින් ඔබට අතීත දෝෂ පිළිබඳ සංඛ්‍යාලේඛන ලාභදායී හා ඉක්මනින් තෝරා ගත හැකිය. තවද අපට රාජකාරි නිලධාරියා අවදි කිරීමට අවශ්ය නම්, අපි ගිගාබයිට් ගොනු පරිලෝකනය නොකර හැෂ් වගුවෙන් බයිට් කිහිපයක් උපුටා ගැනීමෙන් මේ ගැන සොයා ගනිමු.
මෙම දිගුව භාවිතා කර ඇත, උදාහරණයක් ලෙස, සඳහා ගබඩාවේ . ඔබට එය භාවිතා කිරීමට අවශ්ය නම්, ඔබට එය ඔබම ස්ථාපනය කළ හැකිය. ඇත්ත වශයෙන්ම එය විවෘත මූලාශ්රයකි.
නමුත් එය පමණක් නොවේ. අපි දර්ශකවල වෙනස් නොවන උල්ලංඝනයන් සොයා ගැනීමට ප්රජාව විසින් ගොඩනඟන ලද දිගුවක් වන Amcheck භාවිතා කිරීමට පටන් ගත්තෙමු.
ඔබ එය පරිමාණයෙන් ක්රියාත්මක කළහොත් දෝෂ ඇති බව අපි සොයා ගත්තෙමු. අපි ඒවා හදන්න පටන් ගත්තා. අපගේ නිවැරදි කිරීම් පිළිගෙන ඇත.
මෙම දිගුවට GiST සහ GIT දර්ශක විශ්ලේෂණය කළ නොහැකි බව අපි සොයා ගත්තෙමු. අපි ඔවුන්ට සහයෝගය ලබා දුන්නා. නමුත් මෙම සහයෝගය තවමත් ප්රජාව විසින් සාකච්ඡා කරනු ලැබේ, මෙය සාපේක්ෂව නව ක්‍රියාකාරිත්වයක් වන අතර එහි බොහෝ විස්තර ඇත.
තවද, අනුකරණ නායකයා මත, මාස්ටර් මත උල්ලංඝනය කිරීම් සඳහා දර්ශක පරීක්ෂා කිරීමේදී, සෑම දෙයක්ම හොඳින් ක්රියාත්මක වන නමුත් අනුපිටපත් මත, අනුගාමිකයා මත, දූෂණ සෙවීම එතරම් ඵලදායී නොවන බව අපි සොයා ගත්තෙමු. සියලුම වෙනස්වීම් පරීක්ෂා නොකෙරේ. ඒ වගේම එක වෙනස් නොවන කෙනෙක් අපිට ගොඩක් කරදර කළා. තවද අනුරූ පිළිබඳ මෙම පරීක්ෂාව සක්‍රීය කිරීම සඳහා අපි ප්රජාව සමඟ සන්නිවේදනය කිරීමට වසර එකහමාරක් ගත කළෙමු.
අපි සියලු හැකි ... ප්‍රොටෝකෝල අනුගමනය කළ යුතු කේතය ලිව්වෙමු. අපි මෙම පැච් එක Crunchy Data වෙතින් Peter Gaghan සමඟ සෑහෙන කාලයක් සාකච්ඡා කළා. මෙම පැච් එක පිළිගැනීම සඳහා ඔහුට Postgres හි පවතින B-tree තරමක් වෙනස් කිරීමට සිදු විය. ඔහු පිළිගත්තා. දැන් අනුරූ මත දර්ශක පරීක්ෂා කිරීම ද අප මුහුණ දුන් උල්ලංඝනයන් හඳුනා ගැනීමට තරම් ඵලදායී වී ඇත. එනම්, තැටි ස්ථිරාංග වල දෝෂ, Postgres හි දෝෂ, Linux කර්නලයේ දෝෂ සහ දෘඪාංග ගැටළු නිසා ඇති විය හැකි උල්ලංඝනයන් වේ. අපි සූදානම් වෙමින් සිටි ගැටලු මූලාශ්‍ර පිළිබඳ ඉතා පුළුල් ලැයිස්තුවක්.
නමුත් දර්ශක වලට අමතරව, ගොඩවල් වැනි කොටසක් ඇත, එනම් දත්ත ගබඩා කර ඇති ස්ථානය. තවද පරීක්ෂා කළ හැකි බොහෝ වෙනස්වීම් නොමැත.
අපිට Heapcheck කියලා Extension එකක් තියෙනවා. අපි එය සංවර්ධනය කිරීමට පටන් ගත්තා. ඊට සමාන්තරව, අප සමඟ එක්ව, EnterpriseDB සමාගම ද මොඩියුලයක් ලිවීමට පටන් ගත් අතර, එය ඔවුන් Heapcheck ලෙස හැඳින්වූයේ එලෙසම ය. අපි එය PgHeapcheck ලෙස හැඳින්වූ අතර ඔවුන් එය හැඳින්වූයේ Heapcheck යනුවෙනි. ඔවුන් සතුව එය සමාන කාර්යයන්, තරමක් වෙනස් අත්සනක් ඇත, නමුත් එකම අදහස් ඇත. සමහර තැන්වල ඒවා ටිකක් හොඳට ක්රියාත්මක කළා. ඒවගේම එයාලා ඕපන් සෝස් එකේ කලින් පෝස්ට් කළා.
දැන් අපි ඔවුන්ගේ ව්‍යාප්තිය වර්ධනය කරමින් සිටිමු, මන්ද එය තවදුරටත් ඔවුන්ගේ ව්‍යාප්තිය නොව ප්‍රජාවේ ව්‍යාප්තියයි. අනාගතයේදී, මෙය සෑම කෙනෙකුටම සපයනු ලබන කර්නලයේ කොටසක් වන අතර එමඟින් අනාගත ගැටළු පිළිබඳව කල්තියා දැනගත හැකිය.
සමහර ස්ථානවල, අපගේ නිරීක්ෂණ පද්ධතිවල ව්‍යාජ ධනාත්මක බව පවා අපි නිගමනය කළෙමු. උදාහරණයක් ලෙස, 1C පද්ධතිය. දත්ත සමුදායක් භාවිතා කරන විට, Postgres සමහර විට එය කියවිය හැකි දත්ත ලියයි, නමුත් pg_dump කියවිය නොහැක.
මෙම තත්ත්වය අපගේ ගැටලු හඳුනාගැනීමේ පද්ධතියට දූෂණයක් සේ පෙනුණි. රාජකාරි නිලධාරියා අවදි විය. රාජකාරි නිලධාරියා මොකද වෙන්නේ කියලා බැලුවා. ටික වෙලාවකින් සේවාදායකයෙක් ඇවිත් කිව්වා මට ප්රශ්න තියෙනවා කියලා. සේවකයා ගැටලුව කුමක්දැයි පැහැදිලි කළේය. නමුත් ප්‍රශ්නය තියෙන්නේ Postgres core එකේ.
මෙම විශේෂාංගය පිළිබඳ සාකච්ඡාවක් මට හමු විය. ඔහු ලියා ඇත්තේ අපට මෙම අංගය හමු වූ බවත් එය අප්රසන්න බවත්, එය කුමක්දැයි සොයා ගැනීමට පුද්ගලයෙකු රාත්‍රියේ අවදි වූ බවයි.
ප්රජාව ප්‍රතිචාර දැක්වූයේ, "අනේ, අපි එය නිවැරදි කළ යුතුයි."
මට සරල සමානකමක් ඇත. ඔබ වැලි කැටයක් ඇති සපත්තුවක ඇවිදිනවා නම්, ප්‍රතිපත්තිමය වශයෙන්, ඔබට ඉදිරියට යා හැකිය - ගැටළුවක් නැත. ඔබ මිනිසුන් දහස් ගණනකට සපත්තු විකුණන්නේ නම්, අපි වැලි නොමැතිව සපත්තු සාදන්නෙමු. ඔබේ සපත්තු භාවිතා කරන්නන්ගෙන් කෙනෙකු මැරතන් ධාවනය කිරීමට යන්නේ නම්, ඔබට ඉතා හොඳ සපත්තු සෑදීමට අවශ්ය වේ, ඉන්පසු ඒවා ඔබේ සියලු පරිශීලකයින්ට පරිමාණය කරන්න. එවැනි අනපේක්ෂිත පරිශීලකයින් සැමවිටම වලාකුළු පරිසරයේ සිටී. සෑම විටම පොකුර කිසියම් මුල් ආකාරයකින් ගසාකන පරිශීලකයින් සිටී. මේ සඳහා ඔබ සැමවිටම සූදානම් විය යුතුය.
අප මෙහි ඉගෙන ගෙන ඇත්තේ කුමක්ද? අපි සරල දෙයක් ඉගෙන ගත්තා: වඩාත්ම වැදගත් දෙය වන්නේ ගැටලුවක් ඇති බව සමාජයට පැහැදිලි කිරීමයි. ප්රජාව ගැටලුව හඳුනාගෙන තිබේ නම්, ගැටලුව විසඳීම සඳහා ස්වාභාවික තරඟයක් පැන නගී. මොකද හැමෝටම ඕන වැදගත් ප්රශ්නයක් විසඳගන්න. සියලුම වෙළෙන්දන්, සියලුම හැකර්වරුන් තමන්ටම මෙම පෝරකයට පා තැබිය හැකි බව තේරුම් ගෙන ඇත, එබැවින් ඔවුන්ට ඒවා ඉවත් කිරීමට අවශ්ය වේ.
ඔබ යම් ගැටලුවක් මත වැඩ කරන නමුත් එය ඔබට හැර වෙන කිසිවෙකුට කරදරයක් නොවේ නම්, නමුත් ඔබ එය ක්‍රමානුකූලව ක්රියාත්මක කර අවසානයේ එය ගැටලුවක් ලෙස සලකනු ලැබේ නම්, ඔබේ ඇදීමේ ඉල්ලීම අනිවාර්යයෙන්ම පිළිගනු ලැබේ. ඔබේ පැච් පිළිගනු ඇත, ඔබේ වැඩිදියුණු කිරීම් හෝ වැඩිදියුණු කිරීම් සඳහා ඉල්ලීම් පවා ප්රජාව විසින් සමාලෝචනය කරනු ලැබේ. දවස අවසානයේදී, අපි එකිනෙකා සඳහා දත්ත සමුදාය වඩා හොඳ කරමු.
සිත්ගන්නා දත්ත සමුදායක් වන්නේ ග්රීන්ප්ලම් ය. එය මට ඉතා හුරුපුරුදු Postgres codebase මත පදනම් වූ ඉතා සමාන්තර දත්ත සමුදායකි.
ග්රීන්ප්ලම් සිත්ගන්නා ක්‍රියාකාරීත්වයක් ඇත - ප්‍රශස්ත වගු එකතු කරන්න. මේවා ඔබට ඉක්මනින් එකතු කළ හැකි වගු වේ. ඒවා තීරු හෝ පේළිය විය හැකිය.
නමුත් පොකුරු කිරීමක් නොතිබුණි, එනම් එක් දර්ශකයක ඇති අනුපිළිවෙලට අනුකූලව වගුවේ ඇති දත්ත ඔබට සකස් කළ හැකි ක්‍රියාකාරීත්වයක් නොතිබුණි.
කුලී රථයේ සිටි අය මා වෙත පැමිණ මෙසේ පැවසීය: “ඇන්ඩ්‍රේ, ඔබ පෝස්ට්ග්‍රෙස්ව දන්නවා. තවද මෙහි එය පාහේ සමාන වේ. විනාඩි 20කට මාරු වෙන්න. ඔබ එය රැගෙන එය කරන්න. ” මම හිතුවා ඔව්, මම Postgres දන්නවා, විනාඩි 20 ක් මාරු කරනවා - මට මේක කරන්න ඕනේ.
නමුත් නැහැ, එය විනාඩි 20 ක් නොවේ, මම එය මාස ගණනක් ලිව්වා. PgConf.Russia සම්මන්ත්‍රණයේදී, මම Pivotal වෙතින් Heikki Linakangas වෙත පැමිණ මෙසේ ඇසුවෙමි: “මෙය සමඟ ගැටලු තිබේද? ඇමුණුම් ප්‍රශස්ත වගු පොකුරු නැත්තේ ඇයි?" ඔහු කියනවා: “ඔබ දත්ත ගන්න. ඔබ වර්ග කරන්න, ඔබ නැවත සකස් කරන්න. ඒක රැකියාවක් විතරයි." මම: "ඔව් ඔව්, ඔයා ඒක අරගෙන ඒක කරන්න ඕනේ." ඔහු කියනවා: “ඔව්, මේක කරන්න අපිට නිදහස් අත් අවශ්‍යයි.” මම හිතුවා මේක අනිවාර්යයෙන්ම කරන්න ඕන කියලා.
මාස කිහිපයකට පසු මම මෙම ක්‍රියාකාරිත්වය ක්රියාත්මක කරන ලද ඇදීමේ ඉල්ලීමක් ඉදිරිපත් කළෙමි. මෙම ඇදීමේ ඉල්ලීම ප්රජාව සමග එක්ව Pivotal විසින් සමාලෝචනය කරන ලදී. ඇත්ත වශයෙන්ම, දෝෂ තිබුණි.
නමුත් වඩාත්ම සිත්ගන්නා කරුණ නම් මෙම පුල් ඉල්ලීම ඒකාබද්ධ කරන විට ග්රීන්ප්ලම් තුළම දෝෂ හමු වීමයි. ගොඩ වගු සමහර විට පොකුරු විට ගනුදෙනු බිඳ දමන බව අපි සොයාගෙන ඇත. අනික මේක හදන්න ඕන දෙයක්. අනික එයා ඉන්නෙ මම අල්ලපු තැන. මගේ ස්වභාවික ප්‍රතිචාරය වූයේ - හරි, මටත් මේක කරන්න දෙන්න.
මම මේ දෝෂය නිවැරදි කළා. සවිකරන්නන් වෙත ඇදීමේ ඉල්ලීමක් යැවීය. ඔහු මරා දමන ලදී.
මෙම ක්‍රියාකාරිත්වය PostgreSQL 12 සඳහා Greenplum අනුවාදයෙන් ලබා ගත යුතු බව එයින් පසුව පෙනී ගියේය. එනම්, මිනිත්තු 20 ක වික්‍රමය නව රසවත් වික්‍රමාන්විතයන් සමඟ දිගටම පවතී. ප්රජාව නව සහ වඩාත්ම වැදගත් විශේෂාංග කපා හරින වත්මන් සංවර්ධනය ස්පර්ශ කිරීම සිත්ගන්නා සුළු විය. එය ශීත කර ඇත.
නමුත් එය එතැනින් අවසන් වූයේ නැත. සියල්ලට පසු, මේ සියල්ල සඳහා අපට ලේඛන ලිවීමට අවශ්ය බව පෙනී ගියේය.
මම ලේඛන ලිවීමට පටන් ගත්තා. වාසනාවකට මෙන්, Pivotal හි වාර්තාකරුවන් පැමිණියහ. ඉංග්‍රීසි ඔවුන්ගේ මව් භාෂාවයි. ඔවුන් මට ලියකියවිලි සමඟ උදව් කළා. ඇත්ත වශයෙන්ම, ඔවුන් විසින්ම මා යෝජනා කළ දේ සැබෑ ඉංග්‍රීසියට නැවත ලිවීය.
මෙන්න, පෙනෙන විදිහට, වික්‍රමය අවසන් විය. එතකොට ඔයා දන්නවද මොකද වුනේ කියලා? කුලී රථයේ සිටි අය මා වෙත පැමිණ මෙසේ කීහ: “තවමත් වික්‍රමාන්විතයන් දෙකක් තිබේ, එක් එක් විනාඩි 10 බැගින්.” සහ මම ඔවුන්ට කුමක් කිව යුතුද? මම කිව්වා දැන් මම පරිමාණයෙන් වාර්තාවක් දෙන්නම්, එවිට අපි ඔබේ වික්‍රමාන්විතයන් දකිමු, මන්ද මෙය සිත්ගන්නාසුළු රැකියාවකි.
මෙම නඩුවෙන් අප ඉගෙනගත්තේ කුමක්ද? විවෘත මූලාශ්‍ර සමඟ වැඩ කිරීම සැමවිටම නිශ්චිත පුද්ගලයෙකු සමඟ වැඩ කරන නිසා, එය සැමවිටම ප්රජාව සමඟ වැඩ කරයි. මක්නිසාද යත්, සෑම අදියරකදීම මම යම් සංවර්ධකයෙකු, සමහර පරීක්ෂකයෙකු, සමහර හැකර්වරුන්, සමහර වාර්තාකරුවෙකු, සමහර ගෘහ නිර්මාණ ශිල්පියෙකු සමඟ වැඩ කළෙමි. මම ග්රීන්ප්ලම් සමඟ වැඩ කළේ නැත, මම ග්රීන්ප්ලම් අවට සිටින අය සමඟ වැඩ කළෙමි.
එහෙත්! තවත් වැදගත් කරුණක් තිබේ - එය වැඩ පමණි. එනම්, ඔබ එන්න, කෝපි බොන්න, කේතය ලියන්න. සියලුම ආකාරයේ සරල වෙනස්වීම් ක්රියා කරයි. එය සාමාන්යයෙන් කරන්න - එය හොඳ වනු ඇත! ඒ වගේම ඒක හරිම රසවත් වැඩක්. Yandex.Cloud සේවාලාභීන්ගෙන් මෙම කාර්යය සඳහා ඉල්ලීමක් ඇත, Yandex ඇතුළත සහ පිටත අපගේ පොකුරු භාවිතා කරන්නන්. ඒ වගේම මම හිතන්නේ අපි සහභාගී වන ව්යාපෘති සංඛ්‍යාව වැඩි වන අතර අපගේ මැදිහත්වීමේ ගැඹුර ද වැඩි වනු ඇත.
එච්චරයි. අපි ප්රශ්න වලට යමු.
ප්රශ්න සැසිය
ආයුබෝවන්! අපට තවත් ප්‍රශ්නෝත්තර සැසියක් ඇත. සහ චිත්රාගාරයේ Andrei Borodin. විවෘත මූලාශ්‍ර සඳහා Yandex.Cloud සහ Yandex හි දායකත්වය ගැන ඔබට දැන් පැවසූ පුද්ගලයා මෙයයි. අපගේ වාර්තාව දැන් සම්පූර්ණයෙන්ම Cloud ගැන නොවේ, නමුත් ඒ සමඟම අපි එවැනි තාක්ෂණයන් මත පදනම් වේ. ඔබ Yandex තුළ කළ දේ නොමැතිව, Yandex.Cloud හි සේවාවක් නොමැත, එබැවින් මගෙන් පුද්ගලිකව ඔබට ස්තූතියි. විකාශනයේ පළමු ප්‍රශ්නය: “ඔබ සඳහන් කළ එක් එක් ව්යාපෘති ලියා ඇත්තේ කුමක්ද?”
WAL-G හි උපස්ථ පද්ධතිය Go හි ලියා ඇත. මෙය අප වැඩ කළ නවතම ව්යාපෘති වලින් එකකි. ඔහුට වචනාර්ථයෙන් වයස අවුරුදු 3 ක් පමණි. තවද දත්ත සමුදායක් බොහෝ විට විශ්වසනීයත්වය පිළිබඳ වේ. තවද මෙයින් අදහස් කරන්නේ දත්ත සමුදායන් තරමක් පැරණි වන අතර ඒවා සාමාන්යයෙන් C අකුරින් ලියා ඇති බවයි. Postgres ව්‍යාපෘතිය ආරම්භ වූයේ වසර 30කට පමණ පෙරය. එවිට C89 නිවැරදි තේරීම විය. ඒ මත Postgres ලියා ඇත. ClickHouse වැනි නවීන දත්ත සමුදායන් සාමාන්යයෙන් C++ වලින් ලියා ඇත. සියලුම පද්ධති සංවර්ධනය පදනම් වන්නේ C සහ C++ වටා ය.
ක්ලවුඩ් හි වියදම් සඳහා වගකිව යුතු අපගේ මූල්‍ය කළමනාකරුගෙන් ප්රශ්නයක්: “ක්ලවුඩ් විවෘත මූලාශ්‍ර සඳහා සහය දැක්වීම සඳහා මුදල් වියදම් කරන්නේ ඇයි?”
මෙහි මූල්‍ය කළමනාකරුට සරල පිළිතුරක් ඇත. අපි මෙය කරන්නේ අපගේ සේවාවන් වඩා හොඳ කිරීමටයි. අපට වඩා හොඳින් කළ හැක්කේ කුමන ආකාරවලින්ද? අපට දේවල් වඩාත් කාර්යක්ෂමව, වේගවත්ව සහ දේවල් වඩාත් පරිමාණය කළ හැකිය. නමුත් අපට නම්, මෙම කතාව මූලික වශයෙන් විශ්වසනීයත්වය ගැන ය. උදාහරණයක් ලෙස, උපස්ථ පද්ධතියක අපි එයට අදාළ වන පැච් වලින් 100% ක් සමාලෝචනය කරමු. කේතය කුමක්දැයි අපි දනිමු. තවද නව අනුවාදයන් නිෂ්පාදනයට ඉදිරිපත් කිරීම අපට වඩාත් පහසු වේ. එනම්, පළමුවෙන්ම, එය විශ්වාසය, සංවර්ධනය සඳහා සූදානම සහ විශ්වසනීයත්වය ගැන ය
තවත් ප්රශ්නයක්: "Yandex.Cloud හි ජීවත් වන බාහිර පරිශීලකයින්ගේ අවශ්‍යතා අභ්යන්තර වලාකුළේ ජීවත් වන අභ්යන්තර පරිශීලකයින්ට වඩා වෙනස්ද?"
පැටවුම් පැතිකඩ, ඇත්ත වශයෙන්ම, වෙනස් වේ. නමුත් මගේ දෙපාර්තමේන්තුවේ දෘෂ්ටි කෝණයෙන්, සියලු විශේෂ හා රසවත් නඩු නිර්මාණය කර ඇත්තේ සම්මත නොවන බරක් මතය. පරිකල්පනය ඇති සංවර්ධකයින්, අනපේක්ෂිත දේ කරන සංවර්ධකයින්, අභ්‍යන්තරව හා බාහිරව සොයා ගැනීමට ඉඩ ඇත. මේ සම්බන්ධයෙන්, අපි සියල්ලෝම ආසන්න වශයෙන් සමාන ය. තවද, බොහෝ විට, දත්ත සමුදායේ Yandex මෙහෙයුම තුළ ඇති එකම වැදගත් ලක්ෂණය වනුයේ Yandex තුළ අපට ඉගැන්වීමක් තිබීමයි. යම් අවස්ථාවක දී, සමහර ලබා ගත හැකි කලාපය සම්පූර්ණයෙන්ම සෙවනැල්ලට යන අතර, සියලුම Yandex සේවාවන් කෙසේ හෝ මෙය නොතකා දිගටම ක්රියාත්මක විය යුතුය. මේක පොඩි වෙනසක්. නමුත් එය දත්ත සමුදායේ සහ ජාල තොගයේ අතුරු මුහුණතේ බොහෝ පර්යේෂණ සංවර්ධනයක් නිර්මාණය කරයි. එසේ නොමැතිනම්, බාහිර සහ අභ්යන්තර ස්ථාපනයන් මඟින් විශේෂාංග සඳහා එකම ඉල්ලීම් සහ විශ්වසනීයත්වය සහ කාර්ය සාධනය වැඩි දියුණු කිරීම සඳහා සමාන ඉල්ලීම් ජනනය කරයි.
ඊළඟ ප්‍රශ්නය: "ඔබ කරන බොහෝ දේ වෙනත් වලාකුළු විසින් භාවිතා කරන බව ඔබට පෞද්ගලිකව හැඟෙන්නේ කෙසේද?" අපි නිශ්චිත ඒවා නම් නොකරමු, නමුත් Yandex.Cloud හි සිදු කරන ලද බොහෝ ව්යාපෘති වෙනත් පුද්ගලයින්ගේ වලාකුළු වල භාවිතා වේ.
මේක නම් මරු. පළමුව, එය අප හරි දෙයක් කර ඇති බවට ලකුණකි. ඒ වගේම මමත්වය සීරීමට ලක් කරනවා. ඒ වගේම අපි නිවැරදි තීරණයක් ගත් බව අපට වඩා විශ්වාසයි. අනෙක් අතට, මෙය අනාගතයේදී අපට නව අදහස්, තෙවන පාර්ශවීය පරිශීලකයින්ගෙන් නව ඉල්ලීම් ගෙන එනු ඇතැයි යන බලාපොරොත්තුව මෙයයි. GitHub එකේ ගොඩක් ප්රශ්න හදන්නේ එක එක system administrators, individual DBAs, personal architects, single engineers, එත් සමහර වෙලාවට systematic experience තියෙන අය ඇවිත් කියනවා සමහර අවස්ථාවල 30% අපිට මේ ප්‍රශ්නය තියෙනවා ඒක විසඳන්නේ කොහොමද කියලා හිතමු. අපි වැඩිපුරම බලා සිටින්නේ මෙයයි. අනෙකුත් වලාකුළු වේදිකා සමඟ අත්දැකීම් බෙදා ගැනීමට අපි බලාපොරොත්තු වෙමු.
ඔබ මැරතන් තරගය ගැන බොහෝ දේ කතා කළා. ඔබ මොස්කව්හි මැරතන් තරඟයක් පැදවූ බව මම දනිමි. ප්රතිඵලයක් වශයෙන්? PostgreSQL වෙතින් කොල්ලන් අභිබවා ගියාද?
නැහැ, Oleg Bartunov ඉතා වේගයෙන් දුවනවා. ඔහු මට වඩා පැයක් ඉදිරියෙන් අවසන් කළේය. පොදුවේ ගත් කල, මම කොපමණ දුරක් පැමිණියද යන්න ගැන මම සතුටු වෙමි. මට නම් නිකම්ම නිමා කිරීම ජයග්‍රහණයක් විය. සමස්තයක් වශයෙන්, postgres ප්රජාව තුළ බොහෝ ධාවකයන් සිටීම පුදුමයට කරුණකි. aerobic ක්‍රීඩා සහ පද්ධති ක්‍රමලේඛනය සඳහා ඇති ආශාව අතර යම් ආකාරයක සම්බන්ධයක් ඇති බව මට පෙනේ.
ඔබ කියන්නේ ClickHouse හි ධාවකයන් නොමැති බව ද?
ඔවුන් එහි සිටින බව මම නිසැකවම දනිමි. ClickHouse ද දත්ත සමුදායකි. මාර්ගය වන විට, ඔලෙග් දැන් මට ලියයි: "අපි වාර්තාවෙන් පසුව දුවන්න යමුද?" මේක නම් නියම අදහසක්.
නිකිටා වෙතින් විකාශනයෙන් තවත් ප්රශ්නයක්: “ඔබ විසින්ම ග්රීන්ප්ලම් හි දෝෂය නිවැරදි කර එය කනිෂ්ඨයන්ට ලබා නොදුන්නේ ඇයි?” ඇත්ත, දෝෂය කුමක්ද සහ කුමන සේවාවෙහිද යන්න එතරම් පැහැදිලි නැත, නමුත් එයින් අදහස් කරන්නේ ඔබ කතා කළ එකයි.
ඔව්, ප්‍රතිපත්තිමය වශයෙන්, එය යමෙකුට ලබා දිය හැකිව තිබුණි. මම දැන් වෙනස් කළේ කේතය පමණි. එය වහාම එය දිගටම කරගෙන යාම ස්වභාවික විය. ප්‍රතිපත්තිමය වශයෙන්, කණ්ඩායම සමඟ විශේෂඥ දැනුම බෙදාගැනීමේ අදහස හොඳ අදහසකි. අපි අපගේ අංශයේ සියලුම සාමාජිකයින් අතර ග්රීන්ප්ලම් කාර්යයන් අනිවාර්යයෙන්ම බෙදා ගන්නෙමු.
අපි කනිෂ්ඨයන් ගැන කතා කරන නිසා, මෙන්න ප්රශ්නයක්. පුද්ගලයා Postgres හි පළමු කැපවීම නිර්මාණය කිරීමට තීරණය කළේය. පළමු කැපවීම කිරීමට ඔහු කුමක් කළ යුතුද?
මෙය සිත්ගන්නා ප්රශ්නයකි: "ආරම්භ කළ යුත්තේ කොතැනින්ද?" සාමාන්යයෙන් කර්නලයේ ඇති දෙයකින් ආරම්භ කිරීම තරමක් අපහසුය. උදාහරණයක් ලෙස, Postgres හි, කළ යුතු දේ ලැයිස්තුවක් ඇත. නමුත් ඇත්ත වශයෙන්ම, මෙය ඔවුන් කිරීමට උත්සාහ කළ නමුත් එය සාර්ථක වූයේ නැත. මේවා සංකීර්ණ දේවල්. සාමාන්යයෙන් ඔබට පරිසර පද්ධතියේ සමහර උපයෝගිතා සොයා ගත හැකිය, වැඩිදියුණු කළ හැකි සමහර දිගු, කර්නල් සංවර්ධකයින්ගේ අවධානය අඩුයි. තවද, ඒ අනුව, එහි වර්ධනය සඳහා තවත් ලකුණු තිබේ. Google Summer of code වැඩසටහනේදී, සෑම වසරකම postgres ප්රජාව ආමන්ත්‍රණය කළ හැකි විවිධ මාතෘකා ඉදිරිපත් කරයි. මේ අවුරුද්දේ අපිට හිටියා, මම හිතන්නේ, සිසුන් තිදෙනෙක්. Yandex සඳහා වැදගත් වන මාතෘකා ගැන WAL-G හි පවා ලියා ඇත. ග්රීන්ප්ලම් හි, පෝස්ට්ග්‍රෙස් ප්‍රජාවට වඩා සියල්ල සරල ය, මන්ද ග්රීන්ප්ලම් හැකර්ස් පුල් ඉල්ලීම් ඉතා හොඳින් සලකන අතර වහාම සමාලෝචනය කිරීමට පටන් ගනී. පෝස්ට්ග්‍රෙස් වෙත පැච් එකක් යැවීම මාස ගණනක ප්රශ්නයක් වන නමුත් ග්රීන්ප්ලම් දිනකින් පැමිණ ඔබ කළ දේ බලන්න. තවත් දෙයක් නම් Greenplum වත්මන් ගැටළු විසඳීමට අවශ්ය බවය. Greenplum බහුලව භාවිතා නොවේ, එබැවින් ඔබේ ගැටලුව සොයා ගැනීම තරමක් අපහසුය. පළමුවෙන්ම, අපි ඇත්ත වශයෙන්ම ගැටළු විසඳා ගත යුතුය.
මූලාශ්රය: www.habr.com