இன்னும் "எங்கள் ரகசிய பிரபஞ்சம்: செல் மறைக்கப்பட்ட வாழ்க்கை" படத்திலிருந்து

முதலீட்டு வணிகமானது வங்கி உலகில் மிகவும் சிக்கலான பகுதிகளில் ஒன்றாகும், ஏனெனில் கடன்கள், கடன்கள் மற்றும் வைப்புக்கள் மட்டுமல்ல, பத்திரங்கள், நாணயங்கள், பொருட்கள், வழித்தோன்றல்கள் மற்றும் கட்டமைக்கப்பட்ட தயாரிப்புகளின் வடிவத்தில் அனைத்து வகையான சிக்கல்களும் உள்ளன.

சமீபகாலமாக, மக்கள்தொகையின் நிதி கல்வியறிவு அதிகரிப்பதைக் கண்டோம். பத்திரச் சந்தைகளில் அதிகமான மக்கள் வர்த்தகத்தில் ஈடுபடுகின்றனர். தனிப்பட்ட முதலீட்டு கணக்குகள் மிக நீண்ட காலத்திற்கு முன்பு தோன்றவில்லை. பத்திரச் சந்தைகளை வர்த்தகம் செய்யவும், வரி விலக்குகளைப் பெறவும் அல்லது வரி செலுத்துவதைத் தவிர்க்கவும் அவை உங்களை அனுமதிக்கின்றன. எங்களிடம் வரும் அனைத்து வாடிக்கையாளர்களும் தங்கள் போர்ட்ஃபோலியோவை நிர்வகித்து, உண்மையான நேரத்தில் அறிக்கையிடுவதைப் பார்க்க விரும்புகிறார்கள். மேலும், பெரும்பாலும் இந்த போர்ட்ஃபோலியோ பல தயாரிப்பு ஆகும், அதாவது, மக்கள் பல்வேறு வணிக வரிகளின் வாடிக்கையாளர்கள்.

கூடுதலாக, ரஷ்ய மற்றும் வெளிநாட்டு கட்டுப்பாட்டாளர்களின் தேவைகள் அதிகரித்து வருகின்றன.

தற்போதைய தேவைகளைப் பூர்த்தி செய்வதற்கும், எதிர்கால மேம்பாடுகளுக்கு அடித்தளம் அமைப்பதற்கும், டாரன்டூலை அடிப்படையாகக் கொண்ட முதலீட்டு வணிக மையத்தை நாங்கள் உருவாக்கியுள்ளோம்.

சில புள்ளிவிவரங்கள். ஆல்ஃபா-வங்கியின் முதலீட்டு வணிகமானது தனிநபர்கள் மற்றும் சட்ட நிறுவனங்களுக்கு பல்வேறு பத்திரச் சந்தைகளில் வர்த்தகம் செய்வதற்கான வாய்ப்பை வழங்குகிறது, பத்திரங்களை சேமிப்பதற்கான டெபாசிட்டரி சேவைகள், தனியார் மற்றும் பெரிய மூலதனம் கொண்ட தனிநபர்களுக்கான நம்பிக்கை மேலாண்மை சேவைகள், பிற நிறுவனங்களுக்கான பத்திரங்களை வழங்குவதற்கான சேவைகள். . Alfa-Bank இன் முதலீட்டு வணிகத்தில் வினாடிக்கு 3 ஆயிரம் மேற்கோள்கள் உள்ளன, அவை பல்வேறு வர்த்தக தளங்களில் இருந்து பதிவிறக்கம் செய்யப்படுகின்றன. வேலை நாளில், வங்கி அல்லது அதன் வாடிக்கையாளர்களின் சார்பாக சந்தைகளில் 300 ஆயிரத்துக்கும் மேற்பட்ட பரிவர்த்தனைகள் முடிக்கப்படுகின்றன. வெளிப்புற மற்றும் உள் தளங்களில் வினாடிக்கு 5 ஆயிரம் ஆர்டர் செயல்படுத்தல்கள் நிகழ்கின்றன. அதே நேரத்தில், அனைத்து வாடிக்கையாளர்களும், உள் மற்றும் வெளிப்புறமாக, தங்கள் நிலைகளை உண்மையான நேரத்தில் பார்க்க விரும்புகிறார்கள்.

முன்வரலாறு

2000 களின் தொடக்கத்தில் இருந்து, எங்களுடைய முதலீட்டு வணிகத்தின் பகுதிகள் சுதந்திரமாக வளர்ந்தன: பரிமாற்ற வர்த்தகம், தரகு சேவைகள், நாணய வர்த்தகம், பத்திரங்கள் மற்றும் பல்வேறு வழித்தோன்றல்களில் எதிர் வர்த்தகம். இதனால், செயல்படும் கிணறுகளின் வலையில் விழுந்து விட்டோம். அது என்ன? ஒவ்வொரு வணிக வரியும் அதன் சொந்த அமைப்புகளைக் கொண்டுள்ளது, அவை ஒருவருக்கொருவர் செயல்பாடுகளை நகலெடுக்கின்றன. ஒவ்வொரு அமைப்புக்கும் அதன் சொந்த தரவு மாதிரி உள்ளது, இருப்பினும் அவை ஒரே கருத்துகளுடன் இயங்குகின்றன: பரிவர்த்தனைகள், கருவிகள், எதிர் கட்சிகள், மேற்கோள்கள் மற்றும் பல. ஒவ்வொரு அமைப்பும் தனித்தனியாக பரிணமித்ததால், பல்வேறு தொழில்நுட்பங்கள் தோன்றின.

