Текущее время: Чт, дек 14 2017, 13:57

Часовой пояс: UTC + 4 часа


Правила форума


ВНИМАНИЕ! Прежде чем задавать вопрос, ознакомьтесь со ссылками ниже:

Вопросы по отличиям версий SAP, Add-On, EHP - сюда
Вопросы по SAP Front End (SAPlogon, SAPgui, guiXT и т.д.) - сюда
Вопросы по LSMW - сюда
Вопросы по архивации в SAP - сюда
Вопросы по SAP GRC - сюда
Вопросы по SAP Business Workplace (почте SAP) и SAP Office - сюда
Вопросы по miniSAP (SAP mini basis) - сюда
Вопросы по SAP HANA - сюда
Вопросы по лицензированию продуктов SAP - сюда



Начать новую тему Ответить на тему  [ Сообщений: 116 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7, 8  След.
Автор Сообщение
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Пт, сен 09 2016, 00:47 
Ассистент
Ассистент

Зарегистрирован:
Сб, окт 17 2015, 14:11
Сообщения: 43
Кодер писал(а):
Вы потоком слов опять "замылили" проблему. Таблицы все равно должны быть в хане полностью в памяти, даже если читается одна строка (ну или партиция, если табла секционирована). Насколько я знаю, лекарства от этого у ханы нет.

Вы плохо знаете, повторюсь. CS Таблицы в Хане могут быть ВЫГРУЖАЕМЫМИ. Часто используется - остается в памяти. Раз в месяц/квартал/год - можно определить порог выгрузки.

avlag писал(а):
Может под этим ником пишут разные люди? Технарь и маркетолог? ;)

Может и разные, но что точно - они немного разбираются в сетевых технологиях - чтобы не сравнивать сферических коней в вакууме :wink:
avlag писал(а):
Сумеете сравнить в цифрах с сетевым интерфейсом на 10 Gb/s ?

Я - нет. А Вы? Только не отвечайте сразу, задумайтесь, все ли вводные озвучены Вами выше, чтобы рассказать нам о скорости передачи данных через сетевой интерфейс в 10Gb/s?
Такие аббревиатуры, как RTT, CWND, SOCKOPTS знакомы?


Последний раз редактировалось kernelpanic Пт, сен 09 2016, 01:33, всего редактировалось 2 раз(а).

Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Пт, сен 09 2016, 00:57 
Ассистент
Ассистент

Зарегистрирован:
Сб, окт 17 2015, 14:11
Сообщения: 43
kds писал(а):
А тем временем .... «Аэрофлот» перенес систему SAP ERP на платформу SAP HANA"[/url]

"Ключевой целью проекта стало повышение скорости принятия управленческих решений на основе информации из SAP ERP за счет уменьшения сроков выполнения транзакций и отчетов. В среднем после перехода на платформу SAP HANA их скорость увеличилась в 4,4 раза." :)


Да много кто уже перенес ERP на HANA. Буквально недавно сталкивался с инсталляцией, обслуживающей в пике 10000 онлайн-пользователей. Suite on HANA.
А самые шустрые уже на S4/HANA мигрируют, причем в облако..


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Пт, сен 09 2016, 09:18 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, сен 16 2004, 18:10
Сообщения: 2223
Откуда: Moscow, кажется...
Пол: Мужской
2 kernelpanic
Вы классический тролль. С вами скушно. Пока вы старательно пытаетесь, чтобы я сначала отвечал на ваши вопросы, а потом вступал сам с собой в дискуссию. Не, не буду.

_________________
Если банахово пространство рефлексивно, то единичный шар слабо компактен! Точно знаю! (c) М.Королюк
BRGDS,
Aleks Изображение


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Пт, сен 09 2016, 12:43 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 16:38
Сообщения: 1092
kernelpanic писал(а):
Вы плохо знаете, повторюсь. CS Таблицы в Хане могут быть ВЫГРУЖАЕМЫМИ. Часто используется - остается в памяти. Раз в месяц/квартал/год - можно определить порог выгрузки.

