Согласен. Так сказать, дал волю эмоциям на уколол от оппонента по поводу моего опыта и "моих институтских лабораторных". Виноват , исправлюсь!


Конечно, против лома нет приема, но я хотел показать разницу в 2-х ситуациях:
1. Когда злоумышленнику нужно перелезть через забор к колючей проволокой, прибить злую собаку, взломать бронированную дверь в дом, перебрать все белье в шкафу, перевернуть все матрацы, найти скрытый сейф, взломать его, и обнаружить в нем флешку с ключем от банковского счета, причем не указано в каком банке счет, не известен его номер, и на кого этот счет оформлен.
2. Залезть в открытую форточку и увидеть, как на столе стоит все добро "нажитое непосильным трудом" уже упакованное в сумки для переноски.


Из собственного опыта по сравнению. Закрытие периода (производственное предприятие, CO/PP), расчет ЗП (то же предприятие, HR-PY/PP/внешняя система с нормативами), обортка по материалам (ретейл MM/SD). Сравнение обычной системы OLTP с неоптимизированной HANA. В первых двух случаях БД - Oracle, в ретейле DB2. Разница составила именно В РАЗЫ. На SAPFans есть тема, там регулярно отписываются два индуса, которые постоянно сравнивают разные отчеты на SAP OLTP и SAP HANA. Так вот, они приводят случаи, где разница составляет не разы, а порядки. Ссылку найду, - выложу дополнительно.
По поводу оптимизации кода под HANA не вижу ничего предосудительного, вот Оракл все под себя оптимизирует. Но вопрос то в том, что нужно заплатить за Хану, а потом заплатить за оптимизицию, а это уже как то не честно. Особенно если сравнить вариант, в котором можно проадейтиться на In memory от того же Оракла или ИБМ и остаться в старом коде.


Согласен, посмотрим. Все может быть. Но, по моему скромному мнению будущее лежит в технологии гридовских решений. Если в сетку гридов включать не сервера, а процессора, имеющие непосредственные выход на высокопроизводительные коммуникационные каналы, типа инфинибенда или что того и плюс все более дешевеющие твердотельные диски. Такой подход намертво убъет подход с поколоночным хранением данных. Я думаю, что Ларри Элиссон именно это имел ввиду, когда ерничал над Ханой. Но... посмотрим.

Не не, давайте без аналогий. Упрощать вроде нечего, и так все доступно, а увлечение аналогиями может завести совсем не туда. Повторюсь - если у вируса оказалось достаточно полномочий чтобы шарить в чужом процессе, то ему скорее всего шарить в памяти ханы и не нужно - найдутся более удобные пути

Ну тут сказать особо нечего - у вас свой опыт, у меня свой. Помимо оптимизированной оборотки мы тестировали еще тяжелые неоптимизированные под хану Z-отчеты - там время выполнения на тестовом и вероятно не очень мощном стенде с ханой было сопоставимо со временем выполнения на продуктиве. Относительно небольшая оптимизация (выкидывание кеширования данных, объединение ряда простых запросов в сложные, перекладывание на сторону СУБД какой то промежуточной обработки данных и тому подобное) давала выигрыш по этим отчетам уже в 5-10 раз.
За ссылку заранее спасибо.

Свои приложения сап переделывает под хану и по моему не просит за это дополнительных денег. А Z да, за свой счет.

Долго не отвечал, может, и неактуально уже..
To markone:


О, я кажется выявил закономерность - Вы делаете выводы на основании неполных(неверных) данных, причем это в целом, не только о процитированном.


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


Вы не поверите, но в памяти данные хранятся в расшифрованном виде, вне зависимости от того, Oracle это, IBM или MS. С шифрованием у HANA все в порядке, и данные при записи на диск будут шифроваться (при условии активации, конечно же)


С чего это Вы вдруг накладываете такое ограничение?


Это всё от бедности. Если есть много дешевой RAM, наиболее оптимальным образом будет хранить всю таблицу в памяти целиком.

А BW-шник, у которого есть реальный (а не по-наслышке) опыт работы с продуктом BW on HANA, знает, что у любой колумнстор-таблицы есть такой признак, как "загружать при старте". И поверьте мне, далеко не у всех BW таблиц он выставлен в true.

