Ограничение размера Cassandra на ключ раздела - PullRequest
Новая
       14

Ограничение размера Cassandra на ключ раздела

0 голосов
/ 07 января 2019

У меня есть эта таблица в Кассандре: 

CREATE TABLE adress (
adress_id uuid,
adress_name text,
key1 text,
key2 text,
key3 text,
key4 text,
effective_date timestamp,
value text,
active boolean,
PRIMARY KEY ((adress_id, adress_name), key1, key2, key3, key4, effective_date)
)

Как я понимаю, cassandra будет распространять данные адреса таблицы на основе ключа раздела (adress_id, adress_name).

Существует риск, когда я пытаюсь вставить слишком много данных, если они совпадают (adress_id, adress_name) ..

Я хотел бы проверить перед вставкой данных, проверка происходит так:

  1. Сколько данных у меня уже есть в Кассандре с парой (adress_id, adress_name), предположим, это 5MO.
  2. Мне нужно проверить, чтобы размер данных, которые я пытаюсь вставить, не превышал предел Кассандры на ключ раздела минус существующие данные в Кассандре.

Мой вопрос заключается в том, как запросить у cassandra размер данных с парой (adress_id, adress_name). После этого, каково ограничение размера ключа раздела в Cassandra.

1 Ответ

0 голосов
/ 08 января 2019

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

Технически возможно определить существующий размер раздела, но он никогда не будет эффективным. Чтобы понять почему, вам нужно вспомнить, как Cassandra хранит данные. Содержимое одного раздела не всегда хранится в одном и том же sstable (файл на диске) - данные для одного раздела могут быть распределены по нескольким файлам. Один файл может иметь несколько строк, другой файл может содержать несколько строк, третий файл может удалять или изменять некоторые старые строки и т. Д. Чтобы выяснить длину раздела, Кассандре нужно будет прочитать все эти данные, объединить их и измерить размер результата. Cassandra делает , а не , обычно это делает при записи - она ​​просто записывает новое обновление в память (и, в конечном итоге, новый sstable), без предварительного чтения старых данных. Это то, что делает записи в Cassandra такими быстрыми - и ваша идея прочитать весь раздел перед каждой записью резко замедлит их.

Наконец, хотя Cassandra не очень хорошо справляется с огромными разделами, нет никакой внутренней причины, по которой это невозможно, если разработчики захотят решить эту проблему. Разработчики Cassandra клонируют Scylla, обеспокоенные этой проблемой, и работают над ее улучшением, но даже в Scylla обработка огромных разделов еще не идеальна. Но в конце концов это будет. Почти - всегда будет ограничение на размер одного раздела (который, по определению, хранится на одном узле) как размер одного диска. Это ограничение также может стать серьезной проблемой, если ваша модель данных действительно повреждена, и вы можете получить терабайт в одном разделе.

...