Как моделировать сущности в Google Datastore

Question

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

Например, допустим, у меня есть приложение, которое отслеживает различные арендуемые транспортные средства.В традиционной базе данных у меня может быть таблица Buses, которая отслеживает длину и количество посадочных мест для каждого автобуса в парке, и Trucks, которая имеет столбец для грузоподъемности и лошадиных сил для каждого грузовика.Каждый автобус и грузовик также имеет цвет и номерной знак.(Если я хочу нормализовать базу данных, я могу выделить эти атрибуты в таблице Vehicle.

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

Каковы преимущества / недостатки использования традиционной модели базы данных, где каждая сущность Datastore представляет таблицу базы данных?

Более эффективно разбивать большие объекты на более мелкие объекты?

РЕДАКТИРОВАТЬ:

Кроме того, какие-либо рекомендации относительно того, какой API использовать: JDO, JPA или низкоуровневый API Datastore?

Спасибо!

Answer 1

Вы не должны думать о таблицах вообще. Подумайте о сущностях. В документации указано, что:

Объекты хранилища данных не содержат схем: два объекта одного типа не обязаны иметь одинаковые свойства или использовать одинаковые типы значений для одинаковых свойств. Приложение отвечает за обеспечение соответствия сущностей схеме при необходимости.

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

Answer 2

Этот вопрос меня долго удивлял.Я думаю, что способ, которым вы захотите искать объект позже, существенно влияет на выбор модели проектирования.Меня поразило то, что в App Engine вы не можете использовать фильтры неравенства для нескольких свойств одной и той же сущности.

Например: Вы не можете запросить сущность «Персона» для возраста> 20 и роста <170.Поскольку возраст и рост - это разные свойства одного и того же объекта. </p>

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

Мне пришлось денормализовать и разделить эти свойства, чтобы выполнить запросы.Вы можете посмотреть видео Bret Saltkin в Google I / O, чтобы лучше понять методы проектирования БД.Я закончил и полностью скрыл мой опыт моделирования хранилища данных в Google app engine здесь .

Answer 3

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

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

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