Grid съхранява голям обем данни (терабайтове)



страница2/4
Дата10.08.2017
Размер1.32 Mb.
#27578
1   2   3   4

Аварии по дисковете

  1. Тъй като бързодействието е свързано с безопасността на съхраняване на данните, когато се опитваме да четем или пишем сектор – провал, но ако пак се опитаме да четем или пишем – успех. Това е т.нар. временна авария.

  2. Когато един или няколко бита са постоянно развалени, т.е. за даден сектор колкото и опита да правим да пишем или четем върху него е неуспешно наричаме разрушаване на носителя.

  3. Когато по време на запис нито можем да осъществим записа до край, нито можем да прочетем старото съдържание. Нарича се авария при писане и може да възникне когато има авария на тока при записване на сектор.

  4. Когато целият диск не може да се чете е повреден веднъж за винаги.

Подробно разглеждане на авариите:

  1. Временната авария – обикновено върху секторите на диска има допълнително битове, които служат да определим дали четенето е правилно или не и дали правилно сме записали. При четене се връща (w, s) – дали правилно са записани данните, където w – данните в сектора, който се чете, а s- статус бит, който показва дали четенето е минало успешно, т.е. дали можем да разчитаме съдържанието на w да е вярно. Ако около 100 пъти статус бита (w, s) не се обърне на добър вече не става дума за временна авария. Но може (w, s) да е добър, а данните да не са верни. Вероятността това да се случи намалява, когато се увеличава статус бита. Това е при четене. При писане също можем да наблюдаваме какво сме записали – можем да се опитаме да прочетем всеки сектор след като сме го записали и да разберем дали записът е бил успешен. Праволинейния начин на проверка е да прочетем сектора и да го сравним със сектора който имаме намерение са запишем, също така вместо пълно сравнение в контролера на диска можем да се опитаме да прочетем сектора и да видим какъв е статуса; ако е добър предполагаме че записът е бил успешен, ако не то записът е бил неуспешен и трябва да се повтори. Но както и при четенето можем да се заблудим ако статусът е добре, но записът всъщност е неуспешен.

2. Сheck суми – статус битовете се формират с помощта на check сумите. Ако при четене се открие, че чексумата на данните не отговаря на прочетените данни тогава връщаме статус “грешка”. Има малка вероятност данните да се прочетат неправилно, но грешните битове могат да имат същите чексуми като правилните. Най-простия вид check суми се основава на четността (броят се колко единици има, ако броя е четен, бита на четност е нула, ако е нечетен - единица). Ползването на check сумата именно бита на четност се извършва от контролера. На сектора имаме данните + един бит за четност. 0110 1100 0 ; 0111 0110 1. Ако имаме n независими бита за check сумата вероятността за грешка е . Ако се използват 4 байта за check сумата, вероятността за грешка е ј милиарда.

3. Устойчива памет

Check сумите служат за откриване на грешки, но не ни позволяват да ги коригираме. За да се избегнат тези проблеми се използва устойчива памет, разделена на един или няколко диска. Секторите са разделени по двойки. Сектор х се записва в ляв сектор и десен сектор – две копия на сектора. Върху дисковете за секторите се записват и check суми за надеждност. С помощта на устойчивата памет наистина имаме надеждни данни. Така че при четене на и ако статус бита е добре прочетената стойност е наистина тази.

Стратегия за борба с авариите чрез устойчивата памет

При писане



  1. Имаме да запишем сектор х – първо записваме данните в сектор , след това проверяваме дали е успешно записването, ако се окаже, че след определен брой проверки резултата е все лош, то тогава сектора е развален. Тогава го маркираме като развален и назначаваме нов сектор за докато се получи успешно записване.

  2. Правим същото и за .

При четене

  1. За да получим стойността на х ние първо четем върху , ако има грешка повтаряме четенията на до 100 пъти

  2. Ако нито веднъж не се върне с добър статус бит, тогава преминаваме към четене на по същия начин.

