Як працюють індекси в базах на прикладі. MySQL vs Postgres. UUID vs Auto Increment.

[@yurii_zh]

Прекрасний контент. Таких якісних відео з програмування я не бачив на російськомовному ютубі. На англомовному ютубі бачив канали десь Вашого рівня, але не кращі за Вас. Це просто супер. Я Вами захоплююсь.

[@AboutProgramming]

Дякую за відгук) Радий, що контент виходить корисним

[@pashnyovv]

а поділіться будьласка англомовним каналом? будь ласка

[@ruslan_lwow79]

та ще й рідною мовою це подвійний лайк комент!++

[@ТІ-01ДихановЯрослав]

найкраще пояснення про індекси під капотом, яке тільки можна знайти

[@scruwi]

Дуже крутезне відео. Таке враження, що до цього моменту я працював з мускулем як макака )

[@AboutProgramming]

Дякую! Радий, що відео вийшло корисним :)

[@scruwi]

@@AboutProgramming з задоволенням ще б послухав про ньюанси комбінованих індексів, якщо там матеріалу набереться на окреме відео )

[@pashnyovv]

мені кажеться, більшість таких

[@_dyats]

Дякую ютубу, що порекомендував мені цей канал

[@БогданЮрчук-т8о]

у нього ще є телеграм канал

[@Pidvysotskyi_Oleksandr]

Велике вам дякую, якраз зараз працюю з таблицями в mySQL, на проекті. І таке глибоке розуміння цих процесів,дуже корисне для побудови загальної структури, та алгоритмів.

[@pashnyovv]

дочитав коментарі, і відповіді на них, тоже дуже цікаво і корисно. Дякую

[@jses8560]

Вельми дякую за такий чудовий та корисний матеріал.

[@oleksandrpodustov]

просто супер мега топ контент!!! дякую що розвиваєте нас і наповнюєте український ютуб!!!

[@roman.koliada]

Чудове відео. З третього відео допетрав, що мускул == MySQL)

[@VStyleMentVS]

Цікава тема. Дякую автору за гарне пояснення з прикладами ще й українською мовою) Ну і ютубу за рекомендацію.

[@avramukk]

Сильний контент. Все чітко і зрозуміло. Будь ласка продовжуйте. Цікавлять від вас основи як все працює на максимально низькому рівні. Мені в роботі це дуже допомагає, коли розумієш щось на глибокому рівні. Мені здається краще розуміти кілька речей досить глибоко ніж супер багато і поверхнево.

[@avramukk]

Пропоновані теми: Алгоритми Ооп Як працюють різні мови програмування (низькорівневі моменти) Як працює конвеєр nodejs Як влаштовані процеси sdlc у вас в google)))

[@arcsin4083]

Дякую за пізнавальний контент українською!

[@СергійСтоленський]

Топовий контент. Дякую за детальне роз'яснення

[@Naikshy]

Дякую за ваші відео, дивлюся вже 5те відео поспіль, ви підіймаєте дуже цікаві теми, про які хочеться зайвий раз послухати і дізнатися щось нове)

[@CupOfCyanidee]

Дуже дякую за круте відео, багато дізнався, було б дуже круто якщо б ти розповів про кеши у базах та рівні ізоляцій транзакцій із прикладами

[@ТимофейВдовиченко-ф9ц]

Було б круто побачити такий ж відос по Postgress. Дуже крутий контент, не так давно проходив курс по SQL і там не було таких корисних деталей.

[@AboutProgramming]

А що саме цікавить? В цьому відео ж розповів про особливості Postgres в тому числі. Відносно бенчмарків, то весь код є на GitHub, можна трохи адаптувати й протестувати. Тобто, навіть не знаю, що ще можна додати 🙂

[@mshkotnyar]

Все круто. але дійшов до місця, де проставляються індекси, то у мене на ССД один індекс робився 9 хвилин) Після цього вирішив просто дивитись)

[@vanodevium]

Вдячний за чудовий матеріал! Але є питання: чому ніхто не звернув увагу, що UUID зберігається як varchar? Є ж можливість зберігати як char(32), що економить 1 байт, а ще є можливість взагалі зберігати як binary(16). Було б чудово обговорити і такі формати й подивитись на розміри індексів. Дякую за популяризацію інженерії через голову, а не через дупу ;)

[@AboutProgramming]

Дякую) Гарний коментар. Спочатку думав для демо робити BINARY, але потім зрозумів, що майже завжди бачу VARCHAR й це буде більш показовим. А ось окреме відео про формати мабуть варто зробити, можна й про IP як INT(4) згадати та інші кейси

[@19n1ght]

Дуже дякую! Чудовий та унікальний матеріал. Згадую часи коли працював в базами, якби я тоді це знав... :)