கூடுதலாக, அமைப்புகளின் குறியீடு அடிப்படை ஏற்கனவே மிகவும் காலாவதியானது, ஏனெனில் சில தயாரிப்புகள் 1990 களின் நடுப்பகுதியில் தோன்றின. மேலும் சில பகுதிகளில் இது வளர்ச்சி செயல்முறையை மெதுவாக்கியது மற்றும் செயல்திறன் சிக்கல்கள் இருந்தன.

புதிய தீர்வுக்கான தேவைகள்

மேலும் வளர்ச்சிக்கு தொழில்நுட்ப மாற்றம் இன்றியமையாதது என்பதை வணிகங்கள் உணர்ந்துள்ளன. எங்களுக்கு பணிகள் வழங்கப்பட்டன:

1. அனைத்து வணிகத் தரவையும் ஒரே, வேகமான சேமிப்பகத்திலும், ஒரே தரவு மாதிரியிலும் சேகரிக்கவும்.
2. இந்தத் தகவலை நாம் இழக்கவோ மாற்றவோ கூடாது.
3. தரவைப் பதிப்பிப்பது அவசியம், ஏனென்றால் எந்த நேரத்திலும் சீராக்கி முந்தைய ஆண்டுகளுக்கான புள்ளிவிவரங்களைக் கேட்கலாம்.
4. நாம் சில புதிய, நாகரீகமான DBMSகளை மட்டும் கொண்டு வராமல், வணிகச் சிக்கல்களைத் தீர்ப்பதற்கான தளத்தை உருவாக்க வேண்டும்.

கூடுதலாக, எங்கள் கட்டிடக் கலைஞர்கள் தங்கள் சொந்த நிபந்தனைகளை அமைத்துள்ளனர்:

1. புதிய தீர்வு நிறுவன வகுப்பாக இருக்க வேண்டும், அதாவது சில பெரிய நிறுவனங்களில் இது ஏற்கனவே சோதிக்கப்பட்டிருக்க வேண்டும்.
2. தீர்வின் இயக்க முறையானது முக்கியமானதாக இருக்க வேண்டும். இதன் பொருள் நாம் ஒரே நேரத்தில் பல தரவு மையங்களில் இருக்க வேண்டும் மற்றும் ஒரு தரவு மையத்தின் செயலிழப்பை அமைதியாக வாழ வேண்டும்.
3. கணினி கிடைமட்டமாக அளவிடக்கூடியதாக இருக்க வேண்டும். உண்மை என்னவென்றால், எங்கள் தற்போதைய அமைப்புகள் அனைத்தும் செங்குத்தாக மட்டுமே அளவிடக்கூடியவை, மேலும் வன்பொருள் சக்தியின் குறைந்த வளர்ச்சியின் காரணமாக நாங்கள் ஏற்கனவே உச்சவரம்பைத் தாக்குகிறோம். எனவே, நாம் உயிர்வாழ கிடைமட்டமாக அளவிடக்கூடிய அமைப்பு இருக்க வேண்டிய தருணம் வந்துவிட்டது.
4. மற்றவற்றுடன், தீர்வு மலிவானதாக இருக்க வேண்டும் என்று நாங்கள் கூறினோம்.

நாங்கள் நிலையான வழியைப் பின்பற்றினோம்: நாங்கள் தேவைகளை உருவாக்கி, கொள்முதல் துறையைத் தொடர்புகொண்டோம். பொதுவாக, எங்களுக்காக இதைச் செய்யத் தயாராக இருக்கும் நிறுவனங்களின் பட்டியலை அங்கிருந்து பெற்றோம். பிரச்சினையைப் பற்றி எல்லோரிடமும் சொன்னோம், அவர்களில் ஆறு பேரிடமிருந்து தீர்வுகளின் மதிப்பீட்டைப் பெற்றோம்.

வங்கியில், யாருடைய வார்த்தையையும் நாங்கள் ஏற்றுக்கொள்ள மாட்டோம்; எல்லாவற்றையும் நாமே சோதிக்க விரும்புகிறோம். எனவே, எங்கள் டெண்டர் போட்டியின் கட்டாய நிபந்தனை சுமை சோதனைகளில் தேர்ச்சி பெறுவதாகும். சுமை சோதனை பணிகளை நாங்கள் உருவாக்கினோம், மேலும் ஆறு நிறுவனங்களில் மூன்று நிறுவனங்கள் அதைச் சோதிப்பதற்காக தங்கள் சொந்த செலவில் நினைவகத்தில் உள்ள தொழில்நுட்பங்களின் அடிப்படையில் ஒரு முன்மாதிரி தீர்வைச் செயல்படுத்த ஏற்கனவே ஒப்புக்கொண்டுள்ளன.

