Стратегия фильтрации больших данных в cassandra db

Question

Я не профессионал в проектировании базы данных, но мне посчастливилось придумать стратегию фильтрации данных. Дано cassandra как используемое dbms. Моя цель - изобрести систему кэширования, которая может вернуть одно поле из набора данных для уже запрошенной «конфигурации» параметров. Если эта явная «конфигурация» никогда не запрашивалась раньше, новый запрос будет запускаться в фоновом режиме, но этот механизм не является частью этой темы.

Пример таблицы

id = 1, color = red, size = 10, shape = oval, price = 55.2 
id = 2, color = blue, size = 5, shape = rectangle, price = 33.9 
id = 3, color = red, size = 2, shape = triangle, price = 95.7 

...

Клиент запрашивает красный и овальный элемент формы с размером 10 и хочет знать цену. Поскольку запрошенные параметры, очевидно, уже находятся в db, клиент должен получить ответ очень быстро.

Что я хочу в SQL-то вроде

SELECT price FROM table where color = red AND size = 10 AND shape = oval

В MYSQL не очень критично, но как это сделать в Кассандре?

Im новый с cassandra и не знаю, как это сделать.

Что я уже знаю

• фильтрация в MySql с ИНЕК возможно, но медленно (для больших баз данных), так как БД должен работать и искать через все поля используя вместо индексов

• столбцы фильтра cassandra, которые не проиндексированы или не являются частью первичного ключа, за исключением использования опции ALLOW FILTER, которая также так же медленна, как и фильтрация в реляционных db

• cassandra поддерживает такие типы, как карты, так что можно сохранить parameterset на одном поле, как

  id = 1, properties = {color => red, size => 10, shape => oval}, price = 55.2

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

Другой данное условие, что параметры не всегда одинаковы. Например, элемент 1 имеет атрибут цвета и размера, а элемент 8 имеет только атрибут shape и color. Это говорит о не-реляционной архитектуры, на мой взгляд (?) Дело в том, что одна «конфигурация» должен существовать ровно один раз, так что следующий пример не должен быть возможно

id = 2535, color = red, size = 10, shape = oval, price = 55.2 
id = 3224, color = red, size = 10, shape = oval, price = 33.9 

У меня была идея о строительстве хэш для параметров и использовать его в качестве первичного ключа, но проблема в том, что, например, color = red, size = 10, shape = oval является тождественным, как size = 10, shape = oval, color = red, но хэш отличается.

Возможно, решение очень просто или невозможно? Я искал какое-то время для ответов, но не нашел их.

Я не хочу полного решения, но, возможно, кто-то может дать мне подсказку или ключевое слово для поиска.

Спасибо всем

Answer 1

В вашем примере вы выполняете поиск на равенство трех полей вернуть идентификатор продукта.

Создайте таблицу специально для этого запроса. Поскольку конфигурации уникальны, идентифицируйте их как ключ раздела и кластер на product_id.

create table product_by_color_shape_size (
    color text, 
    size int, 
    shape text, 
    product_id uuid, //(or int) 
    price int, 
    PRIMARY KEY ((color, size, shape),product_id) 
); 

Для получения дополнительной информации по моделированию данных в Кассандре вы должны проверить DS220 Data Modeling course at Datastax Academy.