Да, Вы правы, хотел рассказать для чего это нужно и как этим пользуются в обоих случаях и, в целом, рассказать про эту концепцию. WAL или там всякие подобные логи это не только про индексы, концепция "сначала пишем в логи - потом пишем в " это прям через все айти идет. На примере индексов это, мне кажется, просто наиболее понятно
Все-таки как хранятся данные в самом файле БД? Неотсортированными? И еще, после уплотнения нам ведь нужно обновить ссылки, которые лежат в индексах, так? Как это происходит?
После уплотнения у нас остается одна наиболее релевантная ссылка. Процесс уплотнения это что-то вроде гарбэдж коллектора (если прям совсем просто), то есть мы просто избавляемся от ненужных данных, которые у нас все еще хранятся
@@gijduvon6379 Нет, новую нам не нужно создавать Смотрите, у нас сначала все идет в Memtable, как только она разрослась до слишком больших размеров - все что лежит в ней флашится в виде файла SSTable на диск - этот файл становится последним сегментом в БД. Далее, когда к нам приходит запрос, мы ищем в мемтейбл, потом в последнем, потом в предпоследнем и тд. Так вот, иногда у нас получается так, что например в последнем сегменте лежит "qweasd": "1234", а в предпоследнем - "qweasd":"8697", то есть 8697 - устаревшие данные. Так вот, время от времени мы запускаем в фоне процесс уплотнения который объединяет сегменты засчет удаления устаревших и продублированных данных. Это если на уровне концепции. Если прям вот детальная реализация, то есть статья про то, как это реализовано например в касандре: www.diva-portal.org/smash/get/diva2:946772/FULLTEXT02.pdf Если вдруг ссылка не отображается (я просто не знаю какие правила отображения ссылок и где настраивать), то можно по запросу "Compaction strategies in Apache Cassandra" найти
@@SashkaProgrammiruet спасибо за развернутый ответ. Это да, понятно. Для меня не совсем ясным тут остаётся вопрос именно индексов для sstables. 1 - где они хранятся (ну тут по идее ответ должен быть простой - некий отдельный от сегмента файлик с записями в виде ключ значение, где ключ соответствует ключу в sstable, а значение - смещение в этом файле, при чем индекс разреженный) 2. И если так, то получается, что при compaction эти индексные файлы должны переписываться, удалятся или пересоздаваться, так как никуда не уйти от того, что смещения после сжатия становятся неактуальны.
Да обычную, по делу. Например, как происходит уплотнение сегментов? Записи выкидываются или объединяются или там битовая карта или ещё какой приём. С примерами, естественно.
Спасибо, хорошее видео. Про фильтры Блума было бы очень интересно посмотреть.
Расскажи про красно-чёрные деревья
Log для LSM и WAL для B-Tree это ведь по факту одно и тоже в том смысле, что все операции над деревом попадают в этот лог. Разницы нет
Да, Вы правы, хотел рассказать для чего это нужно и как этим пользуются в обоих случаях и, в целом, рассказать про эту концепцию.
WAL или там всякие подобные логи это не только про индексы, концепция "сначала пишем в логи - потом пишем в " это прям через все айти идет. На примере индексов это, мне кажется, просто наиболее понятно
Все-таки как хранятся данные в самом файле БД? Неотсортированными?
И еще, после уплотнения нам ведь нужно обновить ссылки, которые лежат в индексах, так? Как это происходит?
После уплотнения у нас остается одна наиболее релевантная ссылка. Процесс уплотнения это что-то вроде гарбэдж коллектора (если прям совсем просто), то есть мы просто избавляемся от ненужных данных, которые у нас все еще хранятся
@@SashkaProgrammiruet "остаётся" - это же значит, что мы удаляем старые и создаем новую?
@@gijduvon6379 Нет, новую нам не нужно создавать
Смотрите, у нас сначала все идет в Memtable, как только она разрослась до слишком больших размеров - все что лежит в ней флашится в виде файла SSTable на диск - этот файл становится последним сегментом в БД. Далее, когда к нам приходит запрос, мы ищем в мемтейбл, потом в последнем, потом в предпоследнем и тд.
Так вот, иногда у нас получается так, что например в последнем сегменте лежит "qweasd": "1234", а в предпоследнем - "qweasd":"8697", то есть 8697 - устаревшие данные. Так вот, время от времени мы запускаем в фоне процесс уплотнения который объединяет сегменты засчет удаления устаревших и продублированных данных.
Это если на уровне концепции. Если прям вот детальная реализация, то есть статья про то, как это реализовано например в касандре: www.diva-portal.org/smash/get/diva2:946772/FULLTEXT02.pdf
Если вдруг ссылка не отображается (я просто не знаю какие правила отображения ссылок и где настраивать), то можно по запросу "Compaction strategies in Apache Cassandra" найти
@@SashkaProgrammiruet спасибо за развернутый ответ. Это да, понятно. Для меня не совсем ясным тут остаётся вопрос именно индексов для sstables. 1 - где они хранятся (ну тут по идее ответ должен быть простой - некий отдельный от сегмента файлик с записями в виде ключ значение, где ключ соответствует ключу в sstable, а значение - смещение в этом файле, при чем индекс разреженный)
2. И если так, то получается, что при compaction эти индексные файлы должны переписываться, удалятся или пересоздаваться, так как никуда не уйти от того, что смещения после сжатия становятся неактуальны.
Очень тихо!
Очень плохой звук
Есть такой момент, в следующих видео научился в DaVinci корректировать его))
Никакой конкретики, к сожалению. Бесполезное видео
Какую конкретику Вы ожидали здесь услышать?
Да обычную, по делу. Например, как происходит уплотнение сегментов? Записи выкидываются или объединяются или там битовая карта или ещё какой приём. С примерами, естественно.