ఏది మంచిది - ఒరాకిల్ లేదా రెడిస్ లేదా ప్లాట్‌ఫారమ్ ఎంపికను ఎలా సమర్థించాలి

"ఇది అవసరం," ఆమె ఎవరినీ ఉద్దేశించి మాట్లాడకుండా బిగ్గరగా చెప్పింది. - ఇది అవసరం! ఇది ఖచ్చితంగా చెప్పేది: వాటాదారుల ప్రయోజనాలలో లాభం పొందడం కంపెనీ యొక్క ప్రధాన పని. బాగా, దాని గురించి ఆలోచించండి! వారు దేనికీ భయపడరు!

యులీ డుబోవ్, "తక్కువ చెడు"

అటువంటి హెడ్‌లైన్‌ని చూసిన మీరు, ఆ కథనం మూర్ఖత్వమో లేదా రెచ్చగొట్టేదో అని ఇప్పటికే నిర్ణయించుకుని ఉండవచ్చు. కానీ తీర్మానాలకు తొందరపడకండి: పెద్ద సంస్థల ఉద్యోగులు, ప్రత్యేకించి రాష్ట్ర భాగస్వామ్యం ఉన్న కార్పొరేషన్లు, చాలా తరచుగా వేర్వేరు ప్లాట్‌ఫారమ్‌లను సరిపోల్చాలి, వీటిలో పూర్తిగా భిన్నమైన వాటితో సహా - ఉదాహరణకు, టైటిల్‌లో ఉన్నవి.

వాస్తవానికి, ఎవరూ ఈ విధంగా DBMSలను పోల్చరు, ఎందుకంటే వాటి బలాలు మరియు బలహీనతలు బాగా తెలుసు. నియమం ప్రకారం, కొన్ని అప్లికేషన్ సమస్యను పరిష్కరించే ప్లాట్‌ఫారమ్‌లు పోలికకు లోబడి ఉంటాయి. వ్యాసంలో నేను హబ్ర్ పాఠకులకు ప్రత్యక్షంగా తెలిసిన సబ్జెక్ట్‌గా డేటాబేస్‌ల ఉదాహరణను ఉపయోగించి, ఈ సందర్భంలో ఉపయోగించే పద్దతిని చూపుతాను. కాబట్టి,

ప్రేరణ

మీరు ఎడ్యుకేషనల్ ప్రాజెక్ట్ లేదా హాబీ ప్రాజెక్ట్‌ను ప్రారంభించినప్పుడు, ప్లాట్‌ఫారమ్‌ను ఎంచుకోవడానికి ప్రేరణ చాలా వైవిధ్యంగా ఉంటుంది: “ఇది నాకు బాగా తెలిసిన ప్లాట్‌ఫారమ్”, “దీనిని అర్థం చేసుకోవడానికి నాకు ఆసక్తి ఉంది”, “ఇక్కడ ఉత్తమ డాక్యుమెంటేషన్ ఉంది” ... వాణిజ్య సంస్థ విషయంలో, ఎంపిక ప్రమాణం ఒకే విధంగా ఉంటుంది: నేను ఎంత చెల్లించాలి మరియు ఈ డబ్బు కోసం నేను ఏమి పొందుతాను.

సహజంగానే, మీరు తక్కువ చెల్లించి ఎక్కువ పొందాలనుకుంటున్నారు. అయితే, మీరు మరింత ముఖ్యమైనది ఏమిటో నిర్ణయించుకోవాలి - తక్కువ చెల్లించడం లేదా ఎక్కువ పొందడం మరియు ప్రతి నోడ్‌కు బరువును కేటాయించడం. చౌకైన వాటి కంటే అధిక-నాణ్యత పరిష్కారం మాకు చాలా ముఖ్యమైనదని అనుకుందాం మరియు మేము "కాస్ట్" నోడ్‌కు 40% మరియు "అవకాశాలు" నోడ్‌కు 60% బరువును కేటాయిస్తాము.