[@IlarionHalushka]

Віктор, це просто розрив 🔥 відео ТОП!

[@pidgornyiandrii40]

Крутезне відео! Дякую! Мені здається, що відео з камери краще змістити в верхній правий кут при шерингі консолі! Вибачайте за непрохану пораду )))

[@AboutProgramming]

Дякую! Спробую погратися з розміщенням відео з камери. Може буде краще)

[@konstantin88527]

Дякую! Класна подача і дуже цікаво дивитись)

[@ОлексійМоторний-ы5в]

Дуже зрозуміла подача складних і незрозумілих речей. Дуже допомагає практична частина відео(приклади)

[@TVV14]

Дуже цікаво було подивитися - а ще цікавіше було скачати дамп і трохи покрутити його самостійно!))) Щиро дякую за чудовий і корисний контент, Вікторе! Так тримати!!!

[@pashnyovv]

Дякую за відео, та ще з прикладами

[@oleksandrburiakovskyi3774]

Дуже круте відео, дякую, чекаю з нетерпінням наступних відосів!!!

[@taraskruvch]

Ви дуже чітко роз'яснили принцип роботи індексів у MySQL та PostgreSQL, а також важливість вибору між UUID та Auto Increment. Чекаю на ваші наступні відео. Дякую

[@vasyok92]

унікальний контент! а подачааааааааааа)))

[@protchenko.oleksandr]

Було дуже цікаво. Щось я знав, щось забув, тому було познавально. Особливо нюанс з офсетом!

[@dyadyaB]

Лайк за хардковий контент :)

[@turbosega]

Дякую. Класне відео!

[@KuzyoYaroslav]

Чудовий контент. Цікаво було почути, як краще організувати онволення індексів на проекті, особливо коли дані часто онволюються.

[@victormasny2336]

Дякую за твої зусилля. Чудовий матеріал. Особливо дякую за порівняння між mysql та postgres!

[@user-oe6zb2rx2c]

Дуже круте відео дякую

[@matash149]

Хотілось би побачити відео на тему вибір між mysql і postgres. Основні нюанси які потрібно враховувати на початку створенні проекту, по швидкодії, розміру проекту і тд.

[@AboutProgramming]

Зазвичай критичної різниці немає в стандартних фічах. Головне вміти готувати ту чи іншу базу. Але різниця є в додаткових фічах. Колись в postgres не було logical replication, а в MySQL геоіндексів. Зараз більш менш парітет. Також є різниця в ліцензіях. Також раніше не всі провайдери підтримували обидві бази в managed варіанті. Я персонально в більшості випадків користую MySQL, оскільки він мені зрозуміліший й немає всіляких штук типу Auto vacuum й тд. Також мені подобається тулінг під MySQL типу workbench. Але в ряді проектів був й postgres

[@matash149]

​@@AboutProgramming дякую, зараз в багатьох вакансіях вимагають іменно postgres , а я мав справу тільки з MySQL тому і цікаво чи є там щось настільки кардинального

[@currentid]

Чудово, дякую! Поступово буду індексувати контент з вашого каналу у своїй голові :)

[@liubkkkk0]

Дякую за корисний контент для розробників, очікую на наступні відео з нетерпінням)

[@ОлексійБулах-ф7п]

топ канал для програмістів повага за українську мову

[@wegafran2491]

Дякую за відео!

[@NDA-z3n]

Круто. Дякую!

[@illiadenysenko7776]

Неймовірно круто. Що прям дуже незвично це те що, є одночасно і теорія і реальна практика з прикладами реальних систем. І це напевно про весь канал можна сказати. Респект, напевно ніколи такого не бачив. (Хоча може і погано шукав :D)

[@markh3329]

це вже цікаво, з підв'язкою до заліза і практики

[@AndriyHulyk]

MySQL може використовувати різні storage engine. Тому бажано уточнити, що те, що ви розповіли актуально для InnoDb ;)

[@AboutProgramming]

Так, innodb вже давно дефолт в MySQL. Myisam навіть не знаю навіщо сьогодні може знадобитися на практиці. Але так, в відео все про innodb. Гарне зауваження

[@Taronimus]

Мені подобається цілісність бачення у створенні цих відео. Думаю, тому я досі не помітив води, все по-суті

[@romkalily]

Як завжди на найвищому рівні!!!!

[@chaker2710]

