Понимание хранилища данных Google App Engine - PullRequest
0 голосов
/ 18 апреля 2011

Я нахожусь на ранних стадиях разработки ОЧЕНЬ крупной системы (это система точек продаж уровня предприятия). как некоторые из вас знают, модели данных на этих вещах могут быть очень сложными. я хочу запустить эту штуку на google app engine, потому что я хочу потратить больше своих ресурсов на разработку программного обеспечения, а не на создание и обслуживание инфраструктуры.

В этом духе я много читал о GAE и DataStore. я разработчик реляционных баз данных старой школы, и я видел несколько разных концепций того, что такое база данных без схемы, и я думаю, что выяснил, что такое хранилище данных, но я хочу убедиться, что у меня все правильно

Итак, если я прав, то это система, основанная на таблице Сорта. так что если я создаю Java-сущность

class user
public string firstname
public string lastname

и разверните его, пользователь «таблицы» будет автоматически создан и запущен. затем в последующих выпусках, если я изменю пользователя класса

class user
public string firstname
public string lastname
public date addDate

и разверните его, пользователь «таблицы» автоматически обновляется новым полем.

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

class user
public long id
public string firstname
public string lastname

class phone
public string phonenumber
public user userentity

и вывести телефонные номера пользователя с нуля вместо

select phone from phone inner join user as phone.userentity = user where user.id = 5
(lay off i know the syntax is incorrect but you get the point) 

я бы сделал что-то вроде

select user from user where user.id = 5
then
select phone from phone where phone.userentity = user

и при этом будут получены все телефонные номера пользователя.

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

Ответы [ 2 ]

5 голосов
/ 18 апреля 2011

Там действительно нет таблиц вообще.Если вы сделаете некоторых пользователей только с именем и фамилией, а затем добавите addDate, то ваши исходные сущности все равно не будут иметь свойства addDate.Ни один из пользовательских объектов не связан вообще никоим образом.Их нет в таблице Users.

Вы можете получить доступ ко всем объектам, которые вы записали в базу данных с именем «User», потому что appengine хранит большие, длинные списки (индексы) всех объектов, которыеесть каждое имя.Таким образом, любой объект, который вы поместите туда с именем (видом) «Пользователь», получит запись в этом списке.Позже вы можете прочитать этот индекс, чтобы получить местоположение каждого из ваших объектов, и использовать эти местоположения (ключи) для извлечения объектов.Их нет в столе, они просто плавают вокруг.Некоторые из них имеют некоторые общие свойства, но это совпадение, а не требование.

Если вы хотите получить все объекты User, которые имеют определенное имя (выберите * из User, где firstname = "Joe"), вам придется поддерживать еще один большой длинный индекс ключей.Этот индекс имеет свойство firstname, а также ключ объекта в каждой строке.Позже вы можете отсканировать индекс для определенного firstname, получить все ключи, а затем перейти к поиску реальных сущностей, которые вы сохранили с этими ключами.Все эти объекты будут иметь свойство firstname (поскольку вы не введете объект без свойства firstname в своем индексе firstname), но они могут не иметь других общих полей, потому что они не находятся втаблица, которая обеспечивает любую структуру данных вообще.

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

3 голосов
/ 19 апреля 2011

Отличное введение в хранилище данных Google написано создателем objectify Framework: Основные понятия хранилища данных

...