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

177

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

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

Теперь Google Cloud SQL обеспечивает поддержку реляционной базы данных для Google App Engine. Если вы все еще ищете решение для хранилищ данных, вы можете использоватьGoogle Cloud SQL. Chandana
Возможно, вы захотите проверить API Mungo Datastore:bit.ly/13eSDpr xybrek
DataSource - это старый API, который мы постепенно удаляем - он был очень привязан к модели подключения к базе данных. DataStore - это API низкого уровня, который обеспечивает доступ к «сырому» интерфейсу. потоковый подход к ГИС-контенту с использованием FeatureReaders и FeatureWriter. murali

Ваш Ответ

8   ответов
145

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

The datastore makes no distinction between inserts and updates. When you call put() on an entity, that entity gets stored to the datastore with its unique key, and anything that has that key gets overwritten. Basically, each entity kind in the datastore acts like an enormous map or sorted list. Querying, as you alluded to, is much more limited. No joins, for a start.

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

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

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

С точки зрения того, как изменить представление данных, наиболее важным является предварительный расчет. Вместо выполнения соединений во время запроса предварительно рассчитайте данные и сохраните их в хранилище данных, где это возможно. Если вы хотите выбрать случайную запись, сгенерируйте случайное число и сохраните его с каждой записью.There's a whole cookbook of these sort of tips and tricks Вот Редактировать: поваренная книга больше не существует.

Хорошая новость, интернет не забыл про кулинарную книгу, а именно интернет-архив не забыл. Призрак сайта все еще существует здесь:web.archive.org/web/20090416113704/http://…
-6

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

(большая таблица:http://en.wikipedia.org/wiki/BigTable)

Этот вопрос относится конкретно к Google App Engine, который использует Bigtable; использование реляционной базы данных не вариант.
6

гласит:

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

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

40

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

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

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

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

Мне нравится & quot; пусть ваши взгляды определяют ваши модели. & Quot; немного. Я думаю, что это зависание от СУБД, но оно все упрощает.
3

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

Одна проблема со ссылочными свойствами заключается в том, что они могут быстро создать проблему запроса 1 + N. (Потяните 1 запрос, чтобы найти 100 человек, затем сделайте еще один запрос для каждого из них, чтобы получить person.address.)
ссылка исправлена. не стесняйтесь редактировать любой ответ, если / когда у вас достаточно повторений.
Ссылка на «ссылочные свойства» сломан, возможно, добавлением поддержки Java. Пытаться:code.google.com/appengine/docs/python/datastore/…
22

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

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

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

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

12

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

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

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

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

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

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

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

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

Data Insert/Update/Delete/Select
Здесь нас всех интересует, так как в RDMBS нам требуется один запрос для вставки, обновления, удаления и выбора точно так же, как в СУБД, хранилище данных поместило, удалило, получило (не слишком волнуется), потому что хранилище данных помещало или получало в терминахПишите, читайте, небольшие операции(ЧитатьCosts for Datastore Calls) и именно здесь Data Modeling вступает в действие. Вы должны свести к минимуму эти операции и поддерживать работу приложения. Для уменьшенияОперация чтения ты можешь использоватьMemcache.

Похожие вопросы