DBA-бот Joe. Анатоль Станслер (Postgres.ai)

Як backend-распрацоўшчык разумее, што SQL-запыт будзе добра працаваць на «продзе»? У буйных ці хутка растучых кампаніях доступ да "проду" ёсць далёка не ва ўсіх. Ды і з доступам далёка не ўсе запыты можна бязбольна праверыць, а стварэнне копіі БД часта займае гадзіннік. Каб вырашыць гэтыя праблемы, мы стварылі штучнага DBA – Joe. Ён ужо паспяхова ўкаранёны ў некалькі кампаній і дапамагае не аднаму дзясятку распрацоўшчыкаў.

Відэа:

Ўсім прывітанне! Мяне клічуць Анатоль Станслер. Я працую ў кампаніі Postgres.ai. Мы займаемся тым, што паскараем працэс распрацоўкі, прыбіраючы затрымкі, звязаныя з працай Postgres, у распрацоўшчыкаў, DBA і QA.

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

Калі мы вядзем распрацоўку і які робіцца складаныя нагружаныя міграцыі, мы задаем сабе пытанне: «Ці ўзляціць гэта міграцыя?». Мы карыстаемся review, мы карыстаемся ведамі больш дасведчаных калегаў, DBA-экспертаў. І яны могуць сказаць - паляціць яна ці не паляціць.

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

Хто калі-небудзь проста на prod рабіў індэксы або нейкія змены ўносіў? Даволі шмат. А ў каго гэта прыводзіла да таго, што дадзеныя губляліся ці прастоі былі? Тады вам знаёмы гэты боль. Дзякуй богу, бэкапы ёсць.

Першы падыход - гэта тэсціраванне ў prod. Ці, калі распрацоўшчык сядзіць з лакальнай машыны, у яго тэставыя дадзеныя, ёсць нейкая абмежаваная выбарка. І мы выкочваем на prod, і атрымліваем вось такую ​​сітуацыю.

Гэта балюча, гэта дорага. Мусіць, так лепш не рабіць.

А як лепей зрабіць?

Давайце возьмем staging і вылучым туды нейкую частку prod. Ці ў лепшым выпадку возьмем сапраўдным prod, усе дадзеныя. І пасля таго, як лакальна распрацавалі, будзем дадаткова правяраць яшчэ і на staging.

Гэта нам дазволіць нейкую частку памылак прыбраць, т. е. не дапусціць на prod.

Якія ёсць праблемы?

• Праблема ў тым, што гэты staging мы дзелім з калегамі. І вельмі часта так бывае, што ты робіш нейкую змену, бам - і ніякіх дадзеных няма, праца насмарку. Staging быў шматтэрабайтным. І трэба доўга чакаць, пакуль ён зноў падымецца. І мы вырашаем дапрацаваць гэта заўтра. Усё, у нас распрацоўка ўстала.
• І, канешне, у нас працуе там шмат калег, шмат каманд. І трэба ўзгадняць уручную. А гэта няёмка.

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

Гэта лепш, чым папярэдні падыход, але ўсё роўна ёсць большая верагоднасць, што нейкая памылка пойдзе на production.

Што нам мяшае даць кожнаму распрацоўніку тэставы стэнд, поўнапамерную копію? Я думаю, што зразумела, што замінае.

У каго база дадзеных больш, чым тэрабайт? Больш, чым у паловы залі.

І зразумела, што трымаць машыны для кожнага распрацоўніка, калі такі вялікі production, гэта вельмі дорага, а да таго ж яшчэ і доўга.

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

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

Але яны выкарыстоўваюць гэты падыход, таму што гэта дазваляе трымаць prod надзейным.

Што мы тут можам зрабіць? Давайце зробім так, каб тэставыя стэнды былі таннымі і будзем кожнаму распрацоўніку даваць свой уласны тэставы стэнд.

І такое магчыма.

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

Рэальны прыклад:

