Как получить огромное (> 2000) количество сущностей из хранилища данных GAE менее чем за 1 секунду?

Question

У нас есть часть нашего приложения, которой нужно загрузить большой набор данных (> 2000 объектов) и выполнить вычисления на этом наборе. Размер каждого объекта составляет около 5 КБ.

В нашей начальной, наивной реализации узким местом является время, необходимое для загрузки всех объектов ( ~ 40 секунд для 2000 объектов ), тогда как время, необходимое для выполнения самого вычисления, очень маленький (<1 секунда). </p>

Мы попробовали несколько стратегий для ускорения поиска сущностей:

• Разделение поискового запроса на несколько параллельных экземпляров с последующим объединением результата: ~ 20 секунд для 2000 объектов .
• Хранение сущностей в кеше в памяти, помещенном в резидентный сервер: ~ 5 секунд для 2000 сущностей .

Вычисления должны выполняться динамически, поэтому предварительное вычисление во время записи и сохранение результата не работает в нашем случае.

Мы надеемся, что сможем получить ~ 2000 объектов за одну секунду. Это в пределах возможностей GAE / J? Какие-нибудь другие стратегии, которые мы могли бы реализовать для такого рода поиска?

ОБНОВЛЕНИЕ: Предоставление дополнительной информации о нашем сценарии использования и результате распараллеливания:

• У нас в хранилище данных более 200 000 объектов одного типа, и операция только для поиска.
• Мы экспериментировали с 10 параллельными рабочими экземплярами, и типичный результат, который мы получили, можно увидеть в этой пасте . Похоже, что сериализация и десериализация, необходимые при передаче объектов обратно в главный экземпляр, снижают производительность.

ОБНОВЛЕНИЕ 2: приводим пример того, что мы пытаемся сделать:

1. Допустим, у нас есть объект StockDerivative, который необходимо проанализировать, чтобы узнать, является ли это хорошей инвестицией или нет.
2. Выполненный анализ требует сложных вычислений, основанных на многих факторах, как внешних (например, предпочтения пользователя, рыночные условия), так и внутренних (т. Е. Из свойств объекта), и выдает единственное значение "инвестиционного балла".
3. Пользователь может запросить сортировку производных по его инвестиционному баллу и попросить предоставить N-число производных с наибольшим количеством баллов.

Answer 1

200.000 на 5 КБ - 1 ГБ. Вы можете хранить все это в памяти на самом большом бэкэнд-экземпляре или иметь несколько экземпляров. Это будет самое быстрое решение - ничто не сравнится с памятью.

Вам нужны целые 5 КБ каждой сущности для вычислений? Нужны ли все 200 тыс. Сущностей при запросе перед вычислением? Касаются ли запросы все сущности?

Кроме того, проверьте BigQuery . Это может удовлетворить ваши потребности.

Answer 2

Использование Memcache . Я не могу гарантировать, что этого будет достаточно, но если это не так, вам, вероятно, придется перейти на другую платформу.

Answer 3

Наше решение заключается в периодическом чтении объектов в фоновой задаче и сохранении результата в BLOB-объекте json.Таким образом, мы можем быстро вернуть более 100 тыс. Строк.Вся фильтрация и сортировка выполняются в javascript с использованием модели DataView SlickGrid.

Как кто-то уже прокомментировал, MapReduce - это путь к GAE.К сожалению, Java-библиотека для MapReduce не работает для меня, поэтому мы используем неоптимальную задачу для выполнения всего чтения, но мы планируем запустить MapReduce в ближайшем будущем (и / или Pipeline API).

Имейте в виду, что в прошлый раз, когда я проверял, Blobstore не возвращал gzipped сущности> 1 МБ, поэтому в данный момент мы загружаем контент из сжатой сущности и расширяем его в память, таким образом, конечная полезная нагрузка получает gzipped.Мне это не нравится, это приводит к задержке, я надеюсь, что они скоро решат проблемы с GZIP!

Answer 4

В конце концов, не получается, что мы можем извлечь> 2000 объектов из одного экземпляра менее чем за одну секунду, поэтому мы вынуждены использовать кэширование в памяти, помещенное в наш внутренний экземпляр, как описано в исходном вопросе.Если кто-то придумает лучший ответ или мы найдем лучшую стратегию / реализацию для этой проблемы, я бы изменил или обновил принятый ответ.

Answer 5

Это очень интересно, но да, это возможно, и я видел ошеломляющие результаты.

Я бы сделал то же самое;концепция сокращения карты

Было бы здорово, если бы вы предоставили нам больше метрик о том, сколько параллельных экземпляров вы используете и каковы результаты каждого экземпляра?один или поиск и хранение?

Сколько элементов у вас в вашем хранилище данных?4000?10000?Причина в том, что вы можете кэшировать его из предыдущего запроса.

regards