Основная концепция Cassandra заключается в том, что вы разрабатываете таблицы на основе ваших запросов (поскольку записи в таблицу не имеют ограничений). Дизайн основан на фильтрах запросов. Приложение, которое запрашивает таблицу по некоторому идентификатору, несколько неестественно, поскольку CITY_ID может иметь любое значение и обычно неизвестно (если вы не запустили предыдущий запрос, чтобы получить его). Что-то более естественное может быть CITY_NAME. В любом случае, при условии, что в таблице нет индексов (которые сами являются простыми таблицами), в Cassandra существуют правила, касающиеся предоставляемых вами фильтров и структуры таблицы, главным образом, что как минимум один из фильтров ДОЛЖЕН быть ключом раздела. Ключ секционирования помогает направить кассандру на правильный узел для данных (именно так оптимизируются чтения). Если ни один из ваших фильтров не является ключом раздела, вы получите сообщение об ошибке (если вы не используете ALLOW FILTERING, что является нет-нет). Другие фильтры, если они есть, должны быть столбцами кластеризации (у вас не может быть фильтра, который не является ни ключом раздела, ни столбцами кластеризации - опять же, если вы не используете ALLOW FILTERING).
Эти ограничения, исходящие из мира RDBMS, неестественны и трудно поддаются адаптации, и из-за них вам, возможно, придется дублировать данные в очень похожие структуры (возможно, единственное отличие - это ключи разделов и столбцы кластеризации). По большей части, приложение должно манипулировать каждой структурой, когда происходят изменения, и приложение должно знать, какую таблицу запрашивать, основываясь на предоставленных фильтрах. Все это считается болезненным, происходящим из реляционного мира (где вы можете делать все, что хотите, с одной структурой). Эти «ограничения» необходимо сопоставить с причинами, по которым вы выбрали Cassandra для своего механизма хранения.
Надеюсь, это поможет.
-Джит