Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: HCC без экзадаты  [new]
Birkhoff
Member

Откуда: Москва
Сообщений: 3047
Alexander Anokhin
Birkhoff
пропущено...
Не совсем уверен, что понял ваш вопрос. Конечно, я пробовал это на Exadata. Распаковкой HCC занимаются ячейки Exadata. Возможно, если использовать какие-то эмуляторы или заставлять заниматься распаковкой сервер Oracle (а не ячейки) может быть и будет какое-то замедление.

Полагаю, что вы ошибаетесь.
Распаковкой занимаются ячейки Exadata, если offloading произошел. Иначе database серверы.
Ну я как бы и имел в виду, что запрос с offloading. Иначе смысла сравнивать нет.
Да, у меня условно запрос был как у orawish - подсчет суммы фуллсканом по одной таблице. Такой запрос очень хорошо оффлоадится.
В чем ошибка?
18 апр 12, 19:06    [12435312]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
Alexander Anokhin
Member

Откуда: Хабаровск
Сообщений: 500
Нет ошибки, всё верно.
18 апр 12, 19:09    [12435329]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
Alexander Anokhin
Member

Откуда: Хабаровск
Сообщений: 500
Я был (и продолжаю быть ;-)) немного запутан этой фразой
автор
если использовать какие-то эмуляторы или заставлять заниматься распаковкой сервер Oracle (а не ячейки)
потому как сервер Oracle итак занимается распаковкой, если не распаковалось на offloading. Если же распаковывать во время offloading не на ячейках, а на на database level, тогда offloading данных не увидит.
18 апр 12, 19:24    [12435419]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
Birkhoff
Member

Откуда: Москва
Сообщений: 3047
Alexander Anokhin
Я был (и продолжаю быть ;-)) немного запутан этой фразой
автор
если использовать какие-то эмуляторы или заставлять заниматься распаковкой сервер Oracle (а не ячейки)
потому как сервер Oracle итак занимается распаковкой, если не распаковалось на offloading. Если же распаковывать во время offloading не на ячейках, а на на database level, тогда offloading данных не увидит.
А я вот не понял, что значит "Если же распаковывать во время offloading не на ячейках" :) Это как? offloading вроде бы как раз и предполагает обработку на ячейках.
18 апр 12, 19:30    [12435448]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
recovery manager
Guest
А ничего что сжатые данные вобще не "распаковываются" при обработке?
18 апр 12, 20:07    [12435611]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
Alexander Anokhin
Member

Откуда: Хабаровск
Сообщений: 500
Birkhoff
А я вот не понял, что значит "Если же распаковывать во время offloading не на ячейках" :) Это как?

этот был перефразирован следующий фрагмент:
Birkhoff
...заставлять заниматься распаковкой сервер Oracle (а не ячейки)
Birkhoff
Ну я как бы и имел в виду, что запрос с offloading.
18 апр 12, 20:12    [12435627]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
Birkhoff
Member

Откуда: Москва
Сообщений: 3047
recovery manager
А ничего что сжатые данные вобще не "распаковываются" при обработке?
А сумму как считать?
18 апр 12, 20:13    [12435628]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
Birkhoff
Member

Откуда: Москва
Сообщений: 3047
Alexander Anokhin
Birkhoff
А я вот не понял, что значит "Если же распаковывать во время offloading не на ячейках" :) Это как?

этот был перефразирован следующий фрагмент:
Birkhoff
...заставлять заниматься распаковкой сервер Oracle (а не ячейки)
Birkhoff
Ну я как бы и имел в виду, что запрос с offloading.
Ну, например, если данные лежат на ZFS, который поддерживает HCC, но не имеет Exadata Software, то данные будут браться со стораджа и распаковываться на сервере Oracle после передачи по сети.

Возможны, конечно и другие варианты, когда офлоадинг не проходит, но я имел в виду именно рафинированный случай, когда запрос оффлоадится и все, что можно делается на ячейках. В начале дискуссии народ писал о разных вариантах использовать HCC без Exadata. Это я не рассматриваю.
18 апр 12, 20:17    [12435645]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
recovery manager
Guest
Birkhoff
recovery manager
А ничего что сжатые данные вобще не "распаковываются" при обработке?
А сумму как считать?


Ну хоть ради любопытства посмотри как устроен HCC.
Вся обработка ведется на сжатых данных, восстановление
строки производится только при возврате result-set клиенту.
18 апр 12, 20:22    [12435657]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
Birkhoff
Member

Откуда: Москва
Сообщений: 3047
recovery manager
Birkhoff
пропущено...
А сумму как считать?