Възможности за обработка на грешките в устойчивата памет

  1. разваляне на носителя – ако след кат сме съхранили х в и и някое от тях се развали, то стойността винаги може да се възстанови от другия сектор.

  2. Авария при запис – по време на записа на х падне напрежението или друга системна авария, тогава в ОП, където е копието на х то ще се загуби. Освен това копието, което в момента се записва също може да се развали, т.е. ако аварията настъпи в момент на записване в , то в ги имаме и можем да запишем в новите данни и обратното.

  3. авария на целия диск – данните са разрушени завинаги. Ако тези данни не са съхранявани върху лента или на друго място – нищо не можем да направим. Излишество – това са схеми RAID. При схеми нива 4,5,6 – чрез тях се преодоляват проблемите на авария на единичен сектор.

Модел на аварии на дисковете

Въпроса е свързан със статистиката на авариите. Средно време на авариите = периода за който 50% от дисковете аварират катастрофално. За съвременните дискове този срок е 10 години. Всяка година 1/10 от всички дискове аварират.


Аварии

заводски дефекти


стабилизация

Време
По-късните дефекти се дължат на това, че с времето по дисковете се набива фин прах.

Схеми за възстановяване на данните

Дискове за данни. Освен това се използват един или повече дискове, чието съдържание се определя от самите данни = дискове на излишества

RAID1

Огледалните дискове – единия диск е за данни, другия – за излишества (те съдържат една и съща информация). Средното време на загуба на данни е много по-голямо от средното време за авариране на диска. При 10 години средно време за авария се допуска, че вероятността за 1 година да настъпи авария е 10%. Когато единия от огледалните дискове се развали ние правим копие на разваления и докато се копира работи само единия.

Средното време на авария за данни е 1 път на 146 хиляди години.

RAID4

Ползва се един диска на излишествата и много дискове на данните (дисковете са идентични[приемаме, че са от 1 до n и че блоковете на дисковете имат еднакви битове]). В диска на излишество i–я блок се състои от проверки за четност на i–тите блокове за проверки за четност на всички блокове.

Четенето на блокове от диск за данни не се различава от четенето на блокове.

Писане – при запис трябва да запишем нов блок и в диска на излишествата трябва да отразим тази промяна. Ползваме старата и новата версия на i–я блок и в кои позиции е настъпила промяната (прави се сумиране по модул от 2). Четири достъпа:



  1. четем старата стойност на блока

  2. четем старата стойност от диска на излишествата

  3. записваме новия блок

  4. след това записваме промените върху диска на излишествата

RAID5

Не прави разлика между диск за данни и диск на излишествата.

Ако имаме n+1 диска с номера от 0 до n тогава можем i-я цилиндър на j-я диск да ползваме за излишество, където j е остатъка от i делено на n+1. n=3 т.е. имаме четири диска с номера от 0 до 3. Имаме нулев диск j=0 на нулевия диск ще бъдат използвани цилиндър 4,8,12,16. На първия диск цилиндър на излишествата ще са 1,5,9,13 ; на втория 2,6,10,14 ; на третия 3,7,11,15. При четене и при писане има равномерно разпределение (натоварване) между дисковете.

RAID6

Авария на няколко диска. Теорията кодове за коригиране на грешки. Когато аварират два диска едновременно – код на Hamming. Разглеждаме го със седем диска с номера от 1 до 7. Първите 4 диска са дискове за данни, а останалите – за излишество. Матрица на кода на Hamming

1234567111010011010101011001

Колоните на дисковете на излишествата съдържат само една единица, а колоните на дисковете на данни има поне две единици. Сумата по модул от 2 между дисковете е нула. Дисковете с единица от даден ред в матрицата се разглеждат като множество от дискове, обработващи схема RAID4. Пети диск се разглежда като диск на излишествата на дискове 1,2,3; шести – на 1,2,4; седми – 1,3,4.

Операцията по четене може да става от всеки диск и тогава дисковете на излишество не ни интересуват. Когато записваме даден блок данни ползвайки матрицата трябва да преценим кой е диска на излишествата. Гръмват 2 произволни диска.

