Концепция семейства столбцов и модель данных
Я исследую различные типы типов баз данных NoSQL, и я пытаюсь обернуть голову вокруг модели данных семейных хранилищ столбцов, таких как Bigtable, HBase и Cassandra.
модель
некоторые люди описывают семейство столбцов как коллекция строк, где каждая строка содержит столбцы [1], [2]. Пример этой модели (семейства столбцов прописными буквами):
{
"USER":
{
"codinghorror": { "name": "Jeff", "blog": "http://codinghorror.com/" },
"jonskeet": { "name": "Jon Skeet", "email": "jskeet@site.com" }
},
"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": "jskeet@site.com" },
"BOOKMARK":
{
"http://msmvps.com/blogs/jon_skeet/": "Coding Blog",
"http://manning.com/skeet2/": "C# in Depth, Second Edition"
}
}
}
возможные причины модель это не все семейства столбцов имеют отношение как USER
и BOOKMARK
do. Это означает, что не все семейства столбцов содержат идентичные ключи. Размещение семейств столбцов на внешнем уровне кажется более естественным с этой точки зрения.
имя "семейство столбцов" подразумевает группу столбцов. Именно так семейства столбцов представлены в модель.
обе модели являются допустимыми представлениями данных. Я понимаю, что эти представления предназначены исключительно для передачи данных людям; приложения не "думают" о данных в таком путь.
вопрос
что такое "стандартное" определение семейства столбцов? Это коллекция строк или группа связанных столбцов внутри строки?
мне нужно написать статью по этому вопросу, поэтому меня также интересует, как люди обычно объясняют концепцию "семьи столбцов" другим людям. Обе эти модели противоречат друг другу. Я хотел бы использовать "правильную" или общепринятую модель для описания семейства столбцов хранилище.
обновление
Я остановился на второй модели для объяснения модели данных в моей статье. Мне все еще интересно, как вы объясните модель данных столбцов-семейных магазинов другим людям.
3 ответов
база данных Cassandra следует вашей первой модели, я думаю. ColumnFamily-это коллекция строк, которая может содержать любые столбцы в разреженном виде (поэтому каждая строка может иметь разную коллекцию имен столбцов, если это необходимо). Количество столбцов, разрешенных в строке, почти неограниченно (2 миллиарда в Cassandra v0.7).
ключевым моментом является то, что ключи строк должны быть уникальными в семействе столбцов по определению, но могут быть повторно использованы в других семействах столбцов. Таким образом, вы можете хранить несвязанные данные об одном и том же ключе в разных ColumnFamilies.
в Cassandra это имеет значение, потому что данные в определенном семействе столбцов хранятся в одних и тех же файлах на диске, поэтому более эффективно размещать элементы данных, которые могут быть извлечены вместе, в одном и том же семействе ColumnFamily. Это отчасти практическая проблема скорости, но также вопрос организации ваших данных в четкую схему. Это касается вашего второго определения - можно рассмотреть все данные о конкретном ключе быть "строкой", но разделенной семейством столбцов. Однако в Cassandra это не одна строка, потому что данные в одном ColumnFamily могут быть изменены независимо от данных в других ColumnFamilies для того же ключа строки.
обе модели, которые вы описали, одинаковы.
семейство столбцов:
Key -> Key -> (Set of key/value pairs)
концептуально это выглядит так:
Table -> Row -> (Column1/Value1, Column2/Value2, ...)
подумайте об этом как о карте карты пар ключ/значение.
UserProfile = {
Cassandra = [emailAddress:"cassandra@apache.org", age:20],
TerryCho = [emailAddress:"terry.cho@apache.org", gender:"male"],
Cath = [emailAddress:"cath@apache.org", age:20, gender:"female", address:"Seoul"],
}
выше приведен пример семейства столбцов. Если вы должны были табулировать его, вы получите таблицу под названием UserProfile, которая выглядит так:
UserName | Email | Age | Gender | Address
Cassandra | cassandra@apache.org | 20 | null | null
TerryCho | terry.cho@apache.org | null | male | null
Cath | cath@apache.org | 20 | female | Seoul
запутанная часть заключается в том, что на самом деле нет столбца или строки, как мы привыкли думать о них. Существует куча "семейств столбцов", которые запрашиваются по имени (ключ). Эти семейства содержат кучу наборов пар ключ / значение, которые также запрашиваются по имени (ключ строки), и, наконец, каждое значение в наборе также может быть просмотрено по имени (ключ столбца).
Если вам нужна табличная точка отсчета, " семейства столбцов "будут вашими"таблицами". Каждый "набор пар k/v" внутри них будет вашими "строками". Каждая "пара набора" будет " именами столбцов и их значения."
внутренне данные внутри каждого столбца familly будут храниться вместе, и он будет храниться таким образом, что строки будут один за другим, и в каждой строке столбцы будут один за другим. Так что вы получите row1 -> col1/val1, col2/val2, ... , row2 -> col1/val1 ... , ... -> ...
. Таким образом, в этом смысле данные хранятся гораздо больше как хранилище строк и меньше как хранилище столбцов.
чтобы закончить, выбор слов здесь просто неудачный и вводящий в заблуждение. Столбцы в семействах столбцов должны называться атрибутами. Строки должны называться наборами атрибутов. Семейства столбцов должны называться семействами атрибутов. Отношение к классической табличной лексике слабое и вводящее в заблуждение, так как на самом деле это довольно разные.
насколько я понимаю, 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);
Fetched вставлен выше деталей с помощью 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)