Сложные запросы с помощью хранилища данных GAE
Прохладный.
я также нашел документацию относительно E:
http://www.postgresql.org/docs/8.3/interactive/sql-syntax-lexical.html#SQL-SYNTAX-STRINGS
PostgreSQL также принимает строковые константы "Escape", которые являются расширением стандарта SQL. Строковая константа Escape определяется путем записи буквы E (верхний регистр или нижний регистр) незадолго до вводной одинарной кавычки, например, E'foo'. (При продолжении строковой константы Escape через строки запишите E только перед первой вводной кавычкой.) В строке Escape символ обратной косой черты (\) начинает подобную C escape-последовательность обратной косой черты, в которой комбинация обратной косой черты и после символа (символов) представляет специальное значение байта. \b является клавишей Backspace, \f является переводом формата, \n является новой строкой, \r является возвратом каретки, \t является вкладкой. Также поддерживаемый \digits, где цифры представляют восьмеричное значение байта и \xhexdigits, где hexdigits представляет шестнадцатеричное значение байта. (Это - Ваша ответственность, что последовательности байта, которые Вы создаете, являются допустимыми символами в кодировании набора символов сервера.) Любой другой символ после обратной косой черты взят буквально. Таким образом, для включения символа обратной косой черты запишите две обратных косых черты (\\). Кроме того, одинарная кавычка может быть включена в строку Escape путем записи \', в дополнение к нормальному способу' '.
3 ответа
По сути, вы описываете OLAP - оперативную аналитическую обработку. OLAP - это то, в чем «традиционные» СУБД очень хороши, отчасти из-за гибкости и мощности SQL, а нереляционные базы данных, такие как хранилище данных App Engine, - нет. Похоже, что ваши запросы типа OLAP будут относительно нечастыми по сравнению с обычным доступом, поэтому я предлагаю один из двух подходов:
- Зеркальное отображение всех ваших данных из хранилища данных App Engine в реляционную базу данных через определенные промежутки времени и выполнение аналитические запросы к реляционной базе данных. Пользовательский трафик по-прежнему обслуживается хранилищем данных, поэтому вы получаете все преимущества этого, но у вас есть автономная копия, с которой можно выполнять сложные запросы.
- Use App Engine ' s Поддержка очереди задач для выполнения запросов, исследующих большие наборы данных. Вы можете написать свой запрос на Python или Java, а затем использовать очередь задач для его выполнения в очень большом наборе данных и асинхронно получать результаты, когда они будут выполнены. Очевидно, что для упрощения этого требуется небольшая работа с инфраструктурой (хотя следите за моим блогом на предмет будущих проектов, связанных с этим;).
Я бы сказал, что хранилище типа bigtable менее подходит для статистических приложений по тем самым причинам, которые вы упомянули. Но это классический компромисс, на который вам нужно пойти. Я редко обнаруживал, что использую гибкость действительно сложных запросов, но много раз был вынужден придумывать более специализированные решения для вещей, которые изначально не должны были быть в базе данных.
Если вы придерживаетесь РСУБД, вы можете довольно легко выполнить логическое разделение и денормализацию, например, с помощью стратегий сохранения Hibernates и Hibernate Shards . Если вы можете жить с несколько более медленной обработкой, вы также можете выполнять SQL-запросы в хранилище типа bigtable (см., Например, hadoop pig latin ).
Хранилище данных GAE полностью отличается от СУБД. В реляционной БД легко написать что-то вроде:
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 имеет множество ограничений - см. Здесь - так что это непросто перевести. Для агрегатных функций (сумма, стандартное отклонение и т. Д.) Вы должны вытащить все данные на уровень приложения и вычислить или поддерживать агрегированные объекты, которые обновляются при каждой вставке / обновлении данных.
Обновление
Вы можете рассмотреть возможность использования GAE для Пользовательский интерфейс и бизнес-логика, но с отдельной реляционной базой данных где-то в другом месте в облаке, например: Microsoft SQL, DB2 на Amazon, MySQL где-то еще, а не с использованием хранилища данных GAE для предварительно рассчитанных агрегатов и статистики. Таким образом, статистика по-прежнему рассчитывается в СУБД, но вы сохраняете результаты (частичную, предварительно рассчитанную статистику) в хранилище GAE; аналогично хранению измерений в аналитических кубах.