Што лепш - 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 vs. Redis), то відавочна, што для карэктнай адзнакі неабходна зрабіць сайзінг (разлік колькасці абсталявання). Сайзінг неіснуючай сістэмы - занятак вельмі няўдзячнае, таму такога параўнання ўсё ж імкнуцца не дапускаць. Зрабіць гэта проста: у якія адсякаюць умовах пішуцца нулявая страта дадзеных і рэляцыйная мадэль ці ж наадварот - нагрузка ад 50 тысяч транзакцый у секунду.

Для ацэнкі ліцэнзій дастаткова запытаць у вендара або яго партнёраў кошт ліцэнзіі на фіксаваную колькасць ядраў і падтрымкі на фіксаваны тэрмін. Як правіла, у кампаній ужо выбудаваны трывалыя адносіны з вендарамі праграмнага забеспячэння, і калі аддзел эксплуатацыі БД не можа адказаць на пытанне аб кошце самастойна, то для атрымання гэтай інфармацыі дастаткова аднаго ліста.

У розных вендараў могуць быць розныя метрыкі ліцэнзавання: па колькасці ядраў, аб'ёме дадзеных або колькасці вузлоў. Standby-база можа быць бясплатнай, а можа ліцэнзавацца гэтак жа, як і асноўная. Калі толькі выявіліся нейкія адрозненні ў метрыках, давядзецца дэталёва апісваць мадэльны стэнд і лічыць кошт ліцэнзій для стэнда.

Важны момант для карэктнага параўнання - аднолькавыя ўмовы падтрымкі. Скажам, падтрымка Oracle каштуе 22% ад кошту ліцэнзіі ў год, а за падтрымку PostgreSQL можна не плаціць. Ці карэктна так параўноўваць? Не, таму што ў памылкі, якая не можа быць ухіленая ўласнымі сіламі, зусім розныя наступствы: у першым выпадку адмыслоўцы падтрымкі хутка дапамогуць яе ўхіліць, а ў другім выпадку ёсць рызыка затрымкі праекту або прастою гатовай сістэмы на працягу нявызначанага тэрміна.

Ураўняць умовы разліку можна трыма спосабамі:

  1. Выкарыстоўваць Oracle без падтрымкі (у рэальнасці такога не бывае).
  2. Купіць падтрымку на PostgreSQL - напрыклад, у кампаніі Postgres Professional.
  3. Закласці ў разлік рызыкі, звязаныя з адсутнасцю падтрымкі.

Напрыклад, разлік рызык можа выглядаць так: у выпадку неадхільнага збою базы дадзеных простай сістэмы складзе 1 працоўны дзень. Планаваны прыбытак ад выкарыстання сістэмы - 40 млрд мангольскіх тугрыкаў у год, частата аварый ацэньваецца як 1/400, такім чынам, рызыка адсутнасці суправаджэння ацэньваецца прыкладна ў 100 млн мангольскіх тугрыкаў у год. Відавочна, што "планаваны прыбытак" і "ацэначная частата аварый" - велічыні віртуальныя, але значна лепш мець такую ​​мадэль, чым не мець ніякай.

У рэчаіснасці сістэма можа быць занадта важная, і рэпутацыйнага страты ад працяглага прастою апынуцца недапушчальнымі, таму падтрымка спатрэбіцца. Калі ж просты дапускаецца, то адмова ад падтрымкі часам можа быць нядрэнным спосабам зэканоміць.

Дапусцім, што пасля ўсіх разлікаў кошт эксплуатацыі платформы A на працягу 5 гадоў апынулася 800 мангольскіх тугрыкаў, кошт эксплуатацыі платформы B - 650 млн тугрыкаў, а кошт эксплуатацыі платформы C - 600 млн тугрыкаў. Платформа C як пераможца атрымлівае за кошт паўнаважкі бал, а платформы A і B - крыху менш, прапарцыйна таму, у колькі разоў яны даражэй. У дадзеным выпадку - 0.75 і 0.92 балаў адпаведна.

Ацэнка магчымасцяў

Ацэнка магчымасцяў дзеліцца на мноства груп, колькасць якіх абмежавана толькі фантазіяй таго, хто робіць адзнаку. Аптымальным варыянтам здаецца дзяленне магчымасцей па камандах, якія гэтымі магчымасцямі будуць карыстацца; у нашым прыкладзе гэта распрацоўшчыкі, адміністратары і афіцэры інфармацыйнай бяспекі. Дапушчальны, што вагі гэтых функцый размяркоўваюцца як 40:40:20.

Да функцый распрацоўкі можна аднесці:

  • зручнасць маніпуляцыі дадзенымі;
  • маштабаванне;
  • наяўнасць другасных азначнікаў.

