Моделирование вопросов прямого и обратного запросов в Bigtable - PullRequest
Новая
       84

Моделирование вопросов прямого и обратного запросов в Bigtable

0 голосов
/ 11 декабря 2018

Скажем, у нас есть три следующих объекта: 

Organization
 - id

Role
 - id

Member
 - id

Роль может быть предоставлена ​​Участнику в Организации, что дает этому Участнику определенные права контроля доступа для этой Организации. Я хотел бы иметь возможность ответить на следующие два запроса :

  1. Перечислите идентификаторы всех членов, которые имеют данную Роль в данной Организации (например, дали РольID и идентификатор организации дают мне список участников).
  2. Перечислите все идентификаторы ролей, которые были предоставлены участнику в рамках данной организации (например, если указаны идентификатор участника и идентификатор организации, укажите мне списокРоли).

Я пытаюсь найти рекомендации о том, как смоделировать это в Bigtable (в идеале, с одной строкой для атомных мутаций) ... Я также открыт для других технологических рекомендаций (яЯ пытаюсь проектировать в рамках ограничений, которые дала мне моя компания).

Если мы смоделируем отношения, описанные выше, с помощью ключа строки Bigtable org#{orgID}#role#{roleID}#member#{memberID}, я легко могу ответить на первый вопрос.Однако это не позволяет мне легко ответить на второй вопрос.Если я продублирую данные и сохраню еще один ключ строки org#{orgID}#member#{memberID}#role#{roleID}, тогда я легко смогу ответить на второй вопрос, но теперь у меня есть две строки для управления, и невозможно гарантировать атомарные обновления между ними, что может привести к проблемам согласованности.

Кто-нибудь в сообществе сталкивался с подобной проблемой, и если да, то как вы ее решили?

Ответы [ 2 ]

0 голосов
/ 17 декабря 2018

Раскрытие информации:

  • Я возглавляю управление продуктами для Cloud Bigtable.
  • Я стал одним из основателей проекта JanusGraph .

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

Подход к реляционной СУБД

Как упоминал Дан в в своем ответе , вы можете использовать управляемый MySQL или PostgreSQL через Google Cloud SQL или Google Cloud Spanner , в зависимости от ваших потребностей в масштабировании, репликации, согласованности, совместимости с существующим кодом / средами и т. Д.

Подход к базе данных графиков

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

Например, вы можете развернуть Janusgraph в GKE с Bigtable и Elasticsearch и запросить данные, используя язык Gremlin , который является стандартным поддерживаемым языком обхода / запроса графов.многими графическими базами данных.

Обратите внимание, что JanusGraph + Bigtable наследует транзакционность Bigtable (который, как вы заметили, является атомарным на уровне строк).Поскольку JanusGraph хранит каждой вершины в отдельной строке в Bigtable , только одно-вершинные обновления будут атомарными.Если вы хотите обновлять транзакции через JanusGraph, вам может потребоваться использовать другой сервер хранения , например,

  • BerkeleyDB (локальный, нераспределенный сервер хранения)
  • FoundationDB (недавний вклад сообщества JanusGraph)

Существует много других графовых баз данных, которые вы можете рассмотреть, некоторые из которыхтакже поддерживает Gremlin или другие языки запросов графов.Например, вы можете развернуть Neo4j на GCP , если хотите, который поддерживает Gremlin и Cypher.

0 голосов
/ 12 декабря 2018

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

В зависимости от ваших ограничений (провайдер облачных вычислений, масштаб данных, атомарность, репликация в нескольких регионах и т. Д.), Вам может быть лучше работать сстандартная реляционная база данных (например, Postgres, MySQL) или Google Cloud Spanner .

Возможные подходы с помощью Spanner для этого:

  • Естьодиночная таблица, представляющая отношение члена <-> роли.Если RoleID является основным индексом для строки, а затем добавьте Вторичный индекс для MemberID, и вы сможете выполнять запросы к любому из них.

  • ПерейтиТрадиционный маршрут реляционной базы данных, включающий присоединение таблицы Member, Role и MemberRole.С Spanner у вас должны быть атомарные обновления через транзакцию .При запросах у вас могут возникнуть проблемы с чтениями, проходящими через несколько разделений, но вам придется провести некоторое реальное тестирование, чтобы увидеть, как будет выглядеть ваша производительность.

...