Ну хоть ради любопытства посмотри как устроен HCC.
Вся обработка ведется на сжатых данных, восстановление
строки производится только при возврате result-set клиенту.
Не знаю, но допустим. А как это влияет на принципиальное ускорение обработки фуллсканов, о котором идет речь? Вопрос о том, ускоряется ли обработка на Exadata при условии, что данные сжаты HCC?

P.S. Что-то много анонимов в треде.
18 апр 12, 20:30    [12435680]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
recovery manager
Guest
Birkhoff
recovery manager
пропущено...


Ну хоть ради любопытства посмотри как устроен HCC.
Вся обработка ведется на сжатых данных, восстановление
строки производится только при возврате result-set клиенту.
Не знаю, но допустим. А как это влияет на принципиальное ускорение обработки фуллсканов, о котором идет речь? Вопрос о том, ускоряется ли обработка на Exadata при условии, что данные сжаты HCC?

P.S. Что-то много анонимов в треде.


За счет уменьшения обьема сканирумых данных, которые разжимать
_не_надо_, плюс отсутствие накладных расходов БД, таких как
дерганье разнообразных латчей и прочей гадости. Плюс обработкой
занимается не один процесс/ядро, а все ядра storage-cell, которых
по одному на каждый физический диск.

Не забываем про Storage Index и Flash Cache.

ps. Какие бывают flash cache в Экзадате ? ;-)
18 апр 12, 20:56    [12435768]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
ускорить full scan/index range
Guest
recovery manager
Birkhoff
пропущено...
Не знаю, но допустим. А как это влияет на принципиальное ускорение обработки фуллсканов, о котором идет речь? Вопрос о том, ускоряется ли обработка на Exadata при условии, что данные сжаты HCC?

P.S. Что-то много анонимов в треде.


За счет уменьшения обьема сканирумых данных, которые разжимать
_не_надо_, плюс отсутствие накладных расходов БД, таких как
дерганье разнообразных латчей и прочей гадости. Плюс обработкой
занимается не один процесс/ядро, а все ядра storage-cell, которых
по одному на каждый физический диск.

Не забываем про Storage Index и Flash Cache.

ps. Какие бывают flash cache в Экзадате ? ;-)

Ну для partition range iterator и storage index понятное дело, что разжимать данные не нужно. Помимо них offload-ятся так же предикаты where и HCC. (агрегаты и оконные функции не офлоадятся)
А для smart scan по предикатам их тоже не нужно разжимать, т.е. и по сети к DBMS они передаются в сжатом виде после обработки where?
И какой из известных алгоритмов сжатия позволяет фильтровать и вычленять любые куски данных без распаковки?
18 апр 12, 21:14    [12435842]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
Birkhoff
Member

Откуда: Москва
Сообщений: 3047
recovery manager
Birkhoff
пропущено...
Не знаю, но допустим. А как это влияет на принципиальное ускорение обработки фуллсканов, о котором идет речь? Вопрос о том, ускоряется ли обработка на Exadata при условии, что данные сжаты HCC?

P.S. Что-то много анонимов в треде.


За счет уменьшения обьема сканирумых данных, которые разжимать
_не_надо_, плюс отсутствие накладных расходов БД, таких как
дерганье разнообразных латчей и прочей гадости. Плюс обработкой
занимается не один процесс/ядро, а все ядра storage-cell, которых
по одному на каждый физический диск.

Не забываем про Storage Index и Flash Cache.

ps. Какие бывают flash cache в Экзадате ? ;-)
Нет, ты опять не понял мой вопрос. Дискуссия о том, дает ли HCC на Exadata ускорение для запросов? Дает. Все с этим согласились. И даже привели цифры.
Как именно это работает на атомарном уровне я, например, могу до конца не знать, но это и не моя задача/работа.

Я выяснил эмпирически, что ускорение свободного падения - 9,8 м/c^2. Но я не знаю, ответственны ли за это бозоны Хиггса, есть ли они вообще или всему виной искривление пространства-времени?

Хотя я все равно не понял, как сумму сжатых чисел сосчитать не распаковывая.
18 апр 12, 21:18    [12435862]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
recovery manager
Guest
ускорить full scan/index range
recovery manager
пропущено...


За счет уменьшения обьема сканирумых данных, которые разжимать
_не_надо_, плюс отсутствие накладных расходов БД, таких как
дерганье разнообразных латчей и прочей гадости. Плюс обработкой
занимается не один процесс/ядро, а все ядра storage-cell, которых
по одному на каждый физический диск.

Не забываем про Storage Index и Flash Cache.

