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

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

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

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

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

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

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

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

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

Спасибо)

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

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

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

спасибо

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

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

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

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

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

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

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

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

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

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

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

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

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

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