Comments 32
Маскирование интересное.
А есть еще какие-нибудь killing feature помимо чего-то простого вроде «взять NetApp и FlexClone»?
А есть еще какие-нибудь killing feature помимо чего-то простого вроде «взять NetApp и FlexClone»?
Здесь все в одном флаконе. Delphix может использовать любую СХД. Кроме того, это софтверное решение (вирт образ) и может легко быть развернут в облаке или в ЦОДе.
NetApp — сложнее в установке и администрировании, а Delphix устанавливается за 1 день.
У Delphix простой и понятный UI, доступный разработчикам, NetApp – это сложные скрипты.
NetApp — сложнее в установке и администрировании, а Delphix устанавливается за 1 день.
У Delphix простой и понятный UI, доступный разработчикам, NetApp – это сложные скрипты.
На сложном PowerShell?
Писать скрипты непросто, нужны знания.
GUI Delphix – прост и понятен разработчикам на интуитивном уровне. Он выглядит как Apple GUI для ребёнка. А если баз данных/сред разработки много и много проектных команд? Писать скрипты становится еще дороже и сопровождать их тоже. Всё ведь не упомнишь, верно?
GUI повышает производительность труда, однозначно. И вообще текстовый редактор Фотон «умер», в Ворд процветает.
GUI Delphix – прост и понятен разработчикам на интуитивном уровне. Он выглядит как Apple GUI для ребёнка. А если баз данных/сред разработки много и много проектных команд? Писать скрипты становится еще дороже и сопровождать их тоже. Всё ведь не упомнишь, верно?
GUI повышает производительность труда, однозначно. И вообще текстовый редактор Фотон «умер», в Ворд процветает.
Оригинальный «фреймворк» у них вроде на перле.
Для решения такой задачи обычно обходятся клонами («тонкими» копиями), либо основной базы, либо ее реплики. Клонирование умеет делать некоторое количество СХД (NetApp в часности), ZFS, BTRFS, а также системы виртуализации (VMWare). Если СХД уже есть, то лицензия на клонирование явно будет дешевле, а главное проще внедрения нового ПО. Сами клоны «бесплатны» по занимаемому месту, увеличивается лишь число iops (причем чтение оседает в общем для всех клонов кэше)
К тому, что написал выше, хочу добавить, что ещё важна способность Delphix восстанавливать виртуальные базы данных в считанные минуты и на любой момент времени. Это позволяет исключить расходы на хранение избыточных резервных копий. Ничтожно малый объем пространства, занимаемого виртуальными базами данных Delphix, позволяет использовать более длительные периоды времени непрерывного восстановления по сравнению с альтернативными решениями. Полная копия нужна в процессах DRP. Delphix выступает в качестве дополнительного уровня защиты непрерывности бизнес-процессов.
В крупных компаниях управлять Delphix все равно будет админ (как минимум настраивать полномочия для представителей каждой из 4х групп разработчиков), да и обычно разбираться в интерфейсе никому не охота, а отправить письмо «Вась, откати базу db4 на вчера» куда проще. Но ок, запишем это как преимущество.
Никакой экономии пространства у Delphix по сравнению с клонами нет.
Снапшоты — почти эквивалент откатыванию на любой период времени, с поправкой на частоту их создания. Точность до секунды для дев-БД врядли нужна.
Вебинтерфейс для управления снапшотами есть и у СХД
Никакой экономии пространства у Delphix по сравнению с клонами нет.
Снапшоты — почти эквивалент откатыванию на любой период времени, с поправкой на частоту их создания. Точность до секунды для дев-БД врядли нужна.
Вебинтерфейс для управления снапшотами есть и у СХД
Если клоны — это копия БД, как же нет экономии?
Вдумайтесь: в прежние времена компании для разработки 7 продуктов потребовалось бы 7 новых физических тестовых баз данных, которые заняли бы порядка 210тБ. Сегодня же для этого нужно всего лишь 25тБ.
Заказчик хорошо умеет считать. Очень.
И еще, Delphix не пытается заменить сложившийся порядок вещей. Там, где снэпшоты — норма жизни, ок, это их дело. Но, думаю, что в формулировке «почти эквивалент» ключевым является слово «почти».
И да, еще один важный момент: Delphix не только для СУБД, но и для слоя приложений, причем не только пакетных. Он легко синхронизирует папки приложений из прода в тестовые среды.
Вдумайтесь: в прежние времена компании для разработки 7 продуктов потребовалось бы 7 новых физических тестовых баз данных, которые заняли бы порядка 210тБ. Сегодня же для этого нужно всего лишь 25тБ.
Заказчик хорошо умеет считать. Очень.
И еще, Delphix не пытается заменить сложившийся порядок вещей. Там, где снэпшоты — норма жизни, ок, это их дело. Но, думаю, что в формулировке «почти эквивалент» ключевым является слово «почти».
И да, еще один важный момент: Delphix не только для СУБД, но и для слоя приложений, причем не только пакетных. Он легко синхронизирует папки приложений из прода в тестовые среды.
> Если клоны — это копия БД, как же нет экономии?
Вы похоже совсем не разбираетесь в вопросе, раз считаете, что клон на современной СХД, это полная копия. Copy-on-Write придумали так давно, что никто это уже новостью не считает. Размер каждого клона соответствует дельте изменений между основым образом и клоном. Стоит это копейки, во многих банглах современных СХД это присутствует вообще бесплатно.
Поэтому да, экономии здесь нет от слова совсем. Есть совершенно идиотская ситуация, которая была в у клиента до вас и не самое оптимальное решение с вашей стороны.
Вы похоже совсем не разбираетесь в вопросе, раз считаете, что клон на современной СХД, это полная копия. Copy-on-Write придумали так давно, что никто это уже новостью не считает. Размер каждого клона соответствует дельте изменений между основым образом и клоном. Стоит это копейки, во многих банглах современных СХД это присутствует вообще бесплатно.
Поэтому да, экономии здесь нет от слова совсем. Есть совершенно идиотская ситуация, которая была в у клиента до вас и не самое оптимальное решение с вашей стороны.
Давайте определимся с термином «клон». Под клоном понимается полная копия на отдельной СХД. Полагаю, что клон на современной СХД (в вашем толковании) не подошёл для заказчика. Думаю, по этой же причине на рынке есть и другие схожие решения. Не всё «родное» от вендора (в том числе и СХД) является оптимальным. И дело тут не только и не столько в экономии СХД. Например, здесь экономия достигается за счет того, что при создании очередной виртуальной БД Delphix хранит не всю БД, а только изменения, которые в неё вносит разработчик или тестировщик. Более того, по отношению к каждой виртуальной БД разработчик/тестировщик может моментально получить состояние БД к любому моменту времени на временной шкале. Сколько нужно технологий, чтобы сделать снепшот для тестовой БД не нагружая продакшен БД? Ответ — более трех. Репликация данных с продакшена с последующим инкрементом, в вашем случае, снимки на уровне СХД, time-recovery на уровне БД, маскирование, скрипты и т.п. Множим это на количество тестовых БД и на десятки тестовых сред разработки. И на время стораджистов.
> Полагаю, что клон на современной СХД (в вашем толковании) не подошёл для заказчика.
Ну, давайте будем честны. Если интегратор клиенту его (клон на СХД) не продавал, то он ему «не подошел». Если интегратору выгоднее продать «свой» продукт X, вместо «чужой» СХД с фичей Y, то у клиента, при налаженных отношениях с интегратором, почти нет шансов настоять на своем.
Ну, давайте будем честны. Если интегратор клиенту его (клон на СХД) не продавал, то он ему «не подошел». Если интегратору выгоднее продать «свой» продукт X, вместо «чужой» СХД с фичей Y, то у клиента, при налаженных отношениях с интегратором, почти нет шансов настоять на своем.
При разработке для создания новой версии приложения, новой функциональности продукта или обновления существующей требуется несколько экземпляров приложения и соответствующих баз данных для разработки, тестирования, интеграции, обучения и поддержки. Кроме того, чтобы обезопасить конфиденциальную информацию и предоставлять нужные данные нужным пользователям, необходимо расширенное управление данными. Одними клонами на СХД требуемую функциональность не сделать.
Странное решение, хотя очень прямолинейное. Во-первых, как выше сказали не ясно почему не использовать thin provisioning на СХД или операционной системе? Во-вторых, зачем вам копии полной базы? Да, для произоводительности и расследования это необходимо, но тогда выгоднее делать моментальные снепшоты, или временно открывать стендбай (у вас же Oracle?) Но для разработки это не надо. Для нормальной разработки, по крайне мере.
Зачем тут плодить сущности? Чтоб продать дороже?
Зачем тут плодить сущности? Чтоб продать дороже?
Кроме упомянутого выше, Delphix убирает лишнюю нагрузку с инфраструктурщиков и других админов. Сами разработчики и тестировщики делают, что им надо. Либо просят отдельного одного админа Delphix, но это всего один человек (точнее, кто-то из админов, ведущий это ПО, даже не отдельная должность), а не целый отдел инфраструктурщиков только для нужд тестирования.
Мда, что-то я не понимаю в этих ваших Ингострахах. Для того чтобы обслуживать одну СХД c синпровижененгом и одну железную машину с виртуалками на ней нужен отдел? Т.е. там не автоматизирована развертка приложухи? Жесть какая-то. А разработчики тоже ваши, Кроковские?
Еще раз повторю: заказчик умеет считать и очень хорошо.
У них была развертка приложений и до Delphix — долгая, дорогая, с «разборками» кто, когда и что должен делать. И покупкой доп. СХД, зачастую.
А теперь 1 человеко-час в день (админ Delphix) справляется с пожеланиями разрабов. Возросшими пожеланиями, конечно, ибо с приходом Delphix стало понятно, что разрабы смогут больше в единицу времени. Может, даже точат зуб на инфраструктурщиков.
У них была развертка приложений и до Delphix — долгая, дорогая, с «разборками» кто, когда и что должен делать. И покупкой доп. СХД, зачастую.
А теперь 1 человеко-час в день (админ Delphix) справляется с пожеланиями разрабов. Возросшими пожеланиями, конечно, ибо с приходом Delphix стало понятно, что разрабы смогут больше в единицу времени. Может, даже точат зуб на инфраструктурщиков.
Комментарий удален
Как я понял, это решение для нужд разработки, а можно было бы ее решить именно со стороны разработки?
Сделать baseline существующих метаданных с продовой базы (+ нужные данные, например справочники, т.к. для нужд разработки редко требуется весь объем данных прода), положить это все под контроль версий. Затемзаставить научить разработчиков изменять базу миграциями (если этого до сих пор нет, или есть но не во всех командах). Т.о. можно будет быстро развернуть любое кол-во баз любой нужной версии.
Сделать baseline существующих метаданных с продовой базы (+ нужные данные, например справочники, т.к. для нужд разработки редко требуется весь объем данных прода), положить это все под контроль версий. Затем
В частном случае ваш вариант может работать. Попробуйте сделать baseline для разных команд разработки с различных приложений и баз данных с продовых систем. А потом храните версии изменений приложения, БД на несколько проектных команд и еще предоставляйте по требованию данные на требуемый момент времени с внедрёнными в пром изменениями для новых команд разработки. Без автоматизации сложно будет.
С помощью Delphix можно одновременно управлять формированием и распространением (маскированных) данных. Из-за сочетания методов маскировки данных с технологией их виртуальной доставки снимаются ограничения традиционных решений.
С помощью Delphix можно одновременно управлять формированием и распространением (маскированных) данных. Из-за сочетания методов маскировки данных с технологией их виртуальной доставки снимаются ограничения традиционных решений.
Согласен, с автоматизацией такого решения есть проблемы. Существует много всяких отдельных экстракторов кода из БД (DDL/DML), миграторов, дифферов, VCS, CI (чтобы была уверенность, что БД успешно собирается из исходников), но вот чтобы все это вместе заработало, чтобы можно было гибко настроить под свой конкретный flow — такого инструмента я пока не встречал.
Интересное решение. Что будет если например выполнить ALTER по полю в таблице на 2.5 гигабайт?
Delphix — действительно, дублирует функциональность СХД с thin provisioning. Плюс добавляет свое, типа data masking, etc.
В чем отличие? Delphix — полностью софтовое решение. Отсюда все плюсы и минусы.
Что лучше? Это все равно что выяснять, что лучше, какой-нибудь железный маршрутизатор, или sdn-решение?
В чем отличие? Delphix — полностью софтовое решение. Отсюда все плюсы и минусы.
Что лучше? Это все равно что выяснять, что лучше, какой-нибудь железный маршрутизатор, или sdn-решение?
Delphix использует подключение без агентов по стандартным интерфейсам API для создания одной виртуальной копии файлов производственной базы данных и журналов. Благодаря сжатию, уже только на этапе первоначальной загрузки базы данных может сократить объем данных до 75%. В решениях Delphix исключается повышенная нагрузка на промышленную БД и систему хранения данных вследствие хранения полных резервных копий. Вместо этого осуществляется запрос и запись только изменившихся данных и блоков журналов. Применяя записи изменений к первоначальной копии производственной базы данных, Delphix может мгновенно восстановить виртуальные базы с полными возможностями чтения и записи по состоянию на любой момент времени. Плюсом и маскирование.
Вопрос с задних рядов от людей, которые больше гигабайта баз не видели: «По какой причине невозможно 'укоротить' базу для программерских нужд?». Понятно, что некоторые запросы надо тестировать на большом количестве записей, но не думаю, что надо брать все 20ТБ и на них гонять! База в 1ТБ вполне успешно может эмулировать все 30, вся соль в отладке запросов, которым как бы пофигу, сколько данных в базе — пропорции временных затрат будут те же.
Представьте,
— БД в надцать ТБ
— несколько тысяч таблиц
— несколько десятков тысяч пакетов
— несколько десятков людей, которые каждый день правят базу, пару раз в неделю выкатывают релизы в прод.
Простое копирование базы с прода в дев, зачистка персональных данных и прочей чувствительной информации традиционными инструментами БД занимает несколько суток. Чистить данные? В целом рационально. Но помните про количество таблиц и пакетов? Конечно есть партиции, отключение констреинтов и прочие хитрости, но и они не спасают от длительности операций. Получаем срок от недели и больше.
Это только технические сложности. А есть и просто бизнесовые.
Продукты не статичны. Сегодня контора продает продукт А с одними свойствами, завтра тот же продукт А с другими свойствами, послезавтра с третьими и т.д. В итоге, не имея возможности гонять операции со всех существующих сущностях, получаем, у одного клиента все работает как задумано, у второго проблемы.
— БД в надцать ТБ
— несколько тысяч таблиц
— несколько десятков тысяч пакетов
— несколько десятков людей, которые каждый день правят базу, пару раз в неделю выкатывают релизы в прод.
Простое копирование базы с прода в дев, зачистка персональных данных и прочей чувствительной информации традиционными инструментами БД занимает несколько суток. Чистить данные? В целом рационально. Но помните про количество таблиц и пакетов? Конечно есть партиции, отключение констреинтов и прочие хитрости, но и они не спасают от длительности операций. Получаем срок от недели и больше.
Это только технические сложности. А есть и просто бизнесовые.
Продукты не статичны. Сегодня контора продает продукт А с одними свойствами, завтра тот же продукт А с другими свойствами, послезавтра с третьими и т.д. В итоге, не имея возможности гонять операции со всех существующих сущностях, получаем, у одного клиента все работает как задумано, у второго проблемы.
Кроме всего прочего, в базе хранятся не только данные, но и логика их обработки. И логика логики обработки тоже.
Роман brahew, Спасибо, очень интересный случай!
К сожалению не совсем понял в вашей дискуссии с Дмитрем BasilioCat почему в вашем случае Delphix оказался лучше клонирования на СХД? Для меня интересно, либо это конкретный случай используемой СХД, где данный функционал нет возможности реализовать корректное, полноценное, без снижения производительности, клонирование? Или вы нашли некий недостаток в данной операции? Или вы нашли такое преимущество в Delphix, которое нельзя реализовать при клонировании? Или причина вообще в другой плоскости — задействовать старое оборудование, которое не использовалось бы при клонировании в рамках одной СХД?
К сожалению не совсем понял в вашей дискуссии с Дмитрем BasilioCat почему в вашем случае Delphix оказался лучше клонирования на СХД? Для меня интересно, либо это конкретный случай используемой СХД, где данный функционал нет возможности реализовать корректное, полноценное, без снижения производительности, клонирование? Или вы нашли некий недостаток в данной операции? Или вы нашли такое преимущество в Delphix, которое нельзя реализовать при клонировании? Или причина вообще в другой плоскости — задействовать старое оборудование, которое не использовалось бы при клонировании в рамках одной СХД?
Sign up to leave a comment.
«Пьяная» база данных: как на 1 базе мы сделали 7 тестовых площадок, причём у каждой — свой собственный инкремент и дифф