பில்டர்களுக்கான B2B சேவையின் உதாரணத்தைப் பயன்படுத்தி தரவுத்தள வினவல்களை மேம்படுத்துதல்

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

கட்டுமான நிறுவனங்களில் வணிக செயல்முறைகளை நிர்வகிப்பதற்கான சேவையை நான் செய்கிறேன். சுமார் 3 ஆயிரம் நிறுவனங்கள் எங்களுடன் இணைந்து செயல்படுகின்றன. ஒவ்வொரு நாளும் 10-4 மணி நேரம் எங்கள் அமைப்பில் 10 ஆயிரத்துக்கும் மேற்பட்டோர் வேலை செய்கிறார்கள். இது திட்டமிடல், அறிவிப்பு, எச்சரிக்கை, சரிபார்த்தல் போன்ற பல்வேறு சிக்கல்களைத் தீர்க்கிறது... PostgreSQL 9.6 ஐப் பயன்படுத்துகிறோம். தரவுத்தளத்தில் எங்களிடம் சுமார் 300 அட்டவணைகள் உள்ளன, மேலும் ஒவ்வொரு நாளும் 200 மில்லியன் வினவல்கள் (10 ஆயிரம் வித்தியாசமானவை) பெறப்படுகின்றன. சராசரியாக ஒரு வினாடிக்கு 3-4 ஆயிரம் கோரிக்கைகள் உள்ளன, மிகவும் சுறுசுறுப்பான தருணங்களில் வினாடிக்கு 10 ஆயிரத்துக்கும் மேற்பட்ட கோரிக்கைகள் உள்ளன. பெரும்பாலான வினவல்கள் OLAP ஆகும். மிகக் குறைவான சேர்த்தல்கள், மாற்றங்கள் மற்றும் நீக்குதல்கள் உள்ளன, அதாவது OLTP சுமை ஒப்பீட்டளவில் குறைவாக உள்ளது. இந்த எண்கள் அனைத்தையும் நான் வழங்கியுள்ளேன், இதன் மூலம் எங்கள் திட்டத்தின் அளவை நீங்கள் மதிப்பிடலாம் மற்றும் எங்கள் அனுபவம் உங்களுக்கு எவ்வளவு பயனுள்ளதாக இருக்கும் என்பதைப் புரிந்து கொள்ளலாம்.

படம் ஒன்று. பாடல் வரிகள்

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

படம் இரண்டு. புள்ளியியல்

எனவே ஒரு நாளைக்கு எங்கள் தரவுத்தளத்தில் சுமார் 10 ஆயிரம் வெவ்வேறு வினவல்கள் செயல்படுத்தப்படுகின்றன. இந்த 10 ஆயிரத்தில், சராசரியாக 2-3 எம்எஸ் செயல்பாட்டு நேரத்துடன் 0.1-0.3 மில்லியன் முறை செயல்படுத்தப்படும் அரக்கர்கள் உள்ளனர், மேலும் ஒரு நாளைக்கு 30 முறை என்று அழைக்கப்படும் 100 வினாடிகளின் சராசரி செயல்பாட்டு நேரத்துடன் வினவல்கள் உள்ளன.

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

முக்கிய கோரிக்கைகள்

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

அனைத்து நிறுவனங்களின் வழக்கமான நடைமுறை TOP கோரிக்கைகளுடன் வேலை செய்வதாகும். அவற்றில் சில உள்ளன; ஒரு வினவலைக் கூட மேம்படுத்துவது 5-10% வளங்களை விடுவிக்கும். எவ்வாறாயினும், திட்டம் முதிர்ச்சியடையும் போது, ​​TOP வினவல்களை மேம்படுத்துவது பெருகிய முறையில் அற்பமான செயல் அல்ல. அனைத்து எளிய முறைகளும் ஏற்கனவே வேலை செய்யப்பட்டுள்ளன, மேலும் "கனமான" கோரிக்கையானது "மட்டும்" 3-5% வளங்களை எடுக்கும். மொத்தத்தில் TOP வினவல்கள் 30-40% க்கும் குறைவான நேரத்தை எடுத்துக் கொண்டால், அவற்றை விரைவாகச் செயல்பட வைக்க நீங்கள் ஏற்கனவே முயற்சி செய்துள்ளீர்கள், மேலும் அடுத்த குழுவிலிருந்து வினவல்களை மேம்படுத்துவதற்கான நேரம் இது.
இந்தக் குழுவில் எத்தனை முக்கிய வினவல்கள் சேர்க்கப்பட வேண்டும் என்ற கேள்விக்கு இது பதிலளிக்க வேண்டும். நான் வழக்கமாக குறைந்தபட்சம் 10 ஐ எடுத்துக்கொள்கிறேன், ஆனால் 20 க்கு மேல் இல்லை. TOP குழுவில் முதல் மற்றும் கடைசி நேரம் 10 மடங்குக்கு மேல் வேறுபடாமல் இருப்பதை உறுதிசெய்ய முயற்சிக்கிறேன். அதாவது, வினவல் செயல்படுத்தும் நேரம் 1 வது இடத்திலிருந்து 10 வது இடத்திற்கு கடுமையாகக் குறைந்தால், நான் TOP-10 ஐ எடுத்துக்கொள்கிறேன், வீழ்ச்சி படிப்படியாக இருந்தால், குழு அளவை 15 அல்லது 20 ஆக அதிகரிக்கிறேன்.

நடுத்தர விவசாயிகள்