Что значит, "не задевая"? Не распихивая процессорными руками? =))
Если упрощенно, то SELECT FIELD1, FIELD2, FIELD3 FROM TAB1 WHERE FIELD1='A' (при условии, что TAB1 - column store) выполняется так:
- по словарю вычисляется смещение элемента в WHERE условии (т.к. это в нашем случае 'A' - то смещение равно 1.) Вычислительная сложность данного действия - O(logN). В случае другой БД, при отсутствии индекса и промаха в кэше - это FullScan c O(N) сложностью и 90% времени ожидания на дисковом I/O.
- далее, используя аппаратные SIMD инструкции, первое ядро ЦПУ идет по сжатой FIELD1, второе - по FIELD2 и т.д., параллельно - это несколько процессорных тактов.
- затем формируется вектор значений, на основе которых производится материализация (подставляются значения словаря), и в сокет уходит содержимое SELECT'a


Вы реально не понимаете, как работает HANA. См. мой коммент выше.


Факты в студию, пожалуйста.


Технологии In-Memory мешало развиваться раньше только одно - дороговизна RAM. Как только ситуация изменилась, мир начал меняться, и это происходит на наших глазах, хотим мы этого или нет.

"Как? Вы не знаете что такое престидижидация?! О чем с Вами можно дальше разговаривать?" (с)
Я пониманию Ваше нежелание касаться темы защиты данных в HANA, - лучше в очередной раз съерничать. Потому что на вопрос " А как защищены данные в HANA", ответ - "А никак!". То что SAP называет защитой, это чепуха, - замочек от добрых людей, типа, как на почтовом ящике.



Не поверю. У Oracle точно есть возможность хранить данные DBIM в зашифрованном виде в оперативной памяти, не говоря уж про диски. Насколько мне известно, подобная функция есть и в DB2 BLU. про MS не скажу. У Oracle, кстати, в архитектуре SPARC есть даже специальный соспроцессор, позволяющий вести шифрование/расшифровку "влет" без задействования вычислительных ресурсов, что конечно у HANA нет и в помине.



Во-первых, это не от бедности, а от жадности, от жадности компании SAP. Только SAP лицензирует IM по объему памяти.
В во-вторых, как HANA может разместить 100 Тb таблицу (не говоря уж про базу данных)? Просто интересно, каким образом HANA сможет просто адресовать такой объем RAM? А еще интересно , сколько это будет стоить, и в железе, и в лицензиях?



Интересный пример. Вот давайте разберем его подробнее. Процесс вычисления смещения пропустим, пусть будет так, как описано - с логарифмами Остановимся на термине "смещение". Для определения однозначного объекта данных в БД есть два термина: 1- указатель, и 2- смещение. Указатель, это как номер дома. Вы идете по улице и знаете, что нам нужен дом 50, даже не так, вам нужен дом 50 и кв 30. В говорите таксисту, он подвозит к конкретному дому, а там вы находите нужный этаж и квартиру А вот когда вам говорят, что вам нужен 50 -й дом от угла, - это смещение, вы просите таксиста довезти вас до угла, и начинаете считать все дома попорядку: 1-й, 2-й..... 49-й, 50-й. Бинго! Вы на месте!

Вот, когда говориться "...первое ядро ЦПУ идет по сжатой FIELD1" имеется в виду, что в ядре процессора открывается вычислительный поток (или нить, кто как говорит), и в данном потоке идет перебор всех встречающихся записей пока мы не найдем наш "дом 50". Платформа х86 позволяет открывать 2 потока на ядро. Поток нельзя прерывать, некуда сохранять промежуточные данные. Если поток прервется, например на обработку более приоритетной задаи,все начинаем сначала. Если все потоки заняты, стоим курим бамбук. При процессоре Е5 с 18 ядрами у нас 36 потоков. Это несколько меньше, чем на SPARC с 256 потоками, вернее это более чем в 7 раз меньше! Ну это так, к слову.

И вот нам надо протащить три столбца ( FIELD1, FIELD2, FIELD3) через процессор для того чтобы найти нужное нам поле. Процессор все это время занят подсчетом нашего 50-го дома. В случае, если в столбце 1 млрд записей, -это как раз наши "несколько тактов" . (Написал "для того чтобы прочитать нужное нам поле", потом исправил на "найти") Да, поле еще не прочитано, а не прочитано, оно потому что оно сжато. Нам надо его раскрыть (разжать). Это еще "несколько тактов", вернее, это "затем формируется вектор значений, на основе которых производится материализация". Материализация! Вот оно ключевое слово! Мы наконец таки МАТАРИАЛИЗОВАЛИ значение SQL запроса к HANA.