పెద్ద సంస్థలలో, వ్యతిరేకం సాధారణంగా నిజం - ఖర్చు బరువు 50% కంటే తక్కువగా ఉండదు మరియు బహుశా 60% కంటే ఎక్కువ. మోడల్ ఉదాహరణలో, ముఖ్యమైనది ఏమిటంటే, ఏదైనా పేరెంట్ నోడ్ యొక్క చైల్డ్ నోడ్‌ల మొత్తం బరువు తప్పనిసరిగా 100% ఉండాలి.

కట్టింగ్ పరిస్థితులు

వెబ్సైట్ db-engines.com దాదాపు 500 డేటాబేస్ మేనేజ్‌మెంట్ సిస్టమ్‌లు ఉన్నాయి. సహజంగానే, మీరు అనేక ఎంపికల నుండి లక్ష్య ప్లాట్‌ఫారమ్‌ను ఎంచుకుంటే, మీరు సమీక్ష కథనాన్ని ముగించవచ్చు, కానీ వాణిజ్య ప్రాజెక్ట్ కాదు. ఎంపిక స్థలాన్ని తగ్గించడానికి, కట్-ఆఫ్ ప్రమాణాలు రూపొందించబడ్డాయి మరియు ప్లాట్‌ఫారమ్ ఈ ప్రమాణాలను సంతృప్తిపరచకపోతే, అది పరిగణించబడదు.

కట్-ఆఫ్ ప్రమాణాలు సాంకేతిక లక్షణాలకు సంబంధించినవి కావచ్చు, ఉదాహరణకు:

• ACID హామీలు;
• రిలేషనల్ డేటా మోడల్;
• SQL భాషా మద్దతు (గమనిక, ఇది "రిలేషనల్ మోడల్" వలె లేదు);
• క్షితిజ సమాంతర స్కేలింగ్ యొక్క అవకాశం.

సాధారణ ప్రమాణాలు ఉండవచ్చు:

• రష్యాలో వాణిజ్య మద్దతు లభ్యత;
• ఓపెన్ సోర్స్;
• టెలికాం మరియు మాస్ కమ్యూనికేషన్స్ మంత్రిత్వ శాఖ యొక్క రిజిస్టర్‌లో ప్లాట్‌ఫారమ్ లభ్యత;
• కొంత రేటింగ్‌లో ప్లాట్‌ఫారమ్ ఉనికి (ఉదాహరణకు, db-engines.com రేటింగ్‌లో మొదటి వందలో);
• మార్కెట్‌లో నిపుణుల ఉనికి (ఉదాహరణకు, వెబ్‌సైట్ hh.ruలో రెజ్యూమ్‌లో ప్లాట్‌ఫారమ్ పేరు కోసం శోధించిన ఫలితాల ఆధారంగా).

అన్నింటికంటే, ఎంటర్‌ప్రైజ్-నిర్దిష్ట ప్రమాణాలు ఉండవచ్చు:

• సిబ్బందిపై నిపుణుల లభ్యత;
• మానిటరింగ్ సిస్టమ్ X లేదా బ్యాకప్ సిస్టమ్ Yతో అనుకూలత, అన్ని మద్దతు ఆధారంగా...

అతి ముఖ్యమైన విషయం ఏమిటంటే కట్-ఆఫ్ ప్రమాణాల జాబితా ఉంది. లేకపోతే, మేనేజ్‌మెంట్ నుండి ప్రత్యేక నమ్మకాన్ని పొందే కొంతమంది నిపుణులు (లేదా "నిపుణులు") ఖచ్చితంగా ఉంటారు, వారు "మీరు ప్లాట్‌ఫారమ్ Z ను ఎందుకు ఎంచుకోలేదు, ఇది ఉత్తమమైనదని నాకు తెలుసు" అని చెబుతారు.

ఖర్చు అంచనా

