Подтвердить что ты не робот

Концепция и модель семейства столбцов

Я изучаю различные типы типов типов NoSQL, и я пытаюсь обернуть голову вокруг модели данных для хранилищ колонок, таких как Bigtable, HBase и Cassandra.

Первая модель

Некоторые люди описывают семейство столбцов как набор строк, где каждая строка содержит столбцы [1], [2]. Пример этой модели (семейства столбцов имеют верхний регистр):

{
  "USER":
  {
    "codinghorror": { "name": "Jeff", "blog": "http://codinghorror.com/" },
    "jonskeet": { "name": "Jon Skeet", "email": "[email protected]" }
  },
  "BOOKMARK":
  {
    "codinghorror":
    {
      "http://codinghorror.com/": "My awesome blog",
      "http://unicorns.com/": "Weaponized ponies"
    },
    "jonskeet":
    {
      "http://msmvps.com/blogs/jon_skeet/": "Coding Blog",
      "http://manning.com/skeet2/": "C# in Depth, Second Edition"
    }
  }
}

Вторая модель

Другие сайты описывают семейство столбцов как группу связанных столбцов в строке [3], [4]. Данные из предыдущего примера, смоделированные таким образом:

{
  "codinghorror":
  {
    "USER": { "name": "Jeff", "blog": "http://codinghorror.com/" },
    "BOOKMARK":
    {
      "http://codinghorror.com/": "My awesome blog",
      "http://unicorns.com/": "Weaponized ponies"
    }
  },
  "jonskeet":
  {
    "USER": { "name": "Jon Skeet", "email": "[email protected]" },
    "BOOKMARK":
    {
      "http://msmvps.com/blogs/jon_skeet/": "Coding Blog",
      "http://manning.com/skeet2/": "C# in Depth, Second Edition"
    }
  }
}

Возможное обоснование первой модели заключается в том, что не все семейства столбцов имеют отношение, подобное USER и BOOKMARK do. Это означает, что не все семейства столбцов содержат одинаковые ключи. Размещение этих семейств на внешнем уровне кажется более естественным с этой точки зрения.

Имя "семейство столбцов" подразумевает группу столбцов. Именно так представлены семейства столбцов в второй модели.

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

Вопрос

Что такое "стандартное" определение семейства столбцов? Является ли это набором строк или группой связанных столбцов внутри строки?

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

Update

Я рассмотрел вторую модель для объяснения модели данных в моей статье. Меня все еще интересует, как вы объясняете модель данных хранилищ колонок для других людей.

4b9b3361

ОТВЕТЫ

Ответ 1

Я думаю, что база данных Cassandra следует вашей первой модели. ColumnFamily представляет собой набор строк, который может содержать любые столбцы в разреженном порядке (поэтому каждая строка может иметь различную коллекцию имен столбцов, если это необходимо). Количество столбцов, разрешенных в строке, почти неограничено (2 миллиарда в Cassandra v0.7).

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

В Cassandra это важно, потому что данные в определенном семействе столбцов хранятся в одних и тех же файлах на диске - поэтому более эффективно размещать элементы данных, которые могут быть извлечены вместе, в том же столбце. Это отчасти практическая проблема скорости, но также вопрос организации ваших данных в четкую схему. Это касается вашего второго определения - можно считать все данные о том, что конкретный ключ является "строкой", но разделен на Column Family. Однако в Cassandra это не одна строка, потому что данные в одном ColumnFamily могут быть изменены независимо от данных в других ColumnFamilies для одного и того же ключа строки.

Ответ 2

По моему пониманию, Cassandra ColumnFamily - это не набор строк, а кластер столбцов. Столбец группируется вместе на основе ключа кластеризации. например, давайте рассмотрим ниже columnfamily:

CREATE TABLE store (
  enrollmentId int,
  roleId int,
  name text,
  age int,
  occupation text,
  resume blob,
  PRIMARY KEY ((enrollmentId, roleId), name)
) ;


INSERT INTO store (enrollmentid, roleid, name, age, occupation, resume)
values (10293483, 01, 'John Smith', 26, 'Teacher', 0x7b22494d4549);

Выбрав введенные выше данные с помощью cassandra-cli, он довольно хорошо сгруппирован на основе ключа кластеризации, в этом примере "name = John Smith" является ключом кластеризации.

RowKey: 10293483:1
=> (name=John Smith:, value=, timestamp=1415104618399000)
=> (name=John Smith:age, value=0000001a, timestamp=1415104618399000)
=> (name=John Smith:occupation, value=54656163686572, timestamp=1415104618399000)
=> (name=John Smith:resume, value=7b22494d4549, timestamp=1415104618399000)

Ответ 3

Обе модели, которые вы описали, одинаковы.

Семейство столбцов:

Key -> Key -> (Set of key/value pairs)

Концептуально это становится:

Table -> Row -> (Column1/Value1, Column2/Value2, ...)

Подумайте об этом как о карте карт пар ключ/значение.

UserProfile = {
    Cassandra = [emailAddress:"[email protected]", age:20],
    TerryCho = [emailAddress:"[email protected]", gender:"male"],
    Cath = [emailAddress:"[email protected]", age:20, gender:"female", address:"Seoul"],
}

Вышеприведенное является примером семейства столбцов. Если вы хотите ввести его в таблицу, вы получите таблицу под названием UserProfile, которая выглядит так:

UserName | Email | Age | Gender | Address
Cassandra | [email protected] | 20 | null | null
TerryCho | [email protected] | null | male | null
Cath | [email protected] | 20 | female | Seoul

Запутанная часть состоит в том, что на самом деле нет столбца или строки, как мы привыкли думать о них. Там есть куча "семейств столбцов", которые запрашиваются по имени (ключ). Эти семейства содержат множество наборов пар ключ/значение, которые также запрашиваются по имени (строка строки), и, наконец, каждое значение в наборе может быть просмотрено также по имени (клавиша столбца).

Если вам нужна табличная контрольная точка, "семейства столбцов" будут вашими "таблицами". Каждый "набор пары k/v" внутри них будет вашим "строками". Каждая "пара множества" будет "именами столбцов и их значениями".

Внутренне данные внутри каждого столбца familly будут храниться вместе, и они будут сохранены так, что строки будут один за другим, а в каждой строке столбцы будут один за другим. Итак, вы получаете row1 -> col1/val1, col2/val2, ... , row2 -> col1/val1 ... , ... -> .... Таким образом, в этом смысле данные хранятся намного больше, чем хранилище строк, и меньше, чем хранилище столбцов.

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