Как скопировать данные из таблицы Cassandra в другую структуру для повышения производительности

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

По правде говоря, наличие множества похожих таблиц с похожими данными - это хорошо для Cassandra. Ограничьте первичный ключ тем, что вы будете искать. Если вы планируете искать данные с похожими, но разными критериями, сделайте это отдельной таблицей. Нет недостатка в том, что одни и те же данные хранятся по-разному. Дублирование данных - ваш друг в Кассандре.

[...]

Если вам нужно сохранить один и тот же фрагмент данных в 14 разных таблицах, запишите его 14 раз. Нет препятствий против многократной записи.

Я понял это, и теперь мой вопрос: при условии, что у меня есть существующая таблица, скажем

CREATE TABLE invoices (
    id_invoice int PRIMARY KEY,
    year int,
    id_client int,
    type_invoice text
)

Но я хочу запрашивать по годам и набирать вместо этого, поэтому я хотел бы иметь что-то вроде

CREATE TABLE invoices_yr (
    id_invoice int,
    year int,
    id_client int,
    type_invoice text,
    PRIMARY KEY (type_invoice, year)
)

Используя id_invoice в качестве ключа раздела и year в качестве ключа кластеризации, какой способ лучше копировать данные из одной таблицы в другую для выполнения оптимизированных запросов позже?

Моя версия Кассандры:

user@cqlsh> show version;
[cqlsh 5.0.1 | Cassandra 3.5.0 | CQL spec 3.4.0 | Native protocol v4]

cassandra cqlsh cql cql3
person astrojuanlu    schedule 03.01.2017    source источник
comment
У вас есть только ванильный C * (спарк?)? Какая версия (если доступны материализованные представления)?   -  person Chris Lohfink    schedule 03.01.2017
comment
Что касается утверждения Дублирование данных - ваш друг в Кассандре, я настоятельно рекомендую этого не делать. Дублирование данных вам не друг. Это может привести к проблемам с синхронизацией и повреждению данных. В лучшем случае это знакомство, которому не следует полностью доверять или полагаться на него.   -  person Ben Harrison    schedule 23.05.2018
comment
Я не думаю, что дублирование данных вам не друг, поскольку общее утверждение можно легко сказать и в контексте баз данных больших данных.   -  person astrojuanlu    schedule 23.05.2018

Ответы (3)


arrow_upward
9
arrow_downward

Чтобы повторить то, что было сказано о команде COPY, это отличное решение для чего-то вроде этого.

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

Чтобы облегчить масштабирование КОПИРОВАНИЯ для больших наборов данных, вы можете использовать параметры PAGETIMEOUT и PAGESIZE.

COPY invoices(id_invoice, year, id_client, type_invoice) 
  TO 'invoices.csv' WITH PAGETIMEOUT=40 AND PAGESIZE=20;

Правильно используя эти параметры, я раньше использовал COPY для успешного экспорта / импорта 370 миллионов строк.

Для получения дополнительной информации ознакомьтесь с этой статьей под названием: Новые возможности и повышение производительности в копии cqlsh.

person Aaron    schedule 04.01.2017

arrow_upward
17
arrow_downward

Вы можете использовать команду cqlsh COPY:
Чтобы скопировать данные счетов в файл csv, используйте:

COPY invoices(id_invoice, year, id_client, type_invoice) TO 'invoices.csv';

И скопируйте обратно из файла csv в таблицу, в вашем случае invoices_yr используйте:

COPY invoices_yr(id_invoice, year, id_client, type_invoice) FROM 'invoices.csv';

Если у вас огромные данные, вы можете использовать sstable writer для записи и sstableloader, чтобы загружать данные быстрее. http://www.datastax.com/dev/blog/using-the-cassandra-bulk-loader-updated

person Ashraful Islam    schedule 04.01.2017

arrow_upward
3
arrow_downward

Альтернативой использованию команды COPY (примеры см. В других ответах) или Spark для переноса данных является создание материализованного представления для денормализации за вас.

CREATE MATERIALIZED VIEW invoices_yr AS
       SELECT * FROM invoices
       WHERE id_client IS NOT NULL AND type_invoice IS NOT NULL AND id_client IS NOT NULL
       PRIMARY KEY ((type_invoice), year, id_client)
       WITH CLUSTERING ORDER BY (year DESC)

Кассандра заполнит стол за вас, так что вам не придется мигрировать самостоятельно. В версии 3.5 помните, что ремонт не работает должным образом (см. CASSANDRA-12888 ).

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

person Chris Lohfink    schedule 04.01.2017
comment
Привет, Крис! Хороший отзыв о ремонте в 3.5. - person Aaron; 04.01.2017
comment
Крис, в вашем примере возникает следующая ошибка: InvalidRequest: code=2200 [Invalid query] message="Cannot include more than one non-primary key column 'year' in materialized view partition key" - person astrojuanlu; 05.01.2017
comment
Для справки: docs.datastax.com/en/cql/3.3 /cql/cql_using/useCreateMV.html - person astrojuanlu; 05.01.2017
comment
Требования к материализованному представлению: столбцы первичного ключа исходной таблицы должны быть частью первичного ключа материализованного представления. К первичному ключу материализованного представления можно добавить только один новый столбец. Статические столбцы не допускаются. - person astrojuanlu; 05.01.2017
comment
Материализованные представления многообещающи, но в существующем виде решение включает в себя изменение исходной таблицы и добавление ключей кластеризации, чтобы их можно было включить в материализованное представление, что может предотвратить, например, ОБНОВЛЕНИЯ. - person astrojuanlu; 05.01.2017