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