Когда я писал "обработать одну строку", я имел ввиду, что ее надо прочитать, изменить данные, и эти измененные данные записать обратно в те же поля той же стоки. Я думаю, что уважаемый kernelpanic сможет описать процесс замены данных. Этот процесс гораздо более интереснее и увлекательнее чем банальное чтение. Да и kernelpanic прекрасно знает HANA, правила ее работы. Наверняка он прослушал множество курсов от SAP и еще болше прочитал методичек от SAP, не говоря уж о презентациях SAP. Может быть он даже где нибудь добудит данные бенчмаркинга именно работы OLTP HANA. Покажет нам , как HANA действительно "быстро" отрабатывает SQL запросы и мы сравним с другими БД. А ваш покорный слуга не скоро сможет отписаться в этой теме, - работы много.

Я хотел бы подвести некотрую красную черту своим постам в теме.
У меня абсолютно нейтральное отношение к HANA. Продукт, как продукт, - со своими плюсами и своими недостатками. НО! У меня ужасное впечатление от того, как SAP преподносит этот продукт. За свои 20 лет работы в SAP-овской теме я ни разу не сталкивался, с если можно так сказать, с таким хамским и неуважительным отношением SAP к своим партнерам и заказчикам, как в подаче темы HANA. Главный фокус не в том, что SAP говорит, а в том, о чем SAP не говорит. Комрады выше уже писали по поводу своей настроженности при взгляде в перспективу. У меня, например, нет видения положительного развития сценария HANA. Может я конечно чего то не знаю из стратегических планов, но разговаривая с коллегами, как в России, так вне, такую обеспокоенность проявляю не тллько я.
Недавно распивали очередную бутылку шнапса с коллегами из Вальдорфа, котрые работают чуть ли не с основания SAP. Понятно что их во всю выпихивают на пенсию, им от этого грустно. Но дело в другом. Они сейчас занимаются поддержкой и они показали интересную статистику, отчет о развернутых продуктивных ландшафтах и на каких БД. Отчет показали мельком, многие цифры не запомнил, но на что обратил внимание. 2011 год - Oracle - 235 000 PRD (запомнил Oracle, потому что больше всего), HANA соответсвенно 0 PRD. Конец 2015 - HANA - 1300 PRD, Oracle - чуть меньше 250 000 (или 249 500 или 248 500) Со слов немецких коллег 90% HANA PRD - новые, 10 % миграции. Делайте выводы.

markone, знаете, почему мне интересно с Вами дискутировать? Потому что любопытно по косвенным признакам составить картину того, насколько Вы (не)разбираетесь в информационных технологиях, пытаясь скрыть это под метафорами и маской менторства а-ля "эх, молодежь.."

Вкратце по Вашим тезисам:
1. Я с удовольствием коснусь темы защиты данных в HANA, тем паче, что эта сфера моих интересов. Но давайте только по существу, без воды.
2. Ваше утверждение, что "У Oracle точно есть возможность хранить данные DBIM в зашифрованном виде в оперативной памяти" говорит о том, что Вы имеете отдаленное представление о шифровании в принципе. Данные в БД, хранящиеся в зашифрованном виде на диске, в памяти, и не подвергающиеся операции шифрования-дешифрования на сервере баз данных возможны только при одном условии - когда шифрование осуществляется на клиенте, и сервер ничего про это не знает. Для него это будут обычные данные, пусть и бессмысленные с т.з. просмотра человеком в шестнадцатеричном редакторе. Если мы говорим о шифровании данных на уровне сервера БД, мы говорим о том, что данные подвергаются операциям шифрования-дешифрования. Единственная оптимизация, известная мне - это удаление ключа шифрования из оперативной памяти после расшифровки. Сами данные в памяти хранятся в расшифрованном виде. Не верите? Возьмите отладчик, и вперед, изучать. Впрочем, кому я это советую.. Умудренному опытом седому профессионалу от IT.
Про сопроцессор тоже понравилось =) Открою Вам страшную тайну, в интеловской архитектуре операции (де)шифрования х86 они встроены в основной процессор. За подробностями - в главу 5.12 Intel Software Developer Guide, vol.1
3. Опять же, наверное потрясение устоев для Вас, но размещает и адресует не база данных, а ОС и железо. Поэтому отвечая на Ваш вопрос ,как HANA разместит и адресует 100 ТБ таблицу - так же, как и Oracle, MS-SQL, Postgres и кто-там-еще - запросит соответствующие системные вызовы операционной системы. Ибо это не заботы (в общем) СУБД, а ОС.
4. Про смещение - тоже отличный пассаж! Почитайте (простите, но не могу не попытаться ликвидировать компьютерную безграмотность) про косвенную адресацию. Тогда Ваша метафора про адреса домов потеряет всякую художественную выразительность. Чтобы вычислить адрес значения из словаря в приведенном мною примере, процессору необходимо взять базовый адрес, взять длину элемента (никогда не задумывались, почему при проектировании таблицы, надо указывать длину поля?), умножить на смещение, после чего суммировать с базовым адресом. Это не операция последовательного перебора, как в примере с таксистом. Такое не знать простительно дизайнеру там, или даже "веб-программисту", плодящему сайты на CMS, но мы с Вами в специализированном разделе форума..
5.Далее, встречаю довольно разумное "в ядре процессора открывается вычислительный поток..." и у меня даже появляется надежда, что не все потеряно, как Вы все портите следующим - "Если поток прервется, например на обработку более приоритетной задаи,все начинаем сначала. " Увы, это опять говорит, что "что-то слышал про компьютеры". Вы не поверите (скорей всего), но даже горячо Вами любимый Oracle, и даже на SPARC'e от нескольких десятков до нескольких тысяч раз в секунду прерывается на исполнение более приритетной задачи, а точнее, задач, имя которым - обработчики прерываний. Более того (надеюсь, не разрушу Ваш мир), это единственно возможное поведение для операционных систем с вытесняющей многозадачностью (preemptive multitasking), коими являются современные UNIX'ы (допускаю, что не все), WinNT и Linux.
По поводу "сжатого поля" - опять же, Вы не понимаете, как работает механизм сжатия в HANA. Сжимается не словарь, я непосредственные значения в колонке (он же ValueID Array)
6. Коллега, Вы многократно наступаете на одни и те же грабли, несмотря на то, что Вам на это указывают. Не судите по людям по дате их регистрации на том или ином ресурсе. У Вас неправильные вводные, соответственно, и выводы неверные.
7. Никак не могу прокомментировать статистику по миграциям и новым проектам, не владею темой. Подводя красную черту Вашей красной черте, я хочу заметить, что у Вас есть недовольство SAP, есть недовольство их флагманом - HANA, но по техническому существу вопроса Вам сказать нечего.
Еще раз, я не преумаляю Oracle DB, не превозношу SAP HANA, мне в целом не нравится, когда люди не владея вопросом, стремятся что-то авторитетно заявлять. Особенно в техническом (не курилке) подразделе форума.