పరిష్కారం యొక్క ధర స్పష్టంగా లైసెన్సుల ఖర్చు, మద్దతు ధర మరియు పరికరాల ధరలను కలిగి ఉంటుంది.

సిస్టమ్‌లు దాదాపు ఒకే తరగతిలో ఉంటే (ఉదాహరణకు, Microsoft SQL సర్వర్ మరియు PostgreSQL), అప్పుడు సరళత కోసం మేము రెండు పరిష్కారాల కోసం పరికరాల మొత్తం దాదాపు ఒకే విధంగా ఉంటుందని భావించవచ్చు. ఇది పరికరాలను అంచనా వేయకుండా మిమ్మల్ని అనుమతిస్తుంది, తద్వారా చాలా సమయం మరియు కృషిని ఆదా చేస్తుంది. మీరు పూర్తిగా భిన్నమైన వ్యవస్థలను (ఒరాకిల్ వర్సెస్ రెడిస్ అని చెప్పండి) పోల్చవలసి వస్తే, సరైన అంచనా కోసం పరిమాణాన్ని (పరికరాల మొత్తం గణన) చేయడం అవసరం అని స్పష్టంగా తెలుస్తుంది. ఉనికిలో లేని వ్యవస్థను సైజ్ చేయడం చాలా కృతజ్ఞత లేని పని, కాబట్టి వారు ఇప్పటికీ అలాంటి పోలికలను నివారించడానికి ప్రయత్నిస్తారు. దీన్ని చేయడం చాలా సులభం: కట్-ఆఫ్ పరిస్థితుల్లో, సున్నా డేటా నష్టం మరియు రిలేషనల్ మోడల్ వ్రాయబడతాయి లేదా దీనికి విరుద్ధంగా - సెకనుకు 50 వేల లావాదేవీల లోడ్.

లైసెన్స్‌లను మూల్యాంకనం చేయడానికి, నిర్ణీత సంఖ్యలో కోర్ల కోసం లైసెన్స్ ధర మరియు నిర్ణీత వ్యవధికి మద్దతు కోసం విక్రేత లేదా దాని భాగస్వాములను అడగడం సరిపోతుంది. నియమం ప్రకారం, కంపెనీలు ఇప్పటికే సాఫ్ట్‌వేర్ విక్రేతలతో బలమైన సంబంధాలను కలిగి ఉన్నాయి మరియు డేటాబేస్ కార్యకలాపాల విభాగం దాని స్వంత ఖర్చు ప్రశ్నకు సమాధానం ఇవ్వలేకపోతే, ఈ సమాచారాన్ని పొందడానికి ఒక అక్షరం సరిపోతుంది.

వేర్వేరు విక్రేతలు వేర్వేరు లైసెన్సింగ్ మెట్రిక్‌లను కలిగి ఉండవచ్చు: కోర్ల సంఖ్య, డేటా వాల్యూమ్ లేదా నోడ్‌ల సంఖ్య ద్వారా. స్టాండ్‌బై బేస్ ఉచితం కావచ్చు లేదా ప్రధానమైనదిగా అదే విధంగా లైసెన్స్ పొందవచ్చు. కొలమానాలలో ఏవైనా తేడాలు కనుగొనబడితే, మీరు మోడల్ స్టాండ్‌ను వివరంగా వివరించాలి మరియు స్టాండ్ కోసం లైసెన్స్‌ల ధరను లెక్కించాలి.

