NetApp становится еще эффективнее с inline dedupe

[navion]

Для полного счастья им надо запилить дедупликацию на E-серии.

В памяти хранятся только хэш записанных недавно блоков — при перезагрузке хранилище будет очищено и статистика будет накапливаться заново.

Выходит, без постпроцессинга эффективность будет очень низкая (если не гнать один паттерн потоком)?

[exLH]

На E-серию — сильно сомневаюсь, там совсем другая архитектура.

Выходит, без постпроцессинга эффективность будет очень низкая (если не гнать один паттерн потоком)?

Никто не обещает чудесного решения на все случаи. Безусловно, эффективность зависит от профиля нагрузки на конкретный том. Если дедупликация эффективна только в долгосрочной перспективе, то лучше поспроцессинг. Инлайн, кроме того, позволяет разгрузить бэкенд, а это может стать большим плюсом.

[navion]

На E-серию — сильно сомневаюсь, там совсем другая архитектура.

У них ведь есть EF серия на той ОС, могут оттуда портировать дедупликацию.

[exLH]

EF серия (как и любая другая «E») не имеет к ONTAP никакого отношения, поэтому портировать что-либо туда (или обратно) достаточно проблематично.

[navion]

Я про портирование из EF на E. Разве в ней нет инлайн дедупликации, как во всех All-Flash массивах?

[exLH]

Нет, на EF нет ни дедупликации, ни компрессии. Эти системы ориентированы на тех, кому производительность важнее всего и их не перегружают «лишним» функционалом. Хотя, конечно можно сказать проще :) — их архитектура не подразумевает возможности легко добавить такие штуки.

[RolexStrider]

Oracle OLTP — что там за dataset-то такой?

[tmk826]

А как сказывается дедупликация на производительности и задержках?

[exLH]

Обещан CPU оверхед меньше 1%. А далее все зависит. На производительности (за счет разгрузки бэкенда) должно сказываться положительно. Как скажется на задержках, нужно мерить на конкретных задачах (тестов вендора я еще не встречал). Судя по тому, как реализован механизм, каких-то «проседаний» в латентности ждать не надо.