• БД - 4,5 тэрабайта.

• Мы можам атрымліваць незалежныя копіі за 30 секунд.

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

Гэта крута. Тут мы гаворым пра магію і паралельны сусвет.

У нашым выпадку гэта працуе з дапамогай сыстэмы OpenZFS.

OpenZFS - гэта copy-on-write файлавая сістэма, якая сама са скрынкі падтрымлівае снапшоты і клоны. Яна надзейная і якая маштабуецца. Ёй вельмі проста кіраваць. Яе літаральна ў дзве каманды можна разгарнуць.

Ёсць іншыя варыянты:

• LVM,

• СГД (напрыклад, Pure Storage).

Database Lab, пра які я расказваю, ён модульны. Можна рэалізаваць пры выкарыстанні такіх варыянтаў. Але пакуль мы засяродзіліся на OpenZFS, таму што менавіта з LVM былі праблемы.

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

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

І вось гэты карыстач будзе працаваць з такім наборам дадзеных. Ён іх будзе паступова змяняць, рабіць свае снапшоты.

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

Каб разгарнуць у сябе такую ​​сістэму, трэба вырашыць дзве праблемы:

• Першая - гэта крыніца дадзеных, адкуль вы будзеце іх браць. Можна наладзіць рэплікацыю з production. Можна выкарыстоўваць ужо бэкапы, якія ў вас настроеныя, я спадзяюся. WAL-E, WAL-G ці Barman. І нават, калі вы выкарыстоўваеце нейкае Cloud-рашэнне, напрыклад, RDS або Cloud SQL, тыя вы можаце выкарыстоўваць лагічныя дампы. Але мы ўсёткі вам раім выкарыстоўваць бэкапы, таму што пры такім падыходзе ў вас захаваецца яшчэ і фізічная структура файлаў, што дазволіць быць яшчэ бліжэй да тых метрыкаў, якія вы б убачылі на production, каб адлоўліваць тыя праблемы, якія ёсць.

• Другая - гэта месца, дзе вы хочаце выкрасці Database Lab. Гэта можа быць Cloud, гэта можа быць On-premise. Тут важна сказаць, што ZFS падтрымлівае сціск дадзеных. І дастаткова добра гэта робіць.

Уявіце, што ў кожнага такога клона ў залежнасці ад тых аперацый, якія мы з базай які робіцца, будзе нарастаць нейкі dev. Для гэтага dev таксама трэба будзе месца. Але за кошт таго, што мы ўзялі базу ў 4,5 тэрабайта, ZFS яе сцісне да 3,5 тэрабайт. У залежнасці ад налад гэта можна вар'іраваць. І ў нас яшчэ для dev застанецца месца.

Такую сістэму можна выкарыстоўваць для розных кейсаў.

• Гэта распрацоўшчыкі, DBA для праверкі запытаў, для аптымізацыі.

• Гэта можна выкарыстоўваць у QA-тэставанні для праверкі канкрэтнай міграцыі перад тым, як мы будзем выкочваць гэта ў prod. І таксама мы можам падымаць спецыяльныя environment для QA з рэальнымі дадзенымі, дзе яны могуць патэставаць новы функцыянал. І гэта будзе займаць секунды замест таго, каб чакаць гадзіннік, а, можа быць, і суткі ў нейкіх іншых выпадках, дзе тонкія копіі не выкарыстоўваюцца.

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

З такім падыходам:

1. Нізкая верагоднасць памылак на "продзе", таму што мы ўсе змены пратэставалі на поўнапамерных дадзеных.

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

3. І няма перашкоды, няма чакання паміж тэсціраваннямі. Ты рэальна можаш пайсці і праверыць. І так будзе лепш, бо мы паскорым распрацоўку.

• Будзе менш рэфактарынгу. Менш багаў трапіць у prod. Мы менш іх адрэфактарым потым.

• Мы можам звяртаць незваротныя змены. Гэтага ў стандартных падыходах няма.

