Это время включает в себя дедупликацию, сжатие и собственно передачу данных. Для shared системы резервного копирования — это приемлемая скорость. На выделенных решениях, например, кейс 2, скорость будет выше – до 3 Gb/s. Дедупликация на стороне клиента.
Ясно. Спасибо.
HANA работает на виртуальных машинах
А ваше облако каким-то образом сертифицировано SAP-ом под HANA (спрашиваю потому что обнаружить вас в списке SAP HANA Certified IaaS Platforms не удалось)?
Полный бэкап одной из баз данных объемом 181 ГБ делается за 1 час 54 минуты.
27 MB/s? Что- то совсем не быстро. Дедупликация где выполнялась? На HANA-хосте или медиа-агенте?
У клиента был большой объем исходных данных (почти 18 ТБ). Если складывать данные на ленточную библиотеку, как клиент это делал ранее, то потребовалось бы несколько десятков картриджей
Хм… на LTO-6 картридже с компрессией вполне себе лежат 4 бекапа 1.5TB базы.
Не совсем в тему вопрос: клиент хостит HANA'у на выделенных физ. машинах или на виртуалках?
У меня была виртуалка на 16vCPU на стареньком IBM x3850M2 (4 x 4 core Xeon X7350) + 60GB RAM.
LINEITEM и ORDERS были непартицированные с опцией COMPRESS FOR DIRECT_LOAD, загружены sqlldr'ом. Раздувал sga_target и прогонял запросы первым проходом, чтобы все таблицы закешировались. В последующие запуски смотрел nmon'ом, чтобы отсутствовал disk i/o.
Тоже гонял TPC-H (SF=50, таблица LINEITEM на 300M строк) на предмет сравнения отдельных запросов из буффер-кэша vs. инмемори-кэша. Из IMC получалось в среднем в 3 раза быстрее. Можете показать результат Q1 для обоих случаем с использованием /* parallel(4) */?
Технология особенно интересна своей гибкостью (возможностью грузить в IMC отдельные колонки/партиции), но стоит ли оно того чтобы платить +50% к процессорной лицензии на EE это «нужно посмотреть» в каждом отдельном случае.
По поводу результатов в бенчмарке SAP BW-EML: по-честному победить HANA'у не удалось, поэтому нагло читили с использованием матвьюшек, в результате закономерно не получили своего сертификата, что конечно же нисколько не мешает рассказывать «пастве» о том, как «мы порвали SAP на его же бенчмарке поэтому он наш результат не сертифицирует»
Ясно. Спасибо.
А ваше облако каким-то образом сертифицировано SAP-ом под HANA (спрашиваю потому что обнаружить вас в списке SAP HANA Certified IaaS Platforms не удалось)?
27 MB/s? Что- то совсем не быстро. Дедупликация где выполнялась? На HANA-хосте или медиа-агенте?
Хм… на LTO-6 картридже с компрессией вполне себе лежат 4 бекапа 1.5TB базы.
Не совсем в тему вопрос: клиент хостит HANA'у на выделенных физ. машинах или на виртуалках?
Пост интересный. Спасибо.
У меня была виртуалка на 16vCPU на стареньком IBM x3850M2 (4 x 4 core Xeon X7350) + 60GB RAM.
LINEITEM и ORDERS были непартицированные с опцией COMPRESS FOR DIRECT_LOAD, загружены sqlldr'ом. Раздувал sga_target и прогонял запросы первым проходом, чтобы все таблицы закешировались. В последующие запуски смотрел nmon'ом, чтобы отсутствовал disk i/o.
Технология особенно интересна своей гибкостью (возможностью грузить в IMC отдельные колонки/партиции), но стоит ли оно того чтобы платить +50% к процессорной лицензии на EE это «нужно посмотреть» в каждом отдельном случае.
По поводу результатов в бенчмарке SAP BW-EML: по-честному победить HANA'у не удалось, поэтому нагло читили с использованием матвьюшек, в результате закономерно не получили своего сертификата, что конечно же нисколько не мешает рассказывать «пастве» о том, как «мы порвали SAP на его же бенчмарке поэтому он наш результат не сертифицирует»