Cassandra 3.0 обновлен формат SSTable

по данным этой выпуска, формат хранения Кассандры был обновлен в 3.0.

если раньше я мог использовать cassandra-cli, чтобы увидеть, как построен SSTable, чтобы получить что-то вроде этого:

[default@test] list phonelists;
-------------------
RowKey: scott
=> (column=, value=, timestamp=1374684062860000)
=> (column=phonenumbers:bill, value='555-7382', timestamp=1374684062860000)
=> (column=phonenumbers:jane, value='555-8743', timestamp=1374684062860000)
=> (column=phonenumbers:patricia, value='555-4326', timestamp=1374684062860000)
-------------------
RowKey: john
=> (column=, value=, timestamp=1374683971220000)
=> (column=phonenumbers:doug, value='555-1579', timestamp=1374683971220000)
=> (column=phonenumbers:patricia, value='555-4326', timestamp=137468397122

Как будет выглядеть внутренний формальный в последней версии Cassandra? Не могли бы вы привести пример?

какую утилиту я могу использовать, чтобы увидеть внутреннее представление таблицы в Cassandra указанным выше способом, но с новым Формат SSTable?

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

Как я могу посмотреть в него?

1 ответов


до 3.0 sstable2json была полезной утилитой для получения понимания того, как данные организованы в SSTables. В настоящее время эта функция отсутствует в cassandra 3.0, но в конечном итоге будет альтернатива. До тех пор я и Крис Лофинк разработали альтернативу sstable2json (sstable-инструменты) для Cassandra 3.0, который вы можете использовать, чтобы понять, как организованы данные. Есть некоторые разговоры о том, чтобы довести это до Кассандры Кассандра-7464.

ключевым отличием между форматом хранения между более старыми версиями Cassandra и Cassandra 3.0 является то, что SSTable ранее представлял разделы и их ячейки (определяемые их кластеризацией и именем столбца), тогда как с Cassandra 3.0 SSTable теперь представляет разделы и их строки.

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

самое большое преимущество, которое вы увидите, заключается в том, что в общем случае ваш размер данных будет уменьшаться (в некоторых случаях большим фактором), так как большая часть накладных расходов, введенных CQL, была устранена некоторыми ключевыми улучшениями.

вот пример, показывающий разницу между C* 2 и 3.

схема:

create keyspace demo with replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
use demo;
create table phonelists (user text, person text, phonenumbers text, primary key (user, person));
insert into phonelists (user, person, phonenumbers) values ('scott', 'bill', '555-7382');
insert into phonelists (user, person, phonenumbers) values ('scott', 'jane', '555-8743');
insert into phonelists (user, person, phonenumbers) values ('scott', 'patricia', '555-4326');
insert into phonelists (user, person, phonenumbers) values ('john', 'doug', '555-1579');
insert into phonelists (user, person, phonenumbers) values ('john', 'patricia', '555-4326');

sstable2json C * 2.2 вывод:

[
{"key": "scott",
 "cells": [["bill:","",1451767903101827],
           ["bill:phonenumbers","555-7382",1451767903101827],
           ["jane:","",1451767911293116],
           ["jane:phonenumbers","555-8743",1451767911293116],
           ["patricia:","",1451767920541450],
           ["patricia:phonenumbers","555-4326",1451767920541450]]},
{"key": "john",
 "cells": [["doug:","",1451767936220932],
           ["doug:phonenumbers","555-1579",1451767936220932],
           ["patricia:","",1451767945748889],
           ["patricia:phonenumbers","555-4326",1451767945748889]]}
]

sstable-инструменты toJson C * 3.0 выход:

[
  {
    "partition" : {
      "key" : [ "scott" ]
    },
    "rows" : [
      {
        "type" : "row",
        "clustering" : [ "bill" ],
        "liveness_info" : { "tstamp" : 1451768259775428 },
        "cells" : [
          { "name" : "phonenumbers", "value" : "555-7382" }
        ]
      },
      {
        "type" : "row",
        "clustering" : [ "jane" ],
        "liveness_info" : { "tstamp" : 1451768259793653 },
        "cells" : [
          { "name" : "phonenumbers", "value" : "555-8743" }
        ]
      },
      {
        "type" : "row",
        "clustering" : [ "patricia" ],
        "liveness_info" : { "tstamp" : 1451768259796202 },
        "cells" : [
          { "name" : "phonenumbers", "value" : "555-4326" }
        ]
      }
    ]
  },
  {
    "partition" : {
      "key" : [ "john" ]
    },
    "rows" : [
      {
        "type" : "row",
        "clustering" : [ "doug" ],
        "liveness_info" : { "tstamp" : 1451768259798802 },
        "cells" : [
          { "name" : "phonenumbers", "value" : "555-1579" }
        ]
      },
      {
        "type" : "row",
        "clustering" : [ "patricia" ],
        "liveness_info" : { "tstamp" : 1451768259908016 },
        "cells" : [
          { "name" : "phonenumbers", "value" : "555-4326" }
        ]
      }
    ]
  }
]

В то время как выход больше (это больше следствие инструмента). Ключевые различия, которые вы можете увидеть:

  1. данные теперь представляют собой коллекцию разделов и их строк (которые включают ячейки) вместо коллекции разделов и их ячеек.
  2. метки времени теперь находятся на уровне строки (liveness_info), а не на уровне ячейки. Если некоторые ячейки строки дифференцируйте в своих метках времени, новый механизм хранения делает Дельта-кодирование для экономии места и связанной разницы на уровне ячейки. Это также включает TTLs. Как вы можете себе представить, это экономит много места, если у вас много неключевых столбцов типа timestamp не нужно повторять.
  3. информация о кластеризации (в этом случае мы кластеризованы на "person") теперь присутствует на уровне строки вместо уровня ячейки, что сохраняет кучу накладных расходов в качестве столбца кластеризации значения не обязательно должны быть на уровне ячеек.

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

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