Как мыслить хранилищами данных, а не базами данных?

По сравнению с «традиционными» реляционными базами данных в хранилище данных App Engine нужно привыкнуть:

• Хранилище данных не делает различий между вставками и обновлениями. Когда вы вызываете put () для сущности, эта сущность сохраняется в хранилище данных со своим уникальным ключом, и все, что имеет этот ключ, перезаписывается. По сути, каждый тип объекта в хранилище данных действует как огромная карта или отсортированный список.
• Запросы, как вы упомянули, гораздо более ограничены. Для начала, никаких присоединений.

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

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

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

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

Я решил переключить сознание на то, чтобы вообще забыть о базе данных.

В мире реляционных баз данных вам всегда нужно беспокоиться о нормализации данных и структуре вашей таблицы. Бросьте все это. Просто создайте макет своей веб-страницы. Разложите их все. А теперь посмотри на них. Вы там уже 2/3.

Если вы забываете о том, что размер базы данных имеет значение и данные не должны дублироваться, тогда вы на 3/4, и вам даже не нужно было писать код! Пусть ваши взгляды диктуют ваши модели. Вам больше не нужно брать свои объекты и делать их двухмерными, как в мире отношений. Теперь вы можете хранить объекты с формой.

Да, это упрощенное объяснение испытания, но оно помогло мне забыть о базах данных и просто создать приложение. На данный момент я сделал 4 приложения App Engine, используя эту философию, и это еще не все.

Я всегда хихикаю, когда люди говорят: это не отношения. Я написал cellectr на django, и вот фрагмент моей модели ниже. Как вы увидите, у меня есть лиги, которыми управляют или тренируют пользователи. Я могу получить от лиги всех менеджеров или от конкретного пользователя могу вернуть лигу, которую он тренирует или менеджеров.

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

Мои два пенса.

class League(BaseModel):
    name = db.StringProperty()    
    managers = db.ListProperty(db.Key) #all the users who can view/edit this league
    coaches = db.ListProperty(db.Key) #all the users who are able to view this league

    def get_managers(self):
        # This returns the models themselves, not just the keys that are stored in teams
        return UserPrefs.get(self.managers)

    def get_coaches(self):
        # This returns the models themselves, not just the keys that are stored in teams
        return UserPrefs.get(self.coaches)      

    def __str__(self):
        return self.name

    # Need to delete all the associated games, teams and players
    def delete(self):
        for player in self.leagues_players:
            player.delete()
        for game in self.leagues_games:
            game.delete()
        for team in self.leagues_teams:
            team.delete()            
        super(League, self).delete()

class UserPrefs(db.Model):
    user = db.UserProperty()
    league_ref = db.ReferenceProperty(reference_class=League,
                            collection_name='users') #league the users are managing

    def __str__(self):
        return self.user.nickname

    # many-to-many relationship, a user can coach many leagues, a league can be
    # coached by many users
    @property
    def managing(self):
        return League.gql('WHERE managers = :1', self.key())

    @property
    def coaching(self):
        return League.gql('WHERE coaches = :1', self.key())

    # remove all references to me when I'm deleted
    def delete(self):
        for manager in self.managing:
            manager.managers.remove(self.key())
            manager.put()
        for coach in self.managing:
            coach.coaches.remove(self.key())
            coaches.put()            
        super(UserPrefs, self).delete()    

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

Вы, должно быть, уже знали, что хранилище данных построено с возможностью масштабирования, и это то, что отличает его от RDMBS. для лучшего масштабирования с большим набором данных в App Engine внесены некоторые изменения (некоторые из них означают много изменений).

СУБД VS DataStore
Структура
В базе данных мы обычно структурируем наши данные в таблицах, строках, которые в хранилище данных становятся Виды и объекты.

Отношения
В РСУБД большинство людей следуют отношениям "один к одному", "многие к одному", "многие ко многим" в хранилище данных, поскольку в нем есть параметр "Нет соединений". но все же мы можем добиться нормализации с помощью "ReferenceProperty", например Один-к-одному Пример.

