Кайсынысы жакшы - Oracle же Redis же платформаны тандоону кантип актоо керек

"Бул керек", - деди ал катуу үн менен, эч кимге кайрылбай. - Бул керек! Дал мына ушундай деп айтылат: компаниянын негизги милдети – акционерлердин кызыкчылыгында пайда алуу. Мейли, ойлонуп көр! Алар эч нерседен коркпойт!

Юлий Дубов, "Кичине жамандык"

Мындай баш макаланы көрүп, сиз макаланы келесоолук же провокация деп чечкен чыгарсыз. Бирок тыянак чыгарууга шашпаңыз: ири корпорациялардын кызматкерлери, айрыкча мамлекеттин катышуусу бар корпорациялар, көбүнчө ар кандай платформаларды, анын ичинде такыр башкаларды - мисалы, аталыштагыларды салыштырууга туура келет.

Кайсынысы жакшы - Oracle же Redis же платформаны тандоону кантип актоо керек

Албетте, эч ким МББды минтип салыштырбайт, анткени алардын күчтүү жана алсыз жактары белгилүү. Эреже катары, кээ бир колдонмо маселесин чечүүчү платформалар салыштырууга жатат. Макалада мен бул учурда колдонулган методологияны көрсөтөм, маалымат базаларынын мисалын Хабр окурмандарына биринчи жолу тааныш болгон тема катары колдоном. Ошентип,

жөнүн көрсөтүү

Сиз билим берүү долбоорун же хобби долбоорун баштаганда, платформаны тандоо мотивациясы абдан ар түрдүү болушу мүмкүн: "бул мен эң жакшы билген платформа", "мен муну түшүнүүгө кызыгам", "бул жерде эң мыкты документация" ...Коммерциялык компанияда тандоо критерийи бирдей: мен канча төлөшүм керек жана бул акчага эмне алам.

Албетте, сиз аз төлөп, көбүрөөк алгыңыз келет. Бирок, сиз эмне маанилүүрөөк экенин чечишиңиз керек - азыраак төлөө же көбүрөөк алуу жана ар бир түйүнгө салмакты дайындоо. Келгиле, биз үчүн арзанга караганда жогорку сапаттагы чечим маанилүү деп ойлойлу жана биз "Чыгым" түйүнүнө 40%, ал эми "Мүмкүнчүлүктөр" түйүнүнө 60% салмак ыйгарабыз.

Кайсынысы жакшы - Oracle же Redis же платформаны тандоону кантип актоо керек

Ири корпорацияларда, адатта, тескерисинче болот - чыгымдын салмагы 50% дан төмөн түшпөйт, балким 60% дан ашат. Үлгү мисалында, эң негизгиси, кандайдыр бир ата-эне түйүнүнүн бала түйүндөрүнүн жалпы салмагы 100% болушу керек.

Кесүү шарттары

Вебсайт db-engines.com 500гө жакын маалымат базасын башкаруу системасы белгилүү. Албетте, эгерде сиз көптөгөн варианттардын ичинен максаттуу платформаны тандасаңыз, анда сиз коммерциялык долбоор эмес, карап чыгуу макаласына ээ болушуңуз мүмкүн. Тандоо мейкиндигин азайтуу үчүн, чектөө критерийлери түзүлөт, эгерде платформа бул критерийлерге жооп бербесе, анда ал каралбайт.

Кесүү критерийлери технологиялык өзгөчөлүктөргө байланыштуу болушу мүмкүн, мисалы:

  • ACID кепилдиктери;
  • реляциялык маалыматтар модели;
  • SQL тилин колдоо (көңүл буруңуз, бул "байланыш модели" менен бирдей эмес);
  • горизонталдуу масштабдоо мүмкүнчүлүгү.

