AS
но считайте что для каждого блока который надо дедупить надо килобайт памяти.
Size: a a a
2020 November 30
PН
про эту же тему в соседнем чате =)
Дедупликация файлов - это не то что мне нужно. Меня интересует дедупликация блоков данных. Условно, что бы 2 одинаковых png картинки, одна из которых имеет битый пиксель, они занимали место как 1 картинка и уточнение для второй картинки, с данными о изменённом пикселе
AS
Дедупликация файлов - это не то что мне нужно. Меня интересует дедупликация блоков данных. Условно, что бы 2 одинаковых png картинки, одна из которых имеет битый пиксель, они занимали место как 1 картинка и уточнение для второй картинки, с данными о изменённом пикселе
таких алгоритмов на рынке нет. это фантазия
AS
даже если бы они были они требовали бы ну просто бездну памяти.
PН
даже если бы они были они требовали бы ну просто бездну памяти.
Почему?
AS
потому что потербовали бы таблицу блоков, таблицу патчей
AS
и поиск по этому был бы..... ну прямо скажем адовый.
PН
и поиск по этому был бы..... ну прямо скажем адовый.
Почему?
EN
Дедупликация файлов - это не то что мне нужно. Меня интересует дедупликация блоков данных. Условно, что бы 2 одинаковых png картинки, одна из которых имеет битый пиксель, они занимали место как 1 картинка и уточнение для второй картинки, с данными о изменённом пикселе
сейчас имхо максимум на уровне блочных устройство можно. ну может у вендоров железных есть решения специализированные. конечно за отдельные деньги
AS
ну и в 2020 году диски стоят на много меньше чем стоит проц который нужен был бы для применения таблицы патчей и памяти необходимой для храннеия обоих структур
AS
впрочем я вполне допускаю спеицализированное решение которое сделает вендор за какую нить сумму денег.
AS
но там решение было бы от 9 нулей
EN
я помню про хп семинар какой-то. стор-уанс типа того что-то. вроде софт, но можно и в железе. точнее наоборот.
AS
я помню про хп семинар какой-то. стор-уанс типа того что-то. вроде софт, но можно и в железе. точнее наоборот.
там как раз блочное с размером блока от мега
EN
ну это для прикидки что к чему на этом поле
AS
Почему?
потому что на операцию записи вам бы потребовалось
1. найти блок в таблице блоков
2. сформировать патч
3. сохранить патч в памяти или на диске в таблице метаданных
4. потенциально потебовался gabarge collector который бы сливал распухшие дифы. и его реализация была бы не тривиальной ибо запись одного файла могла потенциально перестроить половину файловой системы. в результате каскада мержей
запрос на чтение бы потребовал
1. постоянного random read ибо данные в результате дедпубликации лежали бы в разных областях диска
2. примение всех патчей которые нужны для чтения файла
1. найти блок в таблице блоков
2. сформировать патч
3. сохранить патч в памяти или на диске в таблице метаданных
4. потенциально потебовался gabarge collector который бы сливал распухшие дифы. и его реализация была бы не тривиальной ибо запись одного файла могла потенциально перестроить половину файловой системы. в результате каскада мержей
запрос на чтение бы потребовал
1. постоянного random read ибо данные в результате дедпубликации лежали бы в разных областях диска
2. примение всех патчей которые нужны для чтения файла
AS
тоесть в этом случае мы бы купили капасити диска за памяти и проц и iops.
AS
наверное это одно из самых не выгодных приобретений
AS
спасибо за милую умозрительную конструкцию
PН
потому что на операцию записи вам бы потребовалось
1. найти блок в таблице блоков
2. сформировать патч
3. сохранить патч в памяти или на диске в таблице метаданных
4. потенциально потебовался gabarge collector который бы сливал распухшие дифы. и его реализация была бы не тривиальной ибо запись одного файла могла потенциально перестроить половину файловой системы. в результате каскада мержей
запрос на чтение бы потребовал
1. постоянного random read ибо данные в результате дедпубликации лежали бы в разных областях диска
2. примение всех патчей которые нужны для чтения файла
1. найти блок в таблице блоков
2. сформировать патч
3. сохранить патч в памяти или на диске в таблице метаданных
4. потенциально потебовался gabarge collector который бы сливал распухшие дифы. и его реализация была бы не тривиальной ибо запись одного файла могла потенциально перестроить половину файловой системы. в результате каскада мержей
запрос на чтение бы потребовал
1. постоянного random read ибо данные в результате дедпубликации лежали бы в разных областях диска
2. примение всех патчей которые нужны для чтения файла
Тут вопрос в архитектуре. Например, можно при записи файла просто вычислять перцептивный хэш и индексировать его.
Тогда запись выглядела бы так:
- Вычислить хэш файла
- Поискать в списке индексов самый близкий хэш
- Если найден достаточно близкий, посчитать разницу
- Если целесобразно - записать на диск только патч
Тогда запись выглядела бы так:
- Вычислить хэш файла
- Поискать в списке индексов самый близкий хэш
- Если найден достаточно близкий, посчитать разницу
- Если целесобразно - записать на диск только патч