Вопрос по – GAE DataStore vs Google Cloud SQL для систем управления предприятием

14

Я создаю приложение, которое представляет собой систему управления предприятием, используя gae. Я создал несколько приложений, использующих gae и хранилище данных, но ни одно из них, которое не потребует большого количества пользователей, вводящих транзакции, наряду с необходимостью административной и управленческой отчетности. Больше всего я боюсь, что когда мне понадобится создавать перекрестные таблицы и другие подробные отчеты (или отчеты бизнес-аналитики и манипулировать данными), я столкнусь с огромным количеством проблем, связанных с запросами хранилища данных gae и ограничениями получения данных. Это действительно просто архитектурное предпочтение или здесь есть количественные проблемы?

В прошлом я создавал системы с использованием C ++ / c # / Java против Oracle / MySql / MSSql (с добавленным слоем кэширования для повышения производительности сложных или часто используемых результатов поиска в БД).

Я продолжаю читать, что мы должны отбросить старый менталитет реляционных данных и переместиться в новый мир большой таблицы McHashTable в небе ... но новое не всегда лучше ... Любое понимание или опыт в отношении вышеизложенного будет полезным.

Реляционная модель зарекомендовала себя очень полезной, но существующие продукты не смогли предоставить ее в масштабе Интернета, поэтому у нас есть много разных решений с их собственными проблемами. NuoDB является примером интересного и перспективного «NewDB» база данных. Пока мы ждем, люди склонны комбинировать решения для своих конкретных случаев использования, копируя данные в отдельные базы данных для запросов и отчетов, используя гигапространства перед rdbms и так далее. tesdal

Ваш Ответ

2   ответа
6

так это ограничение номера индекса. Например, если вам нужен поиск по какому-либо полю или сортировка - вам нужен +1 индекс. Всего вы можете иметь 200 индексов. Если у вас есть объект с 10 полями для поиска и вы можете сортировать по любому полю - будет около 100 комбинаций. Итак, вам нужно 100 индексов. Я разработал несколько небольших проектов для геев - и это истории успеха. Но когда приходит большой - это не для геев.

Насчет кеша - вы можете сделать это с помощью gae, но они распределяют кеш, работает очень медленно. Я предпочитаю создавать частный единый экземпляр постоянного бэкэнда с RESTfull API, который хранит кэшированные значения в памяти. Экземпляры внешнего интерфейса вызывают этот API для получения / установки значений.

Возможно, возможно построить сложную систему с помощью gae, но это будет набор небольших приложений / сервисов.

@proppy, это потрясающая ссылка. спасибо за это
Да, прочитайте это уже. Имеет большое значение с точки зрения ограничений. MindWire
Как описано в этой статьеdevelopers.google.com/appengine/articles/indexselectionНовый расширенный планировщик запросов может значительно сократить количество индексов для сложных запросов, используя зигзагообразное объединение слиянием для индексов с одним свойством вместо дорогостоящей комбинации составных индексов.
Ограничение индекса исчезает (было объявлено). Кроме того, меняются затраты на запросы DS, возможно, для большинства пользователей они снижаются.
Да, я прочитал это, но все же по формуле, которая обеспечивает, если у вас есть поиск по 1 из 10 полей и сортировка по 1 из 10 полей, вы получите примерно 100 индексов. Так что если у вас есть несколько таких объектов в вашем проекте - да, может быть, Gae может быть одним. Но некоторые проекты содержат большое количество таких сущностей. Так что я все еще нахожусь в своем положении - ге с хранилищем данных хорошо для небольших проектов. Вы можете создать что-то огромное, используя gae, если распространяете это через небольшие проекты.
21

Cloud SQL FAQ:

Should I use Google Cloud SQL or the App Engine Datastore?

This depends on the requirements of the application. Datastore provides NoSQL key-value > storage that is highly scalable, but does not support the complex queries offered by a SQL database. Cloud SQL supports complex queries and ACID transactions, but this means the database acts as a ‘fixed pipe’ and performance is less scalable. Many applications use both types of storage.

Если вам нужно много записей (~ XXX в / с) в дБ сущности с распределенными ключами, то в этом случае хранилище данных Google App Engine действительно блестяще.

Если вам нужна поддержка сложных и случайных пользовательских запросов, Google Cloud SQL более удобен.

Я на самом деле только что столкнулся с этим, что придает некоторый вес моему предыдущему комментариюstackoverflow.com/a/1711757/525541 MindWire
Если у вас есть огромный объем данных, вы также можете рассмотреть возможность использования Big Querydevelopers.google.com/bigqueryбольше подходит для работы с большим набором импортируемых данных.
Спасибо, это здорово. Это заставляет меня задуматься о том, какие инструменты нужны (OLTP = хранилище данных, OLAP = Google Cloud SQL) ИЛИ (OLTP = Google Cloud SQL, OLAP = BigQuery) ... В любом случае, я думаю, что оптимально см. OLTP с использованием хранилища данных, ежедневные запросы / отчеты с использованием GCSQL с разбросом большого запроса на случай, когда отчет проходит через некоторые массивные данные (например, данные транзакций по дебету / кредиту) ... MindWire
Похоже, сочетание этих двух может быть лучшим в этих обстоятельствах. Возможно, я могу разбить вещи на две стадии. Я могу использовать хранилище данных в качестве интерфейса приложения для OLTP, а затем через асинхронные очереди или задания cron перенести эти данные в облако sql для OLAP. Существует дублирование данных, но я мог бы использовать миграцию как возможность преобразовать данные в самом коде перед записью в более нормализованное состояние и очистить «устаревшие» данные. данные со стороны хранилища данных ... аааа работа, которую я только что создал для себя ... MindWire

Похожие вопросы