Медленное время вставки с композитным основным ключом в Cassandra

Question

Я работаю с Cassandra, и я ударил немного камнем преткновения. Для того, как мне нужно искать данные, я обнаружил, что первичный ключ Composite отлично работает для того, что мне нужно, но время вставки для записи в этой семействе колонок идет к собакам с этим, и я не совсем уверен, почему.

Таблица Определение:

CREATE TABLE exampletable (
clientid int, 
filledday int, 
filledtime bigint, 
id uuid, 
...etc... 
PRIMARY KEY (clientid, filledday, filledtime, id) 
); 

ClientID = Внутренний идентификатор клиента. fullday = количество дней с 01.01.1900. filltime = количество тиков того дня, когда была получена запись. id = A Guid.

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

Я знаю, что магазины Cassandra Column Families с составными первичными ключами совершенно по-разному. Насколько я понимаю, он сохранит все как новые столбцы от базовой строки основного компонента первичного ключа. Это причина, по которой вставки будут медленными? Когда я говорю «медленно», я имею в виду, что если у меня только первичный ключ на id, то вставка займет ~ 200 миллисекунд, а с составным первичным ключом (или любым его подмножеством, я попробовал просто clientid и id с тем же эффектом), это займет до 32 секунд для 1000 записей. Время выбора быстрее из таблицы составных клавиш, так как я должен применять вторичные индексы и использовать «ALLOW FILTERING», чтобы вернуть правильные записи со стандартной таблицей ключей (я знаю, что могу сделать это в коде, но проблема что я имею дело с некоторыми массивными наборами данных, и это не всегда будет практичным или возможным).

Я объявляю семейство колонок или первичный ключ неправильными в отношении того, что я пытаюсь сделать? Со всеми незарегистрированными, непервичными ключевыми столбцами таблица имеет ширину 37 столбцов, будет ли это проблемой? На данный момент я совершенно в тупике. Я не могу действительно найти что-либо о других, имеющих похожие проблемы.

Answer 1

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

Также вы можете привести пример запросов, которые вы запускаете? В Кассандре модель данных всегда должна напоминать запросы, которые вы хотите запустить. Если вам нужно «разрешить фильтрацию», то кажется, что с вашей моделью данных что-то не так. Например, я действительно не вижу смысла «заполненного времени» в вашей ПК. Если вы хотите выполнить запрос по периоду времени, просто замените три столбца на столбец TimeUUID «ts». Это создало бы широкую строку с одним столбцом на запись с уникальным timestam, кластеризованным/разделенным на один идентификатор клиента. Это позволяет делать запросы, как:

select * from exampletable where clientid = 123 and ts > minTimeuuid('2013-06-18 16:23:00') and ts < minTimeuuid('2013-06-18 16:24:00'); 

Опять же, это будет зависеть от запросов вы на самом деле нужно запустить.

И, наконец, для общего руководства по моделированию данных ознакомьтесь с this ebay tech blog. Чтение помогло мне кое-что выяснить для меня.

Надеюсь, что это поможет!