Дякую за відео, нещодавно ютуб підкинув в рекомендаціях. В очевидних речах знаходиш шось нове. Дозволю собі ремарку щодо показаного в відео (27:01). Не знайшов в коментарях, можливо зле шукав, тому сорі якщо дубль. На прикладі з одним полем name не так критично. Але по факту прийдеться додати пів таблиці в індекс по умовно взятому року, бо то все треба показати користувачу. Ми ж не тільки назву покажемо. Ще якусь картинку, кусок опису і т.д. Тому якось не сильно ефективно з точки зору розміру такого індексу. Як варіант, щоб не тримати все в індексі можна то ділити в два запити. Спочатку з індексу витягувати айді, а потім робити селект по айді. На практиці то виходить ефективніше.

[@AboutProgramming]

Так й є. Часом два запити краще або можна subquery й join - www.taogenjia.com/2022/08/23/MySQL-Query-Optimization-Tips/#High-Offset-Page-Query-Improvement

[@4opper1]

Відео супер! Дуже цікаву тему вибрав автор. Дякую!

[@juliegvozdikova357]

Дуже корисно! Дякую за відео!

[@ПавелБабич-э2ф]

GO UA!

[@maximzhuravlenko4932]

Чудове і дуже корисне відео)

[@maxymdyachenko9247]

Дуже багато чого дізнався, дякую

[@sergeylypko5817]

Привіт, дякую за відос - дуже цікава тема) ти згадував про убер, що вони переїздили с постргреса на майсіквел, так от взагалі було б цікаво подивитися, як би ти до прикладу аналізував архітектури БД різних біг тех проектів. Ну звісно там велика варіативність, але думаю зрозуміло що маю на увазі. Я вивчаю бази даних зараз, і вважаю найбільш важливою але і складною темою - розуміння концептуального використання різних БД під різні кейси. Так от мені здається, що великі тех стартапи - це гарний приклад хайлоаду і аналізу що і як повинно працювати. Можливо це більше про сістем дизайн, ніж про лоу левельні фундаментальні речі, але виходить все сильно пов'язано.

[@ВиталийПервий]

Дуже корисне відео, дякую!

[@FreelanceTripper]

Дуже класний контент, дякую велике! Хотілось би ще почути "Real life uses" для індексування, як саме аналізувати проект під час вибору Бази даних, чи використовувати індексування, чи може коли треба комбінувати різні техніки. P.S. Дуже подобається такий україномовний контент

[@monfrid]

Дуже дякую!

[@Epic0n]

Домашне завдання по темі мігрувати праймарі ключ з юід в ід на живій базі ;) Якщо що то це був жарт :)

[@НазарійПивовар]

Дякую за класний контент)

[@yuriyk2668]

Норм пояснив. Дякую

[@AdminAdmin-sl2qf]

❤❤❤❤❤❤❤❤❤❤❤❤

[@OleksandrTorosh]

Дякую за цікаве відео

[@МаксимНазаров-э7ю]

Спасибо большое за материал)

[@АнтонКоваленко-ъ2е]

Дякую!

[@MascleGinger]

Very useful info

[@Philip_Just]

Цікаво дякую

[@knyazevtaras]

Дякую, дещо дізнався нове. Але от у мене ще в житті не було стільки записів в таблицях. Це може якісь круті магазини, чи системи високонавантажені. Один раз у мене була таблиця там десь трішки більше 1 млн записів.

[@ivanovserg8795]

Дякую! Все чудово, але... Швидкість вставки - ви робите 20_000 транзакцій (мережевих) порціями по 1_000 товарів. А якщо навпаки - зробити TOTAL_BATCHES = 1_000 , а BATCH_SIZE = 20_000. Гадаю що усі показники часу зменшуватимуться, але їх рейтинг так само збережеться.

[@AboutProgramming]

Так, гарне зауваження, пакетні вставки зазвичай працюють швидше, бо додаєтсья багато даних в рамках однієї транзакції. Але на практиці, зазвичай вставляється взагалі по 1-2 об'єкти (якщо це просто веб-трафік). Пачками вставляється зазвичай при імпорті даних з файлів.

[@olegmakarikhin]

15:52 підозрюю що така різниця між розмірами обумовлена тим що кластерний uuid це гарантовані і вставки в "середину" індекса, це можна перевірити якщо перебудувати індекс, optimize /alter table.. force. Але в реальній базі на це витратиш дофіга часу, заблокуєш, але подальша робота, інсерти знову приведуть до того ж результату

[@AboutProgramming]

Так, дякую! В відео я згадував, що може резервуватися додаткове місце, але на цьому не робив акцент, оскільки це відбувається для всіх індексів. Й окрім того по дефолту innodb_fill_factor дорівнює 100, тому ефект мінімальний. Але протестую на базі й відпишу, що вийшло

[@dimitro.cardellini]

Привіт, Вікторе! Класні відео -- дякую. Є маленька прохання: коли показуєш консоль, то підійми її від нижнього краю екрану, бо якщо зачепити мишку, то вспливає панель керування переглядом на ю-тьюб і командний рядок не видно -- доводиться перематувати, а бо читати вже історію. Будь ласка.