எல்லாவற்றையும் நாங்கள் எவ்வாறு சோதித்தோம், எவ்வளவு நேரம் எடுத்தோம் என்பதை நான் உங்களுக்குச் சொல்லமாட்டேன், நான் சுருக்கமாகச் சொல்கிறேன்: Mail.ru குழும மேம்பாட்டுக் குழுவின் Tarantool அடிப்படையில் ஒரு முன்மாதிரி தீர்வு மூலம் சுமை சோதனைகளில் சிறந்த செயல்திறன் காட்டப்பட்டது. நாங்கள் ஒரு ஒப்பந்தத்தில் கையெழுத்திட்டோம் மற்றும் வளர்ச்சியைத் தொடங்கினோம். Mail.ru குழுமத்திலிருந்து நான்கு பேர் இருந்தனர், மேலும் Alfa-Bank இலிருந்து மூன்று டெவலப்பர்கள், மூன்று கணினி ஆய்வாளர்கள், ஒரு தீர்வு கட்டிடக் கலைஞர், ஒரு தயாரிப்பு உரிமையாளர் மற்றும் ஒரு ஸ்க்ரம் மாஸ்டர் இருந்தனர்.

அடுத்து, எங்கள் அமைப்பு எவ்வாறு வளர்ந்தது, அது எவ்வாறு உருவானது, நாங்கள் என்ன செய்தோம், ஏன் இது பற்றிச் சொல்கிறேன்.

வடிவமைப்பு

எங்களுடைய தற்போதைய அமைப்புகளில் இருந்து தரவை எவ்வாறு பெறுவது என்பதுதான் நாங்கள் கேட்ட முதல் கேள்வி. HTTP எங்களுக்கு மிகவும் பொருத்தமானது என்று நாங்கள் முடிவு செய்தோம், ஏனென்றால் எல்லா தற்போதைய அமைப்புகளும் HTTP வழியாக XML அல்லது JSON ஐ அனுப்புவதன் மூலம் ஒருவருக்கொருவர் தொடர்பு கொள்கின்றன.

நாங்கள் SSL அமர்வுகளை நிறுத்த வேண்டிய அவசியம் இல்லாததால் Tarantool இல் கட்டமைக்கப்பட்ட HTTP சேவையகத்தைப் பயன்படுத்துகிறோம், மேலும் அதன் செயல்திறன் எங்களுக்கு போதுமானது.

நான் ஏற்கனவே கூறியது போல், எங்கள் எல்லா அமைப்புகளும் வெவ்வேறு தரவு மாதிரிகளில் வாழ்கின்றன, மேலும் உள்ளீட்டில் நாம் நம்மை விவரிக்கும் மாதிரிக்கு பொருளைக் கொண்டு வர வேண்டும். தரவை மாற்ற அனுமதிக்கும் மொழி தேவைப்பட்டது. நாங்கள் லுவாவைத் தேர்ந்தெடுத்தோம். எல்லா தரவு மாற்றக் குறியீட்டையும் சாண்ட்பாக்ஸில் இயக்குகிறோம் - இது பாதுகாப்பான இடமாகும், அதைத் தாண்டி இயங்கும் குறியீடு செல்லாது. இதைச் செய்ய, தேவையான குறியீட்டை ஏற்றி, எதையும் தடுக்கவோ கைவிடவோ முடியாத செயல்பாடுகளைக் கொண்ட சூழலை உருவாக்குகிறோம்.

மாற்றத்திற்குப் பிறகு, நாங்கள் உருவாக்கும் மாதிரியுடன் இணங்குவதற்கு தரவு சரிபார்க்கப்பட வேண்டும். என்ன மாதிரி இருக்க வேண்டும், அதை விவரிக்க என்ன மொழி பயன்படுத்த வேண்டும் என்று நாங்கள் நீண்ட நேரம் விவாதித்தோம். மொழி எளிமையானது மற்றும் டரான்டூலின் ஆதரவைக் கொண்டிருப்பதால் அப்பாச்சி அவ்ரோவைத் தேர்ந்தெடுத்தோம். மாடல் மற்றும் தனிப்பயன் குறியீட்டின் புதிய பதிப்புகள், நாளின் எந்த நேரத்திலும், சுமையின் கீழும் அல்லது இல்லாமலும் கூட, ஒரு நாளைக்கு பல முறை செயல்பாட்டில் வைக்கப்படலாம் மற்றும் மாற்றங்களை மிக விரைவாக மாற்றியமைக்கலாம்.

சரிபார்த்த பிறகு, தரவு சேமிக்கப்பட வேண்டும். நாங்கள் இதை vshard ஐப் பயன்படுத்தி செய்கிறோம் (எங்களிடம் புவி-சிதறப்பட்ட துண்டுகளின் பிரதிகள் உள்ளன).

