Тайм-аут чтения Кассандры

Я извлекаю большой объем данных из cassandra 2.0, но, к сожалению, получаю исключение тайм-аута. Моя таблица:

CREATE KEYSPACE StatisticsKeyspace
  WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 };


CREATE TABLE StatisticsKeyspace.HourlyStatistics(
KeywordId text,
Date timestamp,
HourOfDay int,
Impressions int,
Clicks int,
AveragePosition double,
ConversionRate double,
AOV double,
AverageCPC double,
Cost double,
Bid double,
PRIMARY KEY(KeywordId, Date, HourOfDay)
);
CREATE INDEX ON StatisticsKeyspace.HourlyStatistics(Date);

Мой запрос:

SELECT KeywordId, Date, HourOfDay, Impressions, Clicks,AveragePosition,ConversionRate,AOV,AverageCPC,Bid 
FROM StatisticsKeyspace.hourlystatistics 
WHERE Date >= '2014-03-22' AND Date <= '2014-03-24'

Я изменил конфигурации в моем файле cassandra.yaml.

read_request_timeout_in_ms: 60000
range_request_timeout_in_ms: 60000
write_request_timeout_in_ms: 40000
cas_contention_timeout_in_ms: 3000
truncate_request_timeout_in_ms: 60000
request_timeout_in_ms: 60000

Но все равно выкидывает таймаут примерно через 10 секунд. Любые идеи, как я могу решить эту проблему?


cassandra datastax-java-driver datastax cassandra-2.0 cassandra-cli
person Wild Goat    schedule 16.06.2014    source источник
comment
Это использование cassandra-cli или java-приложения? Из ваших тегов это остается неясным, хотя запрос намекает на cli.   -  person John    schedule 16.06.2014

Ответы (1)


arrow_upward
7
arrow_downward

При использовании java-клиента из datastax нумерация страниц включена по умолчанию с набором строк 5000. Если вы все еще получаете тайм-аут, вы можете попытаться уменьшить его, используя

public Statement setFetchSize(int fetchSize)

(подробнее)

Если вы используете cli, вам может понадобиться поэкспериментировать с ручной разбивкой на страницы:

SELECT KeywordId, Date, HourOfDay, Impressions, Clicks,AveragePosition,ConversionRate,AOV,AverageCPC,Bid 
FROM StatisticsKeyspace.hourlystatistics 
WHERE Date >= '2014-03-22' AND Date <= '2014-03-24' 
LIMIT 100;

SELECT * FROM ....  WHERE token(KeywordId) > token([Last KeywordId received]) AND ...
LIMIT 100;

Чтобы обнаружить некоторые проблемы с кластером, вы можете попробовать выбрать с пределом 1, возможно, есть основная проблема.

Надеюсь, это поможет.

Если у вас по-прежнему возникают проблемы с производительностью при выполнении запроса, я бы посмотрел на ваш вторичный индекс, поскольку объем передаваемых данных кажется разумным (возвращаются только «маленькие» типы данных). Если я прав, изменение размера выборки мало что изменит. Вместо этого вы вставляете даты только в столбец «Дата» (отметка времени)? Если вместо этого вы вставляете фактические метки времени, вторичный индекс в этом столбце будет очень медленным из-за количества элементов. Если вы вставите только дату, отметка времени по умолчанию будет равна дате + "00". :00:00" + TZ, что должно уменьшить количество элементов и, таким образом, повысить скорость поиска. (остерегайтесь проблем с часовым поясом!) Чтобы быть абсолютно уверенным, попробуйте использовать вторичный индекс для столбца с другим типом данных, например, int для даты (считая дни с 1970-01-01 или sth).

person John    schedule 16.06.2014
comment
Спасибо! На самом деле я был изменен SocketOptions и установил тайм-аут в моем Java-клиенте datastax. Прямо сейчас это не тайм-аут, но занимает целую вечность. Как вы думаете, я могу улучшить производительность, настроив FetchSize? - person Wild Goat; 16.06.2014
comment
Я обновил свой ответ. Попробуйте, если уменьшение FetchSize поможет выявить проблему. Возможно, это вторичный индекс (см. Мой ответ). - person John; 17.06.2014
comment
Спасибо за ваш ответ. Я до сих пор не понял, почему временная метка снижает производительность, так как я округляю ее до полуночи, в моем понимании количество индексов не должно отличаться от количества дней с 1970 года, но я обязательно попробую прямо сейчас! Кроме того, как вы думаете, должен ли я переместить свой Date как первичный индекс и keywordId как вторичный, как это отразится на моей производительности INSERT/READ? Большое спасибо! - person Wild Goat; 17.06.2014
comment
Ну, основное влияние PK — это распределение между вашими узлами. Для оптимальной производительности записи требуется равномерное распределение. Использование только атрибутов, связанных со временем, всегда будет приводить к горячим остановкам (например, каждая запись между 10:00 и 11:00 может выполняться на один и тот же узел). Не могли бы вы дать некоторую информацию о вашем поле keywordId? Если количество идентификаторов ключевых слов ограничено, вы можете в любое время добавить его в качестве еще одного вторичного индекса и посмотреть, увеличит ли это скорость поиска. Кроме того, попробуйте отслеживать пропускную способность чтения/записи, например, с помощью Datastax opsCenter или аналогичного. - person John; 17.06.2014
comment
Спасибо! Я пытался использовать int days с 1970 года и похоже, что это улучшило производительность, но в любом случае у меня только один узел, не могли бы вы объяснить это поведение и почему он быстрее учитывает тот факт, что я округлял все даты до полуночи 00:00:00 и работает на одном узле. Кроме того, мое ключевое слово представляет собой строку в следующем формате: 53961673d446bd71503d8bde - person Wild Goat; 17.06.2014
comment
Как у вас может быть только 1 узел, но replication_factor равен 3 (в вашем вопросе)? Это может вызвать проблемы; документация: когда коэффициент репликации превышает количество узлов, записи отклоняются, но операции чтения обслуживаются до тех пор, пока соблюдается желаемый уровень согласованности. Что касается производительности вторичного индекса округленных временных меток по сравнению с целыми числами, я не уверен, как временные метки индексируются Cassandra. Вторичные индексы не распределены, как таблицы обратного просмотра, поэтому поиск попадает в каждый узел, и производительность в порядке, если мощность не так высока. Может быть, поиск дорого обходится ТС.. - person John; 17.06.2014
comment
Спасибо! Должен ли я поставить replication_factor:1, если я только на одном узле? - person Wild Goat; 17.06.2014
comment
Давайте продолжим обсуждение в чате. - person John; 17.06.2014
comment
@omni, как точка доступа в ПК влияет на распределение по узлам? Разве распределение не основано на хэше ПК, что устраняет проблему таких горячих точек в ключе? - person Stevel; 05.10.2016
comment
@Stevel Это может вызвать другой вопрос, но здесь мы идем: в исходном сообщении говорится, что он использует даты в своем ПК, что имеет все значение. Распределение по узлам определяется ключом раздела, в данном случае KeywordId. Если бы вместо этого он использовал свою дату в качестве ключа секции, эта дата привела бы к тому же хешированному ключу секции в этот день, поскольку хэш с одним и тем же значением даты всегда будет возвращать одно и то же хешированное значение. Все записи данных за этот день будут попадать в одни и те же узлы, создавая горячую точку. - person John; 05.10.2016