Хорошо известно, что стирающее кодирование добавляет дополнительную сложность из-за операций кодирования и декодирования. Из-за этого недостатка большинство облачных сервисов рекомендуют использовать репликацию данных для горячие данные и кодирование стирания для холодные данные.
Например, из документации Ceph:
Набор правил уничтожения пула с кодом стирания предназначен для оборудования, предназначенного для холодного хранения с высокой задержкой и медленным временем доступа. Набор правил разбиения реплицированного пула нацелен на более быстрое оборудование для обеспечения лучшего времени отклика.
Есть ли лучшее определение горячих данных, чем «данные, к которым обращаются чаще, чем к другим»?
Давайте рассмотрим систему хранения, основанную на кодировании стирания, и приложение, которое на ней работает, что определяется интенсивной рабочей нагрузкой ввода-вывода. Считаются ли это горячими данными?
Теперь, как я могу сказать, жизнеспособен код стирания моей системы хранения или нет? Уместно ли измерять количество операций ввода-вывода в секунду со стороны приложения для некоторых конкретных тестов (например, случайное / последовательное чтение / запись)?
Есть ли порог, который говорит, что коды стирания неприменимы для горячих данных, потому что я записываю только (например) сто операций ввода-вывода в секунду на стороне приложения для операции случайной записи блоков 4 КБ? Что, если я запишу сто миллиардов операций ввода-вывода в секунду?
Актуальны ли IOPS для такого рода тестов (может быть, другой показатель сказал бы больше)?
У меня полно вопросов по этому поводу и буду благодарен за любую помощь.
Чтобы сделать стирание доступным для горячих данных, вы должны подумать о кодировании стирания, которое отлично работает с размером блока данных, который соответствует тому, который используется файловой системой (обычно 4K). Однако этого недостаточно, мы также должны подумать об архитектуре вашей файловой системы и, в частности, о потенциальном влиянии, которое она может оказать на метаданные (обычно где находятся серверы, на которых были сохранены каждый блок и т. Д.).
Таким образом, чтобы построить файловую систему, использующую кодирование стирания, нам, скорее, нужно подумать о построении файловой системы на основе кодирования стирания, а не просто добавлять кодирование стирания в существующую файловую систему.
Одним из общих недостатков кодирования со стиранием было время ЦП, и большая часть реализаций на основе Рида-Соломона использовала большой размер блока, чтобы компенсировать проблему пропускной способности. По этой причине большинство из них нацелены только на архивирование.
Однако есть альтернатива, позволяющая заставить его работать с небольшим блоком данных (4K). В нашем горизонтально масштабируемом продукте NAS (RozoFS) мы используем другой алгоритм кодирования со стиранием (геометрический или алгебраический для случая Рида-Соломона), который имеет преимущество в обеспечении быстрого кодирования / декодирования при небольшом размере блока данных (более 10 ГБ / s на Intel I7 @ 2 ГГц).
Скорость кодирования / декодирования, связанная с тем фактом, что он работает с размером блока в диапазоне файловой системы, позволяет избежать штрафа за дополнительное чтение при произвольных запросах записи. И, кстати, мы можем обратиться к случаю живых данных и, в частности, к случаю случайного ввода-вывода при небольшом размере блока данных.
В вашем интересе подробности с точки зрения производительности. У нас есть веб-сайт, на котором мы разместили тест, который мы сделали, Iozone (тесты с последовательным и произвольным доступом). (rozofs.com - раздел блога)).