மேலும், விவரக்குறிப்பு என்னவென்றால், எங்களுக்குத் தரவை அனுப்பும் பெரும்பாலான அமைப்புகள் நாம் அதைப் பெற்றோமா இல்லையா என்பதைப் பொருட்படுத்துவதில்லை. அதனால்தான் ஆரம்பத்திலிருந்தே பழுதுபார்க்கும் வரிசையை நடைமுறைப்படுத்தினோம். அது என்ன? சில காரணங்களால் ஒரு பொருள் தரவு மாற்றம் அல்லது சரிபார்ப்புக்கு உட்படவில்லை என்றால், நாங்கள் இன்னும் ரசீதை உறுதிப்படுத்துகிறோம், ஆனால் அதே நேரத்தில் பழுதுபார்க்கும் வரிசையில் பொருளைச் சேமிக்கவும். இது நிலையானது மற்றும் முக்கிய வணிக தரவுக் கிடங்கில் அமைந்துள்ளது. அதற்கான நிர்வாகி இடைமுகம், பல்வேறு அளவீடுகள் மற்றும் விழிப்பூட்டல்களை உடனடியாக எழுதினோம். இதன் விளைவாக, நாங்கள் தரவை இழக்க மாட்டோம். மூலத்தில் ஏதேனும் மாற்றம் ஏற்பட்டிருந்தாலும், தரவு மாதிரி மாறியிருந்தால், அதை உடனடியாகக் கண்டறிந்து மாற்றியமைக்க முடியும்.

சேமித்த தரவை எவ்வாறு மீட்டெடுப்பது என்பதை இப்போது நீங்கள் கற்றுக் கொள்ள வேண்டும். நாங்கள் எங்கள் கணினிகளை கவனமாக பகுப்பாய்வு செய்தோம், ஜாவா மற்றும் ஆரக்கிளின் கிளாசிக் ஸ்டேக்கில் தரவுகளை தொடர்புடையதாக இருந்து பொருளுக்கு மாற்றும் ஒருவித ORM அவசியமாக இருப்பதைக் கண்டோம். எனவே உடனடியாக ஒரு வரைபட வடிவில் அமைப்புகளுக்கு பொருட்களை ஏன் கொடுக்கக்கூடாது? எனவே நாங்கள் மகிழ்ச்சியுடன் GraphQL ஐ ஏற்றுக்கொண்டோம், இது எங்கள் எல்லா தேவைகளையும் பூர்த்தி செய்தது. வரைபடங்களின் வடிவத்தில் தரவைப் பெறவும், இப்போது உங்களுக்குத் தேவையானதை மட்டும் இழுக்கவும் இது உங்களை அனுமதிக்கிறது. நீங்கள் நிறைய நெகிழ்வுத்தன்மையுடன் API ஐ பதிப்பு செய்யலாம்.

நாங்கள் பிரித்தெடுக்கும் தரவு போதுமானதாக இல்லை என்பதை உடனடியாக உணர்ந்தோம். மாதிரியில் உள்ள பொருட்களுடன் இணைக்கக்கூடிய செயல்பாடுகளை நாங்கள் உருவாக்கியுள்ளோம் - அடிப்படையில், கணக்கிடப்பட்ட புலங்கள். அதாவது, புலத்தில் ஒரு குறிப்பிட்ட செயல்பாட்டை இணைக்கிறோம், எடுத்துக்காட்டாக, சராசரி மேற்கோள் விலையை கணக்கிடுகிறது. மேலும் தரவைக் கோரும் வெளிப்புற நுகர்வோருக்கு இது கணக்கிடப்பட்ட புலம் என்பது கூட தெரியாது.

ஒரு அங்கீகார அமைப்பு செயல்படுத்தப்பட்டது.

எங்கள் முடிவில் பல பாத்திரங்கள் படிகமாக இருப்பதை நாங்கள் கவனித்தோம். பங்கு என்பது ஒரு வகையான செயல்பாடுகளின் தொகுப்பாகும். பொதுவாக, பாத்திரங்கள் வெவ்வேறு உபகரண பயன்பாட்டு சுயவிவரங்களைக் கொண்டுள்ளன:

• டி-இணைப்பு: உள்வரும் இணைப்புகளைக் கையாளுகிறது, CPU வரையறுக்கப்பட்ட, குறைந்த நினைவக நுகர்வு, நிலையற்றது.
• IB-Core: Tarantool நெறிமுறை வழியாக அது பெறும் தரவை மாற்றுகிறது, அதாவது இது அட்டவணைகளுடன் செயல்படுகிறது. இது மாநிலத்தை சேமிக்காது மற்றும் அளவிடக்கூடியது.
• சேமிப்பு: தரவை மட்டுமே சேமிக்கிறது, எந்த தர்க்கத்தையும் பயன்படுத்தாது. இந்த பாத்திரம் எளிமையான இடைமுகங்களை செயல்படுத்துகிறது. vshardக்கு அளவிடக்கூடிய நன்றி.

அதாவது, பாத்திரங்களைப் பயன்படுத்தி, கிளஸ்டரின் வெவ்வேறு பகுதிகளை ஒருவருக்கொருவர் துண்டித்தோம், அவை ஒருவருக்கொருவர் சுயாதீனமாக அளவிடப்படலாம்.