1. Гэта выгадна, таму што мы дзелім рэсурсы тэставых стэндаў.

Ужо добра, а што яшчэ можна было б паскорыць?

Дзякуючы такой сістэме мы можам моцна знізіць парог уваходжання ў такое тэсціраванне.

Цяпер ёсць замкнёнае кола, калі распрацоўшчык, каб атрымаць доступ да рэальных поўнапамерных звестак, павінен стаць экспертам. Яму павінны даверыць такі доступ.

Але як расці, калі яго няма. А што, калі табе даступны толькі вельмі маленькі набор тэставых даных? Тады атрымаць рэальны досвед не атрымаецца.

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

Што ён дазваляе рабіць? Можна ўзяць канкрэтны запыт і адправіць яго ў спецыяльны канал для базы дадзеных. Мы аўтаматычна за секунды разгорнем тонкі клон. Прагонім гэты запыт. Збяром метрыкі і рэкамендацыі. Пакажам візуалізацыю. І далей гэты клон застанецца для таго, каб гэты запыт можна было неяк аптымізаваць, дадаць індэксы і г.д.

І таксама Slack нам дае магчымасці для калабарацыі са скрынкі. Паколькі гэта проста канал, можна прама там у thread для такога запыту пачаць гэты запыт абмяркоўваць, пінгаваць сваіх калегаў, DBA, якія ёсць усярэдзіне кампаній.

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

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

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

Стромка было б мець такое ж жалеза як на production, але яно можа адрознівацца.

Давайце ўспомнім як Postgres працуе з памяццю. У нас ёсць два кэша. Адзін ад файлавай сістэмы і адзін уласны Postgres, т. е. Shared Buffer Cache.

Важна адзначыць, што Shared Buffer Cache алакуецца пры старце Postgres у залежнасці ад таго, які памер вы задасце ў канфігурацыі.

А другі кэш выкарыстоўваецца ўся даступная прастора.

І калі мы робім некалькі клонаў на адной машыне, атрымліваецца, што мы паступова памяць запаўняем. І па-добраму Shared Buffer Cache - гэта 25% ад усяго аб'ёму памяці, які на машыне даступны.

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

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

Напрыклад, калі на prod у нас кэш вялікі, то ў нас Postgres будзе аддаваць перавагу выкарыстоўваць азначнік. А калі не, то тады будзе SeqScan. І які быў бы сэнс, калі б у нас гэтыя планы не супадалі?

Але тут мы прыходзім да такога рашэння, што насамрэч план у Postgres не залежыць ад пэўнага зададзенага ў Shared Buffer памеру ў плане, ён залежыць ад effective_cache_size.

Effective_cache_size - гэта меркаваны аб'ём кэша, які нам даступны, т. е. у суме Buffer Cache і кэш файлавай сістэмы. Гэта задаецца канфігам. І гэтая памяць не алакуецца.

І за кошт гэтага параметру мы можам падмануць Postgres, сказаўшы, што нам насамрэч даступна шмат дадзеных, нават калі гэтых дадзеных у нас няма. І такім чынам, планы будуць поўнасцю супадаць з production.

Але гэта можа паўплываць на таймінг. І мы запыты аптымізуем па таймінгу, але важна, што таймінг залежыць ад шматлікіх фактараў:

• Ён залежыць ад той нагрузкі, якая зараз ёсць на prod.

• Ён залежыць ад характарыстак самай машыны.

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

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

Давайце разбяром, як менавіта з Joe праходзіць аптымізацыя.

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

Мы пішам паведамленне ў канал, разгарнуўся для нас клон. І мы ўбачым, што такі запыт адпрацуе за 2,5 хвіліны. Гэта першае, што мы заўважым.

B Joe пакажа аўтаматычныя рэкамендацыі, заснаваныя на плане і метрыках.

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

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

