Як backend-розробник розуміє, що SQL-запит добре працюватиме на «проді»? У великих компаніях, що швидко ростуть, доступ до «проду» є далеко не у всіх. Та й з доступом далеко не всі запити можна перевірити безболісно, а створення копії БД часто займає годинник. Щоб вирішити ці проблеми, ми створили штучний DBA - Joe. Він вже успішно впроваджений у кілька компаній та допомагає не одному десятку розробників.
Відео:
Всім привіт! Мене звуть Анатолій Станслер. Я працюю в компанії . Ми займаємося тим, що прискорюємо процес розробки, забираючи затримки, пов'язані з роботою 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 з реальними даними, де вони можуть потестувати новий функціонал. І це буде займати секунди замість того, щоб чекати на годинник, а, можливо, і добу в якихось інших випадках, де тонкі копії не використовуються.
-
І ще окремий кейс. Якщо в компанії не налаштована система аналітики, ми можемо виділити тонкий клон продуктової бази і віддати її під довгі запити або під спеціальні індекси, які в аналітиці можуть використовуватися.
З таким підходом:
-
Низька ймовірність помилок на «проді», тому що всі зміни протестували на повнорозмірних даних.
-
У нас з'являється культура тестування, оскільки тепер не потрібно годинами чекати на свій власний стенд.
-
І немає перепони, немає очікування між тестуваннями. Ти реально можеш піти та перевірити. І так буде краще, бо ми прискоримо розробку.
-
Буде менше рефакторингу. Менше багів потрапить у prod. Ми менше відрефакторимо їх потім.
-
Ми можемо звертати незворотні зміни. Цього у стандартних підходах немає.
- Це вигідно, тому що ми ділимо ресурси тестових стендів.
Вже добре, а що можна було б прискорити?
Завдяки такій системі ми можемо сильно знизити поріг входження до такого тестування.
Зараз є замкнуте коло, коли розробник, щоб отримати доступ до реальних повнорозмірних даних, має стати експертом. Йому мають довірити такий доступ.
Але як рости, якщо його нема. А якщо тобі доступний тільки дуже маленький набір тестових даних? Тоді здобути реальний досвід не вдасться.
Як вийти із цього кола? Як перший інтерфейс, зручний для розробників будь-якого рівня, ми вибрали 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? Ви згадали, що з 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. Коли ви хочете перевірити якийсь запит і бачите, що з ним якась проблема – він повільно відпрацьовує, то насправді проблема не в запиті була, а в тому, що якесь навантаження є паралельним.
І тому тут важливо зосередитись на тому, який буде план, за якими кроками у плані підемо і скільки даних ми для цього піднімемо. Те, що у нас диски, скажімо, будуть навантажені чимось, воно вплине безпосередньо на таймінг. Але ми можемо за кількістю даних оцінити, наскільки цей навантажений запит. Це не так важливо, що одночасно з ним буде ще якесь виконання.
У мене два запитання. Це дуже крута річ. Чи були кейси, коли дані на виробництво критично важливі, наприклад, номери кредитних кард? Чи є вже щось готове, чи це окреме завдання? І друге питання – чи є щось для 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