எனவே, ஒத்திசைவற்ற பரிவர்த்தனை தரவு ஓட்டப் பதிவு மற்றும் நிர்வாக இடைமுகத்துடன் பழுதுபார்க்கும் வரிசையை உருவாக்கியுள்ளோம். வணிகக் கண்ணோட்டத்தில் பதிவு ஒத்திசைவற்றது: எங்கிருந்தாலும் தரவை எழுதுவதற்கு நாங்கள் உத்தரவாதம் அளிக்கப்பட்டால், அதை உறுதிப்படுத்துவோம். அது உறுதிப்படுத்தப்படவில்லை என்றால், ஏதோ தவறு நடந்துவிட்டது மற்றும் தரவு அனுப்பப்பட வேண்டும். இது ஒத்திசைவற்ற பதிவு.

சோதனை

திட்டத்தின் ஆரம்பத்திலிருந்தே, சோதனை உந்துதல் வளர்ச்சியை செயல்படுத்த முயற்சிப்போம் என்று நாங்கள் முடிவு செய்தோம். நாங்கள் டரான்டூல்/டேப் கட்டமைப்பைப் பயன்படுத்தி லுவாவில் யூனிட் சோதனைகளையும், பைடஸ்ட் கட்டமைப்பைப் பயன்படுத்தி பைத்தானில் ஒருங்கிணைப்புச் சோதனைகளையும் எழுதுகிறோம். அதே நேரத்தில், ஒருங்கிணைப்பு சோதனைகளை எழுதுவதில் டெவலப்பர்கள் மற்றும் ஆய்வாளர்கள் இருவரையும் நாங்கள் ஈடுபடுத்துகிறோம்.

சோதனை உந்துதல் மேம்பாட்டை எவ்வாறு பயன்படுத்துவது?

ஏதேனும் புதிய அம்சம் வேண்டுமெனில், அதற்கு முதலில் தேர்வு எழுத முயற்சிக்கிறோம். பிழையைக் கண்டறிந்தால், முதலில் ஒரு தேர்வை எழுதுவதை உறுதிசெய்து, பின்னர் அதைச் சரிசெய்வோம். முதலில் இதுபோன்ற வேலை செய்வது கடினம், ஊழியர்களின் தரப்பில் தவறான புரிதல் உள்ளது, நாசவேலை கூட: "இப்போது அதை விரைவாக சரிசெய்வோம், புதிதாக ஒன்றைச் செய்வோம், பின்னர் அதை சோதனைகளால் மூடுவோம்." இந்த "பின்னர்" மட்டுமே கிட்டத்தட்ட வராது.

எனவே, முதலில் தேர்வை எழுதும்படி கட்டாயப்படுத்தி, மற்றவர்களிடம் அதைச் செய்யச் சொல்ல வேண்டும். என்னை நம்புங்கள், சோதனை உந்துதல் வளர்ச்சி குறுகிய காலத்தில் கூட நன்மைகளைத் தருகிறது. உங்கள் வாழ்க்கை எளிதாகிவிட்டதாக உணர்வீர்கள். 99% குறியீடு இப்போது சோதனைகளால் மூடப்பட்டதாக நாங்கள் உணர்கிறோம். இது நிறைய போல் தெரிகிறது, ஆனால் எங்களுக்கு எந்த பிரச்சனையும் இல்லை: ஒவ்வொரு உறுதிப்பாட்டிலும் சோதனைகள் இயங்கும்.

இருப்பினும், நாங்கள் மிகவும் விரும்புவது சுமை சோதனை; நாங்கள் அதை மிக முக்கியமானதாகக் கருதுகிறோம் மற்றும் தொடர்ந்து அதைச் செயல்படுத்துகிறோம்.

முதல் பதிப்புகளில் ஒன்றின் சுமை சோதனையின் முதல் கட்டத்தை நாங்கள் எவ்வாறு மேற்கொண்டோம் என்பது பற்றிய ஒரு சிறிய கதையை நான் உங்களுக்கு சொல்கிறேன். டெவலப்பரின் மடிக்கணினியில் கணினியை நிறுவி, சுமையை இயக்கி, வினாடிக்கு 4 ஆயிரம் பரிவர்த்தனைகளைப் பெற்றோம். மடிக்கணினிக்கு நல்ல முடிவு. உற்பத்தியை விட பலவீனமான நான்கு சேவையகங்களின் மெய்நிகர் சுமை பெஞ்சில் இதை நிறுவியுள்ளோம். குறைந்தபட்சம் பயன்படுத்தப்பட்டது. நாங்கள் அதை இயக்குகிறோம், ஒரு நூலில் மடிக்கணினியை விட மோசமான முடிவைப் பெறுகிறோம். அதிர்ச்சி உள்ளடக்கம்.

நாங்கள் மிகவும் வருத்தப்பட்டோம். நாங்கள் சர்வர் சுமையைப் பார்க்கிறோம், ஆனால் அவை செயலற்றதாக மாறிவிடும்.