Сорри, что влезаю в дискуссию, но давно хотел узнать про эту тему побольше.
Вроде со времен после dbf современные БД для текстовых полей не хранят бессмысленные пустые символы, добивающие до конца задекларированной длины поля.
Т.е, если объявлено char100, а по факту там три буквы, то место используется только под эти три буквы + спецсивол окончания строки.
Как в таком случае работает косвенная адресация?

Постскриптум.
Специально для kernelpanic

Седина, - это не порок. Это физическое воплощение всего пережитого, то есть опыта. У меня очень яркая и нескучная биография, достаточно высокая самооценка, чтобы не обижаться на колкости, а видеть в них слабости оппонента. То что будет написано ниже уже не имеет отношения к HANA, это некий пассаж для уменьшения Ваших слабостей. Но как Вы онесетесь к моему посту, - дело Ваше. Мне абсолютно наплевать на то, как Вы относитесь к своему развитию и карьере.

Что бы быть таким, как Вы говорите "...(не)разбираетесь в информационных технологиях, пытаясь скрыть это под метафорами и маской менторства а-ля "эх, молодежь.." на протяжении нескольких десятков лет, - очень не просто. Это надо "дурить" в своей некомпетентности коллег, начальство, клиентов, партнеров, позже подчиненных и сотрудников. Не закрадывается ли мысль, что что-то здесь не то, где-то ошибка в суждениях? Ведь так не бывет. Герой Дикаприо в фильме "Поймай меня если сможешь" иногда выдвал себя за тех, кем не является, - за журналиста, пилота, врача, адвоката. Но прикидываться в течение 25 лет профессионалом и чтобы тебе платили за профессионализм, которого "как бы нет", - это утопия, так не бывает.

Что принципиально отличает нас с Вами в профессиональном плане, это то, что вы верите всей получаемой информации, - публикациям, инструкциям, руководствам, презентациям, или просто не верите, потому что "так не может быть". А я проверяю! Я эту информацию проверяю! Если Вы начнете поступать так же, то череез некоторое время Вы обнаружете, что ваш профессионализм и доход начнут расти. Считайте этот пост маленьким бесплатным мастер - классом.

Теперь для закрепления всего сказанного пройдемся по вопросам.

1. Вы так и не ответили ни на один заданный мной вопросов, о том как HANA будет обрабатывать замену записи, о том, почему я задался вопросом об адресации 100 ТБ в оперативке (то что Вы написали - это не в счет) и другие, оставленные мною в более ранних постах. Постатрайтесь действительно разобраться в проблематике и Вы откроете много для себя нового.

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

