Текущее время: Ср, сен 26 2018, 14:35

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




Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Re: SAP HANA карьера
СообщениеДобавлено: Вт, окт 06 2015, 21:51 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 16:38
Сообщения: 1144
Цитата:
А вы в индус-поддержке не спрашивали, что будет, когда закончится память для традиционной СУБД?


(флегматично) для традиционной SQL СУБД, если кончается память - не страшно и свопнуться.

А вот для in-memory обработки ограничения сап несколько.. хммм.. внезапны, что ли. Ну вот сколько HANA может максимум переварить? 4ТБ, да? А теперь вспомним реальные размеры продуктивных БД.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP HANA карьера
СообщениеДобавлено: Ср, окт 07 2015, 01:00 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, сен 28 2006, 12:36
Сообщения: 1329
Откуда: Москва
Пол: Мужской
Кодер написал(а):

Уточнение для ясности: а система, на которую водрузили обнову, соответствовал спецификации сапы? Или по традиции: у нас был свободный ноут, и мы решили попробовать новую систему? :-)

Обижаете... Параметры соответствуют базовому appliance в 128gb памяти. Подкачали только диски по части выдаваемых iops, но на производительность и oom жалоб нет.

Кодер написал(а):

А вот для in-memory обработки ограничения сап несколько.. хммм.. внезапны, что ли. Ну вот сколько HANA может максимум переварить? 4ТБ, да? А теперь вспомним реальные размеры продуктивных БД.

Своими руками год назад просчитывал архитектуру на 16tb scale-out

При этом уже тогда некоторые вендоры говорили о 160tb.

Не стоит забывать, что при расчете обычная бд (сырые данные) -> HANA, берется коэф сжатия 1/10.
И получается требуемый объем памяти для бд.
Т.е. Если ваш нынешний оракл весит 40tb, то по сайзеру сапа ему в бд hana понадобится 4-5tb памяти


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP HANA карьера
СообщениеДобавлено: Ср, окт 07 2015, 01:10 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 16:38
Сообщения: 1144
Цитата:
Своими руками год назад просчитывал архитектуру на 16tb scale-out
При этом уже тогда некоторые вендоры говорили о 160tb.


Ну.. просчитывать архитектуру - это одно. А разрешения в спецухе вендора БД - другое. Можно ссылку на сайте сапа, где говорится, что можно больше 4Тб оперативки?

Цитата:
Не стоит забывать, что при расчете обычная бд (сырые данные) -> HANA, берется коэф сжатия 1/10.
И получается требуемый объем памяти для бд.
Т.е. Если ваш нынешний оракл весит 40tb, то по сайзеру сапа ему в бд hana понадобится 4-5tb памяти


Кем берется? Вот мне опять же интересно по части сжатия, кто-нибудь реально пробовали залить в HANA большую таблу сырых данных, так чтобы там было 3-4 поля с фиксед поинт децималс? И какой коэффициент сжатия был после этого? Ну и ключевой вопрос: относительно чего считался этот коэф. сжатия? Кто-нибудь способен объяснить, что за числа показываются в соответствующем столбце в HANA studio? Чо это за ratio? Отношение чего к чему?
.. если мне не изменяет память, в оракле же тоже есть сжатие? нет?

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


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

Зарегистрирован:
Чт, сен 28 2006, 12:36
Сообщения: 1329
Откуда: Москва
Пол: Мужской
Кодер
коллега, Вы хотите получить готовые ответы на свои риторические вопросы.

про 16Тб - обсчитывался реальный проект со вполне реальным железом.
поищите информацию по фразе "HANA Scale-out"
просто для примера - http://www.ibm.com/solutions/sap/us/en/landing/100tb_hana.html

на счет сжатия - почитайте рекомендации сапа по сайзингу HANA.


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

Зарегистрирован:
Пн, мар 28 2005, 16:38
Сообщения: 1144
Цитата:
коллега, Вы хотите получить готовые ответы на свои риторические вопросы.


Ну не все же из них риторические! Вот к примеру про значение поля "коэф.сжатия" из HANA Studio. Как мне кажется - очень даже конкретный практический вопрос!

Про тех спецуху я могу привести выдержку из официального FAQ:
With current hardware, SAP HANA can scale up to 6TB for a single system, and can scale out to 112TB in a cluster, or more.

таки да. Мои сведения устарели. Уже не 4, а 6 Тб на single system. Дальше только кластер. Не, они говорят далее, что постараются до конца года сделать 24 Тб. Но пока что - что есть, то есть. А вопрос миграции на новую версию той же ханы - тоже не простой.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP HANA карьера
СообщениеДобавлено: Ср, окт 07 2015, 11:25 
Старший специалист
Старший специалист

