Таблица CQL Cassandra INSERT и проблема с INDEX

Я использую приведенную ниже таблицу в нашем случае использования -

create table test_new (
    employee_id text,
    employee_name text,
    value text,
    last_modified_date timeuuid,
    primary key (employee_id, last_modified_date)
   );

create index employee_name_idx on test_new (employee_name);

В приведенной выше таблице employee_id всегда будет уникальным, начиная с 1 и заканчивая 32767. Таким образом, наш шаблон запроса выглядит следующим образом:

  1. Дайте мне все по любому из employee_id?
  2. Дайте мне все, что изменилось за последние 5 минут?
  3. Дайте мне все для любого из employee_name?

Я буду вставлять данные ниже в мою таблицу выше -

insert into test_new (employee_id, employee_name, value, last_modified_date) 
        values ('1', 'e27',  'some_value', now());
insert into test_new (employee_id, employee_name, value, last_modified_date) 
        values ('2', 'e27',  'some_new_value', now());
insert into test_new (employee_id, employee_name, value, last_modified_date) 
        values ('3', 'e28',  'some_new_again_value', now());

Я могу выполнить все мои шаблоны запросов выше, но есть еще одна проблема.


Мой вопрос заключается в том, чтобы избежать этого конкретного сценария для приведенного ниже запроса. Что, если каким-то образом ошибочно попытается выполнить приведенный ниже запрос. Если они это сделают, тогда будет создана другая строка с employee_id равным 1 и с другими полями? Я не хочу, чтобы кто-то снова вставлял один и тот же employee_id, если он уже есть в базе данных Cassandra.

insert into test_new (employee_id, employee_name, value, last_modified_date) 
         values ('1', 'e29',  'some_new_value', now());

Есть предположения? Я знаю, что это спорная ситуация из-за дебатов по поводу использования СУБД против Cassandra.

А также создание индекса для employee_name вызовет какие-либо проблемы? В моем примере одно и то же имя_сотрудника может иметь несколько идентификаторов_сотрудников, но с разными значениями. Имея в виду, что employee_id не будет больше, чем 32767, поэтому максимальное количество строк в приведенной выше таблице будет 32767.

У меня Кассандра 1.2.9


person AKIWEB    schedule 08.11.2013    source источник
comment
Если (employee_id:value) уникален (или должен быть), то почему это не ваш ПК? Это остановит повторяющиеся вставки (хотя это будет действовать как обновление, поэтому ваша last_modified_date изменится).   -  person AndySavage    schedule 13.11.2013


Ответы (1)


Я не хочу, чтобы кто-то снова вставлял один и тот же employee_id, если он уже есть в базе данных Cassandra.

Единственный способ гарантировать ("вставить, только если строки с таким же PK уже не существует"), который предлагает Cassandra, — это условные вставки/изменения, представленные в Cassandra 2.0: http://www.datastax.com/dev/blog/lightweight-transactions-in-cassandra-2-0.

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

При этом, если единственное беспокойство заключается в том, что вы не используете повторно один и тот же employee_id дважды, стандартное решение в C * состоит в том, чтобы просто использовать uuid для employee_id, поэтому вам не нужно беспокоиться о коллизиях.

person pcmanus    schedule 15.11.2013