І, здавалася б, у нас тут index scan і павінна было хутка адпрацаваць, але паколькі мы адфільтравалі занадта шмат радкоў (нам прыйшлося іх лічыць), то запыт павольна адпрацаваў.

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

Давайце паспрабуем зрабіць індэкс дакладней і паглядзім, як зменіцца выкананне запыту пасля гэтага.

Стварэнне індэкса заняло дастаткова шмат часу, але зараз мы правяраем запыт і бачым, што час замест 2,5 хвілін стала ўсяго 156 мілісекунд, што дастаткова добра. І мы чытаем усяго 6 мегабайт дадзеных.

І зараз у нас выкарыстоўваецца index only scan.

Іншая важная гісторыя ў тым, што нам хочацца план прадставіць нейкім больш зразумелым спосабам. Мы ў сябе ўкаранілі візуалізацыю з дапамогай Flame Graphs.

Гэта іншы запыт, больш насычаны. І Flame Graphs мы будуем па двух параметрах: гэтая колькасць дадзеных, якія канкрэтная нода ў плане лічыла і таймінг, т. е. час выканання ноды.

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

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

І распрацоўшчыкі, якія яшчэ не паглыбляліся ў гэтую тэму, таксама карыстаюцца explain.depesz.com, таму што як раз ім прасцей разабрацца якія метрыкі важныя, а якія не.

Ёсць новы падыход да візуалізацыі - гэта explain.dalibo.com. Яны робяць дрэвападобную візуалізацыю, але тут вельмі цяжка параўнаць ноды паміж сабой. Тут добра можна зразумець структуру, праўда, калі будзе вялікі запыт, то трэба будзе скраліць сюды-туды, але таксама варыянт.

Калабарацыя

І, як я ўжо сказаў, Slack нам дае магчымасць калабарацыі. Напрыклад, калі мы сустрэлі складаны запыт, які незразумела, як аптымізаваць, мы можам у thread у Slack гэтае пытанне ўдакладніць са сваімі калегамі.

Нам здаецца, што важна тэсціраваць на поўнапамерных дадзеных. Для гэтага мы зрабілі прыладу Update Database Lab, які даступны ў open source. Вы можаце выкарыстоўваць бот Joe таксама. Вы можаце браць яго прама зараз і ўкараняць у сябе. Усе гайды там даступныя.

Важна таксама адзначыць, што само па сабе рашэнне не з'яўляецца нейкім рэвалюцыйным, таму што ёсць Delphix, але гэтае enterprise-рашэнне. Яно цалкам закрытае, каштуе вельмі дорага. Мы менавіта спецыялізуемся на Postgres. Гэта ўсё прадукты open source. Далучайцеся да нас!

На гэтым я сканчаю. Дзякуй!

пытанні

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

Цікава, як вы разлічваеце месца пад гэта асяроддзе? Тэхналогія мае на ўвазе, што пры пэўных абставінах вашыя клоны могуць вырасці да максімальнага памеру. Грубіянска кажучы, калі ў вас дзесяцітэрабайтная база і 10 клонаў, то лёгка змадэляваць такую ​​сітуацыю, калі кожны клон будзе важыць па 10 унікальных дадзеных. Як вы разлічваеце гэтае месца, г. зн. тую дэльту, пра якую вы казалі, у якой будуць жыць гэтыя клоны?

Добрае пытанне. Тут важна сачыць за пэўнымі клонамі. І калі нейкая занадта вялікая змена ў клона, ён пачынае расці, то мы можам спачатку выдаць папярэджанне карыстачу пра гэта, альбо адразу гэты клон спыніць, каб у нас не адбылася fail-сітуацыя.

Так, у мяне ўкладзенае пытанне. Т. е. як вы забяспечваеце жыццёвы цыкл гэтых модуляў? У нас гэта праблема і цэлая асобная гісторыя. Як гэта адбываецца?

Ёсць нейкі ttl у кожнага клона. У прынцыпе, у нас фіксаваны ttl.

