Совместное использование данных на основе памяти в Google App Engine - PullRequest
2 голосов
/ 22 сентября 2011

Я свободно рассматриваю возможность использования Google App Engine для хостинга некоторых Java-серверов, однако при чтении некоторых документов я столкнулся с проблемой, которая кажется немного проблемной.Большинство серверов, которые я когда-либо писал, и, конечно, тот, который я имею в виду, требуют какой-либо формы хранения на основе памяти, которая сохраняется между сеансами, однако GAE, похоже, не предоставляет механизма для этого.

  • Данные могут храниться как статические объекты, но приложение может использовать несколько серверов, и данные не могут быть разделены между серверами.

  • Существуетmemcache, который является общим, но поскольку это кеш, он ненадежен.

  • Это оставляет только хранилище данных, которое будет работать идеально, но слишком медленно.

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

Мне кажется, здесь большой пробел в функциональности.Или, может быть, я что-то упускаю?

Есть идеи или предложения?

1 Ответ

3 голосов
/ 22 сентября 2011

Статические данные (данные, которые вы загружаете вместе с приложением) видны только для чтения всем экземплярам.

Для обмена данными между экземплярами используйте хранилище данных. Там, где важна низкая задержка, кэшируйте в memcache. Это основные варианты. Чтение из хранилища данных довольно быстрое, оно записывает только те записи, которые вам нужны, и их можно уменьшить, убедившись, что любые свойства сущностей, к которым вам не нужно запрашивать, не проиндексированы.

Другой вариант, если он соответствует вашему бюджету, - это запуск собственного кэша на постоянном внутреннем сервере.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...