இவை அனைத்தும் கடைசி 5-10% தவிர, TOPக்குப் பிறகு உடனடியாக வரும் கோரிக்கைகள். பொதுவாக, இந்த வினவல்களை மேம்படுத்துவதில் சர்வர் செயல்திறனை பெரிதும் அதிகரிக்க வாய்ப்பு உள்ளது. இந்த கோரிக்கைகள் 80% வரை இருக்கும். ஆனால் அவர்களின் பங்கு 50% ஐத் தாண்டியிருந்தாலும், அவற்றை இன்னும் கவனமாகப் பார்க்க வேண்டிய நேரம் இது.

வால்

குறிப்பிட்டுள்ளபடி, இந்த வினவல்கள் இறுதியில் வந்து 5-10% நேரத்தை எடுக்கும். நீங்கள் தானியங்கி வினவல் பகுப்பாய்வு கருவிகளைப் பயன்படுத்தாவிட்டால் மட்டுமே அவற்றைப் பற்றி மறந்துவிடலாம், பின்னர் அவற்றை மேம்படுத்துவதும் மலிவானதாக இருக்கும்.

ஒவ்வொரு குழுவையும் எவ்வாறு மதிப்பிடுவது?

PostgreSQL க்கு அத்தகைய மதிப்பீட்டை மேற்கொள்ள உதவும் SQL வினவலை நான் பயன்படுத்துகிறேன் (இதேபோன்ற வினவல் வேறு பல DBMS களுக்கும் எழுதப்படலாம் என்று நான் நம்புகிறேன்)

TOP-MEDIUM-TAIL குழுக்களின் அளவை மதிப்பிட SQL வினவல்

SELECT sum(time_top) AS sum_top, sum(time_medium) AS sum_medium, sum(time_tail) AS sum_tail
FROM
(
  SELECT CASE WHEN rn <= 20              THEN tt_percent ELSE 0 END AS time_top,
         CASE WHEN rn > 20 AND rn <= 800 THEN tt_percent ELSE 0 END AS time_medium,
         CASE WHEN rn > 800              THEN tt_percent ELSE 0 END AS time_tail
  FROM (
    SELECT total_time / (SELECT sum(total_time) FROM pg_stat_statements) * 100 AS tt_percent, query,
    ROW_NUMBER () OVER (ORDER BY total_time DESC) AS rn
    FROM pg_stat_statements
    ORDER BY total_time DESC
  ) AS t
)
AS ts

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

தேர்வுமுறை வேலை தொடங்கிய நேரத்திலும் இப்போது கோரிக்கைகளின் பங்குகளும் தோராயமாக ஒப்பிடுவது இதுதான்.

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

கோரிக்கைகளின் உரையைப் பெற, பின்வரும் கோரிக்கையைப் பயன்படுத்துகிறோம்

SELECT * FROM (
  SELECT ROW_NUMBER () OVER (ORDER BY total_time DESC) AS rn, total_time / (SELECT sum(total_time) FROM pg_stat_statements) * 100 AS tt_percent, query
  FROM pg_stat_statements
  ORDER BY total_time DESC
) AS T
WHERE
rn <= 20 -- TOP
-- rn > 20 AND rn <= 800 -- MEDIUM
-- rn > 800  -- TAIL

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

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

சில நேரங்களில் மாற்றங்கள் ஈர்க்கக்கூடிய மறுவடிவமைப்புக்கு சமமானவை, ஆனால் அவை கணினி சுமைகளில் 5-10% வழங்கின மற்றும் நியாயப்படுத்தப்பட்டன. காலப்போக்கில், வெளியேற்றமானது சிறியதாகவும் சிறியதாகவும் மாறியது, மேலும் மேலும் தீவிரமான மறுவடிவமைப்பு தேவைப்பட்டது.

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

• COUNT மற்றும் முழு டேபிள் ஸ்கேன் ஆகியவற்றைப் பயன்படுத்தி பதிவுகள் உள்ளனவா என்பதைச் சரிபார்ப்பதற்குப் பதிலாக, EXISTS பயன்படுத்தத் தொடங்கியது
• DISTINCT இல் இருந்து விடுபட்டது (பொது செய்முறை எதுவும் இல்லை, ஆனால் சில சமயங்களில் கோரிக்கையை 10-100 மடங்கு விரைவுபடுத்துவதன் மூலம் அதை எளிதாக அகற்றலாம்).

  எடுத்துக்காட்டாக, ஒரு பெரிய டெலிவரி அட்டவணையில் (டெலிவரி) இருந்து அனைத்து இயக்கிகளையும் தேர்ந்தெடுப்பதற்கான வினவலுக்குப் பதிலாக

  SELECT DISTINCT P.ID, P.FIRST_NAME, P.LAST_NAME
  FROM DELIVERY D JOIN PERSON P ON D.DRIVER_ID = P.ID
  

  ஒப்பீட்டளவில் சிறிய அட்டவணை நபர் மீது வினவினார்

  SELECT P.ID, P.FIRST_NAME, P.LAST_NAME
  FROM PERSON
  WHERE EXISTS(SELECT D.ID FROM DELIVERY WHERE D.DRIVER_ID = P.ID)
  

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

• பல சந்தர்ப்பங்களில், COUNT முற்றிலும் கைவிடப்பட்டது மற்றும்
  தோராயமான மதிப்பைக் கணக்கிடுவதன் மூலம் மாற்றப்பட்டது
• அதற்கு பதிலாக

  UPPER(s) LIKE JOHN%’ 
  

  используем

  s ILIKE “John%”
  

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

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

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

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