Comments 19
Выглядит все обещающе, но возникает ряд вопросов:
— вы пишете о размерах в терабайты, и времени предоставления порядка 30 минут. При этом время копирования данных сюда входит? И эти 30 минут независимо от размера?
— а если вас на промышленную базу просто не пустят в течение рабочего дня, а только ночью — все равно 30 минут?
— а если база содержит персональные данные, или там PCI DSS, то программистам в контур разработки нельзя отдавать ее вместе с данными, а чувствительные данные нужно либо вычистить, либо захешировать, причем процесс этот нетривиальный, потому что иногда хочется сохранить связность, даже по тем данным, которые захешировали. И все равно 30 минут? Или такие процессы просто не предусмотрены?
— а если речь не о единицах терабайт, а скажем о сотнях? До какого размера вы масштабировали — вот эти 20 терабайт это уже много, или еще нормально?
— вы пишете о размерах в терабайты, и времени предоставления порядка 30 минут. При этом время копирования данных сюда входит? И эти 30 минут независимо от размера?
— а если вас на промышленную базу просто не пустят в течение рабочего дня, а только ночью — все равно 30 минут?
— а если база содержит персональные данные, или там PCI DSS, то программистам в контур разработки нельзя отдавать ее вместе с данными, а чувствительные данные нужно либо вычистить, либо захешировать, причем процесс этот нетривиальный, потому что иногда хочется сохранить связность, даже по тем данным, которые захешировали. И все равно 30 минут? Или такие процессы просто не предусмотрены?
— а если речь не о единицах терабайт, а скажем о сотнях? До какого размера вы масштабировали — вот эти 20 терабайт это уже много, или еще нормально?
При этом время копирования данных сюда входит?
я предположил, что тут снапшоты/cow
вы пишете о размерах в терабайты, и времени предоставления порядка 30 минут. При этом время копирования данных сюда входит? И эти 30 минут независимо от размера?
30 минут независимо от размера, конечно. Первичное копирование данных и докат инкрементов — это отдельные процессы. А создание виртуальной БД (VDB) — это и занимает до 30 минут, размер БД не важен. Потому что сама БД не создается, вы просто подсоединяетесь к БД, к датафайлам.
а если вас на промышленную базу просто не пустят в течение рабочего дня, а только ночью — все равно 30 минут?
Да, все равно 30 минут, потому что вы можете создать VDB из тех данных, которые вы уже скопировали.
а если база содержит персональные данные, или там PCI DSS, то программистам в контур разработки нельзя отдавать ее вместе с данными, а чувствительные данные нужно либо вычистить, либо захешировать, причем процесс этот нетривиальный, потому что иногда хочется сохранить связность, даже по тем данным, которые захешировали. И все равно 30 минут? Или такие процессы просто не предусмотрены?
Отличный вопрос. В этом случае необходимо использовать внешнюю систему маскирования. То есть создаете VDB, далее маскируете её решением и вновь создаете VDB из этой замаскированной БД, в нужном вам количестве.
а если речь не о единицах терабайт, а скажем о сотнях?
До какого размера вы масштабировали — вот эти 20 терабайт это уже много, или еще нормально?
20 TB – абсолютно нормально. С большим объемом вы будете иметь дело только один раз – когда делаете initial sync, т.е. первое большое копирование. Далее – только инкременты. Из всего этого скопированного вы и создаете VDB для ваших разрабов/тестировщиков.
Правильно ли я понял, что внутри у этой штуки что-то типа Golden Gate, который реплицирует данные, может быть чуть более хитро и более удобно в настройке?
А можно вообще настроить выборочную репликацию? Ну скажем, очевидный случай — мы иногда имеем дело с таблицами, для которых 10 терабайт — это дневной объем изменений, и даже в виде инкрементов он будет перекачиваться достаточно долго, и разработчикам такое в общем не нужно (по крайней мере на ежедневной основе).
А можно вообще настроить выборочную репликацию? Ну скажем, очевидный случай — мы иногда имеем дело с таблицами, для которых 10 терабайт — это дневной объем изменений, и даже в виде инкрементов он будет перекачиваться достаточно долго, и разработчикам такое в общем не нужно (по крайней мере на ежедневной основе).
Нет, эта штука скорее не про репликацию (как у GG), но про бэкап+быстрый одновременный доступ к одной на всех физической БД.
В основе лежат стандартные API (для СУБД Oracle – это RMAN) + проприетарная файловая система вендора, на которой и лежит БД, которую все одновременно юзают через движок Actifio.
В этом решении подход на первое однократное полное копирование+инкременты day-by-day.
Разработчики, получив свою VDB вчера, вполне могут продолжать работать на ней сколь угодно долго, не докатывая новые данные. Чаще всего разрабам/тестерам супер свежая БД и не нужна.
И в общем-то ничто не мешает вам из полученной большой VDB «нарезать» мини БД для разработчиков, ручками ;)
Но есть и другие решения, которые заточены именно под создание сабсетов тестовых данных из большой продуктивной БД.
В основе лежат стандартные API (для СУБД Oracle – это RMAN) + проприетарная файловая система вендора, на которой и лежит БД, которую все одновременно юзают через движок Actifio.
В этом решении подход на первое однократное полное копирование+инкременты day-by-day.
Разработчики, получив свою VDB вчера, вполне могут продолжать работать на ней сколь угодно долго, не докатывая новые данные. Чаще всего разрабам/тестерам супер свежая БД и не нужна.
И в общем-то ничто не мешает вам из полученной большой VDB «нарезать» мини БД для разработчиков, ручками ;)
Но есть и другие решения, которые заточены именно под создание сабсетов тестовых данных из большой продуктивной БД.
Ну т.е. инкременты можно просто отключить, и таким образом трафик на них экономить?
В общем-то, как часто вы будете делать инкременты, зависит от вас. Вы можете выставить произвольный график и делать их реже (раз в неделю, например).
Инкременты позволяют создавать виртуальны БД (VDB) на основе более свежих данных из продуктивной БД.
Многое также зависит от объема изменений в БД, а вот здесь у всех всё по-разному ;)
Инкременты позволяют создавать виртуальны БД (VDB) на основе более свежих данных из продуктивной БД.
Многое также зависит от объема изменений в БД, а вот здесь у всех всё по-разному ;)
Есть аналогичное решение для Postgres, open-source, позволяет разворачивать терабайтные копии прода за секунды независимо от размера БД – Database Lab (https://postgres.ai/)
Да, у многих проприетарных решений есть опенсорс-аналог, но у которого свои плюсы и минусы.
Всё верно, но мы верим, что постепенно FOSS вытесняет проприетарный софт — и это неспроста. Плюсы сильно перевешивают минусы. Прежде всего, всегда можно понять, как именно что работает — и иногда исправить проблему, не дожидаясь вендора, или же добавить то, что проприетарный вендор никак не сделает. Мне лично никогда не хватает документации закрытого софта, которым активно пользуюсь, и всегда хочется залезть в код, чтобы понять нюансы поведения.
Спасибо вам за обзор, MG88! Было очень интересно узнать о реальном опыте с Actifio (главный конкурент Delphix — оба решения мы держим в радаре и видно, что они ориентируются исключительно на крупные компании), в картинках
Удивило, что клонирование занимает ~15 минут. Вот как раз тут Database Lab явно выигрывает — мы очень постарались, чтобы клон поднимался и был готов к работе именно за секунды. В итоге это открывает возможности привоза таких БД в CI-контекст и это очень важно — получаем автоматизацию тестирования, частые тесты (например, изменений схемы БД), лучшее покрытие ими и качество разработки. Я думаю, что в будущем все компании к этому придут так или иначе.
Мы явно интересуемся и занимаемся близкими темами — был бы рад познакомиться и пообщаться; если взаимно, пинганите меня на nik@postgres.ai.
Николай Самохвалов,
Postgres.ai Founder
Спасибо вам за обзор, MG88! Было очень интересно узнать о реальном опыте с Actifio (главный конкурент Delphix — оба решения мы держим в радаре и видно, что они ориентируются исключительно на крупные компании), в картинках
Удивило, что клонирование занимает ~15 минут. Вот как раз тут Database Lab явно выигрывает — мы очень постарались, чтобы клон поднимался и был готов к работе именно за секунды. В итоге это открывает возможности привоза таких БД в CI-контекст и это очень важно — получаем автоматизацию тестирования, частые тесты (например, изменений схемы БД), лучшее покрытие ими и качество разработки. Я думаю, что в будущем все компании к этому придут так или иначе.
Мы явно интересуемся и занимаемся близкими темами — был бы рад познакомиться и пообщаться; если взаимно, пинганите меня на nik@postgres.ai.
Николай Самохвалов,
Postgres.ai Founder
В оракл есть GRP.
Я как-то в одном из проектов настраивал систему — по выходным PROD бэкап маскировался, и создавался эталонный образ базы. Он накатывался на тестовые среды.
На тестовой базой включался flashback, создавался GRP и можно делать с базой что хочешь. Как только нужно вернуть назад, откатываешься на нужный GRP — занимало ну минут 10-15 при базе в пару терабайт. Откат собственно зависит не столько от размера базы, сколько от активности с этого момента.
Я как-то в одном из проектов настраивал систему — по выходным PROD бэкап маскировался, и создавался эталонный образ базы. Он накатывался на тестовые среды.
На тестовой базой включался flashback, создавался GRP и можно делать с базой что хочешь. Как только нужно вернуть назад, откатываешься на нужный GRP — занимало ну минут 10-15 при базе в пару терабайт. Откат собственно зависит не столько от размера базы, сколько от активности с этого момента.
Да-да, спасибо что напомнили — в подобных решениях такая возможность также имеется (без flashback).
Выглядит как инструмент самоуправления, который можно отдать разрабам и тестерам.
Т.е. допустим они запустили в своей VDB какие-то скрипты, что-то поменяли в данных, словом работали.
Результат не понравился. Благодаря этому инструменту самоуправления сами разрабам и тестеры могут через свой, очень простой GUI инструмент оперативно «откатиться» на состояние до начала работы скрипта.
И начать всё сначала ;)
Выглядит как инструмент самоуправления, который можно отдать разрабам и тестерам.
Т.е. допустим они запустили в своей VDB какие-то скрипты, что-то поменяли в данных, словом работали.
Результат не понравился. Благодаря этому инструменту самоуправления сами разрабам и тестеры могут через свой, очень простой GUI инструмент оперативно «откатиться» на состояние до начала работы скрипта.
И начать всё сначала ;)
Я правильно понимаю, что GRP же тоже пространство на дисках потребляет? Ну т.е. если вы, условно, навносили изменений на терабайт, то у вас должно быть место под логи эквивалентного размера для успешного отката на начало?
Меня всегда удивляют картинки До и После в любом решении направленном на продажу контейнеризации или чего-то подобного. При этом автор опускает неудобные моменты зачастую, делающие решение непригодным для продуктивных задач и т.п. Однако, данные решения тоже имеют право на жизнь. Правда автор рассматривает разницу между выделением чуть ли не физического сервера с полной установкой и Actifio. На деле все давно работают в виртуализации — нарезал ОС из шаблона, нарезал диски, запустил восстановление из копии. Зато своя и на своих ресурсах. И никто потом за положенный сервер не поругает.
Дополню вас: «запустил восстановление из копии» — здесь нет восстановления БД из копии.
Не нужно копию БД «разматывать», выделять для неё место снова и снова для следующих проектных команд.
БД общая и на всех одна. Целостный, непротиворечивый и независимый доступ к ней со стороны разных команд разрабов делает движок Actifio.
В результате «бешеная» экономия железа, человеко-часов и нервов ;)
Не нужно копию БД «разматывать», выделять для неё место снова и снова для следующих проектных команд.
БД общая и на всех одна. Целостный, непротиворечивый и независимый доступ к ней со стороны разных команд разрабов делает движок Actifio.
В результате «бешеная» экономия железа, человеко-часов и нервов ;)
Текст в картинках не читается, перезалейте плиз
Sign up to leave a comment.
Как из одной базы данных сделать 10 разных, храня только инкременты: обзор решения