Таблица запросов Cassandra без ключа раздела - PullRequest
Новая
       6

Таблица запросов Cassandra без ключа раздела

0 голосов
/ 02 марта 2020

Я пытаюсь извлечь данные из таблицы как часть задания по миграции.

Схема выглядит следующим образом: 

CREATE TABLE IF NOT EXISTS ${keyspace}.entries (
    username text,

    entry_type int,

    entry_id text,

    PRIMARY KEY ((username, entry_type), entry_id)
);

Для запроса таблицы нам нужен раздел ключи, первая часть первичного ключа. Следовательно, если мы знаем username и entry_type, мы можем запросить таблицу.

В этом случае username может быть любым, но entry_type является целым числом в диапазоне 0 -9.

При переносе извлечения мы повторяем таблицу 10 раз для каждого имени пользователя, чтобы убедиться, что мы пробуем все версии entry_type.

Мы больше не можем найти какие-либо записи, поскольку у нас есть исчерпал наш список имен пользователей. Но наш nodetool tablestats сообщает, что в таблице еще есть данные, даже гигабайты. Следовательно, мы предполагаем, что таблица не пуста.

Но я не могу найти способ осмотреть таблицу, чтобы выяснить, какие имена пользователей остаются в таблице. Если бы я мог проверить это, я мог бы добавить имена пользователей, оставленные в таблице, к нашему заданию по извлечению, и в итоге мы могли бы истощить таблицу. Но я не могу просто запросить таблицу следующим образом: 

SELECT * FROM ${keyspace}.entries LIMIT 1

, поскольку cassandra требует, чтобы ключи разделения делали содержательные запросы.

Что я могу сделать, чтобы выяснить, что осталось в нашей таблице?

Ответы [ 2 ]

2 голосов
/ 03 марта 2020

Согласно комментарию, процесс миграции включает в себя операцию DELETE из таблицы Cassandra, но ядро ​​будет иметь задержку перед тем, как фактически удалить с диска затронутые записи; этот процесс контролируется внутри с помощью надгробий и атрибута gc_grace_seconds таблицы. Причина этой задержки полностью объяснена в этой записи блога , для tl dr, если значение по умолчанию все еще остается в силе, Cassandra потребуется пройти как минимум 10 дней (864 000 секунд) от выполнения удаление до фактического удаления данных.

Для вашего случая, один из способов продолжить это:

  1. Убедитесь, что все ваши узлы "Вверх" и "Здоров" (UN)

  2. Уменьшите атрибут gc_grace_seconds вашей таблицы, в этом примере он будет установлен на 1 минуту, в то время как по умолчанию будет

    ALTER TABLE .entries с GC_GRACE_SECONDS = 60 ;

  3. Сжать вручную таблицу:

    компактные записи nodetool

  4. После завершения процесса nodetool tablestats должно быть в курсе

1 голос
/ 03 марта 2020

Чтобы ответить на ваш первый вопрос, я хотел бы подробнее остановиться на свойстве gc_grace_seconds .

В Кассандре данные не удаляются таким же образом это в РСУБД. Cassandra разработана для высокой пропускной способности записи и избегает операций чтения перед записью. Таким образом, в Cassandra удаление фактически является обновлением, а обновления - фактически вставками. Маркер «надгробная плита» написан, чтобы указать, что данные теперь (логически) удалены (также известные как мягкое удаление). Записи, помеченные как захороненные, должны быть удалены, чтобы вернуть место для хранения. Это делается с помощью процесса Compaction . Но помните, что надгробные камни имеют право на физическое удаление / сборку мусора только после определенного числа c секунд, известного как gc_grace_seconds. Это очень хороший блог, который можно прочитать более подробно: https://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html

Теперь, возможно, вы изучаете размер таблицы до gc_grace_seconds, и данные все еще там.

Перейдем ко второй проблеме, в которой вы хотите получить некоторые сэмплы из таблицы без предоставления ключей секционирования. Вы можете анализировать содержимое таблицы с помощью Spark. Spark Cassandra Connector позволяет создавать Java приложения, которые используют Spark для анализа данных базы данных. Вы можете следовать статьям / документации, чтобы написать быстрое удобное искровое приложение для анализа данных Cassandra.

https://www.instaclustr.com/support/documentation/cassandra-add-ons/apache-spark/using-spark-to-sample-data-from-one-cassandra-cluster-and-write-to-another/

https://docs.datastax.com/en/dse/6.0/dse-dev/datastax_enterprise/spark/sparkJavaApi.html

Я бы рекомендовал не удалять записи во время миграции. Вместо этого сначала выполните миграцию и выполните публикацию, которая выполняет быструю проверку / проверку, чтобы убедиться, что все записи успешно перенесены (это можно легко использовать, используя Spark buy, сравнивая кадры данных из старых и новых таблиц). После успешной проверки усечение старой таблицы, поскольку усечение не создает надгробий и, следовательно, более эффективно. Обратите внимание, что огромное количество надгробий не очень полезно для здоровья кластера.

...