нибудь важны и фотка сегодняшнего обеда не должна быть повторена завтра или не дай бог платье совпало с подружкиным? В том же пг есть несколько механизмов работы с raw данными - bytea ,largeobject. В других БД и того круче типа Filestream и FileTable. Бекап централизован, не надо обмазываться всякими rsync и прочими bash скриптами. Зато репликация и прочие вкусняшки прям из коробки . Перфоманс обмазать кешем для блобов и заниматься лишь его инвалидацией если из коробки не идет.
Ни фига не понял :-( Ceph - это "сторадж объектов" (как они себя называют), а по сути, сторадж blob-ов. Т.е. позволяет залить блоб по выбранному тобой имени, и скачать блоб по этому имени. Без erasure-coding можно произвольно переписывать содержимое блоба, с erasure-coding вроде только аппендить. Проверки уникальности нет. Все равно придется где-то имена блобов хранить, так там же сохрани и sha-256 от содержимого,и повесь уникальный индекс. Бэкап 1 петабайта.... Я бы с удовольствием посмотрел на это. Потому и выбирался erasure coding, чтобы можно было переживать смерть нескольких машин без смерти кластера целиком, при этом имея replication factor меньше двух. "Перформанс обмазан кэшем" - я как бы сразу сказал, что кэш нужен в стороне. Вообще, у ceph есть возможность организовать прозрачно многослойное хранение, с слоем из реплицированного неймспейса с быстрыми дисками спереди, и erasure coding с емкими дисками сзади. В этом случае, заливка идет вначале в быстрый слой, и прочитанные обьекты тоже поднимаются в быстрый слой, а старые обьекты из быстрого переносятся в емкий. Мы этим не пользовались, т.к. у нас был уже готовый кэш. Я думаю, что современный nginx с proxy-cache спокойно справится с задачей кэширования. А на уровне отдельной тачки работает кэш операционной системы. Думаю, делает он это не намного хуже, чем shared_buffers постгресса. (по сети гуляет мнение, что даже лучше. Я с этим мнением не вполне согласен)
Обсуждают сегодня