நாங்கள் டெவலப்பர்களை அழைக்கிறோம், அவர்கள் எங்களுக்கு விளக்குகிறார்கள், ஜாவா உலகில் இருந்து வருபவர்கள், டரான்டூல் ஒற்றை நூல் என்று. சுமையின் கீழ் உள்ள ஒரு செயலி மையத்தால் மட்டுமே இதை திறம்பட பயன்படுத்த முடியும். ஒவ்வொரு சேவையகத்திலும் சாத்தியமான அதிகபட்ச டரான்டூல் நிகழ்வுகளை நாங்கள் பயன்படுத்தினோம், சுமைகளை இயக்கி ஏற்கனவே வினாடிக்கு 14,5 ஆயிரம் பரிவர்த்தனைகளைப் பெற்றுள்ளோம்.

மீண்டும் விளக்குகிறேன். வளங்களை வித்தியாசமாகப் பயன்படுத்தும் பாத்திரங்களாகப் பிரிப்பதன் காரணமாக, செயலாக்க இணைப்புகள் மற்றும் தரவு மாற்றத்திற்குப் பொறுப்பான எங்கள் பாத்திரங்கள் செயலியை மட்டுமே ஏற்றுகின்றன, மேலும் சுமைக்கு கண்டிப்பாக விகிதாசாரமாகும்.

இந்த வழக்கில், உள்வரும் இணைப்புகள் மற்றும் தற்காலிக பொருட்களை செயலாக்க மட்டுமே நினைவகம் பயன்படுத்தப்பட்டது.

மாறாக, சேமிப்பக சேவையகங்களில், செயலி சுமை அதிகரித்தது, ஆனால் இணைப்புகளைச் செயலாக்கும் சேவையகங்களைக் காட்டிலும் மிகவும் மெதுவாக உள்ளது.

மற்றும் நினைவக நுகர்வு ஏற்றப்பட்ட தரவு அளவிற்கு நேரடி விகிதத்தில் வளர்ந்தது.

சேவைகள்

எங்கள் புதிய தயாரிப்பை குறிப்பாக பயன்பாட்டு தளமாக உருவாக்க, அதில் சேவைகள் மற்றும் நூலகங்களைப் பயன்படுத்துவதற்கான ஒரு கூறுகளை நாங்கள் உருவாக்கியுள்ளோம்.

சேவைகள் என்பது சில துறைகளில் செயல்படும் சிறிய குறியீடுகள் மட்டுமல்ல. அவை மிகவும் பெரிய மற்றும் சிக்கலான கட்டமைப்புகளாக இருக்கலாம், அவை ஒரு கிளஸ்டரின் ஒரு பகுதியாக இருக்கலாம், குறிப்புத் தரவைச் சரிபார்க்கலாம், வணிக தர்க்கத்தை இயக்கலாம் மற்றும் பதில்களை வழங்கலாம். நாங்கள் சேவைத் திட்டத்தை GraphQL க்கு ஏற்றுமதி செய்கிறோம், மேலும் நுகர்வோர் தரவுக்கான உலகளாவிய அணுகல் புள்ளியைப் பெறுகிறார், முழு மாதிரியிலும் உள்நோக்கத்துடன். இது மிகவும் வசதியானது.

சேவைகளில் இன்னும் பல செயல்பாடுகள் இருப்பதால், அடிக்கடி பயன்படுத்தப்படும் குறியீட்டை நகர்த்தும் நூலகங்கள் இருக்க வேண்டும் என்று முடிவு செய்தோம். இது எங்களுக்கு எதையும் உடைக்காதா என்பதை முன்பே சரிபார்த்த நாங்கள் அவற்றை பாதுகாப்பான சூழலில் சேர்த்தோம். இப்போது நூலகங்களின் வடிவத்தில் செயல்பாடுகளுக்கு கூடுதல் சூழல்களை ஒதுக்கலாம்.

சேமிப்பிற்கு மட்டுமல்ல, கம்ப்யூட்டிங்கிற்கும் ஒரு தளம் இருக்க வேண்டும் என்று நாங்கள் விரும்பினோம். எங்களிடம் ஏற்கனவே ஏராளமான பிரதிகள் மற்றும் துண்டுகள் இருப்பதால், நாங்கள் ஒரு வகையான விநியோகிக்கப்பட்ட கணினியை செயல்படுத்தினோம் மற்றும் அதை வரைபடக் குறைப்பு என்று அழைத்தோம், ஏனெனில் இது அசல் வரைபடக் குறைப்பைப் போலவே மாறியது.

பழைய அமைப்புகள்

எங்களின் அனைத்து மரபு அமைப்புகளும் HTTP மூலம் எங்களை அழைக்க முடியாது மற்றும் GraphQL ஐப் பயன்படுத்த முடியாது, இருப்பினும் அவை நெறிமுறையை ஆதரிக்கின்றன. எனவே, இந்த அமைப்புகளில் தரவை நகலெடுக்க அனுமதிக்கும் பொறிமுறையை நாங்கள் உருவாக்கியுள்ளோம்.