Я прекрасно знаю как это сделано в хане. А вы в очередной раз пытаетесь замылить проблему. В классическом подходе при чтении из БД с винта в кэш вытаскиваются только нужные строки. В хане читается вся таблица или партиция. То что они потом при ненадобности могут быть выгружены (тот же самый LRU-алгоритм) - это понтяно. Но еще раз повторюсь: надо считать 1 строку - в обычной субд в памяти в кэше будет только 1 строка, а в памяти ханы - вся таблица.
Таким образом, я присоединюсь к мнению уважаемого avlag
avlag писал(а):
Вы классический тролль. С вами скушно.

Пожалуй, посажу вас на диету :D

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Пт, сен 09 2016, 13:58 
Специалист
Специалист

Зарегистрирован:
Чт, мар 25 2010, 10:02
Сообщения: 195
Skif писал(а):
а есть способ на форуме организовать сводную статистику?


В форумном движке врятли есть такая возможность, можно через теже гугл-формы данные собрать если кому-то интересно будет.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Пт, сен 09 2016, 15:52 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Вт, авг 09 2005, 22:20
Сообщения: 537
kernelpanic писал(а):
Да много кто уже перенес ERP на HANA. Буквально недавно сталкивался с инсталляцией, обслуживающей в пике 10000 онлайн-пользователей. Suite on HANA.

Пруфы! Нам нужны пруфы! (Проплаченная статья про Аэрофлот пруфом не является. Мы про Аэрофлот и без статьи все знаем :))
kernelpanic писал(а):
А самые шустрые уже на S4/HANA мигрируют, причем в облако..

... потому что не в облаке S4/HANA являет из себя пустоту , а в облаке это не S4/HANA, а старая добрая абаповская разработка (Про это уже писали http://sapboard.ru/forum/viewtopic.php?f=22&t=92302&p=548380#p548380 :). Для не самых шустрых (шутрые уже попали). Предлагаю ознакомится с документиком:
Simplification List for SAP S/4HANA on-premise edition
Внимание! В документе 276 страниц

_________________
Мы свое призванье не забудем - смех и радость мы приносим людям


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Пн, сен 12 2016, 23:36 
Ассистент
Ассистент

Зарегистрирован:
Сб, окт 17 2015, 14:11
Сообщения: 43
Кодер писал(а):
Я прекрасно знаю как это сделано в хане...
в обычной субд в памяти в кэше будет только 1 строка, а в памяти ханы - вся таблица.

Если бы Вы "прекрасно знали", то наверное знали бы и о партиционировании, и о page loadable columns
А пока я делаю вывод, что Вы не очень-то разбираетесь в данном предмете.
Кодер писал(а):
Таким образом, я присоединюсь к мнению уважаемого avlag
avlag писал(а):
Вы классический тролль. С вами скушно.

Пожалуй, посажу вас на диету :D

Уважаемый avlag тоже ушел от технического диалога. Полагаю, также из-за нежелания "поплыть" в данной предметной области.
Так что, выражаясь в духе вашего совместного с ним стиля, я могу считать, что "слив защщитан"

@markone - ну хоть Вы то меня не покинете, не оставите "классического тролля" в его техническом одиночестве? ;-)
Я бы с удовольствием раскрыл детали, тем более, что они инженерно очень интересные, но увы, связан NDA, так что не обессудьте. Поверьте на слово =)
Мнение процитированного жуликом инсайдера достаточно интересно, за fresh sexy UI действительно скрывается старый добрый ABAP, даже в S4/Cloud. Что отметил для себя - javascript, который отвечает за UI в итоге создает экземпляры и дергает методы объектов ровно тем же образом, как это делает SAP GUI, только в качестве транспорта выступает http/s, а не RFC/CPIC
Про S4/Cloud замечание касаемо оптимизации производительности - акцент там зачастую смещается с традиционных подходов типа ST03/STAD/ST04 etc. в сторону Fiddler, Httpwatch и developer tools for browsers. Если обладать данным багажом умений, то можно быть востребованным вскорости.
Ну это так, лирическое отступление..


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Вт, сен 13 2016, 00:19 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 16:38
Сообщения: 1092
kernelpanic писал(а):
Если бы Вы "прекрасно знали", то наверное знали бы и о партиционировании, и о page loadable columns
А пока я делаю вывод, что Вы не очень-то разбираетесь в данном предмете.

