જે વધુ સારું છે - ઓરેકલ અથવા રેડિસ અથવા પ્લેટફોર્મની પસંદગીને કેવી રીતે ન્યાયી ઠેરવવી

"આ જરૂરી છે," તેણીએ મોટેથી કહ્યું, કોઈને સંબોધ્યા વિના. - આ જરૂરી છે! આ તે કહે છે તે બરાબર છે: કંપનીનું મુખ્ય કાર્ય શેરધારકોના હિતમાં નફો કરવાનું છે. સારું, તે વિશે વિચારો! તેઓ કંઈપણથી ડરતા નથી!

યુલી ડુબોવ, "ઓછી એવિલ"

આવી હેડલાઇન જોયા પછી, તમે કદાચ પહેલેથી જ નક્કી કર્યું હશે કે લેખ કાં તો મૂર્ખતા છે અથવા ઉશ્કેરણી છે. પરંતુ નિષ્કર્ષ પર ઉતાવળ કરશો નહીં: મોટા કોર્પોરેશનોના કર્મચારીઓ, ખાસ કરીને રાજ્યની સહભાગિતા ધરાવતા કોર્પોરેશનો, ઘણી વાર જુદા જુદા પ્લેટફોર્મની તુલના કરવી પડે છે, જેમાં સંપૂર્ણપણે અલગ હોય છે - ઉદાહરણ તરીકે, તે શીર્ષકમાં છે.

અલબત્ત, આ રીતે કોઈ પણ 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