3. Вопрос шифрования. БД действительно шифруются на диске и в оперативной памяти (если БД размещена в ОП). Т.е. сами данные БД могут быть зашифрофанными, так и сама БД может быть зашифрована на уровне хранилища (в том числе и в RAM). Если у вас на локальной машине применена опция шифрования диска, например McAfee, то разумеется БД, размещенная на этом диске, будет иметь зашифрованный вид на нем, такакая же схема может быть реализована и в RAM. Разумеется применим и указанный Вами вид шифрования данных. Это легко посмотреть. Привожу ссылку Oracle, т.к. рядом лежит. У IBM такая же ситуация.

http://www.oracle.com/ru/products/datab ... index.html

Такого богатства вариантов у HANA нет. Это я и имел ввиду.
Что касается процессоров, имеется ввиду, что то решение по шифрованию, которое применено в SPARC не использует вычислительные ресурсы ядра, в отличии от решения Intel. А так да!, Любой процессор может шифровать.

4.По поводу "Косвенной адресации".
При наборе в Google "Косвенная адресация в БД" выпадает куча ссылок. Беру первую. http://studopedia.org/4-181600.html Название сайта говорит само за себя.
Что читаем про косвенную адресацию



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

А вот что-то поближе к описанному Вами:



Как видим, дома все таки отсчитываются, т.е нужно их посчитать по порядку. Как козлик в старом советском мультфильме: Раз - это я, два, - это теленок....

5. Про вычислительные потоки. С потоками может произойти 3 вещи, - он может оборваться, он может быть остановлен, если запускающая его программа позаботиться о сохранении промежуточных данных, и он может быть перенесен на другой процессор или ядро. С первым и третьим все ясно, а вот остановка- процесс не простой. При обработке аналитических запросов нужно не просто сохранить одну промежуточную переменную, как при ообработке сложной метематической функции, а сохранять нужно почти все содержимое обрабатываемых кубов или таблиц с колонками. Это легко проверить. Запустите TeamQuest серврере HANA и понаблюдайте за потоками, находящимися в обработке. Я видел эту картину, а Вы по все видимости, нет.

В заключении еще несколько слов.
Как я писал в начале поста, Проверка получаемой информации для профессионала является важной составляющей. И в каждой дозе получаемой информации находится доля легкого лукавства. Написано одно, а на деле другое. такое было , есть и будет. Что касается SAP, все материалы, получаемые в течение долгих лет я считал чуть не образчиком честности и открытости. Но с 2011 - 2012 технические документы стало читать невозможно. Слово "вранье" , наверное, не подойдоет. То что происходит, это хуже, это - умалчивание. Все что может быть исталковано, как слабость или недостаток просто игнорируется. Это именна та отправная точка из которого начинает расти сначала недоверие, а потом равнодушие, как к самой компании, так и к его решениям. Это о моем эмоциональном высказывнии в предыдущем посте.

Коллеги, проверяте первоисточники. Здоровое критичное мышление - пропуск в следующий век!

Во-во, мне тоже интересно, что насчет этого споет автор. Т.к. в том же оракле есть такие замечательные типы как VARCHAR2, которые не являются полями фиксированной длины. Кстати, из этого могут получатся замечательные спецэффекты в том же оракле. kernelpanic, вы когда-нибудь про chained rows слышали?

2 kernelpanic:Про распределение в памяти таблицы в 100ТБ для InMemory DB (каковой является HANA) я бы тоже с радостью послушал. Как мне говорили, в ноде по прежнему может быть только 4ТБ оперативки(я ничего не пропустил?). Каким образом тогда таблица 100ТБ будет распределяться в памяти, не подскажете? И что в этот момент будет происходить с остальными таблицами?

Вот сижу, думаю...
Подождем пару лет - посмотрим на жизнеспособность схемы, когда дата базных находится вся себе в памяти, а сервер приложений - на соседнем хосте. И связаны они по хорошей такой сетке 10 Gb, которая и является ограничивающим фактором.
Внимание, вопрос: если в случае с классической БД, которая не ин мемори, поменять HDD на SSD, не будет ли оно, как минимум, не медленнее?
А Seagate уже анонсировал SSD на 60 Tb в следующем году. А Samsung уже продает SSD 15 Tb.

Ну не верю я в повышение быстродействия ERP, пока существует трехзвенная архитектура. Вот как перепишут ВСЕ модули, чтобы они выполнялись внутри БД, тогда можно будет о чем-то говорить.
А пока - пишите внутренние процедуры для бивишников, им HANA поможет. Для ERP оно, пока, бессмысленно, тяжело и дорого.

