Где бы можно было послушать этого замечательного лектора? Рассказывает просто супер, жаль что это, всего лишь, обзор. Как правило, про базы данных рассказывают либо люди, хорошо их знающие, но не способные двух слов связать, либо люди мало в них понимающие. Этот дядька - приятное исключение.
Отлично выбраны ключевые моменты( для всех лекций в серии). Прекрасное изложение. Шикарный юмор. В общем - редкое сочетание для технического материала. Спасибо большое за лекции! Хочется добавить, что довольно часто в том или ином виде базы используют разные подходы к хранению. Как было сказано в лекции, в Oracle мы храним данные в блоках, но пишем redo-log для Durability (из ACID), и чтобы минимизировать издержки на запись, мы используем буферный кэш ( который в некотором виде присутсвует в LSM деревьях). Уровень Memtable в LSM деревьях может быть организован как B-tree ( и вроде как есть примеры с такой реализацией) и в них(LSM деревьях) так же есть redo-log для той же Durability. В общем берут лучшее друг у друга. :) Для логического развития лекций может подойти тема MPP систем ( например Teradata). ИМХО, эта СУБД (как и oracle) ключевая по инновациям и многие NOSQL и BigData решения в том или ином виде тянули идеи из нее (шардинг, Shared nothing подход, алгоритмы расределения данных ( hash map table), дублирование по разным шардам для отказоустойчивости, вторичные индексы поверх шардированных данных и т.п.).
Очень здорово и доходчиво. Мелкое замечание: 18:56 в Оракл запись в индекс как и запись в таблицу не блокирует чтение. Чтение происходит из версий блоков актуальных на момент начала запроса (либо на момент начала транзакции serializable или readonly).
Да, но это справедливо для продвинутых реализаций, типа того же Oracle, с поддержкой версионности и т.д. Тут есть проблема: с одной стороны надо говорить о принципах, а не описывать конкретную реализацию, с другой - все равно скатываешься на конкретные примеры для конкретной базы :)
Вся серия скринкастов по книге Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. Прям даже порядок тем и примеры один в один. Не скажу, что это плохо, но если хотите больше информации, то крайне советую книгу. Автор рассказал лишь первые 10% книги.
Год я ждал этого каммента! И вот, хотя и под роликом, который отошел от нее довольно далеко... Тут все же больше Оракловые доки в основе. Но "книжка с кабанчиком" - это наше все :)
@@vladymyrkuznietsov8815 Рад, что закрыл ваш гештальт с комментом :) Было бы здорово посмотреть скринксты по темам из оставшейся части книги с добавлением информации из личного опыта. Такой формат легче усваивается, чем чтение книги.
@@sergey5565 Сейчас вот над транзакциями потею, там надо примеров много придумать, да и феномены четче прописать, думаю намиксовать с букварем от Vlad Mihalcea... Имхо репликацию надо давать после транзакций...
Все бы было хорошо, да вот только размер сектора диска испокон веков был 512 байт. 8Кб - это, вероятнее всего, имелся ввиду размер кластера, а кластер - это понятие файловой системы, и его размер может задаваться при форматировании.
512 - это минимальный размер, который может диск адресовать физически. physical_block_size, а есть logical_block_size - это обычно 4k, но тру DBA выбирают (ну ок, сейчас на это не заморачиваются обычно) 8k, но согласен, точнее было бы говорить блок или кластер :)
В MyIsam ускорена производительность за счет отсутствия журнала. Но как-то получилась у нас забавная ситуация когда огромная таблица испортилась и восстановить ее не получилось.
Спасибо, я посмотрела весь плейлист )В конце видео Владимир обещал рассказать о более экзотических способах хранения данных(столбцы, кубы). Дальше планируете продолжить эту серию классных уроков?)
Если посмотреть на правую руку Владимира, на которой "проходки" висят, например тут: ruclips.net/video/TQAzmpdwJGA/видео.html, то можно предположить, что его и на отборочных WESG можно встретить... Ну и в Катовице, чего уж там :)
У вас формулы по оценке высоты не точные. Нужно брать логарифм по основанию [m/2]. Ив определении B-дерева, у вас не сказано,что корневой узел имеет как минимум два потомка. Это по Кнуту
Нет-нет-нет, clustered index это совсем другое: он может быть один на таблицу, и идея в том, что записи(rows) записываются упорядочено по ключу. В результате запись медленная, но чтение, особенно если читаются все поля записи, очень быстрое.
@@vladymyrkuznietsov8815 хм, ок буду копать дальше. Владимир, а Вы можете выделить в отдельное видео тему о классификации индексов по разным критериям. Простой-составной; кластеред-нонкластеред, етк... Спасибо заранее )
Кластер индекс это кодга несколько колонок обьединены одним индексом поиска. Причем в строгой последовательности. Например в индекс заисан ключ "склад+товар+партия". И если мы хотим найти записи по товару не зная склад, индекс перестает работать и таблица сканируется полностью. Но если мы знаем склад и товар, но не знаем партию то записи выбираются по индексу.
@@vladymyrkuznietsov8815 И в правду не заснешь.... после такого говолокружительного показа... Дело конечно Ваше, мне данный ролик запомнился постоянной колбасней камеры, а не содержимым ! Кому не интересно и так уснет. постоянный перемещения отнимают внимание, внимание это силы. Когда в рот смотришь начинаешь засыпать... Мое предложение сосредоточить внимание на информации в схемах, диаграммах и т.п. а не на перемещении от лица на диаграммы и обратно. В рот смотреть интересно, но по факту вся информация на листе бумаги... Дальще решать Вам.
не объяснил почему не стоит делать много индексов (или можно?). Кому интересно про Б дерево наберите b-tree visualisation - наглядно можно посмотреть как заполняется дерево www.cs.usfca.edu/~galles/visualization/BTree.html
Где бы можно было послушать этого замечательного лектора? Рассказывает просто супер, жаль что это, всего лишь, обзор.
Как правило, про базы данных рассказывают либо люди, хорошо их знающие, но не способные двух слов связать, либо люди мало в них понимающие. Этот дядька - приятное исключение.
Крутой дядька) Давайте его побольше)
Отлично выбраны ключевые моменты( для всех лекций в серии). Прекрасное изложение. Шикарный юмор. В общем - редкое сочетание для технического материала. Спасибо большое за лекции!
Хочется добавить, что довольно часто в том или ином виде базы используют разные подходы к хранению. Как было сказано в лекции, в Oracle мы храним данные в блоках, но пишем redo-log для Durability (из ACID), и чтобы минимизировать издержки на запись, мы используем буферный кэш ( который в некотором виде присутсвует в LSM деревьях).
Уровень Memtable в LSM деревьях может быть организован как B-tree ( и вроде как есть примеры с такой реализацией) и в них(LSM деревьях) так же есть redo-log для той же Durability.
В общем берут лучшее друг у друга. :)
Для логического развития лекций может подойти тема MPP систем ( например Teradata). ИМХО, эта СУБД (как и oracle) ключевая по инновациям и многие NOSQL и BigData решения в том или ином виде тянули идеи из нее (шардинг, Shared nothing подход, алгоритмы расределения данных ( hash map table), дублирование по разным шардам для отказоустойчивости, вторичные индексы поверх шардированных данных и т.п.).
Шикарная подача информации. Давайте ещё!)
Очень, очень познавательно! Огромное спасибо!
Очень здорово и доходчиво. Мелкое замечание: 18:56 в Оракл запись в индекс как и запись в таблицу не блокирует чтение. Чтение происходит из версий блоков актуальных на момент начала запроса (либо на момент начала транзакции serializable или readonly).
Да, но это справедливо для продвинутых реализаций, типа того же Oracle, с поддержкой версионности и т.д. Тут есть проблема: с одной стороны надо говорить о принципах, а не описывать конкретную реализацию, с другой - все равно скатываешься на конкретные примеры для конкретной базы :)
Цікаві та корисні усі 7 відео! даже для початківців) Дякую!
огонь как понятно подаете информацию! спасибо огромное!
Супер объяснение, спасибо!
Ждем продолжения )
Дуже цікаво !
А где же продолжение? (( Еще интересен разбор примеров. Можно например взять мой сайт на опенкарт и тяжелый запрос.))) буду очень рад)
Вся серия скринкастов по книге Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. Прям даже порядок тем и примеры один в один. Не скажу, что это плохо, но если хотите больше информации, то крайне советую книгу. Автор рассказал лишь первые 10% книги.
Год я ждал этого каммента! И вот, хотя и под роликом, который отошел от нее довольно далеко... Тут все же больше Оракловые доки в основе. Но "книжка с кабанчиком" - это наше все :)
@@vladymyrkuznietsov8815 Рад, что закрыл ваш гештальт с комментом :) Было бы здорово посмотреть скринксты по темам из оставшейся части книги с добавлением информации из личного опыта. Такой формат легче усваивается, чем чтение книги.
@@sergey5565 Сейчас вот над транзакциями потею, там надо примеров много придумать, да и феномены четче прописать, думаю намиксовать с букварем от Vlad Mihalcea... Имхо репликацию надо давать после транзакций...
Все бы было хорошо, да вот только размер сектора диска испокон веков был 512 байт. 8Кб - это, вероятнее всего, имелся ввиду размер кластера, а кластер - это понятие файловой системы, и его размер может задаваться при форматировании.
512 - это минимальный размер, который может диск адресовать физически. physical_block_size, а есть logical_block_size - это обычно 4k, но тру DBA выбирают (ну ок, сейчас на это не заморачиваются обычно) 8k, но согласен, точнее было бы говорить блок или кластер :)
Отлично, спасибо
В MyIsam ускорена производительность за счет отсутствия журнала. Но как-то получилась у нас забавная ситуация когда огромная таблица испортилась и восстановить ее не получилось.
спасибо
Очень здорово! А где продолжение?)
как это? ruclips.net/p/PLmqFxxywkatS8Hfj6-aYgXfrpvV6OoKSc
Спасибо, я посмотрела весь плейлист )В конце видео Владимир обещал рассказать о более экзотических способах хранения данных(столбцы, кубы). Дальше планируете продолжить эту серию классных уроков?)
@@ekaterynaberkhmiller8979 Да, столбцы надо будет осветить... Но пока надо добить транзакции...
@@vladymyrkuznietsov8815 ну очень ждём!
У древних дисков сектора разве не 512байт были?
а можете сказать был ли Владимир на wcs spring в киеве? уж больно лицо знакомо, мне кажется я его видел в кибер арене
Если посмотреть на правую руку Владимира, на которой "проходки" висят, например тут: ruclips.net/video/TQAzmpdwJGA/видео.html, то можно предположить, что его и на отборочных WESG можно встретить... Ну и в Катовице, чего уж там :)
У вас формулы по оценке высоты не точные. Нужно брать логарифм по основанию [m/2]. Ив определении B-дерева, у вас не сказано,что корневой узел имеет как минимум два потомка. Это по Кнуту
угу, вставки я поленился вычитать, и напрасно :(
Спасибо)
Так это и был clustered index. На жёстких дисках эти блоки тоже ведь кластерами зовутся?
Нет-нет-нет, clustered index это совсем другое: он может быть один на таблицу, и идея в том, что записи(rows) записываются упорядочено по ключу. В результате запись медленная, но чтение, особенно если читаются все поля записи, очень быстрое.
@@vladymyrkuznietsov8815 хм, ок буду копать дальше. Владимир, а Вы можете выделить в отдельное видео тему о классификации индексов по разным критериям. Простой-составной; кластеред-нонкластеред, етк... Спасибо заранее )
Кластер индекс это кодга несколько колонок обьединены одним индексом поиска. Причем в строгой последовательности. Например в индекс заисан ключ "склад+товар+партия". И если мы хотим найти записи по товару не зная склад, индекс перестает работать и таблица сканируется полностью. Но если мы знаем склад и товар, но не знаем партию то записи выбираются по индексу.
Оператору: en.wikipedia.org/wiki/30-degree_rule
03:00 - диск считает данные секторами (8кб)
А вот музыка на фоне явно лишняя. Если кому-то она нужна, каждый сам поставит себе по вкусу.
Слушайте, так невозможно камеру качают из строны в сторону, то приближают то удаляют.
Ребяты ЗАЧЕМ ВЫ ЭТО ДЕЛАЕТЕ ? Мы не на дискотеке и т.п. !
Проверка на фокус-группе показала, что если этого не делать, то зритель засыпает в среднем через 3 минуты :)
@@vladymyrkuznietsov8815 И в правду не заснешь.... после такого говолокружительного показа...
Дело конечно Ваше, мне данный ролик запомнился постоянной колбасней камеры, а не содержимым !
Кому не интересно и так уснет. постоянный перемещения отнимают внимание, внимание это силы.
Когда в рот смотришь начинаешь засыпать...
Мое предложение сосредоточить внимание на информации в схемах, диаграммах и т.п. а не на перемещении от лица на диаграммы и обратно. В рот смотреть интересно, но по факту вся информация на листе бумаги... Дальще решать Вам.
Да спасибо за юмор, вот он точно в тему и не дает заснуть !
не объяснил почему не стоит делать много индексов (или можно?). Кому интересно про Б дерево наберите b-tree visualisation - наглядно можно посмотреть как заполняется дерево www.cs.usfca.edu/~galles/visualization/BTree.html
Оператора колбасит...
Слишком много воды