நமக்கு ஏதாவது மாற்றம் ஏற்பட்டால், தனிப்பட்ட தூண்டுதல்கள் சேமிப்பகப் பாத்திரத்தில் தூண்டப்படும் மற்றும் மாற்றங்களுடன் கூடிய செய்தி செயலாக்க வரிசையில் முடிவடையும். இது ஒரு தனி பிரதிப் பாத்திரத்தைப் பயன்படுத்தி வெளிப்புற அமைப்புக்கு அனுப்பப்படுகிறது. இந்த பாத்திரம் மாநிலத்தை சேமிக்காது.

புதிய மேம்பாடுகள்

நீங்கள் நினைவில் வைத்திருப்பது போல், வணிகக் கண்ணோட்டத்தில், நாங்கள் ஒத்திசைவற்ற பதிவு செய்தோம். ஆனால் அது போதுமானதாக இருக்காது என்பதை அவர்கள் உணர்ந்தனர், ஏனென்றால் செயல்பாட்டின் நிலை குறித்து உடனடியாக பதிலைப் பெற வேண்டிய ஒரு வகை அமைப்புகள் உள்ளன. எனவே எங்கள் GraphQL ஐ நீட்டித்து பிறழ்வுகளைச் சேர்த்தோம். தரவுகளுடன் பணிபுரியும் தற்போதைய முன்னுதாரணத்திற்கு அவை இயல்பாக பொருந்துகின்றன. எங்களைப் பொறுத்தவரை, இது மற்றொரு வகை அமைப்புகளுக்கு வாசிப்பது மற்றும் எழுதுவது ஆகிய இரண்டின் ஒரு புள்ளியாகும்.

சேவைகள் மட்டுமே எங்களுக்கு போதுமானதாக இருக்காது என்பதையும் நாங்கள் உணர்ந்தோம், ஏனென்றால் ஒரு நாளைக்கு, ஒரு வாரத்திற்கு, ஒரு மாதத்திற்கு ஒரு முறை உருவாக்கப்பட வேண்டிய கடுமையான அறிக்கைகள் உள்ளன. இதற்கு நீண்ட நேரம் ஆகலாம், மேலும் அறிக்கைகள் டரான்டூலின் நிகழ்வு வளையத்தைத் தடுக்கலாம். எனவே, நாங்கள் தனித்தனி பாத்திரங்களை உருவாக்கினோம்: திட்டமிடுபவர் மற்றும் ரன்னர். ரன்னர்கள் மாநிலத்தை சேமிப்பதில்லை. பறக்கும்போது நாம் கணக்கிட முடியாத கனமான பணிகளை அவை இயக்குகின்றன. திட்டமிடுபவர் பங்கு இந்த பணிகளின் வெளியீட்டு அட்டவணையை கண்காணிக்கிறது, இது கட்டமைப்பில் விவரிக்கப்பட்டுள்ளது. பணிகள் வணிகத் தரவுகளின் அதே இடத்தில் சேமிக்கப்படுகின்றன. சரியான நேரம் வரும்போது, ​​திட்டமிடுபவர் பணியை எடுத்துக்கொள்கிறார், அதை சில ரன்னர்களுக்குக் கொடுக்கிறார், அவர் அதை எண்ணி முடிவைச் சேமிக்கிறார்.

அனைத்து பணிகளும் ஒரு அட்டவணையில் செய்யப்பட வேண்டியதில்லை. சில அறிக்கைகள் தேவைக்கேற்ப படிக்க வேண்டும். இந்தத் தேவை வந்தவுடன், சாண்ட்பாக்ஸில் ஒரு பணி உருவாக்கப்பட்டு, அதைச் செயல்படுத்த ரன்னருக்கு அனுப்பப்படும். சிறிது நேரம் கழித்து, பயனர் ஒரு ஒத்திசைவற்ற பதிலைப் பெறுகிறார், எல்லாம் கணக்கிடப்பட்டு அறிக்கை தயாராக உள்ளது.

ஆரம்பத்தில், எல்லா தரவையும் சேமித்து வைப்பது, பதிப்பிப்பது மற்றும் நீக்காமல் இருப்பது போன்ற முன்னுதாரணத்தை நாங்கள் கடைபிடித்தோம். ஆனால் வாழ்க்கையில், அவ்வப்போது நீங்கள் எதையாவது நீக்க வேண்டும், பெரும்பாலும் சில மூல அல்லது இடைநிலை தகவல்கள். காலாவதியானதன் அடிப்படையில், காலாவதியான தரவிலிருந்து சேமிப்பகத்தை சுத்தம் செய்வதற்கான ஒரு பொறிமுறையை நாங்கள் உருவாக்கியுள்ளோம்.

நினைவகத்தில் தரவைச் சேமிக்க போதுமான இடம் இல்லாத சூழ்நிலை விரைவில் அல்லது பின்னர் வரும் என்பதையும் நாங்கள் புரிந்துகொள்கிறோம், இருப்பினும் தரவு சேமிக்கப்பட வேண்டும். இந்த நோக்கங்களுக்காக, நாங்கள் விரைவில் வட்டு சேமிப்பகத்தை உருவாக்குவோம்.