[@yurii_zh]

Тепер я знаю, що у Вас на комп'ютері KDE Plasma))

[@konstantin6524]

Я щиро вдячний вам за контент такого рівня, дивлячись його я розумію за що люблю програмування! Підкажіть який у вас SSD?)

[@AboutProgramming]

Дякую за відгук🙂 Відносно SSD, у мене Samsung 980 Pro M.2, але зараз можна взяти трохи новіший - 990 Pro

[@pashnyovv]

@@AboutProgramming беріть кілька і в raid масив їх )))

[@harvesterp4412]

Дуже корисно, а ще й українською

[@Roman-oi9el]

Цікавезний матеріал, але чомусь думав що PostgreSQL поле індексу зберігає PK, аналогічно як це Ви показали для MySQL

[@makaka527]

Топчик

[@tonchique]

Дуже корисно! А чого не було подібного бенчмарку з postgres?

[@AboutProgramming]

Дякую! Відносно postgres, то не ставив задачі порівнювати перформанс баз. Ідея була розповісти концептуально про роботу індексів. MySQL більш показово й більш цікаво, оскільки покриває більшість кейсів й кейс з кластерними індексами, тому вибрав його. Ну й на все и часу не вистачає 🙂

[@Sun1ive]

Привіт, круте відео, дуже пізновально. Якщо можна покрити історію з індексами у SQL-server, так як цю базу використовуємо на роботі. Дякую

[@AboutProgramming]

Дякую 🙂 SQL server концептуально працювати має схоже - індекси, дерева, кластерні індекси й тд. Дрібні деталі будуть відрізнятися, але це вже найкраще дивитися по документації для конкретної версії бази. Ще один аспект, який хочу покрити в наступних відео це інвертовані індекси. Й можливо ще geo індекси, теж цікава тема

[@olegmakarikhin]

тут прийшов про mssql розповісти, а тут як питання. як вчасно. коротко - є сторінки по 8кб. це контейнери для як для рядків, так і для індексів. кожна сторінка має інформацію хідер, де є номер файла де вона сберігається, та порядковий номер, а також objectid об'єкта (таблиці) що вона зберігає в собі, а також id індекса (indexid - 0,1,255 зарезервовані). і купу оптимізаційних речей, наприклад сторінки виділяються суміжними блоками по 8 сторінок - екстентами що належать однієй таблиці, це видно коли індекс майже пустої таблиці займає 64кб, doubly linked list - посилання на сусідні сторінки які належать одному і тому ж індексу, якщо індекс (також таблицю) представити у вигляді ланцюжка сторінок, ну і ще є allocation-map. але про індекси. індекси, як і в інших btree-структурах, це можна окремо розділити на root-branch-сторінки, вони там якось побудовані, що в кінці кіців посилаються на leaves цього дерева, і дозволяють швидко знайти ту сторінку з "листом", в якому невелика кількість записів ключів індексів відсортована. в листовій сторінці - в залежності від того чи це кластерний індекс чи ні, : якщо некластерний індекс то там ключі та координати сторінки де шукати рядок з данними. здається це номер-файла-номер-сторінки-оффсет-рядка. "але це не точно", можливо складніше. але фактично посилаються на номер сторінки та запис в сторінці. якщо кластерний, то її то листовою сторінкою будуть самі рядки з даними таблиці. в такому випадку сторінки мають indexid=1, кластерний, і це ввається відсортовані рядки таблиці. такий індекс може бути лише один, тому що для другого сортування потрібно зробити копію листових сторінок таблиці з даними, і підтримувати консистентність. якщо кластерних індексів у таблиці нема, данні таблиці лежать в сторінках що називаються heap table, мають indexid=0, сторінки мають doubly linked list-посилання, це дозволяє сканувати їх. порядок в якому лежать рядки - як придеться, в якому порядку вставили записи, його декларативно нема, і якщо були оновлення що змінюють загальну длину рядка, то select без order by може повернути на той самий запит рядки в іншому порядку. звичайні некластерні індексі - їх може бути багато, мають indexid=2,3... і так далі. сторінки фізично на диску вони можуть лежати в будь-якому порядку, а "таблиця відсортована" - мається на увазі те що якщо зчитувати ланцюжок в порядку який задано в doubly linked list - то рядки будуть відсортовані по ключу (одному або групі полів). перевага саме двозв'язкового списку в тому, що якщо були дуже щільно заповнені даними сторінки в середині ланцюжка, а потім прийшла команда що збільшила довжину рядка, саме тих даних в середині, то підсистема бд виділяє місце в файлах бд в будь-якому вільному місці, додає їх в середину ланцюжка таким чином, що змінює посилання на сусідів лише в двох сторінках між якими вставляє новий екстент з 8 сторінок. до речі в індексних сторінках такі зміни бувають дуже часто, виділяються сторінки, частково заповнені даними, і тому вони розбухають, стають нещільними, потребують регулярної дефрагментації.

