В таком случае, что по вашему мнению означает термин ИНДЕКС?

И зачем было так стараться сжимать данные в поколоночном хранении, чтобы держать их в распакованном виде в словаре?

adropofmind

Да, экономят место в оперативке.
Причем HANA сама в зависимости от данных выбирает "лучший" механизм сжатия - там и кодирование длинн серий и кластерное кодирование и кодирование паттернами и т.д.

murmur

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

Когда данные лежат по строкам их необходимо дополнительно индексировать(создавать эти указатели). Здесь же сама структура хранения подразумевает возможность быстрого поиска.

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

компрессия - декомпрессия - это как верно заметил коллега - для места.
Ну и посыл с многопоточными процессорами, которым так нечем заняться, а так они будут компрессировать-декомпрессировать...
Но вообще, AFAIK, запросы типа - взять все значения из строки - это не конек HANA. И тут традиционные СУБД выигрывают. С другой стороны они проигрывают в поиске, если поиск не по индексу.
Платтнер тут напирает на то, что типа такие запросы (со всеми строками) и не нужны особо.

Ну вот вы и нарисовали классический индекс. У вас в словаре лежит значение и ссылка на сторки пусть не таблицы, но столбца.

Если все-таки предположить, что столбец сжимаем, то получим следующий вид

Словарь у нас для C4 выглядит так:
A1 - 0
A2 - 1
A3 - 2

Сам столбец у нас выглядит так:
0 - 1 2 3
1 - 4 5 6 7
2 - 8 9 10

то мы получаем классический индекс. Однако, если вернуться к запросу, который я нарисовал, то становится понятным, что найдя строку #6 по условиям C1, C2, C3 в приведенной вами схеме хранения (при условии, что данные сжаты) мы не сможем получить значение A2 из C4, пока не разожмем их, причем в такой вид, где можно будет по #6 быстро найти значение ключа 1, по которому затем найдем A2 в словаре. Если же данные не сжаты, то сравните классический реляционный вид

ROWID Field_1 Field_2 ...

с вашим поколоночным

C1(ROWID Field_1), C2(ROWID Field_2), ...

Как по вашему, где избыточность выше? Ну да, я понимаю, что SELECT C1 FROM T WHERE C1 = 'значение' можно выполнить на одном столбце, но еще раз повторю, что когда вы начнете соединять "неключевые" столбцы (такие как C4) вы будете терять в производительности (при условии, что столбцы в оперативке лежат сжатыми). Это не будет очень заметно, т. к. всевыполняется в оперативке. То есть ключ к происводительности - это ОПЕРАТИВКА, а не способ хранения данных!

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

2Dimarik
- а что говорят "новые технологии" по поводу сверки данных в таблицах БД ERP и HANA database(которая не Sybase)?
Поясню свой вопрос.
Есть таблица в БД (ERP, BW, etc.) эта таблица реплицируется в HANA database.
Предположим, что в процессе репликации данных возник некий сбой.
Например, сбой возник при формировании некой проводки в ERP.
Как производить проверку целостности данных в таблице со стороны БД ERP и в HANA database?
Возможно ли быстро и качественно выполнить вышеописанную операцию и синхронизировать данные?
Если возможно, то как именно?

- ой ли?
Не зарекайтесь, САП неоднократно заявлял что "по-другому не будет", ан нет.
При соответствующем уровне компенсации готов работать даже с ХАНОЙ...
Что делать работа есть работа...

Так же, в данном топике уже обсуждался вопрос по поводу ХАНЫ в облаках.
Если это произойдет, то вероятно, что с САП-ом придется расстаться не только мне одному...
Поверьте мне на слово, лично для меня подобный переход будет менее болезненным, чем для других участников данной дискусии.

ЗЫ Как говориться, "easy come easy go".

Ещё раз повторю -
Есть вопрос по SLT и проблемам с репликацией - гоу ту в соответствующую ветку.
Есть вопрос по поводу производительности в HANA - гоу ту в соответствующую ветку.
Хотите потестить производительность HANA vs Application Server - курс HA400 и вперёд (там подробно расскажут как и что с примерами)

Есть сомнения, что HANA это ключевое направление для SAP и что SAP очень хочет отъесть рынок БД - напишите в Walldorf и спросите сами.
Считаете, что HANA сырая и внедрять её пока рано - ждите SP(Ч), где Ч - в интервале от 6(текущий) - до XXX (жизненный цикл)
Считаете, что разберётесь с ханой за пару недель потому что вас есть знания в ХХХ базе - отлично. Когда разберётесь - попробуйте решить задачка для гуру в HANA
Считаете, что Oracle / Teradata / база ХХХ круче HANA - идите работать DBA Oracle / Teradata / база ХХХ
Считаете, что Хассо Платтнер не прав и ничего не понимает в ERP и базах данных - заработайте 6.9 миллиардов долларов, а потом поговорим

Как-то так:)

Я настоятельно прошу вспомнить, кто модератор раздела. И не затыкать людям рты.
И так, до кучи. Что бы не случилось с темой и форумом, кэш гугла хранит всё и много лет. Как бы потом краснеть не пришлось.

- вообще то вопрос был задан по сверке данных в таблице БД ERP и HANA database.
На этот простой, но актуальный вопрос был дан ответ "гоу ту", что неприемлимо...
В любой школе, ВУЗе, собеседовании за подобный ответ Вам гаранитрован твердый "неуд" (в простанародье - двойка).
Лично для себя, я делаю вывод, что низкий уровень Вашей компетенции в данном вопросе не позволяет Вам дать правильный ответ.

Чем, когда, где и как мне заниматься, решу без Вас - это факт, т.к. Вы мне для этого банально не нужны.
Можете повесить себе портрет Хассо Платтнера в углу комнаты и молиться на сей персонаж - это Ваши личные проблемы.

ИМХО Насколько я понимаю, целью данного топика является обсуждение достоинств и недостатков программно-аппаратного комплекса под названием САП ХАНА.
Ну вот, собственно и обсуждаем...

ЗЫ В одном Вы точно правы, Oracle DBA я уже работал...

Вот и скатилось к ожидаемому "читайте пресс-релизы" и "сперва добейся". И зачем было отрицать принадлежность к маркетингу?

Иным участникам стоит вставить в подпись продаю/сопровождаю Хану, и все станет более прозаично.

Я бы тоже хотел бы написать go to, но теперь не буду )
Не надо все так упрощать, сейчас в направлении columnar database in memory движется ведь не только SAP, но и все остальные. Наверное тут есть и маркетинговый hype, так как всегда здорово продать то же самое, вид сбоку, но, наверняка, не только в маркетинге дело. Причем вот тучи способов эффективной работы при куче памяти почему-то не очень придумываются. В той же ХАНА судя по тому, что я читал, куча хитроумных извращений приходится применять даже для достаточно простого подхода. И у остальных вендоров тоже не все так элементарно.
Вы верно пишете, что действительно, чем больше полей, по которым нет поиска возвращаются в результате запроса - тем хуже для таких СУБД. Очевидны проблемы с обновлением данных. Плюс поддержка транзакционности, бэкапы, высокая доступность, расширяемость и т.д.
Но говорить, что это полная фигня, только на основании того, что SAP DB не пошел, Dimarik пишет сообщения не тем тоном, а в Северстали вообще всё упало - не совсем верно

Я не говорил, что это полная фигня. Я просто говорил, что ключом к высокой скорости является прежде всего быстрая память и ее количество, а остальное уже вторично.