Які, калі не сакрэт?

1 гадзіна, г. зн. idle - 1 гадзіна. Калі ён не выкарыстоўваецца, то мы яго грукаем. Але тут ніякага здзіўлення няма, бо мы можам клон паднімаць за секунды. І калі ён зноў спатрэбіцца, то - калі ласка.

Мне наконт выбару тэхналогій таксама цікава, таму што мы, напрыклад, паралельна выкарыстоўваем некалькі спосабаў па тых ці іншых прычынах. Чаму менавіта ZFS? Чаму вы не выкарыстоўвалі LVM? Вы згадалі, што c LVM былі праблемы. Якія былі праблемы? На мой погляд, найболей аптымальным з'яўляецца варыянт з СХД, з пункта гледжання прадукцыйнасці.

У чым галоўная праблема з ZFS? У тым, што ты павінен запускаць на адным хасце, т. е. усе instances будуць жыць у рамка адной аперацыёнкі. А ў выпадку з СХД, ты можаш падключаць рознае абсталяванне. І вузкім месцам з'яўляюцца толькі тыя блокі, якія на СГД. І цікавае пытанне менавіта выбару тэхналогій. Чаму не LVM?

Менавіта пра LVM зможам абмеркаваць на meetup. Пра СГД - гэта проста дорага. Сістэму ZFS мы можам укараніць дзе заўгодна. Вы можаце яе ў сябе на машыне разгарнуць. Вы можаце проста спампаваць рэпазітар і разгарнуць яе. ZFS ставіцца практычна ўсюды, калі мы пра Linux які гаворыцца. Т. е. мы атрымліваем вельмі гнуткае рашэнне. І сам па сабе ZFS са скрынкі вельмі шматлікае дае. Можна загружаць туды колькі заўгодна дадзеных, падлучаць вялікую колькасць дыскаў, ёсць снапшоты. І, як я ўжо казаў, яго проста адміністраваць. Т. е. ён здаецца вельмі прыемным у выкарыстанні. Ён правераны, яму шмат гадоў. У яго ёсць вельмі вялікае community, якое расце. ZFS - вельмі надзейнае рашэнне.

Мікалай Самахвалаў: Можна я яшчэ пракаментую? Мяне Мікалай клічуць, мы разам з Анатолем працуем. Я згодны, што СГД - гэта класна. І ў некаторых нашых кліентаў ёсць Pure Storage і т.д.

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

Але ZFS даступны ўсім. Ужо годзе DelPhix, у іх 300 кліентаў. З іх у fortune 100 – 50 кліентаў, т. е. яны нацэлены на NASA і т. д. Час атрымаць гэтую тэхналогію ўсім. І таму ў нас open source Core. У нас ёсць частка інтэрфейсная, якая не open source. Гэта платформа, якую мы пакажам. Але мы жадаем, каб гэта было даступна кожнаму. Мы жадаем зрабіць рэвалюцыю, каб усе тэстыравальнікі перасталі варажыць на наўтбуках. Мы павінны пісаць SELECT і адразу бачыць, што ен павольны. Хапіць чакаць, калі DBA пра гэта раскажа. Вось гэта галоўная мэта. І я думаю, што мы да гэтага прыйдзем усё. І гэтую штуку мы робім, каб яна была ва ўсіх. Таму ZFS, таму што ён будзе даступны ўсюды. Дзякуй community за вырашэнне праблем і за тое, што там open source ліцэнзія і т. д.*

Вітаю! Дзякуй за даклад! Мяне Максім клічуць. Мы вырашалі такія ж праблемы. У сябе парашылі. Як вы падзяляеце рэсурсы паміж гэтымі клонамі? Кожны клон у кожны момант часу можа займацца сваім: адзін адно тэстуе, іншы іншае, у кагосьці азначнік будуецца, у кагосьці job працуе цяжкая. І калі па CPU можна яшчэ падзяліць, то па IO, як вы дзеліце? Гэта першае пытанне.