ps. Какие бывают flash cache в Экзадате ? ;-)

Ну для partition range iterator и storage index понятное дело, что разжимать данные не нужно. Помимо них offload-ятся так же предикаты where и HCC. (агрегаты и оконные функции не офлоадятся)
А для smart scan по предикатам их тоже не нужно разжимать, т.е. и по сети к DBMS они передаются в сжатом виде после обработки where?
И какой из известных алгоритмов сжатия позволяет фильтровать и вычленять любые куски данных без распаковки?


Перечитал 10 раз. Не понял вобще ничего. Проспись и сформулируй мысль яснее.
18 апр 12, 21:24    [12435895]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
ускорить full scan/index range
Guest
Birkhoff
Хотя я все равно не понял, как сумму сжатых чисел сосчитать не распаковывая.

Да никак. Там человек фантазирует от незнания принципов алгоритмов сжатия.
Тут принципиально могут быть только 2 варианта:
1. это распаковка и тут же выполнение агрегирования, т.е. все в пределах регистров/кэша L1 - экономия времени на запись и чтение распакованных данных из/в RAM
2. Распаковка, фильтрация по where и снова упаковка для якобы ускорения передачи по сети, но это сомнительное удовольствие.
18 апр 12, 21:27    [12435910]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
А.
Guest
recovery manager
За счет уменьшения обьема сканирумых данных, которые разжимать
_не_надо_,

Каким образом обработка без декомпрессии уменьшает объем сканируемых данных?

recovery manager
плюс отсутствие накладных расходов БД, таких как
дерганье разнообразных латчей

Уже выше было сказано, ячейки распаковывают только во время offloading / direct path, что уже исключает дерганье латчей.
Так что не в тему абсолютно.


recovery manager
Плюс обработкой
занимается не один процесс/ядро, а все ядра storage-cell, которых
по одному на каждый физический диск.

Не забываем про Storage Index и Flash Cache.

Это каким образом относится к тому распаковываются ли данные во время обработки без возврата result set?


Чтобы обрабатывать упакованные данные для всех функций, которые поддерживаются при SmartScan должны быть написаны аналоги для всех видов компрессий. Что весьма сомнительно.


К вопросу про то как это влияет на ускорение. Если бы обработка велась без декомпрессии, то запросы с небольшими resultset'ами на упакованных данных потребляли бы меньше CPU, чем на неупакованных.
18 апр 12, 21:41    [12435981]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
recovery manager
Guest
Birkhoff,

Писать детальную статью Exadata Internals сейчас не буду,
вечер таки , схематично накидаю, ок ? :)

Ну смотри как он жмет - берет некий кусок блоков и обьявляет
их неким т.н. compression unit (cu). Для этого юнита у него
есть некая карта, назовем ее compression unit map. (cum. Клевая
аббривеатура получилась, теперь буду использовать всегда :-)

Т.е. к примеру, табличка такого вида:
id, фамилия, город, код тарифного плана, цена. Содержимое вроде:

1, Пупкин, Москва, home_inet_unlim_450, 450руб
2, Васечкин, Москва, ip-tv-100, 120руб
3, Иванов, Москва, home_inet_unlim_450, 460руб
4, Петров, Санкт-Петербург, home_inet_unlim_600, 600руб
5, Сидоров, Москва, home_inet_unlim_600, 600руб

В cum составляется таблица соответствий, ну вроде:

Москва = 1
home_inet_unlim_450 = 2
Санкт-Петербург = 3
450 = 5
600 = 6


Итого в cu будет храниться:

1, Пупкин, #1, #2, #5
2, Васечкин, #1, ip-tv-100, 120
3, Иванов, #1, #2 ,#5
4, Петров, #3, #2, #6
5, Сидоров, #1, #2, #6

Меньше ? Да. Сжали? Да. Чем больше повторяющихся значений,
тем больше сжатие.

Потом, при сканировании, нужно глянуть в cum чтобы понять какой
код чему соответствует. Нужен фильтр по Москве ? Да пожалуйста,
внутри будет выглядеть как select where город = #1.
Просуммировать цену ?
select count where цена = #6 (предельно упрощенно, но принцип понятен,
да?).

Да, есть накладные расходы на считывние cum, именно поэтому ускорение
не 1х, а 0.9х от коэффициента сжатия. Но опять же, карта, как правило
располагается во flash-cache, и доступ к ней быстрее чем физическое чтение.

И декомрессия будет происходить только на этапе fetch данных клиенту,
он будет реконструировать строку из этих кодов.