Жалпы критерийлер болушу мүмкүн:

  • Россияда коммерциялык колдоонун болушу;
  • ачык булак;
  • Телекоммуникация жана массалык коммуникациялар министрлигинин реестринде платформанын болушу;
  • кандайдыр бир рейтингде платформанын болушу (мисалы, db-engines.com рейтингинин биринчи жүздүгүндө);
  • рынокто эксперттердин болушу (мисалы, hh.ru сайтында резюмеде платформанын атын издөөнүн жыйынтыгы боюнча).

Анткени, ишкананын өзгөчө критерийлери болушу мүмкүн:

  • штатта адистердин болушу;
  • бардык колдоо негизделген X мониторинг системасы же резервдик Y системасы менен шайкештик...

Эң негизгиси, кесүү критерийлеринин тизмеси бар. Болбосо, жетекчиликтин өзгөчө ишенимине ээ болгон кандайдыр бир эксперт (же “эксперт”) сөзсүз болот, алар “эмне үчүн Z платформасын тандаган жоксуңар, мен бул эң жакшы экенин билем” деп айтышат.

Чыгым сметасы

Чечүүнүн баасы, албетте, лицензиялардын наркынан, колдоо көрсөтүүгө кеткен чыгымдардан жана жабдуулардын наркынан турат.

Эгерде системалар болжол менен бирдей класста болсо (мисалы, Microsoft SQL Server жана PostgreSQL), анда жөнөкөйлүк үчүн биз эки чечим үчүн жабдуулардын көлөмү болжол менен бирдей болот деп божомолдоого болот. Бул жабдууларды баалоого эмес, ошону менен көп убакытты жана күч-аракетти үнөмдөөгө мүмкүндүк берет. Эгер сиз такыр башка системаларды (айталы, Oracle менен Redisди) салыштырууга туура келсе, анда туура баа берүү үчүн өлчөмдөрдү (жабдыктардын көлөмүн эсептөө) жүргүзүү керек экени айдан ачык. Болбогон бир системанын өлчөмүн аныктоо абдан шүгүрсүз иш, ошондуктан дагы эле мындай салыштыруудан качууга аракет кылышат. Муну жасоо оңой: кесүү шарттарында маалыматтардын нөлдүк жоготуусу жана реляциялык модель жазылат, же тескерисинче - секундасына 50 миң транзакциянын жүктөмү.

Лицензияларды баалоо үчүн сатуучудан же анын өнөктөштөрүнөн өзөктөрдүн белгиленген санына лицензиянын баасын жана белгиленген мөөнөткө колдоо көрсөтүүнү суроо жетиштүү. Эреже катары, компаниялар программалык камсыздоону сатуучулар менен тыгыз байланышта жана эгерде маалымат базасынын операциялар бөлүмү өз алдынча чыгым суроосуна жооп бере албаса, анда бул маалыматты алуу үчүн бир кат жетиштүү.

Ар кандай сатуучулар ар кандай лицензиялык көрсөткүчтөргө ээ болушу мүмкүн: өзөктөрдүн саны, маалымат көлөмү же түйүндөрдүн саны боюнча. Күтүү базасы бекер болушу мүмкүн, же негизгиси сыяктуу эле лицензияланышы мүмкүн. Эгерде метрикадагы кандайдыр бир айырмачылыктар табылса, сиз стенддин моделин толук сүрөттөп, стендге лицензиялардын баасын эсептеп чыгышыңыз керек болот.

Туура салыштыруу үчүн маанилүү жагдай - ошол эле колдоо шарттары. Мисалы, Oracle колдоосу жылына лицензиянын баасынын 22% түзөт, бирок PostgreSQL колдоосу үчүн төлөшүңүз керек эмес. Мындай салыштыруу туурабы? Жок, анткени өз алдынча оңдоого мүмкүн болбогон ката такыр башка кесепеттерге алып келет: биринчи учурда, колдоо адистери аны оңдоого тез жардам беришет, ал эми экинчи учурда, долбоордун кечиктирилиши же аяктагандын токтоп калуу коркунучу бар. системасы белгисиз мөөнөткө.

