Текущее время: Чт, мар 28 2024, 19:23

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




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

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


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

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

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


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

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

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

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

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

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

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

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

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


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

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


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

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


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

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


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

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

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

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


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

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


Ну не все же из них риторические! Вот к примеру про значение поля "коэф.сжатия" из 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, 10:25 
Старший специалист
Старший специалист

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

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


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

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


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

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


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

Зарегистрирован:
Чт, мар 27 2014, 15: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, 11:36 
Почетный гуру
Почетный гуру
Аватара пользователя

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

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

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


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

Зарегистрирован:
Чт, мар 27 2014, 15: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, 14:47 
Старший специалист
Старший специалист

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


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

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


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

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


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

Зарегистрирован:
Пн, фев 21 2005, 12: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, 09:30 
Почетный гуру
Почетный гуру
Аватара пользователя

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


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

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


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

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


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

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


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

Сейчас этот форум просматривают: Google [Bot]


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

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