Как реализовать эффективный движок плитки карты в Google App Engine?

Question

Я пытаюсь внедрить движок карты в Google App Engine.

Данные карты хранятся в базе данных, хранилище данных (большая таблица). Проблема состоит в том, что 20 запросов могут появиться примерно в то же время, чтобы нарисовать 20 плиток на основе того же набора строк в базе данных.

Так поступают 20 запросов, если я напишу код для чтения из базы данных для каждого запроса, тогда я буду делать 20 считываний, которые являются одинаковыми, из базы данных, по одному для каждого вывода изображения. Поскольку каждое чтение является одним и тем же запросом, не имеет смысла делать один и тот же запрос 20 раз. На самом деле это очень неэффективно.

Может ли кто-нибудь предложить лучший способ сделать это?

Если я использую memcache, мне нужно поместить данные в memcache, но в то же время для данных поступает 20 запросов, то если я сделаю реализацию nieve, тогда 20 процессов будут записывать в memcache, так как они все одновременно идут параллельно.

Я программирую в бета-версии Google Go версии 1 на Google App Engine, я имею в виду документ Python здесь, так как они более полные.

Ссылки:

Google Datastore http://code.google.com/appengine/docs/python/datastore/overview.html

листовка JS Я использую для показа фрагментов карты http://leaflet.cloudmade.com/

---

уточнить.

Я генерирую изображения черепицы из данных в базе данных, то есть я запрашиваю базу данных для данных (это не изображение плитки), затем я рисую данные в изображение и отображаю изображение как JPEG. Как GAE эффективен для нанесения изображений на стороне сервера http://blog.golang.org/2011/12/from-zero-to-go-launching-on-google.html

Answer 1

Несколько вещей приходит на ум:

1. Как вы запрашиваете плитки? вы должны иметь возможность получать плитки с помощью Key.get(), который более эффективен, чем запрос.
2. Попробуйте уменьшить количество запросов, используя уровни, чтобы уменьшить количество запросов до 4, чтобы получить карту.

Answer 2

1. Организация плитки объектов, так что вы можете найти их с помощью ключа вместо запрашивая для них, то есть с помощью get() вместо query(). Если вы определите фрагмент, основанный на нескольких критериях, затем создайте естественный идентификатор, объединив критерии. Например. если вы найдете плитку на основе вертикального и горизонтального положения внутри изображения, то вы бы сделали: naturalID = imageID + verticalID + horizontalID (вы также можете добавить разделители для лучшего просмотра).

2. Как только у вас есть свои уникальные идентификаторы, вы можете использовать его для сохранения плитки в Memcache.

3. Если ваши плитки неизменяемы (= после создания, их содержимое не изменяется), вы также можете кэшировать их внутри экземпляра на глобальной карте.

Edit: удален объективизации ссылка как я только понял, что вы используете питона. Edit2: добавлен пункт 3.

Answer 3

Я не знаю о том, как Google App Engine это делает, но MySQL имеет кэш запросов, так что, если тот же запрос, получает упрашивать подряд, то он использует результаты от первого до второго. Google умеет о вещах, поэтому, надеюсь, они это делают. (Возможно, вам удастся выяснить, есть ли у них время.)

Возможно, вам нужно будет убедиться, что запросы абсолютно одинаковы, а не просто возвращают те же результаты. Например, вы не хотите Query1 быть ВЫБРАТЬ Lat, СПГ- MyTable WHERE tileX = 1 И Тили = 1 и Query2, чтобы быть ВЫБРАТЬ лат, СПГ- туЬаЫе WHERE tileX = 1 И Тили = 2

Я делаю плитки с gazillions из полигонов, и когда я делал выбор времени и оптимизацию, я с удивлением обнаружил, что быстрее возвращать ВСЕ ценности и отсеивать те, которые мне не нужны в PHP, чем это нужно придерживаться в предложении WHERE к SQL. Я думаю, что отчасти это было потому, что предложение WHERE было разным для каждой плитки, поэтому сервер MySQL не мог эффективно кэшировать.