Хранилище данных GCP: как моделировать данные? - PullRequest
Новая
       26

Хранилище данных GCP: как моделировать данные?

0 голосов
/ 30 апреля 2020

Я сбит с толку хранилищем данных - особенно мне сложно решить, где хранить информацию о моих объектах.

Например, у меня есть машина, которая принадлежит компании. В JSON это может выглядеть так: 

{
"car_id": "car001", # only unique among a particular owner
"company": "company001",
"value": 5200 # dollars
"Type": "Truck"
}

company и Type ограничены несколькими десятками значений. Я буду часто запрашивать по ID, компании и типу. Особенно это иерархически, в компании есть автомобили нескольких типов, а в каждом типе есть несколько реальных автомобилей.

Я вижу по крайней мере три способа моделирования:

  1. Кодировать это в Идентификаторе: 
 key = client.key("Car", "{company}_{type}_{car_id}")
    entity = datastore.Entity(key=key)
    entity.update({
"car_id": "car001", # only unique among a particular owner
"company": "company001",
"value": 5200 # dollars
"Type": "Truck"
})
Кодировать его в родительских ключах: 
 company_key = client.key("Company", "Company001") 
 type_key = client.key("Type", "Truck", parent=company_key)
 key = client.key("Car", car_id", parent=type_key)
    entity = datastore.Entity(key=key)
    entity.update({
"car_id": "car001", # only unique among a particular owner
"company": "company001",
"value": 5200 # dollars
"Type": "Truck"
})
Запросите это: 
 key = client.key("Car") # identifier is automatically assigned, kind should be Car
    entity = datastore.Entity(key=key)
    entity.update({
"car_id": "car001", # only unique among a particular owner
"company": "company001",
"value": 5200 # dollars
"Type": "Truck"
})

в запросе приложения на свойства.

Но что лучше? Для других No Sql dbs, которые я знаю, обычно есть какое-то руководство, как ожидается его использование (RavenDb, Cassandra et c.), Но я не смог найти такую ​​вещь для хранилища данных.

1 Ответ

1 голос
/ 30 апреля 2020

Хранилище данных автоматически индексирует каждое свойство, поэтому вы можете эффективно выполнять запросы по car_id, company и Type во всех трех предложенных макетах.

Однако есть некоторые другие причины, по которым вы можете выбрать одно из решений:

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