Зарегистрирован:
Пн, фев 21 2005, 13:41
Сообщения: 361
Кодер написал(а):
(флегматично) для традиционной SQL СУБД, если кончается память - не страшно и свопнуться.
А вот для in-memory обработки ограничения сап несколько.. хммм.. внезапны, что ли. Ну вот сколько HANA может максимум переварить? 4ТБ, да? А теперь вспомним реальные размеры продуктивных БД.

А вы считаете, что в HANA жестких дисков нет? Тоже будет свопаться, как и в традиционной СУБД.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP HANA карьера
СообщениеДобавлено: Ср, окт 07 2015, 11:38 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 16:38
Сообщения: 1144
Цитата:
А вы считаете, что в HANA жестких дисков нет? Тоже будет свопаться, как и в традиционной СУБД.


дык.. собственно при свопе будет терятся выигрыш in-memory обработки. О том и плачутся люди на форумах.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP HANA карьера
СообщениеДобавлено: Ср, окт 07 2015, 12:26 
Ассистент
Ассистент

Зарегистрирован:
Чт, мар 27 2014, 16:22
Сообщения: 34
Кодер написал(а):
Вот мне опять же интересно по части сжатия, кто-нибудь реально пробовали залить в HANA большую таблу сырых данных, так чтобы там было 3-4 поля с фиксед поинт децималс?

Реально большой нет, но вот есть одна BW-шная ODS-ка (45GB, 125M строк, 70 колонок - из них 3 штуки DECIMAL (17,2) и все остальные варчары)

Размер в Oracle 12.1.0.2 :

на диске некомпрессная - 46848 MB
на диске компресная (таблица создана с COMPRESS FOR DIRECT_LOAD OPERATIONS) - 14464 MB
в колоночном INMEMORY-кэше (вся таблица в режиме MEMCOMPRESS FOR QUERY HIGH) - 5271 MB

В HANA SPS09, согласно M_CS_TABLES эта же таблица занимает 3338 MB


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: SAP HANA карьера
СообщениеДобавлено: Ср, окт 07 2015, 12:36 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 16:38
Сообщения: 1144
kds: спасибо! Т.е. я правильно понимаю, что у оракла тоже вполне получилось хорошо пожать таблицу? не 10 раз. Но тоже хорошо?

ЗЫ: что-то как-то совсем не о карьере разговор идет

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP HANA карьера
СообщениеДобавлено: Ср, окт 07 2015, 13:56 
Ассистент
Ассистент

Зарегистрирован:
Чт, мар 27 2014, 16:22
Сообщения: 34
Кодер написал(а):
kds: спасибо! Т.е. я правильно понимаю, что у оракла тоже вполне получилось хорошо пожать таблицу? не 10 раз. Но тоже хорошо?

Если говорить за "дисковую" компрессию для direct load , то получается, что данная конкретная таблица пожалась в 3 раза, но здесь сильно зависит от структуры таблицы и самих данных в ней (например таблица LINEITEM из теста TPC-H сжалась только с 36GB до 24GB)
Дополнительно в Oracle есть еще опция (платная) Advanced Compression для OLTP-режима, возможно с ней будет получше, но я не проверял.

