Является ли обслуживание из Memcache или blobstore быстрее/эффективнее/дешевле?

У меня есть данные файла (в частности, файлы языковых ресурсов). Эти файлы автоматически генерируются с помощью API машинного перевода (goog translate). Они изменяются относительно редко, но при изменении основного файла (добавлении или изменении новой строки) все остальные языковые файлы обновляются автоматически.

Я пытаюсь выбрать между обслуживанием этих файлов непосредственно из хранилища BLOB-объектов или их обслуживанием из кэша памяти и сохранением их в хранилище данных.

Что быстрее/эффективнее?


java google-app-engine memcached blobstore
person aloo    schedule 10.02.2012    source источник
comment
Я считаю, что memcache все еще свободен-99.   -  person Dave    schedule 11.02.2012
comment
Как вы планируете обновлять данные внутри blobstore? Я думаю, что мы можем создавать или добавлять большие двоичные объекты, но не обновлять их содержимое.   -  person Ibrahim Arief    schedule 11.02.2012
comment
@IbrahimArief Я бы просто создал новый объект большого двоичного объекта и удалил старый.   -  person aloo    schedule 11.02.2012

Ответы (3)


arrow_upward
5
arrow_downward

Ник Джонсон описал компромиссы скорости в этой статье. Магазин BLOB-объектов лучше всего справляется с загрузками пользователей. Для вашей проблемы вы, вероятно, получите самую быструю и дешевую производительность, используя кэш памяти, поддерживаемый хранилищем данных. В python NDB автоматизирует это за вас. В Java используйте objectify.

person mjibson    schedule 11.02.2012
comment
Разве NDB на данный момент не является API только для Python? Вы можете добиться того же вида автоматизации (поместить-получить в кэш памяти, который автоматически поддерживается хранилищем данных) в Java с помощью Objectify: code.google.com/p/objectify-appengine/wiki/ - person Ibrahim Arief; 11.02.2012
comment
@mjibson спасибо за ссылку. Он проверяет, что memcache работает быстрее, чем обслуживание файлов локальных ресурсов, но не сравнивается с blobstore. Хотя мне все еще интересно, кэшируются ли локальные файлы и даже файлы blobstore в каком-либо Google CDN. - person aloo; 11.02.2012

arrow_upward
1
arrow_downward

Это действительно зависит от того, что вы подаете. Когда люди говорят о хранилище BLOB-объектов, они обычно имеют в виду большие данные (медиафайлы), которые не помещаются в кэш памяти. Наше приложение обслуживает множество аудиофайлов, и я обнаружил, что магазин BLOB-объектов особенно хорош для этого, поскольку он поддерживает загрузку с прогрессивным HTTP.

В обоих случаях время поиска практически мгновенное (они оба являются просто картами, и вы ищете данные по ключу). Время, необходимое для его обслуживания, зависит от возвращаемого товара. Я не могу придумать ни одной причины, по которой я мог бы взять что-то из blobstore и поместить это в memcache. Это действительно не собирается экономить время.

Теперь хранилище данных — это другой зверь...

person Rick Mangi    schedule 11.02.2012
comment
Я только что понял, что вы указали, что это данные файла. Я бы рекомендовал поместить их в хранилище данных и использовать memcache для их обслуживания. Objectify действительно был бы вашим другом здесь. - person Rick Mangi; 11.02.2012
comment
Да, это простые старые текстовые файлы размером ~ 10 КБ .... и да, мы активно используем объектизацию :) - person aloo; 12.02.2012
comment
Если вы обслуживаете их извне через http для конечных пользователей, вы также можете кэшировать их вверх по течению, добавляя соответствующие заголовки к ответу. Это значительно сократило наши расходы. - person Rick Mangi; 12.02.2012

arrow_upward
-2
arrow_downward

Ответ на каждый вопрос «что быстрее» — «сравните это». Особенности вашей настройки (скорость диска, задержка доступа к памяти, пропускная способность, демонические заражения) в лучшем случае делают любой общий ответ о риске производительности. Тот факт, что вы работаете в Google App Engine, еще больше усложняет задачу — вы не знаете знаете, какое оборудование вы собираетесь получить! Так что протестируйте.

Тем не менее, вполне вероятно, что локальный (выходной) кэш памяти, такой как Google, будет быстрее, чем что-либо, что может включать в себя попадание на диск. Задержка доступа к памяти на порядок меньше, чем задержка доступа к диску, а пропускная способность памяти в сто и более раз превышает пропускную способность даже самых быстрых твердотельных накопителей, представленных сегодня на рынке.

Таким образом, если вы можете позволить себе ОЗУ и хотите максимально увеличить скорость отклика, хранение данных в памяти, как правило, более эффективно.

person Borealid    schedule 10.02.2012
comment
Это вводит в заблуждение на нескольких уровнях. Реализация memcache Google хранит ваши данные не в оперативной памяти экземпляра вашего приложения, а на отдельном сервере, который является частью инфраструктуры Google. Доступ к кэшу памяти почти ничего не стоит, поэтому вы почти наверняка можете позволить себе его использовать, загвоздка в том, что нет гарантированного сохранения. Кэширование данных в памяти экземпляра возможно, но с ограниченной эффективностью, поскольку у нас минимальный контроль над жизненным циклом и адресуемостью экземпляра. Часть вашего совета может подойти для обычной кластерной среды, но GAE — совсем другое дело. - person Ibrahim Arief; 11.02.2012
comment
@IbrahimArief Вот почему я указал локальный кэш памяти - Google не дает никаких гарантий относительно местоположения, но даже TCP-over-Infiniband для памяти удаленной машины быстрее, чем попадание на жесткий диск. Что касается постоянства, ни один из известных мне кэшей памяти не выживает после перезагрузки. Неявное предположение здесь состоит в том, что есть копия данных в каком-то более медленном постоянном хранилище. - person Borealid; 11.02.2012