Да и вообще, если дать столько памяти Oracle - получится таже самая фигня. База закешируется, но трехзвенка все порежет на сетевом взаимодействии...

Вспоминаю, как работала первая версия 1С на MS SQL, которую я видел.
SELECT *; FETCH ALL
А потом вся обработка на клиенте.
Вот один в один с тем, как сейчас работает связка ERP с HANA

А тем временем .... «Аэрофлот» перенес систему SAP ERP на платформу SAP HANA"

"Ключевой целью проекта стало повышение скорости принятия управленческих решений на основе информации из SAP ERP за счет уменьшения сроков выполнения транзакций и отчетов. В среднем после перехода на платформу SAP HANA их скорость увеличилась в 4,4 раза."

2 markone:

Поверьте, я нисколько не сомневался в Вашей биографии, может быть, она даже достойна серии ЖЗЛ (Вы ведь должны помнить такую серию книг, правда? Я не берусь ее оценивать, поскольку я ничего о ней не знаю. Но я что-то, да понимаю в области CS, где Вы решили раскрыть свой опыт.
И Вы снова наступили на те же грабли, утверждая, - я с недоверием отношусь к получаемой информации, особенно маркетинговой, не важно, будь она от Microsoft, Oracle или SAP. И когда кто-то прыткий говорит, что HANA в "сто,тыщу,мильен" раз быстрее СУБД Х - мне интересно посмотреть на очередного невежду в области CS. Поэтому я предпочитаю наблюдение за работой БД, нижележащей ОС и не стесняюсь брать в руки gdb и windbg (это, если Вы вдруг не знаете, отладчики под Linux и MS соответственно, хотя, если Вы "эту информацию" проверяете, то должны их знать). К сожалению, Оракла под рукой у меня нету, а HANA есть, поэтому периодически в ее дизассемблированные внутренности я смотрю. Впрочем, давайте все же не обо мне также.
Итак, специально для Вас.
Как производится замена записи в HANA? Это зависит от того, в какую таблицу (RowStore или ColumnSotre) производится запись. Давайте, для начала возьмем колоночную. Если бы Вы немного знали эту БД, то знали бы, что у каждой таблицы есть область памяти, называемая Delta. Она не оптимизирована для чтения, а совсем наоборот, оптимизирована для записи. Именно туда и помещается строка
Ваше утверждение, что "" снова говорит о том, что Вы полагаете, что БД работает, как человек в экселе. Я больше чем уверен, что даже в традиционных БД реализация не такая. Это слишком затратно. Гораздо выгоднее (с т.з. производительности) поместить ее (новую строку) в буфер в неизменном виде, а в старой таблице инвалидировать, то есть занулить указатель на нее (или пометить специальной меткой, которая говорит о том, что запись удалена). Логичнее всего хранить таблицы в памяти в виде одно- или двунаправленных связных списков (это одна из основных структур в Computer Science). Новая строка получает буфер, адрес этого буфера вносится в связный список вместо старого. При таком раскладе надо поменять 4*2 (или 8*2) байт, в зависимости от архитектуры машины. В Вашем же случае замена строки в таблице, скажем, из 500 столбцов, ввергла бы БД в прострацию, если запустить их массированно.
Вернемся к Хане. Итак, новая запись помещается в дельту, к ней линкуется transaction ID (timestamp, фактически) из метаданных. Предположим, следующая транзакция захотела прочитать эту таблицу. Менеджер контроля версий (MVCC) действует по такому алгоритму:
if new_transaction_id >= transaction_id_of_modified_record -> show record ; else -> skip record
Конечно, недостаток данного подхода что если таблица часто обновляется, то и дельта (непроизводительная при чтении) также будет быстро расти, замедляя возвращение результата. Для этого периодически случаются Delta Merge операции, которые объединяют содержимое основной памяти таблицы и ее дельты. Но, любое технологическое решение - это компромисс инженеров.
Что касается 100ТБ таблицы. Не поленился, залез на сайты HP и Dell, одних из основных производителей серверного железа под х86. У HP их топовый HPE Integrity MC990 X в максимальной конфигурации держит 12TB, уDell'a - их PowerEdge R930 - 96X128GB, те же 12TB. (Оракл для своей Exadata предлагает до 14,6TB в топе) Я полагаю, что дело не в HANA, Oracle или MSSQL, а в аппаратных ограничениях платформы х86 на данном этапе ее развития. Вообще же, 64-битное адресное пространство позволяет адресовать до 12 экзабайт, поэтому, как только появится такое железо, то и SAP и Oracle и Microsoft предложат соответствующие версии ПО. Резюмируя - пока не появилось соответствующее железо, данный вопрос имеет сугубо теоретическую ценность.
И еще раз, про шифрование. Прочитал по приведенной ссылке публикацию на оракловом сайте (Oracle Advanced Security White Paper) (которой Вы в целом, призываете не доверять), тут же, на стр. 2 читаю:
Oracle Advanced Security Transparent Data Encryption (TDE) stops attackers from bypassing the database and reading sensitive information from storage by encrypting data in the database layer
рисунок на этой же странице с названием Extracting customer credit card numbers from Oracle database tablespace files как бы тоже намекает.
markone, уж признайтесь, что Вы понимаете как работает шифрование лишь на обывательском уровне - я не расстроюсь.
Ни одна база данных, ни один продукт не защищен от прямого чтения из памяти процесса под привилегированным пользователем. Что бы вам не вещали. А в памяти процесса данные хранятся в расшифрованном виде и могут шифроваться только в одном случае - при записи в файловый дескриптор (или замапленную память) соответсвующего файла данных или сокета. Единственный способ гарантировать нечитаемость данных на всех этапах их процессинга на стороне БД - это шифрование на стороне клиента. Точка. Можете дальше продолжать слепо верить маркетинговым источникам.
И в заключение про вычислительные потоки. Тут Вы, бесспорно, лучше подкованы, чем в шифровании
Я все же дополню абзац, если позволите. Чтобы понять, что такое остановка потока, надо понимать, как работает планировщик операционной системы, хотя бы в общих чертах, и хотя б по-наслышке знать, что такое переключение контекста. Хотя нет, не прав. Еще надо знать, что такое уровни исполнения процессора, регистр флагов (EF), селектор задачи (TSS) и смысл и задачи стека. Зная это, можно избежать вероятности сесть в лужу, рассказывая про сохранение кубов или таблиц с колонками. Уважаемый markone, специально для Вас (потом на очередном диспуте блеснёте знаниями ). Итак, когда срабатывает прерывание, либо происходит выход из функции main() процесса (потока):
- процессор автоматически сохраняет текущее содержимое основных регистров, включая регистр (R)EIP на стеке потока ядра ОС (т.н. контекст задачи)
- управление передается коду ОС через системный вызов ( в случае выхода из main()), либо в регистр (R)EIP загружается адрес глобальной таблицы прерываний и вектор прерывания (оно же смещение внутри таблицы) - в случае обработки прерывания
- стартует обработчик прерывания, в конце своей работы вызывающий функцию sched() ядра ОС. В случае завершения по main() - обновляется статистика счетчиков ОС, и структура task_struct удаляется (по факту, удаляется указатель на нее в связном списке), знаменую завершение работы процесса. С удалением структуры task_struct, освобождается память, на которую она ссылалась (при условии, что эта память больше не адресуется другими процессами)
Объем сохраняемой информации - несколько килобайт (все основные решситры +ММХ) в худшем случае.
Каюсь, картину TeamQuest on HANA я не видел, но за потоками Ханы наблюдал, и смею предположить, больше Вашего, коллега (но меряться не буду)
Да, всецело присоединяюсь к Вашему заключению! Первоисточники и критичность мышления - наше всё!! =)