В IM-кэше (InMemory Option) действительно сжимается хорошо, кстати провел эксперимент : изменил таблицу на режим MEMCOMPRESS FOR CAPACITY HIGH и в IM-кеше она заняла 2512 MB, т.е. в два раза лучше чем в режиме FOR QUERY HIGH (и по сравнению с несжатым объемом вышло 45GB vs 2.5GB, что даже чуть лучше чем у HANA'ы). При этом производительность тестового запроса с фулсканом упала только на 10% (по сравнению с режимом FOR QUERY HIGH).

p.s. все, закругляюсь с офтопом


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: SAP HANA - решение (оффтоп из Обсуждения рынка труда)
СообщениеДобавлено: Ср, окт 07 2015, 15:47 
Старший специалист
Старший специалист

Зарегистрирован:
Пн, фев 21 2005, 13:41
Сообщения: 361
Кодер написал(а):
дык.. собственно при свопе будет терятся выигрыш in-memory обработки. О том и плачутся люди на форумах.
ну извините, если у вас нет памяти, то сложно ожидать выигрыш от in-memory обработки. О чем тут плакаться? :) Если в обычной СУБД закончится RAM, она тоже летать не будет, мягко скажем. А если нет места на диске, то что тогда? Теряются выигрыши от использования СУБД?
Да, сайзинг важен. Это факт. Да, не всегда возможно добавить память. Да, поддержка Scale-Out есть только для BI.
Но это не значит, что здесь зарыта какая-то катастрофа по сравнению с традиционными СУБД. Это тоже самое, что говорить - что нам делать, если у нас на SSD диске место закончилось. Ну плохо, да, ну теряются преимущества, никто не спорит. Но это не значит, что SSD использовать поэтому не надо.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP HANA - решение (оффтоп из Обсуждения рынка труда)
СообщениеДобавлено: Ср, окт 07 2015, 18:40 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 16:38
Сообщения: 1144
BillyBird
Цитата:
А если нет места на диске, то что тогда? Теряются выигрыши от использования СУБД?
Да, сайзинг важен. Это факт. Да, не всегда возможно добавить память. Да, поддержка Scale-Out есть только для BI.
Но это не значит, что здесь зарыта какая-то катастрофа по сравнению с традиционными СУБД. Это тоже самое, что говорить - что нам делать, если у нас на SSD диске место закончилось. Ну плохо, да, ну теряются преимущества, никто не спорит. Но это не значит, что SSD использовать поэтому не надо.


Напрасно ерничаете. В случае обычного оракла: кончилось место - докупили винты, добавили в таблспейс, и понеслась дальше. А у ханы концепция "я нормально работаю только если все в памяти". См выше, на single server ограничение еще недавно было 4 Тб, теперь 6Тб. Но это для прод.базы копейки. И докупкой плашки в сервер вы ситуацию в этом случае не улучшите.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP HANA - решение (оффтоп из Обсуждения рынка труда)
СообщениеДобавлено: Чт, окт 08 2015, 00:40 
Старший специалист
Старший специалист

Зарегистрирован:
Пн, фев 21 2005, 13:41
Сообщения: 361
Кодер написал(а):
Напрасно ерничаете. В случае обычного оракла: кончилось место - докупили винты, добавили в таблспейс, и понеслась дальше. А у ханы концепция "я нормально работаю только если все в памяти". См выше, на single server ограничение еще недавно было 4 Тб, теперь 6Тб. Но это для прод.базы копейки. И докупкой плашки в сервер вы ситуацию в этом случае не улучшите.
Для начала я бы перестал считать блоги bluefin официальными :) Если погуглить одну секунду, очень легко найти список
сертифицированных hardware для HANA, где есть и 12 TB http://global.sap.com/community/ebook/2 ... ances.html.
12 TB база In Memory (которая примерно соответствует 20 TB обычной дисковой, если говорить про ERP) - вовсе не копейки. Например тот же обычный Оракл тоже имеет ограничения на размер тайблспейса, не сильно отличающиеся от этих 20 TB. Тут другая проблема - цена. Тут вопросов нет, намного дороже решение.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP HANA - решение (оффтоп из Обсуждения рынка труда)
СообщениеДобавлено: Чт, окт 08 2015, 10:30 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 16:38
Сообщения: 1144
Цитата:
Для начала я бы перестал считать блоги bluefin официальными :) Если погуглить одну секунду, очень легко найти список
сертифицированных hardware для HANA, где есть и 12 TB http://global.sap.com/community/ebook/2 ... ances.html.


Ок, пусть найденные мной данные не официальные. Но не могли бы вы пояснить, что значат в приведенной вами ссылке сокращения SoH в графе appliance type? Это как раз тот тип, который значится у железа с большим объемом оперативки. Насколько я понял, этот как раз из разряда "совсем даже не 1 нод", и соответственно, ценник - совсем другой.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP HANA - решение (оффтоп из Обсуждения рынка труда)
СообщениеДобавлено: Чт, окт 08 2015, 12:18 
Старший специалист
Старший специалист

Зарегистрирован:
Пн, фев 21 2005, 13:41
Сообщения: 361
Кодер написал(а):
Ок, пусть найденные мной данные не официальные. Но не могли бы вы пояснить, что значат в приведенной вами ссылке сокращения SoH в графе appliance type
Это Suite on HANA. Это один нод. Здесь можно почитать - http://scn.sap.com/docs/DOC-52522. В общем я бы так сказал - да, нужно много памяти для этого решения и в итоге может получиться очень дорого. Проблема в этом основная. Ну и, соглашусь, память не всегда можно взять и вставить, так что сайзинг крайне важен.


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу Пред.  1, 2, 3  След.

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


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

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


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

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