[@Sun1ive]

@@olegmakarikhin дякую!

[@kisliymaxim]

Дякую за відео. Які книги по БД, можете порекомендувати ? Загалом, думаю, буде круто, якщо зможете записити відео зі списком літератури, яка корисна на вашу думку

[@AboutProgramming]

Робив одне відео на каналі про книжки, але там більше про проектування. Відносно баз даних, то Designing Data-Intensive Applications Мартіна Клепмана. Але ще пару відео про книжки планую зробити

[@kisliymaxim]

@@AboutProgramming дякую за рекомендацію)

[@BorysYermokhin]

Дякую за класне відео. Дуже цікаво! Як на рахунок uuid v7 який залежний від часу, це буде теж настільки важким?

[@AboutProgramming]

Дякую) з точки зору розміру те саме, а cache hit буде краще, тому кеш бази буде ефективніше працювати. Тобто при інсерті скоріше за все потрібна сторінка буде в кеші, бо primary key відсортований, але всі інші проблеми залишаться ті самі

[@igorlisovyk9687]

Виходить, якщо ви ще не знаєте кількості запитів на вставку (чи зміну) даних і запитів на читання - то важко зрозуміти які додаткові індекси створювати?

[@AboutProgramming]

Скоріше, якщо невідомий характер навантаження, то зайвими індексами можна зробити гірше. Тобто чим більші індексів, тим повільніше вставка. Але навіть при read heavy load теж треба чітко розуміти, які запита робляться до бази, щоб додати потрібні індекси - на потрібні колонки (часом індекси, що включають декілька колонок)

[@DennyTenny]

Дякую за відео! Підкажіть будь ласка, чи варто використовувати фултекст індекс для пошуку запису з строгою рівністю, а не по слову в середині з використанням %{searchPattern}%? Тобто чи буде відрязнятися швидкість where name="somename" від where Match(name) against ('somename')?

[@AboutProgramming]

Тут краще підійде звичайний індекс. По перформансу має бути як мінімум не гірше

[@pashnyovv]

якщо є час і наснага, пару слів oracle db, а то був на проєкті, де мігрували з оракла в мускуль, і йому було дуже тяжко, часто були таски на оптимізацію. Що там за великі гроші оракл пропонує кардинально краще?

[@AboutProgramming]

Залежить від характеру даних. Я був на проекті й MySQL показував кращі результатати, але рішення з ораклом коштувало на порядок більше. Але в оракл тоді можна було помістити значно більше даних, але це було не те, що нам треба. Цікаво, що зараз Google Cloud пропонує AlloyDB (оптимізований Postgres), як альтернативу ораклу. Також цікаво, що ліцензія оракл не дозволяє публікувати бенчмарки й результати

[@pashnyovv]

@@AboutProgramming дякую, дали їжу для подумати

[@banlex73]

AllowDb коштує... треба вважати чи дійсно потрібно чи звичайний Postgres буде достатньо.

[@TheKidomaz]

Підкажіть, , будь ласка: Covering index важливий тільки для MySQL? Створення індексу з двух полів корисно лише при використані OFFSET? При створені індексу з декількох полів, наприкла (year, name), інформація у вториному індексі для year зявиться не лише первиний ключ, а й name, тобто якщо потрібно створити для поля name, то потрібно змінити порядок (name, year,)? Чи індекс (year, name) добавить до вториного індексу name силку на поле year теж? Буду дуже вдячний за вашу відповідь

[@AboutProgramming]

1. Covering index важливий я для postgres, але там є альтернатива у вигляді include індексів. Концепетуально дуже схожа ідея - додати в індекс додаткові поля, але тільки в leaf nodes. 2. Відносно OFFSET це більш показово, оскільки треба пройтися по великий кількості рядочків, але й просто виборка великої кількості рядків буде швидша з covering index. 3. Не зовсім зрозумів питання. Але ідея така, що якщо второнний індекс має всі поля, які потрібні при виборці, то немає необходіності ходит в основну таблицю (кластерний індекс) й порядок полів не грає ролі. Порядок полів грає роль тільки при фільтрації й сортуванні - якщо у нас індекс (name, year), то не можна зробити виборку чисто по "year", оскільки в першу чергу все в індексі відсотовано по name, а потів вже по year

[@vasylpavuk391]