2 Кодер - в этот раз я пропущу мимо ушей Ваш тон, и отвечу. В следующий раз - проигнорирую.
По поводу varchar2 и chained rows - благодаря Вам, услышал. В данном случае элементом адресации будет являться адрес начала цепочки страниц и, возможно ,смещение внутри цепочки. Чтобы не забивать страницу нулевыми байтами, если заняты лишь первые несколько байт, резонно хранить в самой таблице в этом поле, вместо данных, указатель на начало цепочки страниц и длину цепочки. Т.е. если таблица у нас предположим, вида Int, char(4), varchar2 , bool (со значениями 100;тест;длинный_блоб, TRUE соответственно) то в памяти она может выглядеть как 0х000064|0x0442;0x0435;0x0441;0x0442|0xFFFFFF|0x000001 (где 0xFFFFFF - указатель на начало цепочки страниц) Смещение до следующего элемента можно положить как в само поле, так и в шапку начала цепочки, тут как разработчик решит.
Так вот смещение до следующей строки будет равно сумме длин элементов всех полей (а поле varchar2 будет длиной 4 или 8 байт) и базового адреса (т.е. начала таблицы). Никто никогда не будет класть в данное поле само фактическое значение. Иначе вычисление смещений превратится в киловатты впустую потраченных процессорных мощностей.