Представяне на данни
Сред изискванията на СУБД са:


  1. Атрибутите да бъдат представени като поредица от байтове с фиксирана или променлива дължина, наречени полета.

  2. Полетата заедно се организират в набори с фиксирана или променлива дължина, наречени записи

  3. Записите се съхраняват във физически блокове. Различните структури от данни са полезни, особено ако блоковете със записи трябва да се организират когато базата от данни се модифицира.

  4. Колекция от записи която формира отношение се съхранява като колекция от блокове, наречена файл. За да поддържаме ефикасни заявки и модификации на тези колекции поставяме номер на индексирани структури на файла.

Записите съответстват на кортежи в релационните модели или обекти в обектния модел. Тези записи трябва да се съхраняват в блокове, което се осъществява с помощта на различни структури от данни. Един набор от блокове, в който се съхраняват записи от една и съща релация или клас се нарича файл. Един файл е набор от блокове. За да се търси ефективно се използват индексни структури върху файла (файла в БД е различен от файла в ОС. В операционната система файлът е поредица от байтове и няма структура, в БД е поредица от блокове, в които има организация-индекси и др. ).

Елементи, данни, полета

Елементи – стойностите на атрибутите при релационния или обектно-ориентирания модел. Елементите данни се представят с полета, които се използват за формиране на блокове.

Пример в релационните бази от данни:

CREATE TABLE Movie Star

(Name char (30) Primary key,

Address varchar (255),

Gender char (1),

Birthdate Date)



СУБД взема и създава тази релация. Тя е множество от кортежи, които могат да бъдат разглеждани като записи или структури (в С++). Всеки кортеж се представя като запис, записът заема част от някои блок върху диска и в него всеки атрибут си има по едно поле.

Проблеми:

  1. как се представят типовете като полета?

  2. как представяме кортежите като записи?

  3. как представяме набор от записи (кортежи) като набор от блокове (т.е. къде ще отидат записите от блокове)?

  4. как наборите от блокове се използват за съхраняване и представяне на релации?

  5. как се оправяме със записи, чиито размери могат да варират за различните кортежи?

  6. какво става когато размера на записът се променя? Как се представят големи бинарни обекти?


Обектно-ориентиран модел – как се представят обекти
Обект – кортеж, неговите екземплярни променливи-атрибути. Обектите може да ги представим както представихме кортежите, но има два проблема:

  1. обектите могат да имат методи или функции, асоциирани с тях. При обектно-ориентирания модел тези методи и функции са част от схемата.

  2. обектите имат идентификатори, уникални в някакво глобално адресно пространство, между обектите има и връзки, които или са указатели или списъци от указатели. Методите се съхраняват заедно със схемата, т.к. те са общи с цялата база от данни.

Във всеки един запис, представляващ обект, има поле, което идентифицира към кой клас принадлежи обекта и какви методи се използват за него. Връзките също са част от обекта, но трябва да се съхраняват с него. Обикновено не се знае вида на връзките. Когато са например много към много не се знае колко да се задели и се получава запис с променлива дължина.
Представяне на данни (как SQL типовете данни се представят като елементи в записа):


  1. int – 2-4 байта, float – 4-8 байта. Съхраняват и се разглеждат като поредица от битове, които се интерпретират от хардуера на машината.

  2. Символни низове с фиксирана дължина char (n). поредица от n байта (всеки символ се представя с един байт). char (5) c a t_ _

  3. Символни низове с променлива дължина varchar (n) представянето става по два начина: или да се задели един байт в началото, който съдържа дължината на цялото поле 3 c a t или да бъде използван специален символ за край c a t \x0.

  4. Дата и време – датата е символен низ с фиксирана дължина.

  5. Битове bit (n) поредица от битове, извършва се пакетиране по 8 бита (1 байт). bit (12) {1101 1011} {1011 X}

  6. Булева стойност - true (1000 0000 или 1111 1111) или false(0000 0000)

  7. Изброими типове – имат фиксирано множество от стойности за атрибути {RED,GREEN,BLUE}; {MON,…,SUN}. Множеството от стойности имат символични имена. Стойностите на изброимия тип могат да се представят с числови стойности {0,1,2}; {0,…,6}. Представят се с един байт, ако са по-големи от 255 – с два.