సరైన పోలిక కోసం ఒక ముఖ్యమైన అంశం అదే మద్దతు పరిస్థితులు. ఉదాహరణకు, Oracle మద్దతు సంవత్సరానికి లైసెన్స్ ధరలో 22% ఖర్చవుతుంది, కానీ మీరు PostgreSQL మద్దతు కోసం చెల్లించాల్సిన అవసరం లేదు. ఇలా పోల్చడం సరైనదేనా? లేదు, ఎందుకంటే మీ స్వంతంగా పరిష్కరించలేని లోపం పూర్తిగా భిన్నమైన పరిణామాలను కలిగి ఉంటుంది: మొదటి సందర్భంలో, మద్దతు నిపుణులు త్వరగా దాన్ని పరిష్కరించడానికి మీకు సహాయం చేస్తారు, కానీ రెండవ సందర్భంలో, ప్రాజెక్ట్ లేదా పూర్తయిన పనిని ఆలస్యం చేసే ప్రమాదం ఉంది నిరవధిక కాలానికి వ్యవస్థ.

మీరు గణన పరిస్థితులను మూడు విధాలుగా సమం చేయవచ్చు:

1. మద్దతు లేకుండా ఒరాకిల్ ఉపయోగించండి (వాస్తవానికి ఇది జరగదు).
2. PostgreSQL కోసం మద్దతును కొనుగోలు చేయండి - ఉదాహరణకు, Postgres Professional నుండి.
3. మద్దతు లేకపోవడంతో సంబంధం ఉన్న నష్టాలను పరిగణనలోకి తీసుకోండి.

ఉదాహరణకు, ప్రమాద గణన ఇలా ఉండవచ్చు: ప్రాణాంతకమైన డేటాబేస్ వైఫల్యం సంభవించినప్పుడు, సిస్టమ్ డౌన్‌టైమ్ 1 పని దినం అవుతుంది. వ్యవస్థను ఉపయోగించడం ద్వారా అంచనా వేయబడిన లాభం సంవత్సరానికి 40 బిలియన్ MNT, ప్రమాద రేటు 1/400గా అంచనా వేయబడింది, అందుచేత మద్దతు లేకపోవడం వల్ల వచ్చే ప్రమాదం సంవత్సరానికి సుమారుగా 100 మిలియన్ MNTగా అంచనా వేయబడింది. సహజంగానే, "ప్రణాళిక లాభం" మరియు "అంచనా ప్రమాద తరచుదనం" వర్చువల్ విలువలు, కానీ అలాంటి మోడల్‌ను కలిగి ఉండకుండా ఉండటం కంటే చాలా ఉత్తమం.

వాస్తవానికి, దీర్ఘ-కాల పనికిరాని సమయం యొక్క కీర్తి ఖర్చులు ఆమోదయోగ్యం కానందున సిస్టమ్ చాలా ముఖ్యమైనది కావచ్చు, కాబట్టి మద్దతు అవసరం. పనికిరాని సమయం అనుమతించబడితే, మద్దతును తిరస్కరించడం కొన్నిసార్లు డబ్బు ఆదా చేయడానికి మంచి మార్గం.

అన్ని లెక్కల తర్వాత, 5 సంవత్సరాల పాటు ఆపరేటింగ్ ప్లాట్‌ఫారమ్ A యొక్క ఖర్చు 800 మిలియన్ MNT, ఆపరేటింగ్ ప్లాట్‌ఫారమ్ B యొక్క ఖర్చు 650 మిలియన్ MNT మరియు ఆపరేటింగ్ ప్లాట్‌ఫారమ్ C యొక్క ఖర్చు 600 మిలియన్ MNT అని మనం అనుకుందాం. ప్లాట్‌ఫారమ్ C, విజేతగా, ధర కోసం పూర్తి పాయింట్‌ను అందుకుంటుంది, అయితే A మరియు B ప్లాట్‌ఫారమ్‌లు ఎన్ని రెట్లు ఎక్కువ ఖరీదుగా ఉన్నాయో దానికి అనులోమానుపాతంలో కొంచెం తక్కువగా అందుతాయి. ఈ సందర్భంలో - వరుసగా 0.75 మరియు 0.92 పాయింట్లు.

అవకాశ అంచనా

