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 диск, с сопоставимыми характеристиками. И по сетке. Ограничивающим фактором скорее будет являться соединение клиент-сервер, со слабой пропускной способностью, и повышенной (по сравнению с локальной сетью) задержкой. Пока что даже гигабитного канала между БД и сервером приложений вполне хватает, чтобы сотня-другая диалоговых процессов могла тянуть что-нибудь из базы в параллель.