Записи

Групиране на полета в записи

Схемата на релацията определя схемата на записа В този схема са указани имената и типовете на данните в полетата и офсетите на записите. Когато се пакетират няколко полета в един байт се харчи по-малко дискова памет, но операциите са по-сложни и възможността за грешки е по-голяма.
Записи с фиксирана дължина
Кортежите представяме чрез записи с фиксирани полета.

0 name 2930 address 285286 gender287 birthdate 297В някои машини по-ефективно се чете и пише когато полетата са разположени на граница на дума (тя може да е четна на 4 или 8)


0 29//////32 288/////292/////296 304Нуждата от схема на записа се обосновава на факта, че схемата на релацията може да се изменя и затова се използва при работа само текущата схема.
Заглавни части на записите
Често трябва да се поддържа информация за записа, който не е стойностно поле. Най-често е чрез указател, който сочи къде и коя е схемата на записа (той е в заглавието). В заглавието още има дължината на записа, време, когато записа последно е изменян или четен. СУБД поддържа информация за схемата, която се появява в create table– атрибутите, типовете данни, наредба на атрибутите в кортежа и ограниченията. Тази информация не е в заглавието на записа, а има указател към нея.
Пакетиране в блокове
След като са подредени записите се пакетират в блокове. Блоковете са с фиксирана дължина.
Заглавна частЗапис 1Запис 2...Запис NСвободна паметЗаглавната част съдържа информация за:

  1. връзки към един или повече блокове, които са част от мрежа блокове, използвани за създаване на индекси.

  2. ролята, която играе блока в тази мрежа (индексен, за данни и др.).

  3. за това на коя релация са тези кортежи от блока

  4. директории на записите от блока (таблица, съдържаща офсетите към началото на всеки един запис).

  5. идентификатор на блока

  6. времето на последното обновяване или достъп да блока.

Указателите са важни когато трябва да се организират сложни записи с променлива дължина. Когато един блок е зареден в оперативната памет дължината му е един байт, зареден във виртуалното пространство. Ако блока е във вторичната памет се използва поредица от байтове, която идентифицира мястото на блока. Тя може да съдържа идентификатор на диск, номер на писта, цилиндър и т.н. Записите се адресират чрез блок, едната част на записа е адреса на блока, а другата – офсета в блока.

Операционната система и СУБД поддържат един сървърен процес, който предоставя данните от вторичната памет на един или няколко клиентски процеса. Клиентското приложение ползва конвенционалното адресно пространство (32-битова адресация). СУБД (операционната система) решава кои части от адресното пространство текущо ще бъдат заредени, а хардуера се грижи за преобразуването на виртуалните адреси във физически. Сървърните данни съществуват в адресното пространство на базите от данни. Там данните се адресират с адреси на блокове и с офсети в тях. Данните в това адресно пространство се представят чрез:



  1. физически адреси – поредица от байтове еднозначно определяща къде се намира даден блок или запис във вторичната памет. Тя съдържа:

  1. име на хост (ако една база от данни се съхранява на повече от една машина).

  2. идентификатор на диск или друго устройство, на което е разположен.

  3. номер на цилиндър.

  4. номер на писта в цилиндъра.

  5. номер на блок в пистата.

  6. офсет в блока (ако става дума за запис)

  1. логически адреси – прилагат се както за блокове, така и за записи - низ от байтове с фиксирана дължина. Имат таблица на изображението, която се съхранява на фиксирано място върху диска и служи за преобразуване на логически адреси във физически.

Представяне на логически и физически адреси


Един запис маже да се индексира чрез физическия номер на блока, в който се намира и да се използва ключ вместо офсет. По този начин записът може да се мести в блока. За да разпознаваме записите в блока трябва да знаем тяхното разположение. Най-лесния вариант е записите да са с фиксирана дължина. Комбинация от логически и физически адреси се предлага в т.нар таблица на офсетите, която се намира в заглавната част на блока.
расте расте