అవకాశాల అంచనా అనేక సమూహాలుగా విభజించబడింది, వీటి సంఖ్య అంచనా వేసే వ్యక్తి యొక్క ఊహ ద్వారా మాత్రమే పరిమితం చేయబడింది. ఈ సామర్థ్యాలను ఉపయోగించే బృందాలుగా సామర్థ్యాలను విభజించడం సరైన ఎంపికగా కనిపిస్తుంది; మా ఉదాహరణలో, వీరు డెవలపర్లు, నిర్వాహకులు మరియు సమాచార భద్రతా అధికారులు. ఈ ఫంక్షన్ల బరువులు 40:40:20గా పంపిణీ చేయబడతాయని అనుకుందాం.

అభివృద్ధి విధులు ఉన్నాయి:

• డేటా మానిప్యులేషన్ సౌలభ్యం;
• స్కేలింగ్;
• ద్వితీయ సూచికల ఉనికి.

ప్రమాణాల జాబితా, అలాగే వాటి బరువులు చాలా ఆత్మాశ్రయమైనవి. అదే సమస్యను పరిష్కరించేటప్పుడు కూడా, ఈ జాబితాలు, ఐటెమ్ వెయిట్‌లు మరియు సమాధానాలు మీ బృందం కూర్పుపై ఆధారపడి గణనీయంగా మారుతాయి. ఉదాహరణకు, Facebook డేటాను నిల్వ చేయడానికి MySQLని ఉపయోగిస్తుంది మరియు Instagram Cassandraలో నిర్మించబడింది. ఈ అప్లికేషన్‌ల డెవలపర్‌లు అటువంటి పట్టికలను పూరించే అవకాశం లేదు. మార్క్ జుకర్‌బర్గ్ పూర్తి స్థాయి రిలేషనల్ మోడల్‌ను ఎంచుకున్నారని, అప్లైడ్ షార్డింగ్ అవసరంతో దాని కోసం చెల్లించారని ఒకరు ఊహించవచ్చు, అయితే కెవిన్ సిస్ట్రోమ్ ప్లాట్‌ఫారమ్‌ను ఉపయోగించి స్కేలింగ్‌ను నిర్మించారు, డేటాకు ప్రాప్యత సౌలభ్యాన్ని త్యాగం చేశారు.

అడ్మినిస్ట్రేషన్ విధులు ఉన్నాయి:

• బ్యాకప్ సిస్టమ్ సామర్థ్యాలు;
• పర్యవేక్షణ సౌలభ్యం;
• సామర్థ్య నిర్వహణ సౌలభ్యం - డిస్కులు మరియు నోడ్స్;
• డేటా రెప్లికేషన్ సామర్థ్యాలు.

ప్రశ్నలు తప్పనిసరిగా పరిమాణాత్మక పద్ధతిలో ఉండాలి అని దయచేసి గమనించండి. నిర్దిష్ట ఫంక్షన్‌ను ఎలా మూల్యాంకనం చేయాలో కూడా మీరు అంగీకరించవచ్చు. ఉదాహరణకు, Oracle DBMSతో సరఫరా చేయబడిన సాధనాల ఉదాహరణను ఉపయోగించి బ్యాకప్ సాధనాలను రేట్ చేయడానికి ప్రయత్నిద్దాం:

సాధనం
వ్యాఖ్యను
మూల్యాంకనం

imp/exp
డేటాను అప్‌లోడ్ చేయడం మరియు లోడ్ చేయడం
0.1

బ్యాకప్ ప్రారంభం/ముగింపు
ఫైళ్లను కాపీ చేస్తోంది
0.3

RMAN
పెరుగుతున్న కాపీ సామర్థ్యం
0.7

ZDLRA
పెరుగుతున్న కాపీయింగ్ మాత్రమే, పాయింట్‌కి వేగవంతమైన రికవరీ
1.0

స్పష్టమైన మూల్యాంకన ప్రమాణాలు లేనట్లయితే, రేటింగ్‌లు ఇవ్వమని అనేక మంది నిపుణులను అడగడం అర్ధమే, ఆపై వాటిని సగటున చేయండి.

