Smr система что это
CRM системы: что это? Простыми словами
Где вы храните клиентов? На бумажке, в телефоне, в ежедневнике, в экселе? Или вам в который раз предлагают CRM систему, но у вас нет полного понимания, что это такое и как это работает.
Эта информация не для программистов, айтишников и т.д. Она для владельцев бизнеса, которые хотят понять, что такое CRM система. Не читать про выгоды, пользу, кому она нужна и что это дает, а прежде всего ПОНЯТЬ. Большинство информации на эту тему написано очень умным языком. Даже простые статьи написаны так, как будто люди боятся показаться не профессионалами. И прошу меня простить, если кому-то покажется, что я написал все это слишком простым языком. Я хочу, чтобы вы поняли и разобрались в этом, так как разбираетесь в своем бизнесе, а не считали меня экспертом.
Поэтому давайте разберем CRM систему на части. К чему CRM система относится в бизнесе? Продажи. Что нам нужно для продаж? Клиенты. Поэтому первые две самые важные вещи которые должны у нас быть, и они есть в любой CRM системе, это клиенты и продажи.
Итак. Клиенты. Где вы храните клиентов? На бумажке, в телефоне, в ежедневнике, в экселе?
Вы и сами можете подтвердить что все эти варианты не удобны тем, что:
Решение отличное. Но есть недостаток. Скорость!
Что у нас есть в картотеке? Куча карточек чего-либо. В нашем случае клиентов.
Вот и мы заведем на каждого клиента карточку, как в картотеке. В этой карточке у нас будет храниться вся информация на клиента. Зашли в карточку, и все как на ладони.
Какую информацию будем хранить?
Ту, что нам нужна для того, чтобы успешно продавать и принимать верные решения. Такую информацию по клиенту можно разбить на две части.
Как ее будем хранить?
Согласитесь, что в любой системе должен быть порядок, а иначе это уже не система.
Как мы бы это сделали в картотеке? В самом простом варианте у нас бы были одинаковые для всех клиентов и карточек поля: телефон, почта и т.д. В такие поля мы легко можем поместить информацию по типу 1.
А что делать со всей информацией, которая связана с взаимодействиями с клиентом? У нее есть одна особенность. Она зависит от времени. Вот и расположим ее в зависимости от времени, чтобы вначале видеть самую свежую информацию, а потом более позднюю.
В итоге, мы имеем карточку клиента, где хранится вся основная информация о клиенте. Она расположена в полях. На картинке внизу эти поля слева. Вся информация о взаимодействии с клиентом расположена в зависимости от времени. На картинке внизу это справа.
Осталось решить еще один момент. Клиентов-то у нас не один, а много. Как будем их всех размещать? В картотеке все карточки расположены просто по алфавиту. В нашем же случае ничего лучше списка пока не было придумано.
Делаем простой список клиентов. Сколько клиентов в списке нам без разницы. Потому что нужного или нужных нам клиентов мы найдем с помощью поиска или с помощью фильтра.
А если вы зайдете в любую CRM систему, вы это и увидите. Список клиентов, и у каждого клиента карточка с информаций о нем, а также поиск с фильтром.
Таким образом, у нас и получилась первая из основных частей CRM системы. На самом деле некоторым и этого достаточно. Клиентов уже легко искать и информация не теряется.
Но кому-то этого не хватает. Поэтому пойдем дальше. Мы же хотим видеть, что мы клиенту продавали!
Что будем делать с информацией о продажах?
Мы можем указывать всю информацию о продажах прямо в карточке клиента. Однако возникает несколько неудобств:
Если мы рассмотрим информацию о любой продаже, то как и в случае с клиентом мы сможем ее разбить на две части:
Тогда есть простое решение. Если клиент и продажа так схожи, то давайте для продажи сделаем такую же карточку как и для клиента. Сделаем список всех продаж, как и клиентов, в котором будет легко найти нужную.
Но у продажи и клиента все же есть важное различие. Продажа, в отличии от клиента, это процесс. И как у любого процесса, у нее есть этапы. Т.е. продажа может начинаться – мы вступили в контакт с клиентом, и может завершаться – мы совершили продажу, либо нет. Между началом и концом есть еще и свои этапы.
Например, сначала продавец общается с клиентом по телефону, потом встречается, потом делает ему коммерческое предложение, потом выставляет счет и получает оплату. У каждого бизнеса своя специфика и свои этапы. Но они есть всегда. Просто потому, что у любого процесса они есть. Даже если вы просто захотите выйти из дома, вам сначала нужно одеться, открыть дверь, потом выйти. Уже как минимум три этапа.
Причем не обязательно, что при переходе от первого этапа до последнего придется проходить обязательно по каждому этапу. Вы можете и без одежды выйти на улицу. В продажах, если вам позвонил клиент и сказал: “я хочу купить”, и он знает конкретно, что хочет купить, вы же не будете настаивать на том, чтобы скинуть ему коммерческое предложение. Вы ему выставляете счет. И фактически вы продаете ему без этапа коммерческое предложение. Вы его перепрыгиваете. В этом нет ничего плохого.
Что будем делать с информацией по этапам?
Остается только одно: связать продажи и клиентов.
Есть у нас список клиентов и список продаж с карточками. Но пока они у нас не связанны.
По сути в этом ничего сложного. Например, когда вы заходите в контакт или фейсбук, вы можете зайти в список всех друзей и из всех пользователей социальной сети увидеть только своих друзей. Т.е. по сути увидеть только тех, кто связаны “дружбой” с вами. Так и здесь.
Сделаем так, что в карточке клиента будет раздел, куда мы можем зайти и увидеть список всех продаж этого клиента и оттуда сможем открыть карточки этих продаж. То же самое сделаем в карточке продажи, чтобы легко было попасть в карточку клиента. Получается, что теперь у нас клиенты и продажи связанны.
Именно это вы и увидите при входе в любую CRM систему:
Для этого введем новое понятие. Сущность – это различимый объект; объект, который мы можем отличить от другого. В нашей системе мы будем под сущностью понимать некий объект, который каким-либо образом отображается (например в виде карточки), имеет свои поля ввода (например у клиента – телефон, почта, город; у сделки – сумма) и имеет связи (в нашем случае, например, у клиента есть связи с продажами).
Т.е. клиент и продажа это отдельные сущности. И они связанны друг с другом связями как на картинке. Одному клиенту может быть совершено несколько продаж;
Для того, чтобы полноценно работать с клиентами, не хватает только одного.
Мы не редко забываем, что нужно кому-то позвонить, написать и т.д. Кто-то для этого использует ежедневник, кто-то будильник, а кто-то полагается на память.
Давайте добавим просто возможность ставить себе задачи. К счастью, с задачами всем все понятно. Вопрос только в том как они будут отображаться в системе.
Воспользуемся понятием сущности, которое мы ввели. Мы договорились, что под сущностью понимаем некий объект, который каким-либо образом отображается (в случае задачи, это может быть карточка, только не такая как у продажи и клиента), а имеет свои поля ввода (у задачи это срок выполнения, приоритет и т.д.) и имеет связи (задача связанна либо, с продажей либо с контактом).
Т.е. задача — это сущность со своими связями.
Куда поместим задачи в системе?
Во-первых, удобней всего, чтобы они были распложены списком как контакты и продажи.
Сделаем отдельный список, где отображаются все наши задачи, чтобы все их видеть и будем по порядку выполнять. А все они у нас связанны с клиентом либо с продажей. Поэтому мы через них легко попадаем в клиента или продажу.
И второй вопрос на который нам надо ответить: Где отображать задачи в карточке клиента?
Располагать их также как продажи не совсем удобно.
У задач есть одна особенность. Сами задачи тесно связаны с процессом общения с клиентом. Мы звоним, общаемся, после этого пишем комментарий, ставим задачу, посылаем письмо. Потом по задаче снова звоним или идем на встречу. Т.е. для них очень важно, когда задачи поставили и когда их надо выполнить.
Поэтому пусть задачи будут отображаться там же где комментарии и звонки. Там, где расположена вся информация о взаимодействии с клиентом в зависимости от времени.
Если вы зайдете практически в любую CRM систему, то это и увидите. Список задач и возможность ставить задачи в карточке продажи и карточке клиента. В итоге получаем карточку продажи, карточку клиента и задачи.
Мы получили базу клиентов, в которой хранится вся информация о них. И получили понимание кому что продается. И более того, за счет этапов продажи и задач мы эти продажи даже контролируем, т.е. управляем ими.
CRM – управление взаимоотношениями с клиентами. Управляем? Управляем.
По сути, это и есть основной функционал CRM системы. Но согласитесь, что ездить на “мерседес” гораздо комфортней, чем на “жигули”. Так давайте и нашу систему немного прокачаем. Добавим возможностей.
Клиентов и продаж нам может не хватать. Возьмем сразу пример посложней, чтобы понять насколько все просто.
Кроме клиентов у нас могут быть: поставщики, у которых мы берем товар, чтобы перепродать; логистические компании, с которыми мы можем работать для доставки груза; список самого товара, который мы продаем; документы связанные со всем этим – например, договора.
Вроде бы много всего. Но вспомним, что у нас есть – сущности и связи. Чтобы легко разобраться определим, что все это – поставщики, логистические компании, документы и товары — это новые сущности.
Согласитесь, что у каждого из них должен быть список и карточка. Список, чтобы легко найти нужного поставщика, товар и т.д. Карточка, чтобы там была вся информация о них. Этот вопрос закрыли. Тут ничего сложного.
Все, что нам осталось, это использовать наш второй инструмент – связи. И связать эти сущности друг с другом и с тем, что у нас уже есть – клиент, продажа, задача.
Связи зависят от бизнес-процессов. Рассмотрим вариант, когда мы покупаем товар у поставщика и перепродаем его клиенту.
С чем связан клиент?
По аналогии с продажами мы можем легко видеть в карточке клиента документы, которые с ним связаны.
С чем связана продажа?
С чем связан поставщик?
Правда в данном случае понятие “продажи” зашло за пределы просто получения денег. Тут продажа у нас заканчивается когда клиент получил продукт, который мы предоставляем. Но где она заканчивается мы решаем сами.
И вот насколько бы сложным все это не казалось в начале, из кирпичиков сущностей и связей мы и строим нашу систему. А как все это просто автоматизировать, так чтобы многие процессы происходили автоматически, я распишу в другой раз.
Хотя мы уже вышли за рамки CRM системы. Но это не проблема. Я хотел, чтобы вы поняли, что в любой системе нет ничего сложного.
А если вернуться к понятию CRM системы. Список контактов, список продаж со статусами и задачи — это и есть самый простой пример CRM системы. Что это может вам дать? Любой владелец бизнеса поймет это лучше чем продавец, который хочет ему продать. А все остальное — это моменты удобства, которые позволяют более эффективно осуществлять продажи.
В итоге все равно, система должна быть такой, какая нужна вам, а не такой, какой ее замыслили другие. Она должна автоматизировать ваши бизнес-процессы, а не становиться еще одной обузой.
SMR: понятно в теории, сложно на практике
Сегодня рост объема данных на человека растет в геометрической прогрессии, а компании, предлагающие решения для хранения этих данных, стремятся сделать все возможное, чтобы увеличить доступную емкость своих устройств. Технология черепичной магнитной записи Seagate SMR (Shingled Magnetic Recording) позволяет повысить плотность записи, за счет чего емкость диска увеличивается на 25%. Это возможно благодаря увеличению количества дорожек на каждой пластине и сокращению расстояния между ними. Дорожки размещаются друг над другом (как черепица на крыше), что позволяет записать больше данных, не увеличивая площади пластины. При записи новых данных дорожки частично накладываются друг на друга, или «усекаются». Ввиду того, что считывающий элемент на дисковой головке меньше записывающего, он может считывать данные даже с усеченной дорожки, не нарушая их целостности и достоверности.
Однако с технологией SMR связана следующая проблема: чтобы перезаписать или обновить информацию, необходимо переписать не только требуемый фрагмент, но и данные на последних дорожках. Из-за того, что записывающий элемент шире, он захватывает данные на граничащих дорожках, поэтому необходимо перезаписать и их. Таким образом, при изменении данных на нижней дорожке нужно скорректировать данные на ближайшей наложенной дорожке, потом на следующей, и так далее, пока не будет переписана вся пластина.
По этой причине дорожки SMR-диска объединены в небольшие группы, называемые лентами. Накладываются друг на друга, соответственно, только дорожки в пределах одной ленты. Благодаря такому группированию в случае обновления некоторых данных перезаписывать придется не всю пластину, а лишь ограниченное количество дорожек, что существенно упрощает и ускоряет процесс. Для каждого типа дисков разрабатывается своя архитектура ленты с учетом сферы его применения. Каждая линейка продуктов Seagate рассчитана на определенную сферу применения и конкретные условия работы, и технология SMR позволяет достичь при правильном использовании наилучших результатов.
Seagate SMR — это технология, позволяющая удовлетворить постоянно растущий спрос на дополнительную емкость. На сегодняшний день она активно совершенствуется и в сочетании с другими инновационными методами может быть использована для повышения плотности записи на жестких дисках следующих поколений.
Но прежде всего, необходимо разобраться в некоторых нюансах ее применения.
Выделяют три типа устройств, поддерживающих черепичную запись:
Автономные (Drive Managed)
Работа с этими устройствами не требует никаких изменений в программном обеспечении хоста. Вся логика записи/чтения организована самим устройством. Значит ли, что мы можем просто установить их и расслабиться? Нет.
Диски, в которых реализована Drive Managed технология записи, обычно обладают большим объемом write-back кэша (от 128МБ на диск). При этом последовательные запросы обрабатываются в режиме write-around. Основные сложности, c которыми сталкиваются разработчики устройств и СХД, основанных на данной технологии записи, следующие:
1. Размер кэша лимитирован и по мере его заполнения мы можем получить непредсказуемую производительность устройств.
2. Иногда возникают значительные уровни задержек при интенсивном сбросе кэша.
3. Определение последовательностей — далеко не всегда тривиальная задача, и в сложных случаях мы можем ожидать деградацию производительности.
Основным достоинством данного подхода является полная обратная совместимость устройств с существующими ОС и приложениями. Хорошо понимая вашу задачу, вы можете уже сейчас покупать Drive Managed устройства и получать преимущества от использования технологии. Дальше в статье вы увидите результаты тестирования подобных устройств и сможете определиться, насколько они вам подходят.
Управляемые хостом (Host Managed)
В данных устройствах используется набор расширений к ATA и SCSI для взаимодействия с дисками. Это устройство другого типа (14h), которое требует серьезных изменений во всем Storage Stack и несовместимо с классическими технологиями, то есть без специальной адаптации приложений и операционных систем вы не сможете использовать эти диски. Хост должен выполнять запись на устройства строго последовательно. При этом производительность устройств на 100% предсказуема. Но необходима корректность работы более высокоуровневого ПО для того, чтобы производительность подсистемы хранения была действительно предсказуемой.
Поддерживаемые хостом (Host Aware)
Это гибридные решения, объединяющие преимущества Device Managed и Host Managed технологий. Приобретая такие диски, мы получаем поддержку обратной совместимости с возможностью использования специальных расширений ATA и SCSI для оптимальной работы с SMR-устройствами. То есть мы можем, как просто выполнять запись на устройства, как делали это раньше, так и делать это наиболее оптимальным образом.
Для того, чтобы обеспечить работу с Host Managed и Host Aware устройствами, разрабатывается пара новых стандартов: ZBC и ZAC, которые входят в T10/T13. ZBC является расширение SCSI и ратифицируется T10. Стандарты разрабатываются для SMR дисков, но в будущем могут быть применены и для других устройств.
ZBC/ZAC определяют логическую модель устройств, где основным элементом является зона, которая отображается как диапазон LBA.
Стандарты задают три типа логических зон, на которые разбиты устройства:
1. Conventional zone — зона, с которой мы можем работать традиционным образом, как с обычными жесткими дисками. То есть, можем писать последовательно и случайно.
2. Два типа Write Pointer Zone:
2.1. Sequential write preferred — основной тип зон для Host Aware устройств, отдается предпочтение последовательной записи. Случайная запись на устройства обрабатывается как в Device Managed устройствах и может стать причиной потери производительности.
2.2. Sequential write only — основной тип зон для Host Manged устройств, возможна только последовательная запись. Случайная запись недопустима, при попытках её произвести будет возвращена ошибка.
Каждая зона обладает своим Write Pointer и своим статусом. Для всех устройств, поддерживающих HM тип записи, первый LBA следующей команды записи обязательно должен соответствовать положению Write Pointer. Для HA устройств Write Pointer является информационным и служит для оптимизации работы с диском.
Кроме новой логической структуры в стандартах появляются и новые команды:
REPORT_ZONES является основным методом, благодаря которому можно получить информацию о существующих зонах на устройстве и их статусе. Диск в ответ на эту команду сообщает о существующих зонах, их типах (Conventional, Sequential Write Required, Sequential Write Preferred), состоянии зон, размере, информацию о нахождении Write Pointer.
RESET_WRITE_POINTER является преемником команды TRIM для ZBC устройств. При ее вызове происходит стирание зоны и перемещение Write Pointer на начало зоны.
Для управления статусом зоны используются 3 опциональные команды:
OPEN_ZONE
CLOSE_ZONE
FINISH_ZONE
В VPD страницах появилась новая информация, включая максимальное количество открытых зон, обеспечивающее лучшую производительность и максимальное количество зон, доступных для случайной записи с лучшей производительностью.
Производителям СХД необходимо позаботиться о поддержке устройств HA/HM, внося изменения на всех уровнях стека: библиотеки, планировщики, RAID engine, логические тома, файловые системы.
Кроме того, нужно обеспечить два типа интерфейсов для работы приложений: традиционный интерфейс, организовав массив как device managed устройство, а также реализацию виртуального тома как HOST AWARE устройства. Это необходимо, так как ожидается появление приложений, работающих с HM/HA устройствами напрямую.
В общем виде алгоритм работы с HA устройствами выглядит следующим образом:
1. Определите конфигурацию устройства, использую REPORT_ZONES
2. Определите зоны для случайной записи
2.1. Количество ограничено возможностями устройства
2.2. В этих зонах нет необходимости отслеживать положение Write Pointer
3. Используйте остальные зоны для последовательной записи и используя информацию о положении Write-Pointer и выполняя только последовательную запись
4. Контролируйте количество открытых зон
5. Используйте сборку мусора для высвобождения пула зон
Некоторые техники записи можно применять из имеющихся all-flash СХД, для которых решались проблемы предстательной последовательной записи и сборки мусора.
Компания RAIDIX провела тестирование SMR дисков Seagate у себя в лаборатории и дает несколько рекомендаций по их использованию. Эти диски отличаются тем, что являются Device Managed и не требуют никаких серьезных изменений в работе приложений.
При тестировании была сделана попытка проверить ожидания производительности таких дисков и понять, для чего мы можем их использовать.
В тестах участвовали два диска Seagate Archive HDD объемом 8000GB.
Тестирование выполнялось на операционной системе Debian версии 8.1
CPU Intel i7 c частотой 2,67 MHz
16 GB RAM
Диски имеют интерфейс SATA 3, мы включили контроллер в режим AHCI.
Для начала мы приводим информацию об устройствах, выполнив Inquiry запрос.
Ничего особенного мы не увидели. Попытки прочитать информацию о зонах обернулись неудачей.
RAIDIX делает ПО для СХД, работающих в различных индустриях, и мы стремились не использовать специализированные или платные бенчмарки.
Начинаем с того, что проверяем потоковую производительность дисков на внутренних и внешних дорожках. Результаты тестов дадут максимальную ожидаемую производительность устройства и соответствуют в первую очередь таким задачам, как архивирование данных.
Настройки блочной подсистемы мы не трогали. Выполняем тестирование, записывая на диски данные блоками 1 мегабайт. Для этого мы используем бенчмарк fio v.2.1.11.
Джобы (Jobs) отличаются друг от друга только смещением от начала устройства и запускаются один за другим. В качестве библиотеки ввода-вывода выбрана libaio.
Результаты представляются неплохими:
Производительность на внешних и внутренних дорожках отличается практически в 2 раза.
Мы видим периодические провалы производительности. Они не критичны для архивирования, но могут стать проблемой для других задач. При корректной работе write-back кэша СХД мы предполагаем, что не будем наблюдать подобной ситуации. Мы провели схожий опыт, создав массив RAID 0 из обоих дисков, выделив 2ГБ RAM кэша на каждый диск, и не увидели провалов производительности.
При чтении провалов не видно. И последующие тесты покажут, что на операциях чтения SMR диски по производительности ничем не отличаются от обычных.
Теперь мы проведем более интересные тесты. Запустим 10 потоков c разными offset одновременно. Это мы делаем для того, чтобы проверить корректность буферизации и посмотреть, как диски будут работать на задачах CCTV, Video Ingest и подобных.
На графиках приведена суммарная производительность по всем работам:
Диск неплохо справился с нагрузкой!
Производительность держится на уровне 90 МБ/с, равномерно распределена по потокам, и не наблюдается серьезных провалов. График на чтение абсолютно аналогичен, только приподнят на 20 МБ. Для хранения и раздачи видеоконтента, обмена большими файлами производительность подходящая и практически не отличается от производительности обычных дисков.
Как и ожидалось, диски неплохо показали себя на операциях потоковых чтения и записи, а работа в несколько потоков стала для нас приятным сюрпризом.
Переходим к «случайным» чтению и записи. Посмотрим, как диски поведут себя в классических задачах предприятий: хранение файлов СУБД, виртуализация и пр. Кроме того, в «случайные» операции подпадают частая работа с метаданными и, например, включённая дедупликация на массиве.
Тестирование мы проводим блоками 16 килобайт и по-прежнему верны fio.
В тесте мы настроили несколько джобов с разной глубиной очереди, но полностью результаты приводить не будем. Показательно только начало теста.
Первые 70,5 секунд мы видим нереальные для жесткого диска 2500 IOps. При этом происходят частые провалы. Видимо, в этот момент происходит запись в буфер и его периодический сброс. Потом происходит резкое падение до 3 IOps, которые держатся до конца теста.
Если подождать несколько минут, то после того, как сбросится кэш, ситуация повторится.
Можно ожидать, что при наличии небольшого числа случайных операций диск будет вести себя неплохо. Но если мы ожидаем интенсивную нагрузку на устройство, лучше воздержаться от использования SMR дисков. RAIDIX рекомендует при возможности выносить всю работу с метаданными на внешние устройства.
А что же со случайным чтением?
В этом тесте мы ограничили время отклика 50 мс. Наши устройства справляются неплохо.
Чтение оказывается в промежутке 144-165 IOPs. Сами числа неплохи, но немного пугает разброс в 20 IOPs. Ориентируйтесь на нижнюю границу. Результат неплохой, на уровне классических дисков.
Несколько изменим подход. Давайте еще взглянем на работу с большим количеством файлов.
С этим нам поможет утилита frametest от SGI. Этот бенчмарк создан для проверки производительности СХД при выполнении монтажа несжатого видео. Каждый фрейм является отдельным файлом.
Мы создали файловую систему xfs и смонтировали ее со следующими параметрами:
-o noatime,nodiratime,logbufs=8,logbsize=256k,largeio,inode64,swalloc,allocsize=131072k,nobarrier
Запускаем frametest со следующими параметрами:
Бенчмарк создает 2000 файлов размером 8МБ.
Начало теста проходит неплохо:
Averaged details:
Open I/O Frame Data rate Frame rate
Last 1s: 0.028 ms 79.40 ms 79.43 ms 100.37 MB/s 12.6 fps
5s: 0.156 ms 83.37 ms 83.53 ms 95.44 MB/s 12.0 fps
Но после записи 1500 фреймов ситуация значительно ухудшается:
Averaged details:
Open I/O Frame Data rate Frame rate
Last 1s: 0.035 ms 121.88 ms 121.92 ms 65.39 MB/s 8.2 fps
5s: 0.036 ms 120.78 ms 120.83 ms 65.98 MB/s 8.3 fps
Averaged details:
Open I/O Frame Data rate Frame rate
Last 1s: 0.036 ms 438.90 ms 438.94 ms 18.16 MB/s 2.3 fps
5s: 0.035 ms 393.50 ms 393.55 ms 20.26 MB/s 2.5 fps
Проведем тест на чтение:
В течение всего теста производительность отличная:
Averaged details:
Last 1s: 0.004 ms 41.09 ms 41.10 ms 193.98 MB/s 24.3 fps
5s: 0.004 ms 41.09 ms 41.10 ms 193.98 MB/s 24.3 fps
Сейчас ведется работа над специализированными файловыми системами для SMR дисков.
Seagate разрабатывает основанную на ext4 SMR_FS-EXT4. Можно обнаружить несколько log-structured файловых систем, спроектированных специально для Device Managed SMR дисков, но ни одну из них нельзя назвать зрелым, рекомендуемым к внедрению продуктом. Также Seagate ведется разработка поддерживаемой хостом (Host Aware) версии SMR диска, которая должна быть завершена до конца года.
Какие мы можем сделать выводы по результатам замеров производительности?
Device Managed устройства можно смело использовать для задач, не отличающихся интенсивной записью. Они очень неплохо справляются с задачами однопоточной и многопоточной записи. Для чтения данных они подходят отлично. Периодические “случайные” запросы к дискам при обновлении метаданных поглощаются большим кэшем.
Для решения задач, отличающихся интенсивной “случайной” записью или обновлением большого количества файлов такие устройства не очень подходят, как минимум, без использования дополнительных технических средств.
Параметр MTBF протестированных дисков составляет 800 000 часов, что в 1,5 раза ниже, чем у, например, NAS-дисков. Большой объем дисков значительно увеличивает время восстановления и делает практически невозможным регулярный media-скан. Мы рекомендуем при проектировании хранилища с такими дисками полагаться на RAID с количеством parity, большим чем 2 и/или подходах позволяющих сократить время восстановления (Например, Parity Declustering).