объективизации POST/LIKE/USER Отношения

Question

Я моделирования Google хранилищу с объективизации и часть моего датасторе имеет эти 3 элемента:

пользователя Сообщение новое сообщение, которое может понравиться многим пользователям (типичная социальная сеть).

До сих пор я Пользователь:

@Entity 
public class UserMW { 

    @Id 
    private Long id; 

    @Index 
    private String email; 

    ... 
} 

Сообщение:

@Entity 
public class PostMW{ 

    @Id 
    private Long id; 

    @Load 
    private Ref<UserMW> owner; 

    ... 
} 

И, как:

@Entity 
public class LikeMW { 

    @Id 
    private Long id; 

    @Load 
    private Ref<UserMW> user; 

    private Key likedObject; 

    ... 
} 

Он прекрасно работает и отвечает всем моим потребностям до сих пор. Проблема в том, что я не знаю, по какому пути я должен идти в отличие от поста (удалить объект из рода Likes).

У меня есть пользователь и likedObject ключ, чтобы удалить его, так что если это было в реляционной базе данных было бы очень просто (просто удалить с «где» по ID_пользователя и likedObjectID), но на объективизации ...

Я мог бы подумать о 2 способах:

1 - @index по обоим атрибутам Likes entity, затем запрашивает его и удаляет (но @Index так дорого, а таблица Likes будет гигантской!) Не звучит как хорошая Идея)

2 - @Parent по атрибуту пользователя Likes entity и @Index на понравившемся объекте, затем запрос по предку, а затем фильтр по полю избранным пользователем. d delete (но если я использую @Parent, я все время понимаю, что загружаю 1 пользователя, я загружу ВСЕ ЕГО ЛЮБОВЬ, и, как я уже сказал, таблица Likes станет гигантской! Не звучит также как хорошая идея)

Любое предложение для решения моей проблемы?

Спасибо, ребята!

Answer 1

Я бы с добавлением еще один индекс к Like сущности, как это самый простой рабочий раствор, особенно учитывая datastore's newish pricing что также делает его немного дешевле:

... писать единое целое только стоит 1 писать независимо от индексов, а теперь будет стоить 0,18 доллара за 100 000. Это означает, что записи более доступны по цене для людей, использующих несколько индексов. Вы можете использовать столько индексов, сколько требуется вашему приложению , без увеличения затрат на запись.

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

Answer 2

Да, вы можете просто индексировать user и likedObject поля и выполнять запросы, как у реляционная база данных.Однако, это имеет два недостатка:

• запросы будут в конечном счете соответствует
• Вы не воспользовавшись кэш память

Strong консистенции желательно так, что если пользователь любит/unlikes что-то и перезагружается на странице, они гарантированно будут видеть эффект немедленно.

Вот что я хотел бы сделать:

@Entity 
@Cache 
public class Like { 
    @Parent 
    private Ref<User> user; 

    @Id 
    private String likedObjectKey; 

    public <T> Key<T> getLiked() { return Key.create(likedObjectKey); } 
} 

Используйте toWebSafeString() ключа вещи быть понравился как строка идентификатора из Like лица. Вы можете добавить синтаксический сахар, чтобы скрыть строение/разрушение.

Это означает, что выборка Like s для {user, thing} кортежей всегда является пошаговой. Вы можете их загружать, а выборки будут использовать memcache (как положительные, так и отрицательные удары будут кэшироваться). Результат всегда будет строго согласованным. Вы легко можете получать и модифицировать их в транзакциях.

Примечание: это не позволяет задать вопрос: «Кому это понравилось?» Вы можете также хотите сохранить понравившийся объект ключ как нормальное индексированное поле в Like. Я бы настоятельно рекомендовал его, даже если вы не планируете его немедленно использовать; вы, в конце концов, захотите запустить этот запрос, даже если он предназначен только для отладки. Индексы не стоят столько же, сколько все, кажется, боятся.