Сложные запросы с использованием хранилища данных GAE - PullRequest
9 голосов
/ 10 ноября 2009

Я нахожусь на ранней стадии разработки сайта по спортивной статистике (фрисби) и хотел бы узнать ваше мнение, подходит ли мне Google App Engine.

Я пишу это на Python, используя Django, и уже много лет знаком со стандартной СУБД, но этот сайт - долгосрочный проект, и я ожидаю очень большие объемы данных, поэтому мне бы хотелось "бесконечное" масштабирование, которое хранилище данных GAE предложения. Подавляющее большинство запросов к базе данных будут возвращать очень стандартные результаты, которые сделают хранилище данных логичным выбором. Тем не менее, я хотел бы иметь возможность делать чрезвычайно сложные запросы в будущем, чтобы предлагать новые статистические метрики или просто предлагать интересные результаты. Я планирую многое сделать в будущем, но не буду знать, что это за запросы, пока данные не будут собраны.

Например, вы часто видите, как аналитики бейсбольной статистики придумывают смешную статистику, такую ​​как «Это первый раз за последние 50 лет, когда два левых кувшина, чьи фамилии начинаются с« Z », бросили одиночные удары в дни назад ". Я хотел бы иметь возможность делать любые запросы в будущем. :)

Однако у меня сложилось впечатление, что нереляционная база данных, такая как bigtable, требует, чтобы вы заранее разработали модели, содержащие избыточные данные, и вся работа выполняется на вставках, а не на выборках. Я уже построил модели django, которые будут содержать практически все данные, к которым мне когда-либо понадобится запрашивать, но я понятия не имею, какие денормализованные модели я хочу иметь через год или два. Таким образом, я чувствую, что выполнение сложных запросов в будущем будет чрезвычайно сложным для хранилища данных GAE и потребует от меня удаления тонны информации с сервера перед обработкой в ​​python.

Является ли хранилище данных движка приложений Google просто неправильным для того, что я хочу сделать? Или просто что-то упустил. Большое спасибо заранее!

Обновление: Спасибо за ответы до сих пор. Я понимаю, что должен также упомянуть, что многие из этих сложных запросов - это запросы, которые я хотел бы, чтобы пользователи могли выполнять, поэтому создание автономной базы данных на самом деле не вариант. Например, пользователи должны иметь возможность видеть различные статистические данные о том, насколько хорошо играют два конкретных игрока, когда они находятся на поле одновременно в течение определенных игр или сезонов. Хотя эти запросы встречаются не так часто, как стандартные статистические показатели, они все же будут выполняться с регулярностью.

Было бы неплохо иметь реляционную базу данных, а также хранилище данных GAE, но django пока не поддерживает несколько БД по умолчанию, а исправление решения вместе кажется сложным и грязным. Эрик Флоренцано предлагает хорошее решение для двух баз данных, в обеих из которых используются модели django, но если бы я использовал хранилище данных GAE, мне пришлось бы вместо этого использовать модель db движка приложения. И придумать хорошее решение, как он сделал для этой сложной проблемы, немного выше моего уровня квалификации на данный момент.

Прямо сейчас мои любимые два варианта - использовать очередь задач GAE для выполнения сложных запросов или переходить на более стандартный веб-хостинг, такой как веб-фракция, а затем просто денормализовать мои таблицы позже, когда мои данные вырастут, и мне нужно повысить производительность.

Ответы [ 4 ]

13 голосов
/ 11 ноября 2009

То, что вы описываете, по сути OLAP - Аналитическая обработка в Интернете. OLAP - это одна вещь, в которой «традиционные» СУБД очень хороши, отчасти благодаря гибкости и мощи SQL, а нереляционные базы данных, такие как хранилище данных App Engine, - нет. Похоже, ваши запросы типа OLAP будут относительно редкими по сравнению с обычным доступом, поэтому я бы предложил один из двух подходов:

  • Зеркально отразите все свои данные из хранилища данных App Engine в реляционной базе данных через определенные промежутки времени и выполните аналитические запросы к реляционной базе данных. Пользовательский трафик по-прежнему обслуживается хранилищем данных, поэтому вы получаете все его преимущества, но у вас есть автономная копия, с которой можно выполнять сложные запросы.
  • Используйте поддержку очереди задач App Engine для выполнения запросов, которые проверяют большие наборы данных. Вы можете написать свой запрос в Python или Java, затем использовать очередь задач для выполнения его в очень большом наборе данных и асинхронно получать результаты, когда они будут выполнены. Очевидно, что для облегчения этой работы требуется немного работы над инфраструктурой (хотя следите за моим блогом для будущего проекта, связанного с этим;).
6 голосов
/ 10 ноября 2009

Я бы сказал, что хранилище типа bigtable менее подходит для статистических приложений по тем причинам, которые вы упомянули. Но это классический компромисс, который вы должны сделать. Я редко ловил себя на том, что использую гибкость действительно сложных запросов, но много раз был вынужден придумывать более специализированные решения для вещей, которые не должны были быть в БД.

Если вы придерживаетесь СУБД, вы можете довольно легко сделать логическое разбиение и денормализацию, например, с помощью стратегий сохранения Hibernates и Shibernate Hardsnate . Если вы можете жить с несколько более медленной обработкой, вы также можете выполнять SQL-запросы в хранилище типа bigtable (см., Например, hadoop pig latin ).

2 голосов
/ 10 ноября 2009

GAE data-store - это совершенно другое животное, нежели СУРБД. В реляционной БД легко написать что-то вроде:

SELECT STDEV(player_score)
FROM Table
WHERE player_id = 1234
  AND game_date BETWEEN '2007-01-01' AND '2009-11-10'
  AND city <> 'London'

GAE-запрос имеет множество ограничений - см. Здесь - поэтому это нелегко перевести. Для агрегатных функций (sum, stdev и т. Д.) Необходимо вывести все данные на прикладной уровень и вычислить или поддерживать агрегированные сущности, которые обновляются при каждой вставке / обновлении данных.

Обновление
Вы можете рассмотреть возможность использования GAE для пользовательского интерфейса и бизнес-логики, но иметь отдельную реляционную БД в другом месте в облаке, например: Microsoft SQL, DB2 на Amazon, MySQL в другом месте - и чем использовать хранилище данных GAE для предварительно рассчитанных агрегатов и статистики. Таким образом, статистика все еще рассчитывается в РСУБД, но вы сохраняете результаты (частичные, предварительно рассчитанные статистические данные) в хранилище GAE; аналогично пространственному хранению в аналитических кубах.

0 голосов
/ 09 марта 2013

Я хочу поддержать ссылку MindWire на использование Google CloudSQL.

Мой текущий проект на самом деле работает из хранилища данных, в основном с более ориентированными на SQL задачами, выполняемыми в Cloud SQL.

Документы по ссылкам для App Engine Python SDK

...