Как стать автором
Обновить

Как мы создаём почтовую систему нового поколения Mailion. Эффективное объектное хранилище для электронной почты

Блог компании МойОфис Хранение данных *Сжатие данных *Хранилища данных *
Всего голосов 15: ↑15 и ↓0 +15
Просмотры 4K
Комментарии 10

Комментарии 10

В разделе Отказоустойчивость вы описываете:
Если сегмент существует в единственном экземпляре, то что произойдёт в случае его потери? Если диск, на котором хранится популярный сегмент выйдет из строя, будет ли это означать невозможность чтения всех ссылающихся на него версий? ...

А почему не RAID6?

Насчет дедупликации, довольно сложный алгоритм со слабым звеном — индекс.
Если индекс «слетит», то все ваши данные потеряют связи и станут orphans.
Потеряются данные и восстановить, судя по алгоритму, никак.
Или я ошибаюсь?
Отказоустойчивость хранения данных в системе должна обеспечиваться на разных уровнях. Система должна переживать потерю диска, контроллера, сервера, стойки, машинного зала, дата-центра (в зависимости от требований заказчика). Действительно, как и в RAID6, в нашем алгоритме отказоустойчивого хранения данных используются коды коррекции ошибок. Однако RAID6 решает проблему лишь на уровне потери диска в массиве, но не решает её на других уровнях. Кроме того, RAID6 имеет ограничения по масштабированию. Чем больше диски, тем дольше rebuild time и тем выше шансы, что disk scrubbing (фоновая процедура исправления ошибок) не успеет обнаружить возможные ошибки дисков. Наш подход более гибкий и потенциально позволяет обеспечивать гарантии отказоустойчивости данных и на других уровнях.

Что касается метаданных (индексов), то их отказоустойчивое хранение реализовано с помощью других алгоритмов. Мы обязательно вернёмся к этим темам в статьях, посвящённых горизонтальному масштабированию Dispersed Object Store.
А письма по 500К — это какой-то реальный кейс из вашей практики? Это же очень-очень много текста
Для генерации тестового сета мы опирались на статистику, которую нам предоставили некоторые из заказчиков. В корпоративной среде электронные письма действительно могут быть очень большими.

Цитирования с перечислением адресатов превращают даже простые сообщения в письма огромных размеров, особенно когда к переписке подключают новых людей.

Ещё один частый случай — это письма, формируемые в результате коллаборативной работы над документами. Зачастую они содержат как оргинал текста, так и его редакцию. Например, письма с diff'ами, рассылаемые Confluence при редактировании крупных документов, легко могут достигать нескольких сотен килобайт форматированного текста.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, это опечатка. Имелась в виду компания CloudMouse. Поправили.
НЛО прилетело и опубликовало эту надпись здесь

Довольно неплохо разобран типовой отказ Ceph тут


Основная проблема Ceph – плохая прогнозируемость эксплуатации. Строить коммерческие системы на нем можно, точно понимая что делать во время отказа и имея в запасе инженерную команду, способную эти проблемы чинить на уровне кода.
Это совсем другая модель и компаниям, которые не занимаются разработкой системного ПО такой подход не годится.

НЛО прилетело и опубликовало эту надпись здесь
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.