Комментарии •

  • @EshkinKot1980
    @EshkinKot1980 5 лет назад +40

    Где бы можно было послушать этого замечательного лектора? Рассказывает просто супер, жаль что это, всего лишь, обзор.
    Как правило, про базы данных рассказывают либо люди, хорошо их знающие, но не способные двух слов связать, либо люди мало в них понимающие. Этот дядька - приятное исключение.

  • @asvitin
    @asvitin 5 лет назад +4

    Отлично выбраны ключевые моменты( для всех лекций в серии). Прекрасное изложение. Шикарный юмор. В общем - редкое сочетание для технического материала. Спасибо большое за лекции!
    Хочется добавить, что довольно часто в том или ином виде базы используют разные подходы к хранению. Как было сказано в лекции, в Oracle мы храним данные в блоках, но пишем redo-log для Durability (из ACID), и чтобы минимизировать издержки на запись, мы используем буферный кэш ( который в некотором виде присутсвует в LSM деревьях).
    Уровень Memtable в LSM деревьях может быть организован как B-tree ( и вроде как есть примеры с такой реализацией) и в них(LSM деревьях) так же есть redo-log для той же Durability.
    В общем берут лучшее друг у друга. :)
    Для логического развития лекций может подойти тема MPP систем ( например Teradata). ИМХО, эта СУБД (как и oracle) ключевая по инновациям и многие NOSQL и BigData решения в том или ином виде тянули идеи из нее (шардинг, Shared nothing подход, алгоритмы расределения данных ( hash map table), дублирование по разным шардам для отказоустойчивости, вторичные индексы поверх шардированных данных и т.п.).

  • @kosivanov659
    @kosivanov659 5 лет назад +21

    Крутой дядька) Давайте его побольше)

  • @DmitrijRuss
    @DmitrijRuss 5 лет назад +8

    Шикарная подача информации. Давайте ещё!)

  • @sinystas
    @sinystas 5 лет назад +7

    Очень, очень познавательно! Огромное спасибо!

  • @tarasshevchuk8477
    @tarasshevchuk8477 2 месяца назад

    Дуже цікаво !

  • @prognostik
    @prognostik 2 года назад +1

    Супер объяснение, спасибо!

  • @Anton_Zaviriukhin
    @Anton_Zaviriukhin 5 лет назад +1

    Очень здорово и доходчиво. Мелкое замечание: 18:56 в Оракл запись в индекс как и запись в таблицу не блокирует чтение. Чтение происходит из версий блоков актуальных на момент начала запроса (либо на момент начала транзакции serializable или readonly).

    • @vladymyrkuznietsov8815
      @vladymyrkuznietsov8815 5 лет назад +1

      Да, но это справедливо для продвинутых реализаций, типа того же Oracle, с поддержкой версионности и т.д. Тут есть проблема: с одной стороны надо говорить о принципах, а не описывать конкретную реализацию, с другой - все равно скатываешься на конкретные примеры для конкретной базы :)

  • @oleksandrvoron_ko580
    @oleksandrvoron_ko580 3 года назад

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

  • @testweb5425
    @testweb5425 4 года назад

    огонь как понятно подаете информацию! спасибо огромное!

  • @aleksandrkobelev8868
    @aleksandrkobelev8868 4 года назад +4

    А где же продолжение? (( Еще интересен разбор примеров. Можно например взять мой сайт на опенкарт и тяжелый запрос.))) буду очень рад)

  • @cosmo_polit
    @cosmo_polit 2 года назад

    спасибо

  • @telychkomykola
    @telychkomykola 5 лет назад +2

    Отлично, спасибо

  • @vitaliihanzha5930
    @vitaliihanzha5930 3 года назад +3

    Все бы было хорошо, да вот только размер сектора диска испокон веков был 512 байт. 8Кб - это, вероятнее всего, имелся ввиду размер кластера, а кластер - это понятие файловой системы, и его размер может задаваться при форматировании.

    • @vladymyrkuznietsov8815
      @vladymyrkuznietsov8815 3 года назад +1

      512 - это минимальный размер, который может диск адресовать физически. physical_block_size, а есть logical_block_size - это обычно 4k, но тру DBA выбирают (ну ок, сейчас на это не заморачиваются обычно) 8k, но согласен, точнее было бы говорить блок или кластер :)

  • @alexxx4434
    @alexxx4434 5 лет назад +1

    Ждем продолжения )

  • @sergey5565
    @sergey5565 5 лет назад +2

    Вся серия скринкастов по книге Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. Прям даже порядок тем и примеры один в один. Не скажу, что это плохо, но если хотите больше информации, то крайне советую книгу. Автор рассказал лишь первые 10% книги.

    • @vladymyrkuznietsov8815
      @vladymyrkuznietsov8815 5 лет назад +2

      Год я ждал этого каммента! И вот, хотя и под роликом, который отошел от нее довольно далеко... Тут все же больше Оракловые доки в основе. Но "книжка с кабанчиком" - это наше все :)

    • @sergey5565
      @sergey5565 5 лет назад +1

      @@vladymyrkuznietsov8815 Рад, что закрыл ваш гештальт с комментом :) Было бы здорово посмотреть скринксты по темам из оставшейся части книги с добавлением информации из личного опыта. Такой формат легче усваивается, чем чтение книги.

    • @vladymyrkuznietsov8815
      @vladymyrkuznietsov8815 5 лет назад +1

      @@sergey5565 Сейчас вот над транзакциями потею, там надо примеров много придумать, да и феномены четче прописать, думаю намиксовать с букварем от Vlad Mihalcea... Имхо репликацию надо давать после транзакций...

  • @drovoseg
    @drovoseg 5 лет назад +2

    В MyIsam ускорена производительность за счет отсутствия журнала. Но как-то получилась у нас забавная ситуация когда огромная таблица испортилась и восстановить ее не получилось.

  • @zhuch9277
    @zhuch9277 5 лет назад

    Спасибо)

  • @ПетроПташинський-ь6й

    а можете сказать был ли Владимир на wcs spring в киеве? уж больно лицо знакомо, мне кажется я его видел в кибер арене

    • @vladymyrkuznietsov8815
      @vladymyrkuznietsov8815 5 лет назад

      Если посмотреть на правую руку Владимира, на которой "проходки" висят, например тут: ruclips.net/video/TQAzmpdwJGA/видео.html, то можно предположить, что его и на отборочных WESG можно встретить... Ну и в Катовице, чего уж там :)

  • @НаильШакиров-х2я
    @НаильШакиров-х2я 5 лет назад +1

    У вас формулы по оценке высоты не точные. Нужно брать логарифм по основанию [m/2]. Ив определении B-дерева, у вас не сказано,что корневой узел имеет как минимум два потомка. Это по Кнуту

    • @vladymyrkuznietsov8815
      @vladymyrkuznietsov8815 5 лет назад

      угу, вставки я поленился вычитать, и напрасно :(

  • @ekaterynaberkhmiller8979
    @ekaterynaberkhmiller8979 4 года назад +2

    Очень здорово! А где продолжение?)

    • @SergeyNemchinskiy
      @SergeyNemchinskiy 4 года назад

      как это? ruclips.net/p/PLmqFxxywkatS8Hfj6-aYgXfrpvV6OoKSc

    • @ekaterynaberkhmiller8979
      @ekaterynaberkhmiller8979 4 года назад +1

      Спасибо, я посмотрела весь плейлист )В конце видео Владимир обещал рассказать о более экзотических способах хранения данных(столбцы, кубы). Дальше планируете продолжить эту серию классных уроков?)

    • @vladymyrkuznietsov8815
      @vladymyrkuznietsov8815 4 года назад +2

      @@ekaterynaberkhmiller8979 Да, столбцы надо будет осветить... Но пока надо добить транзакции...

    • @Hare-Code
      @Hare-Code 4 года назад

      @@vladymyrkuznietsov8815 ну очень ждём!

  • @TeuFortMan
    @TeuFortMan 2 года назад

    У древних дисков сектора разве не 512байт были?

  • @MrCter
    @MrCter 5 лет назад +1

    Так это и был clustered index. На жёстких дисках эти блоки тоже ведь кластерами зовутся?

    • @vladymyrkuznietsov8815
      @vladymyrkuznietsov8815 5 лет назад

      Нет-нет-нет, clustered index это совсем другое: он может быть один на таблицу, и идея в том, что записи(rows) записываются упорядочено по ключу. В результате запись медленная, но чтение, особенно если читаются все поля записи, очень быстрое.

    • @MrCter
      @MrCter 5 лет назад +1

      @@vladymyrkuznietsov8815 хм, ок буду копать дальше. Владимир, а Вы можете выделить в отдельное видео тему о классификации индексов по разным критериям. Простой-составной; кластеред-нонкластеред, етк... Спасибо заранее )

    • @DimaVort
      @DimaVort 4 года назад

      Кластер индекс это кодга несколько колонок обьединены одним индексом поиска. Причем в строгой последовательности. Например в индекс заисан ключ "склад+товар+партия". И если мы хотим найти записи по товару не зная склад, индекс перестает работать и таблица сканируется полностью. Но если мы знаем склад и товар, но не знаем партию то записи выбираются по индексу.

  • @user-r1g5i
    @user-r1g5i 3 года назад

    Оператору: en.wikipedia.org/wiki/30-degree_rule

  • @itaccount1993
    @itaccount1993 2 месяца назад

    03:00 - диск считает данные секторами (8кб)

  • @Elmirill
    @Elmirill 2 года назад

    А вот музыка на фоне явно лишняя. Если кому-то она нужна, каждый сам поставит себе по вкусу.

  • @vlera4198
    @vlera4198 3 года назад

    не объяснил почему не стоит делать много индексов (или можно?). Кому интересно про Б дерево наберите b-tree visualisation - наглядно можно посмотреть как заполняется дерево www.cs.usfca.edu/~galles/visualization/BTree.html

  • @ГеоргийСвиридов-м2щ

    Слушайте, так невозможно камеру качают из строны в сторону, то приближают то удаляют.
    Ребяты ЗАЧЕМ ВЫ ЭТО ДЕЛАЕТЕ ? Мы не на дискотеке и т.п. !

    • @vladymyrkuznietsov8815
      @vladymyrkuznietsov8815 5 лет назад +1

      Проверка на фокус-группе показала, что если этого не делать, то зритель засыпает в среднем через 3 минуты :)

    • @ГеоргийСвиридов-м2щ
      @ГеоргийСвиридов-м2щ 5 лет назад

      @@vladymyrkuznietsov8815 И в правду не заснешь.... после такого говолокружительного показа...
      Дело конечно Ваше, мне данный ролик запомнился постоянной колбасней камеры, а не содержимым !
      Кому не интересно и так уснет. постоянный перемещения отнимают внимание, внимание это силы.
      Когда в рот смотришь начинаешь засыпать...
      Мое предложение сосредоточить внимание на информации в схемах, диаграммах и т.п. а не на перемещении от лица на диаграммы и обратно. В рот смотреть интересно, но по факту вся информация на листе бумаги... Дальще решать Вам.

    • @ГеоргийСвиридов-м2щ
      @ГеоргийСвиридов-м2щ 5 лет назад

      Да спасибо за юмор, вот он точно в тему и не дает заснуть !

  • @ГеоргийСвиридов-м2щ

    Оператора колбасит...

  • @tvoidrug2902
    @tvoidrug2902 4 года назад +2

    Слишком много воды