Инфор-мацияСвободно пространствоЗаписN...Запис2Запис1

- таблица на офсетите - заглавна част

Използва се когато записите са с променлива дължина. Записът се адресира – адрес на блока + офсет в таблицата на офсетите. Ако има външни указатели към запис те сочат в таблицата на офсетите. Ако се изтрие един запис в таблицата се слага “надгробен камък” за информация, че записът е изтрит, иначе външният указател ще сочи друг запис.

Например може един запис да се индексира чрез номера на физическия блок и ключ на записа. За да намерим записа прочитаме блока и правим каквото и да е претърсване за откриване на съответния ключ. За да търсим в този блок трябва информация за разположението на записите. Най-лесно ако са с фиксирана дължина Обикновено в заглавната част на блока се разполага таблица на офсетите – кой запис от къде започва.

таблицанаофсетите////////////////заглавна част

Таблицата на офсетите може да се използва като структурирана схема. Обектно – релационните модели поддържат указатели. В индексните схеми също.

Преобразуване на указателите

Често указателите (адресите) са част от кортежа. Когато един указател се прехвърли от първичната във вторичната памет и обратно всеки блок всеки запис има 2 вида адреси – първият е адрес в пространството на сървъра на базата от данни около 8 байта – нарича се адрес в базата от данни. Тези данни имат и адрес във виртуалната памет – получава се когато адресируемият обект е буфериран във виртуалната памет – приблизително 4 байта. Когато обекта е в паметта се използват двата адреса. Трябва да ползваме адреса в базата от данни когато искаме да върнем обекта в дисковата памет. Затова се поддържа в СУБД таблица за преобразуване:


адрес в базата

от данни адрес в паметта



Техника на коктейлните указатели:

Когато един блок от вторичната се прехвърля в основната памет указателите може да бъдат транслирани в адреси във виртуалната памет. Указателите се състоят от : един бит указващ дали е адрес в базата от данни или в паметта и след това самия адрес.


Блок 1 преобразува се в адрес в паметта


Отива във

Вирту алната памет
Блок 2

Адрес в базата от данни

Блок 2 не е буфериран

1.Когато се зарежда нов блок се преглеждат всички указатели. Тези, които сочат към адресируеми обекти в ОП да бъдат автоматично преобразувани в указател към паметта.

2. Преобразуване по заявка. Зарежда се блока, но не се преобразуват указатели докато не се наложи използването на даден указател.

При 1 зареждането на блока става по-дълго и се хаби време за преобразуване на указатели, които няма да се използват в текущата сесия. При 2 за да се използва даден указател е по-бавно.

Механизми:


  1. Схема (ако има) на записите. Там е указано кои и къде са указателите

  2. Ако блока е част от индексна структура в нея са известни местата на указателите.

  3. В заглавната част на блока да се поддържа списък с местата на указателите.

Програмен контрол върху преобразуването – програмиста определя дари преобразуването да е автоматично или по заявка.

От ОП на диска – всички указатели, които са били преобразувани трябва да се върнат обратно. Най-добре би било ако таблицата на преобразуванията съдържа индекси.

SELECT memAdr

FROM TransitionTable

WHERE dbAdr=x ;

SELECT dbAdr

FROM TransitionTable

WHERE memAdr=x ;

Приковани записи и блокове

Един блок е прикован ако в момента не може безопасно да бъде записан на диска. Индицира се с някакъв бит в заглавната част.

Причини:


  1. определени от системата за възстановяване

  2. преобразуването на указателите (ако са към адреси в паметта) и др.

Подходи:

  1. да се поддържа списък от адреси в ОП (освен таблица), които сочат във всеки един елемент.

  2. когато адресите в паметта са по-къси от тези в базата от данни може да се поддържа свързан списък за самите указатели. Ако имаме адрес в базата от данни го заместваме с адрес, който е указател към този списък.

Адрес в базата адрес в

от данни ОП указател

X Y
Y// - X

YЗаписи и данни с променлива дължина

Проблеми:

Първи вид – елементи от данни, чиито размер се променя.

Втори вид – повторяеми полета – връзки от типа много към много.