Индексы
Обычно в RDMBS мы делаем индексы наподобие Primary Ключ, внешний ключ, уникальный ключ и индексный ключ для ускорения поиска и повышения производительности нашей базы данных. В хранилище данных вы должны создать как минимум один индекс для каждого вида (он автоматически сгенерирует нравится вам это или нет), потому что хранилище данных ищет вашу сущность на основе этих индексов и поверьте мне, это лучшая часть. В СУБД вы можете искать, используя неиндексное поле, хотя это займет некоторое время, но будет. В Datastore нельзя выполнять поиск с использованием неиндексных свойств.

Подсчет
В RDMBS подсчет намного проще (*), но в хранилище данных, пожалуйста, даже не думайте об этом обычным образом (да, есть функция подсчета), поскольку в нем есть Лимит 1000 и это будет стоить столько же небольших операций, сколько объект, который не хорошо, но у нас всегда есть хороший выбор, мы можем использовать счетчики осколков.

Уникальные ограничения
в RDMBS , Нам нравится эта функция, правда? но у Datastore свой путь. вы не можете определить свойство как уникальное :(.

Запрос
GAE Datatore предоставляет более удобную функцию LIKE (О, нет! в хранилище данных нет ключевого слова LIKE) SQL, который является GQL.

Вставка / Обновление / Удаление / Выбор данных
Это то, в чем мы все заинтересованы, так как в RDMBS нам требуется один запрос для вставки, обновления, удаления и выбора, точно так же, как РСУБД, хранилище данных поместило, удалило , получите (не слишком волнуйтесь), потому что хранилище данных помещает или получает с точки зрения записи, чтения, небольших операций (см. Затраты на вызовы хранилища данных), и именно здесь моделирование данных вступает в действие. вы должны свести к минимуму эти операции и поддерживать работу приложения. Для уменьшения операции чтения можно использовать Memcache.

Взгляните на документацию Objectify. Первый комментарий внизу страницы гласит:

«Хорошо, хотя вы написали это для описания Objectify, это также одно из самых кратких объяснений самого хранилища данных appengine, которое я когда-либо читал. Спасибо».

https://github.com/objectify/objectify/wiki/Concepts

Если вы привыкли думать о сущностях, отображаемых в ORM, то в основном так работает хранилище данных на основе сущностей, такое как Google App Engine. Что-то вроде объединений можно найти в ссылочных свойствах. Вам действительно не нужно беспокоиться о том, использует ли он BigTable для бэкэнда или чего-то еще, поскольку бэкэнд абстрагируется интерфейсами GQL и Datastore API.

Я смотрю на хранилище данных так: вид идентифицирует таблицу как таковую, а сущность - это отдельная строка в таблице. Если бы Google выбрал вид, кроме одной большой таблицы без структуры, и вы могли бы выгрузить все, что захотите, в сущность. Другими словами, если сущности не привязаны к типу, вы в значительной степени можете иметь любую структуру для сущности и хранить в одном месте (вид большого файла без структуры, каждая строка имеет свою собственную структуру).

Теперь вернемся к исходному комментарию, хранилище данных Google и bigtable - это две разные вещи, поэтому не путайте хранилище данных Google со смыслом хранения данных хранилища данных. Bigtable дороже, чем bigquery (основная причина, по которой мы не пошли с ним). У Bigquery есть правильные соединения и СУБД, такие как язык sql, и его дешевле, почему бы не использовать bigquery. При этом у bigquery есть некоторые ограничения, в зависимости от размера ваших данных, с которыми вы можете или не можете столкнуться.

Кроме того, с точки зрения мышления в терминах хранилища данных, я думаю, правильным утверждением было бы «думать в терминах баз данных NoSQL». В наши дни их слишком много, но когда дело доходит до продуктов Google, кроме облачного SQL Google (который является mySQL), все остальное - NoSQL.

Будучи укорененным в мире баз данных, хранилище данных для меня было бы гигантской таблицей (отсюда и название «bigtable»). BigTable - плохой пример, потому что он выполняет множество других вещей, которые типичная база данных может не выполнять, но при этом остается базой данных. Скорее всего, если вы не знаете, что вам нужно создать что-то вроде "bigtable" Google, вам, вероятно, подойдет стандартная база данных. Им это нужно, потому что они обрабатывают безумные объемы данных и систем вместе, и никакая коммерчески доступная система не может действительно выполнять работу так, как они могут продемонстрировать, что они нуждаются в этой работе.

(ссылка на bigtable: http://en.wikipedia.org/wiki/BigTable)