Про партиции я уже писал. Партиции грузятся так же целиком. Кстати, да, о партициях напомнили: там же до сих пор ограничение 2млрд записей на партицию или непартицированную таблицу? Тоже прэлэстно.
Про page loadable column - на момент моего ковыряния в хане(сп5) - оно толком не работало. Ну и сейчас, если верить СДН, это не является серебряной пулей.
Так что, пожалуй, и вправду - голодайте

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Ср, окт 12 2016, 10:21 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 16:38
Сообщения: 1092
Не совсем в тему топика. Но статья очень интересная и познавательная.
Небольшая цитата:
Цитата:
Кстати, производитель рекомендует по возможности использовать однонодовую конфигурацию БД, что и подтверждают результаты нашего тестирования – заставить конфигурацию из двух машин оптимально работать в разы сложнее, чем из одной.

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Ср, окт 12 2016, 11:15 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Вт, май 17 2005, 14:35
Сообщения: 4333
Откуда: Москва
Позволю себе расширить цитату Кодера, уж очень интересно.
Цитата:
На текущий момент HANA при выполнении запроса не умеет размещать промежуточные результаты запросов на диске. Поэтому если памяти не хватает, сессия обрывается, и пользователь остается без результатов.

Как выяснилось в процессе тестирования, даже при условии, что данные двух таблиц, участвующих в join-е, распределены по нодам кластера правильно, join по факту выполняется только на одной ноде кластера. Перед выполнением запроса данные со всего кластера просто переливаются на одну ноду и уже там происходит обсчет join-а. За отведенное под тестирование время победить такую логику и заставить join выполняться локально не смогли.

Кстати, производитель рекомендует по возможности использовать однонодовую конфигурацию БД, что и подтверждают результаты нашего тестирования – заставить конфигурацию из двух машин оптимально работать в разы сложнее, чем из одной.

_________________
Удача - результат нашего желания (© А. Нортон)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Чт, окт 13 2016, 16:32 
Ассистент
Ассистент

Зарегистрирован:
Чт, мар 27 2014, 16:22
Сообщения: 34
Кодер писал(а):
Не совсем в тему топика. Но статья очень интересная и познавательная.
Небольшая цитата:
Цитата:
Кстати, производитель рекомендует по возможности использовать однонодовую конфигурацию БД, что и подтверждают результаты нашего тестирования – заставить конфигурацию из двух машин оптимально работать в разы сложнее, чем из одной.


На прошлой неделе был на мероприятии IBM на тему SAP HANA on IBM POWER.
Там был кейс про миграцию 5ТB BWonHANA одного крупного заказчика.
Мигрировали с 12-ти узлового scale out кластера (1 master + 10 workers + 1 standby, 40 core/512GB в каждой ноде) в scale up на одну машину POWER E880 (точнее LPAR на 48 core/6TB RAM). В результате по словам заказчика BW-шные репорты стали работать в среднем в 5 раз быстрее.

А еще там главный по хАне в SAP СНГ объявил, что все "остальные базы" будут суппортится до 2025 года ;-)
Интересно, а что будет с теми кто не захочет/сможет/успеет мигрировать ? Суппорт-контракт на ERP/BW/etc не продлят ? ;-)


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Чт, окт 13 2016, 17:27 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Вт, авг 09 2005, 22:20
Сообщения: 537
Цитата:
Но статья очень интересная и познавательная.

Статья и правда проработанная. Только выборка странная. Где же самые злые конкуренты, - MS, IBM, Oracle co своими InMemory?

Цитата:
Мигрировали с 12-ти узлового scale out кластера (1 master + 10 workers + 1 standby, 40 core/512GB в каждой ноде) в scale up на одну машину POWER E880 (точнее LPAR на 48 core/6TB RAM). В результате по словам заказчика BW-шные репорты стали работать в среднем в 5 раз быстрее.

Всего только 5Х? Хм! Это если только с учетом тестирования старых ETL BW отчетов такого повышения можно добиться только за счет оптимизации (обеспечения более продуктивной работы при переходе с могогонодового ландшафта на однондовый) работы стораджей. А если говорить про новые технологии поколоночной обработки HANA, - так это ваааще швах. Или это идет речь о переходе со scale out кластера HANA на одну машину POWER E880 тоже на HANA? Тогда тоже все объяснимо! В чем профит то? НИПАНЯЯЯТНА
И да, как насчет всеми любимых ABAP отчетов? Или это только HANA for BW?