Гарне пояснення. Тюнінг індексів це завжди пошук балансу між R/W. У MS SQL Server є можливість побачити статистику по індексах (Seek, Scan, Lookup, Update). Чи є можливість побачити аналогічну статистику у вказаних СУБД?

[@AboutProgramming]

Дякую. Практично в кожній базі є якість інтсрументи профайлінгу. В MySQL є PEROFRMANCE_SCHEMA також є explain analyze для окремого запиту, чи profile. Чи конкретно є загальна статистику по тому, яки використовувався індекс й скільки часу в кожному режимі провів, то такого не памʼятаю (але може вже й є таке). Ну, й можливо Percona MySQL мають більше метрик по індексам

[@banlex73]

В postgres є така сама статистика pg_stat_all_tables and pg_statio_all_indexes

[@skreibb]

Як щодо uuid primary key в mysql використовуючи binary(16) ?

[@AboutProgramming]

Це можна. Трохи ускладнює написання запитів, бо треба конвертувати hex в binary, але розмір індексів зменшить, але все одно це далеко від оптимального варіанту. Припустимо ми індексуємо поле INT, то у нас 4 байти на INT й 16 байт на BINARY UUID. Тобто 80% даних індексу це primary key. А таких індексів може бути багато. Навіть багато текстових полів мають довжину меншу за 16 байт. Друга проблема це cache miss при рандомній вставці, що теж може суттєво уповільнити. Третя це менше записів в блоку й більше блоків й відповідно більше резервування місця під виставку. Тобто мати auto increment int як primary key й окрему колонку для UUID може бути набагато краще, але якщо таблиця зовсім без індексів й виборка тільки по UUID (типу такий собі key value пошук), то тоді від окремої колонки буде тільки гірше

[@dmytronikitiuk2755]

Виходить, що можливий варіант, коли в Postgres швидше не оновлювати рядок, тому що потрібно перебудовувати індекс, а додати новий рядок (тоді індекс перебудовувати не потрібно), тобто зберігати всі стани цього рядка і діставати коли потрібно останній його стан, але тоді збільшується об'єм інформації яку потрібно зберігати. Як вважаєте чи має такий підхід право на існування?

[@AboutProgramming]

Коли ми додаємо рядок, то всі індекси треба перебудувати інакше пошук по цим даним не буде працювати. В Postgres особливість, що оновлення рядка працює, як вставка нового - тобто всі індекси будуть перебудовані (якщо не брати до уваги HOT оптимізацію). В MySQL при оновленні будуть перебудовані тільки ті індекси, де змінилися дані

[@dmytronikitiuk2755]

@@AboutProgramming Дякую за відповідь і крутий контент!

[@eddryha7269]

Я може скіпнув це якось, але коли ви робили запит до products, і шукали по двом полям id, name - це працювало довго, коли id, year - швидко. Притому індекси були створені для усіх ціх окремих стовбців. Різниця в тому що name це строка, а year це число? Чому субд треба перелопатити дані у випадку з id, name, і не треба у випадку з id, year?

[@AboutProgramming]

В обох випадках ми сортуємо по year й відповідно для швидкого пошуку використовується index по year. Але коли ми вибираємо поля id, year - всі дані є в індексі по year, а коли ми вибираємо id, name - нам не вистачає поля name й mysql спочатку витягує поля, а потім робить offset. Й тут звісно виникає питання, а чи не можна було б спочатку прорахувати offset по індексу year, а потім один раз глянути name в кластерному індексі. Mysql так не робить, але можна зробити руками 2 запити (або написати subquery) й тоді буде працювати швидко

[@lestyshchenko3023]

дякую за відео, постає питання - нащо uuid потрібен в базах даних , якщо вони самостійно генерують ключ - індекси . одна справа якщо айді потрібно для використання і створюється простий айді як поле , але унікальне.. але нащо 16 байтний ключ додавати замість індексів... чи є якесь ще призначення uuid окрім створення унікального числа ? наприклад для індифівкатора сесії.

[@AboutProgramming]

В розподілених системах може бути корисно. Наприклад, при master master реплікації. Ще варіант, це коли айді генерує клієнт. Часом роблять, щоб не світити кількість записів (хоча краще тоді окремою колонкою). Й відповідно, в якійсь момент розробники вирішують, що це гарний підхід по замовчуванню, бо ніби uuid вміє те саме, що й auto increment, але трохи більше

[@lestyshchenko3023]

