Способы реализации управления версиями данных в Кассандре

Можете ли вы поделиться своими мыслями о том, как реализовать внедрение версий данных в Cassandra.

Предположим, что мне нужно записать записи в простую адресную книгу. (Записи адресной книги сохраняются как строки в столбце "Семья" ). Я ожидаю, что история:

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

Я рассматриваю следующий подход:

Преобразуйте адресную книгу в семейство Super Column и сохраните несколько версий записей адресной книги в одной строке с ключом (по метке времени) в виде супер столбцов.
Создайте новое семейство Super Column для хранения старых записей или изменений в записях. Такая структура будет выглядеть следующим образом:

{ "строка строки адресной книги": { 'time stamp1': { "имя": "новое имя", 'modified by': 'user id', },
```
'time stamp2': {
        'first name': 'new name',
        'modified by': 'user id',
    },
},
```
'еще одна строка строки адресной книги': { "метка времени": { ....
Сохраняйте версии как сериализованные (JSON) объекты, прикрепленные в новом ColumnFamilly. Представление наборов версий в виде строк и версий в виде столбцов. (моделируется после Простая документация с CouchDB)

Ответ 1

Если вы можете добавить предположение, что адресные книги обычно имеют менее 10 000 записей в них, то использование одной строки в строке адресной книги в суперколонном семействе было бы достойным подходом.

Строка будет выглядеть так:

{'address_book_18f3a8':
  {1290635938721704: {'entry1': 'entry1_stuff', 'entry2': 'entry2_stuff'}},
  {1290636018401680: {'entry1': 'entry1_stuff_v2', ...},
  ...
}

где ключ строки идентифицирует адресную книгу, каждое имя суперколла является меткой времени, а подколонки представляют содержимое адресной книги для этой версии.

Это позволит вам прочитать последнюю версию адресной книги только с одним запросом, а также написать новую версию с одной вставкой.

Причина, по которой я предлагаю использовать это, если адресные книги составляют менее 10 000 элементов, состоит в том, что суперколонки должны быть полностью десериализованы, когда вы читаете хотя бы одну подколонку. В целом, не так уж плохо в этом случае, но это что-то нужно иметь в виду.

Альтернативным подходом было бы использование одной строки для каждой версии адресной книги и использование отдельного CF с строкой строки времени в адресной книге, например:

{'address_book_18f3a8': {1290635938721704: some_uuid1, 1290636018401680: some_uuid2...}}

Здесь some_uuid1 и some_uuid2 соответствуют ключу строки для этих версий адресной книги. Недостатком этого подхода является то, что он требует два запроса каждый раз, когда адресная книга читается. Положительным моментом является то, что он позволяет вам эффективно читать только отдельные части адресной книги.

Ответ 1

Ответ 2