చివరగా, మేము సమాచార భద్రతా విధులను జాబితా చేస్తాము:

• పాస్వర్డ్ నిర్వహణ విధానాల లభ్యత;
• బాహ్య ప్రమాణీకరణ సాధనాలను (LDAP, Kerberos) కనెక్ట్ చేయగల సామర్థ్యం;
• యాక్సెస్ యొక్క రోల్ మోడల్;
• ఆడిట్ సామర్థ్యాలు;
• డిస్క్‌లో డేటా ఎన్‌క్రిప్షన్;
• నెట్‌వర్క్ (TLS) ద్వారా ప్రసార సమయంలో ఎన్‌క్రిప్షన్;
• అడ్మినిస్ట్రేటర్ నుండి డేటా రక్షణ.

పనితీరు పరీక్ష

విడిగా, మీరు వాదనలుగా చేయని ఏవైనా లోడ్ పరీక్షల ఫలితాలను ఉపయోగించకుండా నేను హెచ్చరించాలనుకుంటున్నాను.

ముందుగా, పరీక్షించబడుతున్న అప్లికేషన్‌ల యొక్క డేటా నిర్మాణం మరియు లోడ్ ప్రొఫైల్ మీరు పరిష్కరించబోయే సమస్య నుండి గణనీయంగా భిన్నంగా ఉండవచ్చు. సుమారు 10-15 సంవత్సరాల క్రితం, డేటాబేస్ విక్రేతలు TPC పరీక్షలలో సాధించిన ఫలితాలను ప్రదర్శించడానికి ఇష్టపడ్డారు, కానీ ఇప్పుడు, ఎవరూ ఈ ఫలితాలను తీవ్రంగా పరిగణించలేదు.

రెండవది, సిస్టమ్ పనితీరు కోడ్ వాస్తవానికి ఏ ప్లాట్‌ఫారమ్ కోసం వ్రాయబడింది మరియు పరీక్ష నిర్వహించబడిన పరికరాలపై చాలా బలంగా ఆధారపడి ఉంటుంది. ఒరాకిల్‌ను PostgreSQLతో పోల్చిన అనేక పరీక్షలను నేను చూశాను. ఫలితాలు ఒక వ్యవస్థ యొక్క షరతులు లేని ఆధిపత్యం నుండి మరొకటి సమానమైన షరతులు లేని ఆధిపత్యం వరకు ఉంటాయి.

చివరకు, మూడవదిగా, పరీక్ష ఎవరు చేశారో మీకు ఏమీ తెలియదు. రెండు అర్హతలు ముఖ్యమైనవి, OS మరియు ప్లాట్‌ఫారమ్‌ను సెటప్ చేసే నాణ్యతను ప్రభావితం చేస్తాయి, అలాగే ప్రేరణ, ఇది అన్ని ఇతర కారకాల కంటే పరీక్ష ఫలితాలను ఎక్కువగా ప్రభావితం చేస్తుంది.

పనితీరు కీలకమైన అంశం అయితే, ఉత్పత్తి వ్యవస్థను కాన్ఫిగర్ చేసే మరియు నిర్వహించే వ్యక్తుల సహాయంతో పరీక్షను మీరే నిర్వహించండి.

ఫలితంగా

చివరగా, చేసిన అన్ని పనుల ఫలితం స్ప్రెడ్‌షీట్‌గా ఉండాలి, ఇక్కడ అన్ని అంచనాలు కలిపి, గుణించి మరియు సంగ్రహించబడతాయి:

మీరు అర్థం చేసుకున్నట్లుగా, ప్రమాణాలను మార్చడం మరియు రేటింగ్‌లను సర్దుబాటు చేయడం ద్వారా మీరు ఏదైనా ఆశించిన ఫలితాన్ని సాధించవచ్చు, కానీ ఇది పూర్తిగా భిన్నమైన కథ...

మూలం: www.habr.com