​@@AboutProgramming дякую за відповідь. корисно як і саме відео! master master реплікації - uuid роблять щоб не було загублених чи не вірно оновлених даних через затримку звязку ? завжди думав, що master master реплікації не мають сенсу в реальному часі, а краще - один записує. інші читають і раз в деякий час, копіюють в резервний (як бінарний масив передає файл потоком - частинами.) Хоча я тут не маю досвіду, тому не бачу всієї картини. мене останє дуже часто дивує - коли, особливо коли, на бекенді ігнорують память і швидкість - головне щоб було модерново. Ладно ще фронт може ігнорувати, бо бере конкретні дані і зазвичай вони обмежені кількістю, але чомусь бекенд ігнорує це частіше. Відео про алкоритми мені сподобалось, хоча я б використовував reduce, але алгоритми цікаві, особливо пошук хешем чи сортування Хоара. Не знав як це корисно міняє мислення, поки не почав цікавитись. Тому дійсно гарні теми ви вибрали для відео. про - не світити кількість записів, трохи дивно звучить, особливо коли у відповіді є довжина. та і не зустрічав я в житті коли айді генерує клієнт. Клієнт не повинен працювати настільки з бізнес логікою, хоча - в світі є різні дивовижні створіння. як фейсбук, який не відправляє повідомлення і є соц мережею )

[@muomieg]

Не дуже зрозумів чому з офсетом так довго шукає. Якщо він знайшов потрібний індекс і йому треба піти у основну таблицю і знайти строку, нащо йому проходити по всьому списку, якщо у індексі вказан primary key і достатньо зробити пошук з кластерним індексом

[@AboutProgramming]

Пропустив коментар. З офсетом довго оскільки треба робити скан по даним індекса, щоб зміститися на потрібну позицію, оскільки ми не можемо просто зробити стрибок по індексу в даній ситуації на конкретний запис. Це для кейсу з covering index - запит в рази повільніший, але це ще не секунди. Коли ж немає всіх потрібних полів в індексі, то MySQL ще ходить в кластерний індекс й дочитає додаткові поля для кожного рядка, то це вже просто кладе базу на секунди

[@SS-bo9yt]

можна ще зачепити композитні кластерні індекси і зачепити нормалізації даних в базах

[@shakhrudinov]

Віктор а який планшет ви використовуєте та як транслюєте з нього на лінукс?

[@AboutProgramming]

Зазвичай просто записував екран планшету прямо на планшет, а потім вже це відео додавав під час монтажу. Але в наступних відео планую використовувати програму scrcpy. Дуже проста й гарно працює. Відносно планшету, то у мене Galaxy Tab S7 FE

[@erazelyou]

Віктор, ще питання - я так розумію в мусклі ви використовували таблиці InnoDB? Бо я так здогадуюсь що у інших таблицб інший типу індексів, так як зустрів вказання що саме інноДБ використовують кластерний індекс, для MyIsam щось такого уточнення не зустрів. Для перевірки перестворив табличку з даними але іншого типу. InnoDB зайняла 96 кілобайт (64+32), MyISAM 47кілобайт(28+19). Без індексів: InnoDB - 64/0kb, MyISAM - 28/1kb(таки зробив якісь індекси на 1 кілобайт) Отже получається що різні системи зберігання в MySQL по різному працюють з індексами. Якщо колись у вас буде натхнення то будемо вдячні якщо зробити невеличкий розбір цього питання, як ви зробили в цьому відео. Наперед дякую.

[@AboutProgramming]

Так, все правильно - все про InnoDB. MyISAM ніколи не використовую оскільки: 1. Не підтримує транзакцій 2. Не підтримує Foreign Keys 3. Не підтримує блокування на рівні рядків, а лочить всю таблицю при записі. Тобто великого сенсу в MyISAM немає. Раніше він вмів FTS, але вже давно й InnoDB це теж вміє

[@youknowme9732]

А чому для uuid не використовувати binary, який буде займати 16 байт ? Якщо використовувати ULID або UUID v6 або v7, результати мають вийти зовсім інші.

[@AboutProgramming]

Можна було в бінарному вигляді, трохи складніше писати й вибирати запити було б в консолі (хоча можна було й через BIN_TO_UUID, який вже є в MySQL 8), але хотілося показати на такому прикладі, який найчастіше зустрічаю й його ефект. Використання бінарного UUUD не сильно змінить ситуацію - скоріше за все більше половини даних буде займати UUID (зараз це 70%). Відносно ULID, то це покращить cache hit при вставках, але решта не зміниться

[@youknowme9732]

@@AboutProgramming Створив таблички з PK - int, bigint, uuid (binary 16), uuid_str (varchar 32), uuid_v6 (binary 16). Розміри індексів при 1 млн записів int - 37.56 mb, bigint - 44.58, uuid (binary 16) - 78.64 mb, uuid_str (varchar 32) - 110.97 mb, uuid_v6 (binary 16) - 52.61 mb. Менший розмір має пришвидшити пошук SELECT, бо зменшиться кількість листових сторінок (судячи з параметру n_leaf_pages в таблиці innodb_index_stats). Але дуже цікаво що різниця між UUIDv4 з varchar(32) у 2 рази більша за UUIDv6 binary(16).