Эсептөө шарттарын үч жол менен теңе аласыз:

  1. Oracle'ды колдоосуз колдонуңуз (чындыгында мындай болбойт).
  2. PostgreSQL үчүн колдоо сатып алыңыз - мисалы, Postgres Professional'дан.
  3. Колдоонун жоктугу менен байланышкан тобокелдиктерди эске алыңыз.

Мисалы, тобокелдикти эсептөө төмөнкүдөй көрүнүшү мүмкүн: маалымат базасы өлүмгө дуушар болгон учурда, системанын токтоп калуу убактысы 1 жумушчу күндү түзөт. Системаны колдонуудан болжолдонгон пайда жылына 40 миллиард тенге, кырсыктын деңгээли 1/400 деп болжолдонууда, демек, колдоонун жетишсиз болуу коркунучу жылына болжол менен 100 миллион тенге деп бааланат. Албетте, "пландаштырылган пайда" жана "болжолдуу кырсык жыштыгы" виртуалдык баалуулуктар, бирок андай моделге ээ болбогондон көрө алда канча жакшы.

Чындыгында, система узак мөөнөттүү токтоп калуулардын кадыр-баркы үчүн өтө маанилүү болушу мүмкүн, ошондуктан колдоо талап кылынат. Эгерде токтоп калууга жол берилсе, анда колдоодон баш тартуу кээде акчаны үнөмдөөнүн жакшы жолу болушу мүмкүн.

Баардык эсептөөлөрдөн кийин А платформасынын 5 жылдык баасы 800 миллион тенге, Б эксплуатациялык платформасынын баасы 650 миллион, С платформасынын баасы 600 миллион тенге болуп чыгат деп эсептейли. С платформасы жеңүүчү катары баа үчүн толук упай алат, ал эми А жана В платформалары канча эсе кымбатыраак болгонуна жараша бир аз азыраак алышат. Бул учурда – тиешелүүлүгүнө жараша 0.75 жана 0.92 балл.

мүмкүнчүлүк Assessment

Мүмкүнчүлүктөрдү баалоо көптөгөн топторго бөлүнөт, алардын саны баа берген адамдын фантазиясы менен гана чектелет. Бул мүмкүнчүлүктөрдү колдоно турган командаларга мүмкүнчүлүктөрдү бөлүштүрүү оптималдуу вариант болуп көрүнөт; биздин мисалда, бул иштеп чыгуучулар, администраторлор жана маалыматтык коопсуздук кызматкерлери. Келгиле, бул функциялардын салмагы 40:40:20 деп бөлүштүрүлөт.

Өнүгүү функцияларына төмөнкүлөр кирет:

  • маалыматтарды манипуляциялоонун жөнөкөйлүгү;
  • масштабдоо;
  • экинчилик көрсөткүчтөрдүн болушу.

Критерийлердин тизмеси, ошондой эле алардын салмактары абдан субъективдүү. Ошол эле маселени чечип жатканда да, бул тизмелер, пункттардын салмагы жана жооптор сиздин командаңыздын курамына жараша олуттуу түрдө өзгөрүп турат. Мисалы, Facebook маалыматтарды сактоо үчүн MySQL колдонот, ал эми Instagram Кассандрада курулган. Бул тиркемелерди иштеп чыгуучулар мындай таблицаларды толтурганы күмөн. Марк Цукерберг толук кандуу реляциялык моделди тандап, анын акысын колдонулуучу бөлүштүрүү муктаждыгы менен төлөп, ал эми Кевин Систром платформаны колдонуу менен масштабдоону куруп, маалыматтарга жетүүнүн оңойлугун жоготкондугун болжолдосо болот.

Башкаруу функцияларына төмөнкүлөр кирет:

  • резервдик системанын мүмкүнчүлүктөрү;
  • мониторингдин жөнөкөйлүгү;
  • кубаттуулукту башкаруунун жөнөкөйлүгү - дисктер жана түйүндөр;
  • маалыматтарды репликациялоо мүмкүнчүлүктөрү.

Сураныч, суроолор сандык түрдө түзүлүшү керек экенин эске алыңыз. Сиз атүгүл белгилүү бир функцияны кантип баалоо боюнча макулдаша аласыз. Келгиле, мисалы, Oracle DBMS менен камсыз кылынган куралдардын мисалын колдонуу менен камдык куралдарды баалоого аракет кылалы:

курал
түшүндүрмө
баалоо

imp/exp
Дайындарды жүктөө жана жүктөө
0.1

камдык көчүрмөнү баштоо/аяктоо
Файлдарды көчүрүү
0.3

RMAN
Кошумча көчүрүү мүмкүнчүлүгү
0.7

ЗДЛРА
Кошумча көчүрүү гана, эң тез калыбына келтирүү
1.0

Эгерде баа берүүнүн так критерийлери жок болсо, анда бир нече эксперттерден баа берүүнү суранып, андан кийин алардын орточо деңгээлин аныктоо мааниси бар.

Акырында, биз жөн гана маалыматтык коопсуздук функцияларын тизмектейбиз:

  • сырсөздү башкаруу саясатынын болушу;
  • тышкы аутентификация куралдарын (LDAP, Kerberos) туташтыруу мүмкүнчүлүгү;
  • мүмкүндүк алуу үлгүсү;
  • аудитордук мүмкүнчүлүктөр;
  • дисктеги маалыматтарды шифрлөө;
  • тармак аркылуу берүү учурунда шифрлөө (TLS);
  • администратордон маалыматтарды коргоо.

Performance testing

Өзүнчө, мен аргумент катары сиз тарабынан жасалбаган ар кандай жүк сыноолордун натыйжаларын колдонууга каршы эскертким келет.

Биринчиден, сыналып жаткан тиркемелердин маалымат түзүмү жана жүктөө профили сиз чече турган көйгөйдөн олуттуу айырмаланышы мүмкүн. Болжол менен 10-15 жыл мурун, маалымат базасынын сатуучулары TPC тесттеринде жетишилген натыйжаларды мактаганды жакшы көрүшчү, бирок азыр бул жыйынтыктарды эч ким олуттуу кабыл албайт.

Экинчиден, системанын иштеши коддун башында кайсы платформа үчүн жазылганынан жана сыноо кандай жабдууларда жүргүзүлгөнүнөн көз каранды. Мен Oracle PostgreSQL менен салыштырылган көптөгөн тесттерди көрдүм. Натыйжалар бир системанын шартсыз артыкчылыгынан башкасынын бирдей шартсыз артыкчылыгына чейин.

Акырында, үчүнчүдөн, сиз тестти ким өткөргөнүңүз тууралуу эч нерсе билбейсиз. Эки квалификация тең маанилүү, ОСту жана платформаны орнотуунун сапатына, ошондой эле мотивацияга таасир этет, ал тесттин жыйынтыгына башка бардык факторлорго караганда көбүрөөк таасир этет.

Эгерде өндүрүмдүүлүк маанилүү фактор болсо, анда өндүрүш системасын конфигурациялай турган жана тейлөөчү адамдардын жардамы менен тестти өзүңүз өткөрүңүз.

жыйынтык

Акыр-аягы, бардык аткарылган иштердин натыйжасы бардык эсептөөлөр бириктирилген, көбөйтүлгөн жана жыйынтыкталган электрондук таблица болушу керек:

Кайсынысы жакшы - Oracle же Redis же платформаны тандоону кантип актоо керек

Сиз түшүнгөндөй, шкалаларды өзгөртүү жана рейтингдерди тууралоо менен сиз каалаган натыйжага жете аласыз, бирок бул такыр башка окуя...

Source: www.habr.com

Комментарий кошуу