Можем ли мы использовать UDT в качестве ключа раздела в cassandra [duplicate]

Question

Можем ли мы использовать UDT в качестве ключа раздела в cassandra [duplicate]

Исключение нулевого указателя генерируется, когда приложение пытается использовать null в случае, когда требуется объект. К ним относятся:

Вызов метода экземпляра объекта null.
Доступ или изменение поля объекта null.
Принимая длину null, как если бы это был массив.
Доступ или изменение слотов null, как если бы это был массив.
Бросок null как будто это было значение Throwable.

Приложения должны бросать экземпляры этого класса, чтобы указать на другие незаконные использования объекта null.

Ссылка: http://docs.oracle.com/javase/8/docs/api/java/lang/NullPointerException.html

3

cassandra datastax

задан ashic 21 October 2014 в 17:42

1 ответ

Другие вопросы по тегам:

cassandra datastax

Похожие вопросы:

score 5 · Accepted Answer

Это предложение предназначалось для того, чтобы препятствовать пользователям использовать UDT для столбцов PK без разбора. Основная мотивация UDT в его нынешнем воплощении (то есть, учитывая, что Cassandra поддерживает «замороженный» UDT), предназначена для хранения более сложных значений внутри коллекций. Внешние коллекции UDT могут использовать его, но стоит вам дважды спросить, если вам это нужно. Например:

CREATE TYPE myType (a text, b int);

CREATE TABLE myTable (id uuid PRIMARY KEY, v frozen<myType>);

часто не очень разумно, поскольку вы теряете возможность обновления v.a без обновления v.b. Так что на самом деле это более гибко:

CREATE TABLE myTable (id uuid PRIMARY KEY, a text, b int);

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

CREATE TYPE myType (a text, b int);

CREATE TABLE myTable (id frozen<myType> PRIMARY KEY);

более просто:

CREATE TABLE myTable (a text, b int, PRIMARY KEY ((a, b)))

Кроме того, что касается первичного ключа, любой сложный UDT, вероятно, не имеет смысла. Рассмотрим даже умеренно сложный тип, например:

CREATE TYPE address ( number int, street text, city text, phones set<text> )

Использование такого типа внутри первичного ключа почти наверняка не очень полезно, поскольку ПК идентифицирует строки и так 2 адреса, которые одинаковы, за исключением того, что набор телефонов не будет идентифицировать одну и ту же строку. Существует не так много ситуаций, когда это было бы желательно. В целом, PK имеет тенденцию быть относительно простым, и вы можете иметь мелкозернистый контроль над столбцами кластеризации, поэтому UDT редко бывают хорошими кандидатами.

Таким образом, UDT в столбцах PK не является всегда плохо, просто не часто полезно в этом контексте, и поэтому пользователям не следует пристально изучать способы использования UDT для столбцов PK только потому, что это разрешено.