[@AboutProgramming]

@@youknowme9732 О, цікава статистика. Це розмір додаткових індексів чи це кластерний індекс?

[@youknowme9732]

@@AboutProgramming кластерні

[@AboutProgramming]

​@@youknowme9732 Ага, зрозумів. Цікавіше навіть було б побачити розмір додаткових індексів. Наприклад по полю price чи name. Там вже не має бути такої різниці в розмірі між uuid (binary 16) та uuid_v6 (binary 16). Окрім того буде краще видно вплив вибору PK , бо в leaf nodes буде лише 4 байта під ціну й 16 байт під PK

[@muomieg]

Хіба MySQL шукає другий раз по кластерному індексу? Наскільки я памʼятаю кластерний індекс ти можеш створити сам, і він не для пошуку елементу по айді

[@AboutProgramming]

А як MySQL знаходить елементи по айді?

[@muomieg]

@@AboutProgramming Ну це питання на яке у мене немає відповіді 😂 може він якось по іншому цей індекс називається)

[@muomieg]

@@AboutProgramming у моїй голові кластерний індекс - це індекс по двом і більше полям. Він може бути тільки один, бо це не окрема "колонка" а це сортування самої таблиці. Може я щось плутаю...

[@AboutProgramming]

@@muomieg )) Ні, якраз кластерний й називається dev.mysql.com/doc/refman/5.7/en/innodb-index-types.html

[@AboutProgramming]

Також кажуть кластеризований, але це те саме. Але можливо кластеризований й більш корректно навіть)

[@kurtmiller77]

Чому сі кю ель якщо ес кю ель? )

[@AboutProgramming]

kzbin.info/www/bejne/iWqmaYOEjZxlg9Usi=F4iiSs38oTwjQORU

[@OlegShevtsov512]

Постгрес гарно відправьовує якщо дані не апдейтити?

[@AboutProgramming]

MySQL й Postgres для певних сценаріїв добре, а для певних гірше. Чи буде підхід Postgres проблемним - можливо, але це залежить від того чи ми апдейтим індексовану колонку й скільки індексів всього нам треба оновити. Також при вставці в базу в будь-якому випадку треба оновити всі індекси в таблиці в обох базах. MySQL по ідеї буде мати швидший read по primary key (оскільки, все знаходиться відразу в кластерному індексі). Тобто в кожному конкретному сценарії може бути по різному. Й різні синтетичні бенчмарки показують різні результати - то Postgres швидший, то MySQL. Також в Postgres є нюанси при роботі AutoVacuum (особливіть реалізації MVCC), MySQL теж робить копію даних для транзацій, але не в основній таблиці, тому періодичний Vacuum не потрібен

[@olegmakarikhin]

апдейт в постгресі фактично це інсерт, та відкладений на потім delete/vacuum. це дає класні плюси в аспектах isolation/locking та durability, але оновлювати маленький флажок, статус або counter в широченній таблиці буде дорого.

[@AboutProgramming]

Насправді, MVCC не вимагає реалізації такого механізму апдейту. Наприклад, MySQL має всі ті самі гарантії по ізоляції й по durability, але потреби перебудовувати всі індекси немає. Так, дані будуть копіюватися, але зайві індекси оновлюватися не будуть

[@OlegShevtsov512]

@@AboutProgramming Цікаві відео, про багато речей не задумавався, тому для розширення кругозору і, часом, очей - класний україномовний контент. Дякую.

[@chelovek0com]

Чому кардіналіті індекса для тих самих полів у різних таблицях різний? Наприклад, поле Рік. У таблицях різні дані?

[@AboutProgramming]

Дані мають бути однакові. Просто cardinality містить приблизне значення, якась внутрішня статистична оцінка

[@truthzp]

Дякую за чудовий контент. Чітко, цікаво, без води, ще й солов`їна ласкає вуха ;)

[@rostik18]

ех... **плачу від того що всі PK у всіх таблицях UUID**

[@AboutProgramming]

😅🙈

[@AlexSmith-oe6pr]

Дякую. Було б цікаво продовження в сторону роботи з великими обʼємами даних, sharding vs partitioning vs cqs/cqrs.

[@ehippo1]

Дуже корисне відео. Я от не знав що в Постгресі вирішили проблему з довгими пк в індексах. Ну і звичайно требо поширювати знання про БД серед розробників, бо часто трапляється на проекті немає ДБА і базу проектують саме розробники.

[@eugenemedvediev]

Дякую, дуже гарно розтлумачуєте тему.