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

Question

В качестве примера Google App Engine использует хранилища данных, а не базу данных, для хранения данных. Есть ли у кого-нибудь советы по использованию хранилищ данных вместо баз данных? Кажется, я тренировал свой ум, чтобы думать о 100% объектных отношениях, которые непосредственно сопоставляются с структурами таблиц, и теперь трудно увидеть что-то по-другому. Я могу понять некоторые преимущества хранилищ данных (например, производительность и возможность распространения данных), но некоторые хорошие функциональные возможности базы данных приносятся в жертву (например, объединения).

Есть ли у кого-нибудь, кто работал с хранилищами данных, такими как BigTable, какие-либо полезные советы для работы с ними?

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

Путь я шел о переключателе ума, чтобы забыть о базе данных в целом.

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

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

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

Answer 4

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

Answer 5

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

Answer 6

Посмотрите на документацию объективировать. Первый комментарий внизу страницы гласит:

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

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

Answer 7

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

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

RDBMS VS DataStore
Структура
В базе данных, мы обычно структурировать данные в таблицах, строки которых находится в хранилище данных становится Kinds and Entities.

Отношения
В РСУБД Большинство людей folllows на один-к-одному, много-к-одному, многие-ко-многим, В Datastore, Как есть «Нет объединения» вещь, но все еще мы можем добиться нашей нормализации, используя «ReferenceProperty», например One-to-One Relationship Example.

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

Граф
В RDMBS, гораздо легче считать (*), но в датасторе, пожалуйста, даже не думаю, что это в обычном порядке (Да есть счетчик функция), как это имеет 1000 Limit и это будет стоить много small opertion как сущность, которая не хороша, но у нас всегда есть хороший выбор, мы можем использовать Shard Counters.

Unique Constraints
В RDMBS, Мы любим эту функцию право? но Datastore имеет свой собственный путь. Вы не можете определить свойство как уникальный :(.

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

Вставка данных/Update/Delete/Select
Это, где нас всех интересует, как и в RDMBS, нам нужен один запрос для вставки, обновления, удаления и выбора так же, как RDBMS, Datastore has put, delete, get (dont get too excited), потому что Datastore положить или получить в терминах Write, Read, Small Operations (Прочитано Затраты на вызовы хранилища данных), и в этом случае вступает в действие Data Modeling. вы должны свести к минимуму эти операции и поддерживать работу своего приложения. Для уменьшения Read operation вы можете использовать Memcache.

Answer 8

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

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

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