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

Ответ 1

Есть две основные вещи, чтобы привыкнуть к хранилищу данных App Engine по сравнению с традиционными реляционными базами данных:

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

Я всегда хихикаю, когда люди выходят - это не реляционная. Я написал 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()    

Ответ 4

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

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

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

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

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

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

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

Query
GAE Datatore обеспечивает лучшую функцию гораздо LIKE (нет, у datastore нет LIKE-ключевого слова) SQL, который GQL.

Вставка данных/Обновление/Удаление/Выбор
Это, где нас всех интересует, как и в RDMBS, нам нужен один запрос для Insert, Update, Delete and Select, как RDBMS, Datastore put, delete, get (не слишком возбуждайтесь), потому что Datastore помещает или получает в терминах Запись, чтение, малые операции (чтение затрат на вызовы хранилища данных), и в этом случае вступает в действие Data Modeling. вы должны свести к минимуму эти операции и поддерживать работу своего приложения. Для уменьшения Чтение операции вы можете использовать Memcache.

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

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

(bigtable reference: http://en.wikipedia.org/wiki/BigTable)