Вы захотите использовать RiakBucket::newBinary()
и RiakBucket::getBinary()
, если хотите хранить некодированные двоичные данные в Riak с помощью PHP-клиента.
$image = file_get_contents("images/TagLabs-Logo-White-240x60.png");
$md5 = md5($image);
$riak->bucket("test")
->newObject("image_base64", base64_encode($image))
->store();
$riak->bucket("test")
->newBinary("image_raw", $image, 'image/png')
->store();
$b64Read = $riak->bucket("test")->get("image_base64");
echo "B64 md5 comparison: original=$md5, b64=".md5(base64_decode($b64Read->getData()))."\n";
$rawRead = $riak->bucket("test")->getBinary("image_raw");
echo "Raw md5 comparison: original=$md5, raw=".md5($rawRead->getData())."\n";
Производит продукцию:
B64 md5 comparison: original=6749cfaf1516b01db9792e119d53177a, b64=6749cfaf1516b01db9792e119d53177a
Raw md5 comparison: original=6749cfaf1516b01db9792e119d53177a, raw=6749cfaf1516b01db9792e119d53177a
В моих тестах производительности оба подхода имеют в основном одинаковые издержки с точки зрения Риака. Циклы затрат на кодирование / декодирование base64 (плюс под капотом данные base64 затем кодируются / декодируются в формате json), в целом бинарный подход впереди.
Редактировать: Также обратите внимание, что существует верхний предел ~ 50 МБ для данных, хранящихся в двоичном объекте Riak (см. в этом посте ) из-за ограничения в бэкэнде Erlang. Реально, если вы приближаетесь к этому, вам может понадобиться переосмыслить, как вы храните эти изображения, это много данных для отправки по каналу, если вы обращаетесь к ним часто, что-то вроде NFS или другого локального кэша файловой системы. вероятно, лучшая идея.