Производительность с rows_per_partition и моделью данных в Cassandra

У нас есть приложение с 10 таблицами основных [статических] данных (каждая из которых содержит около 100 строк). Обновления этих таблиц незначительны. Все данные этих таблиц будут отображаться в приложении как список выбора.

  1. Произойдет ли какое-либо улучшение производительности, если значение rows_per_partition будет изменено на 100, как показано ниже, со значения по умолчанию «NONE»? Поскольку эти главные таблицы не обновляются и не доступны постоянно

Eg:

ALTER TABLE devloc.regions
with caching = {
    'keys' : 'ALL',
    'rows_per_partition' : '100'
};

  1. Одна таблица имеет 100 столбцов данных и часто запрашивается для отображения информации. Это похоже на справочную таблицу.

    модель данных1

    СОЗДАТЬ ТАБЛИЦУ devloc.display_all (id uuid PRIMARY KEY, отметка времени datevalue, текст col2, текст col3, текст col4, текст col5, текст col6, текст col7, ....... до 100 столбцов)

    Запрос: выберите * из devloc.display_all, где id = 89d23c25-4921-4d57-8f2c-87a9f4ca204d;

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

модель данных2

СОЗДАТЬ ТАБЛИЦУ devloc.display_all (идентификатор uuid, временная метка значения даты, текст col2, текст col3, текст col4, текст col5, текст col6, текст col7, ....... до 100 столбцов) с первичным ключом (id, datevalue);

Завершил стресс-тестирование для обеих моделей и показал хорошую производительность, когда значение даты не использовалось в качестве корзины.

введите описание изображения здесь

Первый всплеск связан с datamodel1, а второй - с datamodel2. Для нас задержка имеет большое значение даже в миллисекундах. Может кто-нибудь помочь мне понять?

DSE 4.8.5
read Write Consistency level LOCAL_QUORUM
replication 3
Datacenters 2

cassandra data-modeling datastax-enterprise
person Arun    schedule 24.03.2016    source источник

Ответы (2)


arrow_upward
0
arrow_downward

  1. rows_per_partition включает кеширование строк и определяет, сколько первых строк раздела будет храниться в кеше. Если у вас всего 100 строк, то да, он должен их кешировать. Этот параметр также может иметь значение ALL. Однако дополнительно row_cache_size_in_mb должно быть установлено значение, которое может содержать все ваши строки в памяти.

  2. Производительности не очень (если вы запрашиваете его только по идентификатору). Это может дать вам точный порядок, но кажется, что у вас есть одна строка для каждого идентификатора (для каждого разрешения), поэтому вам это не нужно. Помните, что нижележащее значение ключа кластеризации становится префиксом каждого имени столбца в данной строке, поэтому теоретически это может вызвать некоторые накладные расходы (см. Часть таблицы с составными ключами http://www.planetcassandra.org/blog/составные-ключи-in-apache-cassandra/).

person mmatloka    schedule 24.03.2016

arrow_upward
0
arrow_downward

  1. rows_per_partition - это количество строк каждого раздела, которое будет кэшироваться в «Строчном кэше» (это первое место, на которое будет обращать внимание кассандра, когда вы запустите запрос на чтение). Когда вы снова прочитаете эту строку, кассандре не нужно будет снова искать эту строку в таблице, поэтому ваш запрос на чтение будет быстрее.

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

person madooc    schedule 01.04.2016