І другое пытанне пра непадобнасць стэндаў. Дапушчальны, у мяне тут ZFS і ўсё класна, а ў кліента на prod не ZFS, а ext4, напрыклад. Як у гэтым выпадку?

Пытанні вельмі добрыя. Я крыху згадаў гэтую праблему з тым, што мы дзелім рэсурсы. І рашэнне заключаецца ў наступным. Уявіце, што вы на staging тэсціруеце. У вас таксама можа быць адначасова такая сітуацыя, што нехта нагрузку адну дае, нехта іншую. І ў выніку вы бачыце метрыкі незразумелыя. Нават такая ж праблема можа быць з prod. Калі вы хочаце праверыць нейкі запыт і бачыце, што з ім нейкая праблема - ён павольна адпрацоўвае, то насамрэч праблема не ў запыце была, а ў тым, што нагрузка нейкая ёсць паралельная.

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

У мяне два пытанні. Гэта вельмі крутая штука. Ці былі кейсы, калі дадзеныя на production крытычна важныя, напрыклад, нумары крэдытных кард? Ці ёсць ужо нешта гатовае ці гэта асобная задача? І другое пытанне - ці ёсць нешта такое для MySQL?

Наконт дадзеных. Мы будзем рабіць абфусцаванне, пакуль мы гэта не робім. Але калі вы разгортваеце менавіта Joe, калі вы не даяце доступу распрацоўнікам, то доступу да дадзеных няма. Чаму? Бо Joe не паказвае дадзеныя. Ён паказвае толькі метрыкі, планы і ўсё. Так спецыяльна было зроблена, паколькі - гэта адно з патрабаванняў нашага кліента. Яны хацелі мець магчымасць аптымізаваць, але пры гэтым не даваць усім запар доступ.

Наконт MySQL. Гэтую сістэму можна выкарыстоўваць для чаго заўгодна, што захоўвае state на дыску. І паколькі мы займаемся Postgres, мы зараз у першую чаргу робім цалкам усю аўтаматызацыю для Postgres. Мы жадаем аўтаматызаваць атрыманне дадзеных з бэкапу. Мы правільна канфігуруем Postgres. Мы ведаем, як зрабіць так, каб пляны супадалі і г.д.

Але паколькі сістэма якая пашыраецца, яе можна будзе таксама выкарыстоўваць для MySQL. І такія прыклады ёсць. Падобная штука ёсць у Яндэкса, але яны яе не публікуюць нідзе. Яны яе выкарыстоўваюць унутры Яндэкс.Метрыкі. І тамака як раз пра MySQL гісторыя. Але тэхналогіі тыя ж самыя, ZFS.

Дзякуй за даклад! У мяне таксама пара пытанняў. Вы згадалі, што кланаванне можна выкарыстоўваць для аналітыкі, напрыклад, каб будаваць тамака дадатковыя азначнікі. Можаце крыху падрабязней расказаць, як гэта працуе?

І другое пытанне адразу задам на рахунак аднолькавасці стэндаў, аднолькавасці планаў. План залежыць у тым ліку ад статыстыкі, сабранай Postgres. Як вы гэтую праблему вырашаеце?

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

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

Індэкс будзе кожны раз стварацца?

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

Што да пытання наконт статыстыкі, то, калі мы аднаўляемся з бэкапу, калі мы робім рэплікацыю, то ў нас статыстыка будзе дакладна такая ж. Таму што ў нас цалкам уся фізічная структура дадзеных, т. е. дадзеныя як ёсць са ўсімі метрыкамі статыстыкі прывязем таксама.

Тут іншая праблема. Калі ў вас cloud-рашэнне выкарыстоўваецца, то там толькі лагічныя дампы даступныя, таму што Google, Amazon не даюць узяць фізічную копію. Тамака такая праблема будзе.

