Недостатки хранения двоичных данных в Riak?

17

Каковы проблемы, если таковые имеются, хранения двоичных данных в Riak?

Оказывает ли это эффект на работоспособность и производительность кластеризации?

Каковы были бы различия в производительности между использованием Riak для этой, а не распределенной файловой системы?

    
задан mikeal 23.05.2011 в 22:57
источник

5 ответов

12

Добавляя к превосходному ответу Оскара-Годсона, вы, вероятно, столкнетесь с проблемами со значениями, которые намного превышают 50 МБ. Бит-бокс лучше всего подходит для значений, которые составляют до нескольких килобайт. Если вы храните большие значения, вы можете рассмотреть альтернативные серверы хранения, например innostore .

У меня нет опыта хранения двоичных значений, но у нас есть кластер среднего размера (5 узлов, порядка 100 М, 10 из TB), и мы видим частые ошибки, связанные с вставкой и извлекать значения, размер которых составляет 100 с. Производительность в этом случае несовместима - несколько раз она срабатывает, другие - нет, поэтому, если вы собираетесь протестировать, проверьте масштаб.

Мы также видим проблемы с большими значениями при запуске запросов с уменьшением размера - они просто теряют время. Однако это может быть менее актуальным для двоичных значений ... (как упоминал Мэтт-Ранни).

Также см. ответ @ Stephen-C здесь     

ответ дан Elad 23.05.2011 в 23:21
  • Привет, Бен - у вас не должно быть проблем с производительностью с объектами размером менее 1 мегабайта. Если вы хотите предоставить информацию о своем кластере в списке рассылки riak-users, один из нас Bashos может помочь диагностировать. Убедитесь, что вы настроили свою систему в соответствии с рекомендациями в документах. –  Luke Bakken 19.04.2016 в 17:57
6

Единственная проблема, о которой я могу думать, - хранить двоичные данные размером более 50 МБ, которые они советуют. Весь смысл Riak таков:

  

Еще одна причина, по которой можно было бы забрать Riak   для гибкости моделирования ваших данных.   Riak будет хранить любые данные, которые вы им сообщаете   в агностическом контексте - он делает   не применять таблицы, столбцы или   ссылочная целостность. Это значит, что ты   может хранить двоичные файлы прямо рядом   больше программно-прозрачных форматов   как JSON или XML.

Источник: Схема схемы в Riak - Введение

    
ответ дан Oscar Godson 23.05.2011 в 23:06
  • Обратите внимание, что проблема ~ 50 МБ вызвана жесткими ограничениями размера для сетевых распределенных буферов Erlang, а не чем-либо в Riak. –  seancribbs 24.05.2011 в 00:28
  • Есть ли причина, по которой его значение по умолчанию для Erlang? Просто «лучшая практика», или это вызывает проблемы с производительностью? –  Oscar Godson 24.05.2011 в 00:33
4

С Riak рекомендуемый максимум составляет 2 МБ на объект. Помимо этого рекомендуется использовать либо Riak CS, который был протестирован с объектами до 5 ТБ (хранится в Riak как объекты 1 МБ), либо естественным образом разбивает ваш большой объект на 2 Мбайт куски и связывает ключ и суффикс.     

ответ дан Richard Shaw 16.11.2013 в 03:05
3

Я лично не заметил никаких проблем с хранением данных, таких как изображения и документы (как DOC, так и PDF) в Riak. У меня нет номеров производительности, но я могу их запомнить.

Что-то примечание: с помощью Riak вы можете использовать Luwak , который предоставляет api для хранения больших файлов. Это было очень полезно.

    
ответ дан Nick Campbell 23.05.2011 в 23:17
  • ли luwak распространяется вместе с остальными данными в Riak? –  mikeal 23.05.2011 в 23:28
  • также, luwak подвергается через HTTP API? все, что я вижу, это API erlang. –  mikeal 23.05.2011 в 23:32
  • AFAIK Luwak - это всего лишь слой поверх Riak, он обрабатывает данные для вас. Все остальное - обычный бизнес для Riak. –  Nick Campbell 23.05.2011 в 23:33
  • Я использую Luwak через RiakJS, который поддерживается только (по крайней мере, в RiakJS) через HTTP API. –  Nick Campbell 23.05.2011 в 23:36
  • Luwak имеет HTTP API и распределяет данные по кластеру. wiki.basho.com/Luwak.html –  Matt Ranney 23.05.2011 в 23:58
1

Одна из проблем может заключаться в том, что сложно, если не невозможно, использовать карту JavaScript / сокращение по вашим двоичным данным. Для этого вам, вероятно, понадобится Эрланг.

    
ответ дан Matt Ranney 23.05.2011 в 23:18
  • в CouchDB существует отдельный API для хранения двоичных данных (вложений), специально предназначенных для обработки этого случая. только метаданные о вложениях позволяют отображать / уменьшать. –  mikeal 23.05.2011 в 23:27
  • Проверьте ссылки Riak. У вас может быть один объект - метаданные, подходящие для m / r, а затем добавьте ссылку на дополнительный двоичный объект. –  Matt Ranney 24.05.2011 в 00:00
  • Как ссылки могут связывать другой связанный объект с картой / уменьшать? –  mikeal 24.05.2011 в 00:22
  • Вы можете отфильтровать ссылки, которые вы включаете, на основе тегов - см. http://wiki.basho.com/Links-and-Link-Walking.html –  Nick Campbell 24.05.2011 в 15:54