Кстати, даже если обработка не происходит на ячейке, а просто одноблочным
чтением блок компрессированной таблицы попал в буфферный кэш - он
там и останется таким, никаких декомпрессий не происходит.

Хм. Что то и так дофига накатал. Подробности - позже :)
18 апр 12, 21:59    [12436072]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
recovery manager
Guest
Ого вы тут нафлудили пока я писал. :)
Сколько же тут экспертов. И как давно у вас экзадата?
Как глубоко вы изучили механизмы ее работы ? :)
18 апр 12, 22:03    [12436098]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4917
Блог
recovery manager,

Вы замечательно все описали, но у меня остался вопрос, почему описанный вами алгоритм называется Hybrid Columnar Compression?
18 апр 12, 22:06    [12436120]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
Birkhoff
Member

Откуда: Москва
Сообщений: 3047
recovery manager,

Так. Знаешь, я в общем-то ламер в этих делах. Даже с самого начала написал.
Но что меня смущает. HCC - это Hybrid Columnar Compression. Ключевое слово Columnar.

В твоих выкладках я вот совсем не увидел ничего, связанного с колоночной компрессией.

То, что ты описываешь очень похоже на Advanced Compression Option в лучшем случае.

Где колоночность то?

Спасибо за длинный текст.
18 апр 12, 22:10    [12436137]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
recovery manager
Guest
Alexander Ryndin,

Саша, кончай троллить :) Алексей. Первая компания в России
с экзадатой. Узнал ? ;-)
18 апр 12, 22:12    [12436142]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
ускорить full scan/index range
Guest
recovery manager
Ну смотри как он жмет - берет некий кусок блоков и обьявляет
их неким т.н. compression unit (cu). Для этого юнита у него
есть некая карта, назовем ее compression unit map. (cum. Клевая
аббривеатура получилась, теперь буду использовать всегда :-)

Сразу видно - перевод первоисточника.


recovery manager
Итого в cu будет храниться:

1, Пупкин, #1, #2, #5
2, Васечкин, #1, ip-tv-100, 120
3, Иванов, #1, #2 ,#5
4, Петров, #3, #2, #6
5, Сидоров, #1, #2, #6

Вопрос тут задавали про подсчет суммы. В данном случае придется для каждой строки:
1. брать последнее поле
2. лезть в вашу выдуманную аббревиатуру cum, брать оттуда значение
3. и производить сложение
Пункт 2 есть ни что иное, как распаковка.
18 апр 12, 22:23    [12436179]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
recovery manager
Guest
Birkhoff,

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

А вобще там еще мудренее - данные строки хранятся
в разных блоках cu. Типа в cum указано что значения
колонок для строки №1 хранятся в блоках 1,3 и 5.
Дальше при сканировании, агреггации и проч.
работают механизмы обработки без декомпрессии,
которые я описал выше.
18 апр 12, 22:26    [12436190]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
Bfink
Member

Откуда: Москва
Сообщений: 2797
recovery manager
Alexander Ryndin,

Саша, кончай троллить :) Алексей. Первая компания в России
с экзадатой. Узнал ? ;-)


Первой компанией был, все таки Oracle
18 апр 12, 22:40    [12436249]     Ответить | Цитировать Сообщить модератору
 Re: HCC без экзадаты  [new]
recovery manager
Guest
ускорить full scan/index range
recovery manager
Ну смотри как он жмет - берет некий кусок блоков и обьявляет
их неким т.н. compression unit (cu). Для этого юнита у него
есть некая карта, назовем ее compression unit map. (cum. Клевая
аббривеатура получилась, теперь буду использовать всегда :-)

Сразу видно - перевод первоисточника.


recovery manager
Итого в cu будет храниться:

1, Пупкин, #1, #2, #5
2, Васечкин, #1, ip-tv-100, 120
3, Иванов, #1, #2 ,#5
4, Петров, #3, #2, #6
5, Сидоров, #1, #2, #6

Вопрос тут задавали про подсчет суммы. В данном случае придется для каждой строки:
1. брать последнее поле
2. лезть в вашу выдуманную аббревиатуру cum, брать оттуда значение
3. и производить сложение
Пункт 2 есть ни что иное, как распаковка.


Хорошо, так понятнее?

select price,count(*) from accounts group by price;

price count(*)
____ ______
#5 2
#6 2

select (450*2) + (600 *2) from dual;

Куда там "лезть" ? В конце сканирования помножили на значения и вернули.

Ну а по поводу "Сразу видно - перевод первоисточника" - просто хи хи. :)
18 апр 12, 22:41    [12436256]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Oracle Ответить