Дзякуй пра даклад. Тут прагучала два добрыя пытанні пра MySQL і пра падзел рэсурсаў. Але, у сутнасці, усё зводзіцца да таго, што гэта тэма не пэўных СКБД, а ў цэлым файлавай сістэмы. І, адпаведна, пытанні падзелу рэсурсаў таксама павінны вырашацца адтуль, не ў канцы, што гэта Postgres, а ў файлавай сістэме, у серверы, у instance.

Маё пытанне крыху пра іншае. Ён больш набліжаны да шматслойнасці базы дадзеных, дзе некалькі пластоў. Мы, напрыклад, настроілі абнаўленне дзесяцітэрабайтнай выявы, у нас рэплікацыя ідзе. І мы канкрэтна выкарыстоўваем гэтае рашэнне для баз дадзеных. Ідзе рэплікацыя, адбываецца абнаўленне даных. Тут паралельна працуе 100 супрацоўнікаў, якія ўвесь час запускаюць гэтыя розныя здымкі. Што рабіць? Як зрабіць так, каб не было канфлікту, што яны запусцілі адно, а потым файлавая сістэма падмянілася, і гэтыя здымкі ўсё паехалі?

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

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

З папярэдніх пластоў, якія былі з папярэдніх рэплікацый.

Папярэднія пласты адваляцца, але яны будуць спасылацца на стары пласт, а новыя выявы яны будуць з апошняга пласта браць, які быў атрыманы ў абнаўленні?

Увогуле, так.

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

Так, усё правільна. Ёсць нейкае акно. Мы захоўваем тыднёвыя снапшоты. Гэта залежыць ад таго, які ў вас ёсьць рэсурс. Калі ў вас ёсць магчымасць захоўваць шмат дадзеных, можна за доўгі час захоўваць снапшоты. Яны самі не выдаляцца. Ніякага data corruption не будзе. Калі снапшоты састарэлі, як нам здаецца, т. е. гэта залежыць ад палітыкі ў кампаніі, то мы можам іх проста выдаліць і вызваліць месца.

Добры дзень, дзякуй за даклад! Наконт Joe пытанне. Вы сказалі, што замовец не жадаў доступ усім запар даваць да дадзеных. Строга кажучы, калі ў чалавека ёсць вынік Explain Analyze, то ён можа падглядаць дадзеныя.

Усё так. Напрыклад, мы можам напісаць: "SELECT FROM WHERE email = таму тое". Т. е. мы не ўбачым самі дадзеныя, але нейкія ўскосныя прыкметы мы можам паглядзець. Гэта трэба разумець. Але з іншага боку гэта ўсё бачна. У нас ёсць аўдыт логаў, у нас ёсць кантроль іншых калегаў, якія таксама бачаць, чым займаюцца распрацоўшчыкі. І калі нехта паспрабуе так зрабіць, то да іх служба бяспекі прыйдзе і папрацуе над гэтым пытаннем.

Добры дзень! Дзякуй за даклад! У мяне кароткае пытанне. Калі ў кампаніі Slack не выкарыстоўваецца, то нейкая да яго прывязка зараз ёсць ці можна для распрацоўшчыкаў разгарнуць instances, каб падлучыць да баз прыкладанне тэставае?

Цяпер ёсць прывязка да Slack, т. е. няма ніякага іншага месэнджара, але вельмі жадаецца зрабіць падтрымку іншых месэнджараў таксама. Што вы можаце зрабіць? Вы можаце разгарнуць у сябе DB Lab без Joe, хадзіць з дапамогай REST API ці з дапамогай нашай платформы і ствараць клоны, і падлучацца PSQL'ем. Але так можна зрабіць, калі вы гатовыя даць сваім распрацоўнікам доступ да дадзеных, бо тут ужо ніякага экрана не будзе.

Мне гэтая праслойка не патрэбная, а патрэбная такая магчымасць.

Тады - так, гэта можна зрабіць.

Крыніца: habr.com