Трети вид – записи с променлив формат. Не знаем колко пъти ще се повтаря това поле.

Четвърти вид – огромни полета (BLOB TLOB). Съдържат в един запис голям обем информация.

Записи с полета с променлива дължина

В записа трябва да има достатъчно информация за да намерим полето с променлива дължина – разполагаме първо полетата с фиксирана дължина и после тези с променлива дължина. Ако винаги полетата с променлива дължина са в един и същ ред не трябва да се указва началото, защото то е в края на полетата с фиксирана дължина.

MovieStar (

name[променлива дължина],

address[променлива дължина],

gender[4 байта],

birthdate[12 байта]

)

4b 12b


Дължина на записаgenderbirthdatenameaddress заглавна част
Записи с повтарящи се полета

Има вариант за групирането на всички повтарящи се полета заедно, указател към първата поява на повтарящото се поле.


дължинаgenderbirthdatenameaddress

Заглавна част

Указатели към филмите

В които участва


Полетата се разполагат в друг блок в записа вместо повтарящите се полета се съхранява един указател към мястото в другия блок на първата поява на полето и информация колко пъти се появява то.

name address films

заглавнаgenderbirthdateдължинадължинаброй повторения


nameaddress


В този случай заглавната част е по-малка



Записи с променлив формат

Полетата, наредбата не са фиксирани. Кортежи (обекти) в коитио предварително не е ясно съдържанието ме. Най-лесния начин за представяне са маркираните полета.



  1. Име на полето или атрибута

  2. Тип на полето

  3. Дължина на полето (ако не е ясна от типа)

  4. Стойност на самото поле

Маркираните полета се използват когато



  1. разработваме приложения с интеграция на информацията. Имаме релация, която се използва в интегрираното приложение и получава данни от различни източници.

  2. записите с много гъвкава схема, например ако повечето от полетата в записа се повтарят. Дори и да знаем схемата на полетата, маркираните полета пак са полезни.

NSLClint EastwoodRSLHollywood Inn



  1. код за име/ресторант

  2. код за тип (стринг)

- дължина

Записи, които не се побират в един блок са специфични типове данни – аудио, видео файлове. Те са с променлива дължина, но и да са с фиксирана са необходими специални техники за работа с тях.

Техника на разделените записи за управление на такива записи (които не се побират в един блок).

Разделените записи са полезни и когато записите са по-малки от блоковете, но пакетирането им в блока не е ефективно. Техниката се състои от следното:

Записите могат да бъдат разделяни на фрагменти и когато е необходимо един запис може да бъде разположен в два блока т.е. част от фрагментите – в един блок, друга част – в друг. Може да има и нефрагментирани записи. За да се поддържа фрагментацията на записите трябва да поддържаме съответната заглавна част и фрагментацията да съдържа допълнителна информация – 1 бит, който показва дали записът е разделен или не (това е в заглавната част), ако записът е фрагментиран кой номер на фрагмент е, указател към следващ и/или предходен елемент.

BLOBS (Binary Large OBjectS) – може да съдържа филм, изображение, сигнал от радар.

BTEXT – съдържа много голям текст. Манипулацията им е еднаква.



Каталог: fmi -> fmi-ftp-upload-folder -> 3%20Semestur%202004%20&%202005 -> Predmeti -> DBMS -> Lekcii
fmi-ftp-upload-folder -> Бази от данни Упражнение 10
fmi-ftp-upload-folder -> Oracle e-business Suite Модул Financials, подмодул Fixed Assets
fmi-ftp-upload-folder -> Бази от данни Упражнение 9
fmi-ftp-upload-folder -> Basic structures напишете pl/sql блок, който въвежда номера в таблицата messages
Lekcii -> Извличане на документи и инвертирани индекси за целите на web приложенията
Lekcii -> Представяне на данни
Lekcii -> Третична памет
Lekcii -> Многобазово криптиране на големи релации Ако размера на блока е в байта, а в основната памет имаме М


Сподели с приятели:
1   2   3   4




©obuch.info 2024
отнасят до администрацията

    Начална страница