#cassandra
#cassandra
Вопрос:
Учтите следующее, я хочу хранить данные о каменных кирпичах в Cassandra. Во-первых, кирпич имеет уникальное имя / идентификатор под названием brick123. Этот кирпич имеет «размеры» ширины: 6, высоты: 3, длины: 4. Его «вес: 2pds». Он имеет какой-то дикий «цветной» базовый цвет: красный, оттенок: песчаник, чередование: синий. Она «произведена» в следующих странах: 1: Россия, 2: Африка, 3: Япония. Мы можем заказать ее у следующих «поставщиков»: 1: Lowes, 2:bricks-r-us, 3:stone-supply.
Теперь, если у нас есть X количество каменных блоков, должны ли мы использовать семейство суперколонок для размещения наших кирпичных данных? Сможем ли мы запросить у Cassandra каменные блоки из Африки или какие каменные блоки доступны через stone-supply?
Спасибо!
Ответ №1:
Обычный совет, по-видимому, заключается в том, чтобы избегать SCFS в пользу нескольких CFS.
Для простых свойств кирпича (ширина, цвет …) вы можете использовать простую строку для каждого кирпича со столбцом для каждого свойства (вы также можете включить автоматические вторичные индексы, если хотите искать кирпичи с определенными свойствами):
CF "bricks":
brick123 -> w h l weight color hue striping
6 3 4 2pds red sandstone blue
Для многозначных свойств (страны, производители) у вас могут быть отдельные семейства столбцов:
CF "countries":
brick123 -> Russia Africa Japan
<empty> <empty> <empty>
И / или, если вы хотите выполнить поиск блоков из заданной страны, вы создаете дополнительный индекс в качестве другого CF:
CF "country2bricks"
Russia -> brick123 brick124 ...
<empty> <empty>
Africa -> brick123 brick127 ...
<empty> <empty>
Japan -> brick123
<empty>
(и то же самое для поставщиков)
Ключевым моментом является то, что в Cassandra вы структурируете семейства столбцов в соответствии с запросами, которые вы хотите выполнить, денормализуя по мере необходимости.
«пустой» указывает, что мы просто используем только имя столбца для хранения информации с пустым значением столбца.
Комментарии:
1. Спасибо, ДНК! Чем больше я читаю и изучаю эту проблему, тем больше кажется, что вы сказали, либо несколько cf, либо использование столбца CompositeType. CompositeType выглядит многообещающе, за исключением отсутствия поддержки во многих API, таких как PHP.
2. PHP теперь поддерживает составные файлы. просто создайте ключ типа «что-то:something_else».
Ответ №2:
Суперколонки не индексируются — это означает, что доступ для чтения к суперколонке загрузил бы все ее содержимое в оперативную память. Это также еще одна причина избегать SCF, особенно если он содержит большой объем данных.