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

Question

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

Есть ли у кого-нибудь, кто работал с Google Datastore или BigTable, хороший совет по работе с ними?

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

Answer 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()    

Answer 4

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

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

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

Отношения
В RDBMS большинство людей следуют отношениям «один-к-одному», «многие-к-одному», «многие-ко-многим», в Datastore, поскольку в них есть «нет соединений», но все же мы можем добиться нашей нормализации, используя « ReferenceProperty"например Пример отношения один-к-одному .

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

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

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

Запрос
GAE Datatore значительно улучшает возможности LIKE (О, нет! В хранилище данных нет ключевого слова LIKE) SQL, который является GQL .

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

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

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

Answer 8

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

(справочная таблица: http://en.wikipedia.org/wiki/BigTable)