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

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

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

По сравнению с «традиционными» реляционными базами данных в хранилище данных 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()    

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

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

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

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

Индексы
Обычно в RDMBS мы создаем индексы, такие как первичный ключ, внешний ключ, уникальный ключ и ключ индекса, чтобы ускорить поиск и повысить производительность нашей базы данных. В хранилище данных вы должны создать по крайней мере один индекс для каждого вида (он будет автоматически генерировать , нравится вам это или нет), потому что хранилище данных выполняет поиск вашей сущности на основе этих индексов и, поверьте мне, это лучшая часть.В РСУБД вы можете искать, используя неиндексное поле, хотя это займет некоторое время, но будет. В 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, кроме Google Cloud SQL (который является mySQL), все остальное - NoSQL.

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

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