முடிவுக்கு

ஒரே மாதிரியாக டேட்டாவை ஏற்றும் பணியைத் தொடங்கி, மூன்று மாதங்கள் அதை உருவாக்கினோம். எங்களிடம் ஆறு தரவு விநியோக அமைப்புகள் இருந்தன. முழு உருமாற்றக் குறியீடும் ஒரே மாதிரியாக லுவாவில் சுமார் 30 ஆயிரம் வரிகள். மேலும் பெரும்பாலான பணிகள் இன்னும் முன்னால் உள்ளன. சில நேரங்களில் அண்டை அணிகளில் இருந்து உந்துதல் பற்றாக்குறை உள்ளது, மேலும் வேலையை சிக்கலாக்கும் பல சூழ்நிலைகள் உள்ளன. நீங்கள் எப்போதாவது இதேபோன்ற பணியை எதிர்கொண்டால், அதைச் செயல்படுத்த உங்களுக்கு சாதாரணமாகத் தோன்றும் நேரத்தை மூன்றால் அல்லது நான்கால் பெருக்கவும்.

வணிக செயல்முறைகளில் இருக்கும் சிக்கல்களை புதிய DBMS ஐப் பயன்படுத்தி தீர்க்க முடியாது என்பதையும் நினைவில் கொள்ளுங்கள். நான் என்ன சொல்ல வருகிறேனென்றால்? எங்கள் திட்டத்தின் தொடக்கத்தில், இப்போது நாங்கள் ஒரு புதிய வேகமான தரவுத்தளத்தைக் கொண்டு வருவோம், நாங்கள் வாழ்வோம் என்ற எண்ணத்தை வாடிக்கையாளர்களிடையே உருவாக்கினோம்! செயல்முறைகள் வேகமாக நடக்கும், எல்லாம் சரியாகிவிடும். உண்மையில், தொழில் நுட்பம் வணிக செயல்முறைகளில் உள்ள சிக்கல்களை தீர்க்காது, ஏனெனில் வணிக செயல்முறைகள் மக்கள். நீங்கள் மக்களுடன் வேலை செய்ய வேண்டும், தொழில்நுட்பம் அல்ல.

சோதனை உந்துதல் வளர்ச்சி ஆரம்ப கட்டங்களில் வலி மற்றும் நேரத்தை எடுத்துக்கொள்ளும். ஆனால் அதன் நேர்மறையான விளைவு குறுகிய காலத்தில் கூட கவனிக்கப்படும், பின்னடைவு சோதனை நடத்த நீங்கள் எதுவும் செய்ய வேண்டியதில்லை.

வளர்ச்சியின் அனைத்து நிலைகளிலும் சுமை சோதனை நடத்துவது மிகவும் முக்கியம். கட்டிடக்கலையில் சில குறைகளை நீங்கள் விரைவில் கவனிக்கிறீர்கள், அதைச் சரிசெய்வது எளிதாக இருக்கும், இது எதிர்காலத்தில் உங்களுக்கு நிறைய நேரத்தை மிச்சப்படுத்தும்.

லுவாவில் எந்தத் தவறும் இல்லை. ஜாவா டெவலப்பர், ஜாவாஸ்கிரிப்ட் டெவலப்பர், பைதான் டெவலப்பர், முன்-இறுதி அல்லது பின்-இறுதியில் யார் வேண்டுமானாலும் எழுத கற்றுக்கொள்ளலாம். நமது ஆய்வாளர்கள் கூட அதில் எழுதுகிறார்கள்.

எங்களிடம் SQL இல்லை என்ற உண்மையைப் பற்றி பேசும்போது, ​​​​அது மக்களை பயமுறுத்துகிறது. “SQL இல்லாமல் தரவை எவ்வாறு பெறுவது? அது சாத்தியமா? நிச்சயமாக. OLTP வகுப்பு அமைப்பில், SQL தேவையில்லை. சில வகையான மொழியின் வடிவத்தில் ஒரு மாற்று உள்ளது, அது உடனடியாக ஆவணம் சார்ந்த பார்வைக்கு உங்களைத் திருப்பிவிடும். உதாரணமாக, GraphQL. விநியோகிக்கப்பட்ட கணினி வடிவத்தில் ஒரு மாற்று உள்ளது.

நீங்கள் அளவிட வேண்டும் என்பதை நீங்கள் புரிந்து கொண்டால், டரன்டூலில் உங்கள் தீர்வை வடிவமைக்கவும், அது டஜன் கணக்கான டரான்டூல் நிகழ்வுகளுக்கு இணையாக இயங்கும். நீங்கள் இதைச் செய்யாவிட்டால், அது கடினமாகவும் வலியாகவும் இருக்கும், ஏனெனில் டரான்டூல் ஒரு செயலி மையத்தை மட்டுமே திறம்பட பயன்படுத்த முடியும்.

ஆதாரம்: www.habr.com