Цитата:
А еще там главный по хАне в SAP СНГ объявил, что все "остальные базы" будут суппортится до 2025 года ;-)
Интересно, а что будет с теми кто не захочет/сможет/успеет мигрировать ? Суппорт-контракт на ERP/BW/etc не продлят ?

А это как в рекламе недвижимости, - "Срочно, срочно, только до конца этой недели..." А потом неделя превращается в месяц, месяц в год, а квартиры так и стоят не распроданные"

_________________
Мы свое призванье не забудем - смех и радость мы приносим людям


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Чт, окт 13 2016, 18:23 
Ассистент
Ассистент

Зарегистрирован:
Чт, мар 27 2014, 16:22
Сообщения: 34
markone писал(а):
Или это идет речь о переходе со scale out кластера HANA на одну машину POWER E880 тоже на HANA?

Да.
markone писал(а):
Тогда тоже все объяснимо! В чем профит то? НИПАНЯЯЯТНА

Ну видимо в этих "пяти разах". И как бонус меньшем количестве железа
markone писал(а):

И да, как насчет всеми любимых ABAP отчетов?

Без понятия.
markone писал(а):
Или это только HANA for BW?

Именно


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Вт, окт 18 2016, 20:08 
Ассистент
Ассистент

Зарегистрирован:
Сб, окт 17 2015, 14:11
Сообщения: 43
2 Кодер: Спасибо за статью! Упустил ее в новостной ленте Хабра.

LKU писал(а):
Позволю себе расширить цитату Кодера, уж очень интересно.
На текущий момент HANA при выполнении запроса не умеет размещать промежуточные результаты запросов на диске. Поэтому если памяти не хватает, сессия обрывается, и пользователь остается без результатов.

Это верно. При достижении лимита по памяти пользовательская сессия обрывается, а транзакция откатывается.

LKU писал(а):
Как выяснилось в процессе тестирования, даже при условии, что данные двух таблиц, участвующих в join-е, распределены по нодам кластера правильно, join по факту выполняется только на одной ноде кластера. Перед выполнением запроса данные со всего кластера просто переливаются на одну ноду и уже там происходит обсчет join-а. За отведенное под тестирование время победить такую логику и заставить join выполняться локально не смогли.

Кстати, производитель рекомендует по возможности использовать однонодовую конфигурацию БД, что и подтверждают результаты нашего тестирования – заставить конфигурацию из двух машин оптимально работать в разы сложнее, чем из одной.


Действительно, с ростом числа узлов, сложность системы возрастает. Справедливо для любых систем.
Касаемо утверждения, что "данные со всего кластера переливаются на одну ноду...", я бы поспорил. Точку мог бы поставить графический план исполнения, которого увы, нет. В любом случае, если идет межнодовая коммуникация, оптимизатор вычисляет, на какой ноде больше данных, и к той джойнит другую ноду, но не по конечным данным, а, например, по их хешам (хэшируются данные релевантные для запроса). Главная цель межнодовой оптимизации касаемо джойнов (справедливо и для Smart Data Access) - минимальный объем передаваемых данных. В дальнейшем, если таблицы на основе которых выполнялся джоин не менялись, то результат может отдаваться их LRU-кэша.

И не совсем по теме, приятная новость:
SAP HANA Express Edition


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Чт, ноя 10 2016, 15:44 
Ассистент
Ассистент

Зарегистрирован:
Пт, июн 08 2007, 15:00
Сообщения: 39
Пара замечаний по поводу последних пары страниц.

В хане загрузка и управление загрузкой происходит поколоночно. Нет никакого смысла загружать таблицу целиком.
Возможно только для delta merge и компрессии. Не уверен.

В реальных продуктивных системах (наблюдал bw) крайне трудно увидеть сессию, которая отвечает медленнее 5-10 секунд. Это реальная real-time dbms.
В scaleout тоже самое, несмотря на 1gb сеть. Хотя сап рекомендует 10gb.
Я, как базисник, до сих пор не могу придумать как элегантно загрузить базу для целей стресс-тестирования.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 116 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7, 8  След.

Часовой пояс: UTC + 4 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: markone, Sampoi и гости: 12


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB