Изпълнение на различни подходи към данни, базирани на времето

От една страна е добре, че отворихте нов въпрос. Но от страна, чрез извличане на една заявка и запитване дали се изпълнява по-бързо, губи контекста на предишния въпрос, новият въпрос е твърде изолиран. Както съм сигурен, че знаете, администрирането на база данни, управлението на ресурси (памет/кеш, диск, цикли на процесора), управлението на код (добър или лош), който използва тези ресурси, са част от цялата картина. Изпълнението е игра за търговия, нищо не е безплатно.

Основният проблем, който имах, беше дублирането на колоната EndDate, която лесно се извлича. Дублираните колони се равняват на аномалии при актуализиране. Smirkingman предостави класическия пример:някои заявки ще получат един резултат, а други заявки ще получат другия. Това просто не е приемливо за големи организации; или в банки (поне в развитите страни), където данните се проверяват и защитават. Нарушили сте основно правило за нормализиране и трябва да платите санкции.
- Актуализиране на Anomailes; две версии (вече подробно). Одиторите може да не преминат системата.
- Размер на таблица
  Във всяка голяма таблица това е проблем, и особено във времеви серии или времеви данни, където броят на колоните е малък, а броят на редовете е огромен. И какво, ще кажат някои, дисковото пространство е евтино. Да, полово предаваните болести също. Важното е за какво се използва и колко добре се грижи човек за него.
  - Дисково пространство
    Може да е евтино на компютър, но в производствен сървър не е. По принцип сте добавили 62% към размера на реда (13 плюс 8 е равно на 21) и следователно към размера на таблицата. В банката, към която в момента съм назначен, всеки отдел, който притежава данните, се таксува, както следва, базираното на SAN съхранение е всичко, което има. Цифрите са за GB на месец (това не е австралийска банка от висок клас):
    
    $1,05 за RAID5 Unmirrored
    (знаем, че е бавен, но е евтин, просто не поставяйте важна информация върху него, защото ако се счупи, след като новият диск бъде сменен на горещ или студен начин, отнема дни за да се синхронизира повторно.)
    
    $2,10 за RAID5 Mirrored
    В SAN, т.е.
    
    $4,40 за RAID1+0
    Минимум за производствени данни, резервни копия на регистрационни файлове на транзакции и нощни изхвърляния на база данни.
    
    $9,80 за RAID1+0, репликиран
    към идентично SAN оформление на друг, бомбоустойчив сайт. Прекъсване на производството за минути; почти нулева загуба на транзакция.
  - Памет/Кеш
    Добре, Oracle го няма, но сериозните банкови dbs имат кешове и те се управляват. Като се има предвид всеки конкретен размер на кеша, само 62% от редовете ще се поберат в същия размер на кеша.
  - Логически и физически I/O
    Което означава 50% повече I/O за четене на таблицата; както стрийминг в кеша, така и четене на диск.
Следователно, дали заявката се представя по-добре или по-зле изолирано, е академичен въпрос. В контекста на горното, таблицатас е бавен и се представя с 62% по-лошо, през цялото време, при всеки достъп. И това засяга всеки друг потребител на сървъра. Повечето администратори на бази данни няма да се интересуват (аз определено не бих), ако формулярът за подзапитване работи с половината от скоростта, защото техният бонус е обвързан с приемането на одита, а не само с производителността на кода.
- Освен това има допълнителното предимство, че никога не се налага да преразглеждате кода и да коригирате транзакции поради аномалии при актуализиране.
- И транзакциите имат по-малко точки за актуализиране, така че са по-малки; по-малко блокиращи ключалки и т.н.
Съгласете се, че дискусията в коментарите е трудна. В моя отговор подробно описах и обясних две подзаявки. Имаше недоразумение:говорехте за тази подзаявка (в клаузата WHERE, подзаявка за таблица ) и говорех за другата подзаявка (в списъка с колони, скаларна подзаявка ), когато казах, че работи толкова бързо или по-бързо. Сега, след като това е изяснено, не мога да кажа, че първата заявка по-горе (подзаявка в клаузата WHERE, таблица) ще работи толкова бързо, колкото втората заявка (с дублираната колона); първият трябва да извърши 3 сканирания, докато вторият извършва само 2 сканирания. (Смея да твърдя, че второто ще сканира таблицата.)

Въпросът е, че в допълнение към проблема с изолацията, това не е честно сравнение, направих коментара за скаларните подзаявки. Не бих предположил, че заявка за 3 сканирания е толкова бърза или по-бърза от заявка за 2 сканирания.

Изявлението, което направих относно подзаявката за таблица с 3 сканирания (която цитирам тук), трябва да се приеме в пълния контекст (или тази публикация изцяло, или горната). Няма да се оттегля от него.

Прекарвам половината си живот в премахване на Незаконни алтернативи като дублирани колони, които се основават на проблема с производителността, като създателите пеят мантрата, че таблицата е бавна, така че те са „денормализирани за производителност“. Резултатът, предвидим преди да започна, е маса, наполовина по-малка, която работи два пъти по-бързо като цяло . The Times Series е най-често срещаният въпрос тук (връзката препраща към друг въпрос; който препраща към друг), но представете си проблема в банкова база данни:ежедневно OpeningExposure и ClosingExposure за Security на Holding наUnitTrust за Portfolio .
Но нека отговоря на въпрос, който не е задаван. Този вид взаимодействие е нормално, не е необичайно при работа с вътрешни екипи за разработка; появява се поне веднъж месечно. Краш горещ разработчик вече е написал и тества своя код, използвайки таблица с дублирана колона, той лети и сега е спрял, защото няма да го поставя в db.

Не, ще го тествам в контекста на цялата система и:
- половината от времето таблицата влиза без колоната EndDate, защото няма голяма работа за заявка за половин секунда, която сега се изпълнява за една секунда.
- През другата половина от времето производителността на [подзаявка за таблица] не е приемлива, така че прилагам булев (битов) индикатор за идентифициране на IsCurrent . Това е много по-добре от дублирана колона и осигурява скорости на 2 сканирания.
- Нито след един милион години няма да ме накарате да дублирам колона; добавяне на 62% към размера на масата; забавяне на таблицата в пълния многопотребителски контекст с 62%; и рискувате да се провалите на одита. И аз не съм служител, не получавам бонус.
Това би си струвало да се тества:заявка с дублирана колона срещу заявка с IsCurrent индикатор, в пълния контекст на цялостното използване на ресурсите.
Smirkingman повдигна добър въпрос. И ще го повторя ясно, за да не се раздробява и след това един или друг фрагмент да бъде атакуван. Моля, не прекъсвайте това:

Релационна база данни,
Нормализирана от опитен моделиращ релации, до истинска пета нормална форма
(няма аномалии при актуализиране; няма дублирани колони),
с пълно релационно съответствие
(IDEF1X, особено във връзка с минимизирането на Id Първични ключове; и по този начин не осакатява силата на релационния двигател)
ще доведе до повече, по-малки таблици, по-малка база данни,
с по-малко индекси,
изискващи по-малко присъединявания
(точно така, повече маси, но по-малко обединения),
и ще превъзхожда по производителност всичко, което нарушава някое от тези правила
на същия хардуер и предприятие платформа db
(изключва безплатен софтуер, MS, Oracle; но не позволявайте това да ви спира),
в пълния контекст на производствения OLTP използване
с поне един порядък,
и ще бъде много по-лесно за използване
и за промяна
(никога няма нужда от „рефакторинг“).

Правил съм това поне 80 пъти. Два порядъка не са необичайни, ако го правя сам, вместо да предоставя рамката, за да го направи някой друг.

Нито аз, нито хората, с които работя или които ми плащат, не ме интересува какво ще направи едно запитване изолирано.