Текущее время: Пт, сен 21 2018, 23:11

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


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


- Не материться в явном виде (за нарушение выносится первое предупреждение, оно же и последнее, далее - бан)
- Не разжигать рознь на национальной, религиозной, половой и расовой почве (следует немедленный годичный бан)
- Троллинг, кащенизм, холивары, упячка ведут к вечному упокоению в бане
- Пользование подфорумом "Частные объявления" - см. п. 6.2 Правил форума
- Пользование подфорумами "Встречи" и "Поздравления" - см. п. 6.3 Правил форума
- Все прочее - см. раздел 6.1 Правил форума



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

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

Вы плохо знаете, повторюсь. 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
Сообщения: 48
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
Сообщения: 2228
Откуда: Moscow, кажется...
Пол: Мужской
2 kernelpanic
Вы классический тролль. С вами скушно. Пока вы старательно пытаетесь, чтобы я сначала отвечал на ваши вопросы, а потом вступал сам с собой в дискуссию. Не, не буду.

_________________
Я бы хотел поглядеть на эффективную армию, состоящую из эффективных менеджеров.
BRGDS,
Aleks Изображение


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

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

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

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

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


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

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


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


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

Зарегистрирован:
Вт, авг 09 2005, 22:20
Сообщения: 538
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
Сообщения: 48
Кодер написал(а):
Я прекрасно знаю как это сделано в хане...
в обычной субд в памяти в кэше будет только 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
Сообщения: 1144
kernelpanic написал(а):
Если бы Вы "прекрасно знали", то наверное знали бы и о партиционировании, и о page loadable columns
А пока я делаю вывод, что Вы не очень-то разбираетесь в данном предмете.

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

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


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

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

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


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

Зарегистрирован:
Вт, май 17 2005, 14:35
Сообщения: 4419
Откуда: Москва
Позволю себе расширить цитату Кодера, уж очень интересно.
Цитата:
На текущий момент 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
Сообщения: 538
Цитата:
Но статья очень интересная и познавательная.

Статья и правда проработанная. Только выборка странная. Где же самые злые конкуренты, - 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
Сообщения: 48
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  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 158 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7, 8, 9 ... 11  След.

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


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

Сейчас этот форум просматривают: нет зарегистрированных пользователей


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

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