Спіс крытэрыяў, як і іх вагі, вельмі суб'ектыўныя. Нават пры рашэнні адной і той жа задачы гэтыя спісы, вагі пунктаў і адказы будуць істотна адрознівацца ў залежнасці ад складу вашай каманды. Так, напрыклад, Facebook для захоўвання дадзеных выкарыстоўвае MySQL, а Instagram пабудаваны на базе Cassandra. Ці наўрад распрацоўнікі гэтых прыкладанняў запаўнялі такія табліцы. Можна толькі здагадвацца, што Марк Цукерберг абраў паўнавартасную рэляцыйную мадэль, заплаціўшы за гэта неабходнасцю прыкладнога шаліравання, у той час як Кевін Сістрам заклаў маштабаванне сродкамі платформы, ахвяраваўшы выгодай доступу да дадзеных.

Да функцый адміністравання адносяцца:

  • магчымасці сістэмы рэзервовага капіявання;
  • зручнасць маніторынгу;
  • зручнасць кіравання магутнасцямі - дыскамі і вузламі;
  • магчымасці рэплікацыі даных.

Звярніце ўвагу, што фармулёўкі пытанняў павінны дапушчаць колькасную адзнаку. Можна нават дамовіцца, як ацэньваць тую ці іншую функцыю. Давайце, напрыклад, паспрабуем паставіць адзнакі прыладам рэзервовага капіявання на прыкладзе прылад, якія пастаўляюцца з СКБД Oracle:

Інструмент
Каментарыі
Ацэнка

imp/exp
Выгрузка і загрузка дадзеных
0.1

begin/end backup
Капіраванне файлаў
0.3

РМАН
Магчымасць інкрыментальнага капіявання
0.7

ZDLRA
Толькі інкрыментальнае капіраванне, найхутчэйшае аднаўленне на кропку
1.0

Калі выразныя крытэры адзнакі адсутнічаюць, мае сэнс папрасіць некалькіх экспертаў выставіць адзнакі, а затым іх асерадніць.

Нарэшце, проста пералічым функцыі інфармацыйнай бяспекі:

  • наяўнасць палітык кіравання паролямі;
  • магчымасць падключэння знешніх сродкаў аўтэнтыфікацыі (LDAP, Kerberos);
  • ролевая мадэль доступу;
  • магчымасці аўдыту;
  • шыфраванне дадзеных на дыску;
  • шыфраванне пры перадачы па сетцы (TLS);
  • абарона дадзеных ад адміністратара.

Тэставанне прадукцыйнасці

Асобна хацелася б перасцерагчы ад выкарыстання ў якасці аргументаў вынікаў якіх-небудзь нагрузачных тэстаў, зробленых не вамі.

Па-першае, структура дадзеных і профіль нагрузкі тэстоўваных прыкладанняў могуць істотна адрознівацца ад той задачы, якую збіраецеся вырашаць вы. Гадоў 10-15 таму вытворцы баз дадзеных любілі фарсіць вынікамі, дасягнутымі ў тэстах TPC, але цяпер ужо, здаецца, ніхто не ўспрымае гэтыя вынікі сур'ёзна.

Па-другое, прадукцыйнасць сістэмы дастаткова моцна залежыць ад таго, пад якую платформу першапачаткова напісаны код і на якім абсталяванні праводзіўся тэст. Мне даводзілася бачыць мноства тэстаў, дзе Oracle параўноўвалі з PostgreSQL. Вынікі - ад безумоўнай перавагі адной сістэмы да гэтак жа безумоўнай перавагі іншай.

І нарэшце, па-трэцяе, вы нічога не ведаеце аб тым, хто праводзіў тэст. Важная як кваліфікацыя, якая ўплывае на якасць налады АС і платформы, так і матывацыя, якая ўплывае на вынікі тэсту мацней, чым усе астатнія фактары разам узятыя.

Калі прадукцыйнасць з'яўляецца крытычна важным фактарам, правядзіце тэст самастойна, пажадана з удзелам адмыслоўцаў, якія будуць наладжваць і падтрымліваць прамысловую сістэму.

Вынік

Нарэшце, вынікам усёй праведзенай працы павінна стаць электронная табліца, дзе ўсе адзнакі зведзены, перамножаны і падсумаваны:

Што лепш - Oracle або Redis або Як абгрунтаваць выбар платформы

Як вы разумееце, зменай шаляў і карэктоўкай адзнак можна дамагчыся любога патрабаванага выніку, але гэта ўжо зусім іншая гісторыя…

Крыніца: habr.com

Дадаць каментар