2LKU - Да без проблем, влезайте =) Отвечая на Ваш вопрос - зависит от того, какая архитектура, и как кодируется символ. Если архитектура 32-битная, а символы -в ASCII - то вам повезло - прочитается только 4 байта (при условии, что начало поля выровнено по границе в 4 байта). Т.е. в кэше процессора будет только полезная информация - 3 байта слова + нулевой символ окончания строки. Если архитектура х64 - в кэш затянется 8 байт, 4 будут прочитаны, оставшиеся - проигнорированы. Если символы в юникод-8, например, то влезаете в 7 байт. В случае 32 бит - не повезло, придется читать память дважды, в случае х64 - заберете 8 байт за раз. Оптимизации, конечно же, существуют, особенно для полей большой длины. Как в других бд - не знаю, в Хане это реализовано с помощью блоков памяти предопределенной длины. Т.е. если мы пометили поле как char(100), а потом положили туда строку 30 символов длиной, 50, и 80 например, то в данных этого поля будут лежать не сами значения, а ссылки на начало блока данной длины, и смещение внутри. Так, строка в 30 символов попадет в блок длиной 32 байта (предполагаем, что у нас ASCII), строка в 50 символов -в блок 54 байта, строка в 80 символов - в блок 88 и т.д. В любом случае, в процессор данные заезжают выравненно, по границе в 4 или 8 байт, в зависимости от архитектуры.


2 avlag - со вторым абзацем всецело согласен. С первым нет. Время доступа на чтение у SSD впечатляющее, конечно.. 30-50 микросекунд по сравнению с 10-20 миллисекундами обычного диска, это почти на порядок. Но... Время доступа к SDRAM памяти, в среднем 200 наносекунд. В 100 раз быстрее. (если мы говорим, конечно, про традиционные NAND-SSD). вот когда разработают "вечный" аккумулятор, тогда можно будет сделать внешний RAM SSD диск, с сопоставимыми характеристиками. И по сетке. Ограничивающим фактором скорее будет являться соединение клиент-сервер, со слабой пропускной способностью, и повышенной (по сравнению с локальной сетью) задержкой. Пока что даже гигабитного канала между БД и сервером приложений вполне хватает, чтобы сотня-другая диалоговых процессов могла тянуть что-нибудь из базы в параллель.

тоже улыбнуло
терзают сомнения насчёт полезности этих решений от наших "успешных управленцев". Хоть с Ханой, хоть без.

В стопиццотый раз повторяю: пока есть трехзвенная архитектура, ограничивающим фактором является скорость доступа с сервера приложений до сервера БД.
И какая бы быстрая не была память на сервере с HANA, доступ к этой памяти от аппликухи будет осуществляться со скоростью сети. В случае сетки 10G - оно МЕДЛЕННЕЕ, чем скорость SSD-диска на чтение. Поэтому нет никакой разницы между тем находятся ли данные базы в памяти или на SSD-массиве.
И это я еще не говорю про то, что данные БД в памяти считаются "грязными" до тех пор, пока не закоммитились на диск. Со скоростью ДИСКА. Т.е. при масsовом обновлении/добавлении данных БД in memory будет МЕДЛЕННЕЕ обычной БД, построенной на SSD

2 kernelpanic: Вы так и не поняли вопроса про 100ТБ таблу. HANA ведь все, к чему обращаются с запросом, засасывает в память, так? Иначе ведь она не умеет? Если свободной памяти не хватает, по LRU старые данные из памяти выкидываются. Соответственно, если делается выборка из здоровой таблы, то может наступить (и наступает, т.к. сталкивался уже с этим на практике) момент когда HANA будет активно свопить туда-сюда данные, вместо того, чтобы нормально работать. В том же оракле(ну и в том же мс, насколько я знаю), за счет того что in-memory не единственный способ работы, остается пространство для маневра - можно указать: вот эти таблицы будут in-memory, а вот эти - старый-теплый-ламповый-обычный подход .

Трехзвенной архитектуры, на мой взгляд, в обозримом будущем не избежать. А двухзвенную архитектуру проходили уже очень давно и что-то мало кто торопится обратно.
Да и сети разные бывают, насколько знаю есть и 40G и 100G, сетевики могут несколько линков в один объединять. Если уж совсем проблема именно в сети, а железо при трехзвенке отдыхает, то можно же БД и сервер приложений на один сервер завести? Да и опускать все вычисления на уровень БД - она же захлебнется тогда, никакими кластерами не отмасштабировать.

UPD. Я это к чему... Я не базисник, но у вас же наверняка встречались в опыте сервера БД построенные поверх SSD? Там действительно узкое место это сеть?