Есть ли у Cassandra 0.7.2 проблемы с производительностью с get_range_slices?

Question

У меня есть приложение, которое записывает несколько миллиардов записей в Cassandra и удаляет дубликаты по ключу. Затем он группирует их по другим полям, таким как заголовок, в последовательных фазах, так что дальнейшая обработка может быть выполнена для групп похожих записей. Приложение распределено по кластеру машин, потому что мне нужно, чтобы оно было завершено в разумные сроки (часы, а не недели).

Одна фаза приложения работает, записывая записи в Cassandra с помощью клиента hector и сохраняя записи в семействе столбцов с первичными ключами записей в качестве ключей Cassandra. Отметка времени установлена ​​на дату последнего обновления записи, поэтому я получаю только самую последнюю запись для каждого ключа.

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

Я выполнил это пакетное чтение, используя Cassandra.Client.describe_ring (), чтобы выяснить, какая машина в кольце является главной для какого TokenRange. Затем я сравниваю мастер для каждого TokenRange с локальным хостом, чтобы выяснить, какие диапазоны токенов принадлежат локальной машине (удаленное чтение слишком медленное для этого типа пакетной обработки). Как только я узнаю, какие TokenRanges есть на каждой машине локально, я получаю разделение равномерного размера с помощью Cassandra.Client.describe_splits ().

Когда у меня есть куча хороших разделений равномерного размера, которые можно прочитать из локального экземпляра Cassandra, я начинаю читать их как можно быстрее, используя Cassandra.Client.get_range_slices () с ConsistencyLevel.ONE, так что он не нуждается делать любые удаленные чтения. Я получаю 100 строк за раз, последовательно через весь TokenRange (я пробовал разные размеры пакетов, и 100, похоже, лучше всего подходят для этого приложения).

Все это прекрасно работает на Cassandra 0.7.0 с небольшой настройкой размеров памяти и конфигураций семейства столбцов. Таким образом я мог читать от 4000 до 5000 записей в секунду, и локальные диски работали с максимальной скоростью.

Вот пример разделения и скорости, которую я бы увидел при Cassandra 0.7.0:

10/12/20 20:13:08 INFO m4.BulkCassandraReader: split - 20253030905057371310864605462970389448 : 21603066481002044331198075418409137847
10/12/20 20:13:08 INFO m4.BulkCassandraReader: split - 21603066481002044331198075418409137847 : 22954928635254859789637508509439425340
10/12/20 20:13:08 INFO m4.BulkCassandraReader: split - 22954928635254859789637508509439425340 : 24305566132297427526085826378091426496
10/12/20 20:13:08 INFO m4.BulkCassandraReader: split - 24305566132297427526085826378091426496 : 25656389102612459596423578948163378922
10/12/20 20:13:08 INFO m4.BulkCassandraReader: split - 25656389102612459596423578948163378922 : 27005014429213692076328107702662045855
10/12/20 20:13:08 INFO m4.BulkCassandraReader: split - 27005014429213692076328107702662045855 : 28356863910078000000000000000000000000
10/12/20 20:13:18 INFO m4.TagGenerator: 42530 records read so far at a rate of 04250.87/s
10/12/20 20:13:28 INFO m4.TagGenerator: 90000 records read so far at a rate of 04498.43/s
10/12/20 20:13:38 INFO m4.TagGenerator: 135470 records read so far at a rate of 04514.01/s
10/12/20 20:13:48 INFO m4.TagGenerator: 183946 records read so far at a rate of 04597.16/s
10/12/20 20:13:58 INFO m4.TagGenerator: 232105 records read so far at a rate of 04640.62/s

Когда я обновился до Cassandra 0.7.2, мне пришлось перестраивать конфиги, потому что там было несколько новых опций и тому подобное, но я постарался, чтобы все соответствующие настройки были такими же, как в конфигах 0.7.0, которые работал. Однако я едва могу читать 50 записей в секунду с новой версией Cassandra.

Вот пример разделения и скорости, которую я вижу сейчас под Cassandra 0.7.2:

21:02:29.289 [main] INFO  c.p.m.a.batch.BulkCassandraReader - split - 50626015574749929715914856324464978537 : 51655803550438151478740341433770971587
21:02:29.290 [main] INFO  c.p.m.a.batch.BulkCassandraReader - split - 51655803550438151478740341433770971587 : 52653823936598659324985752464905867108
21:02:29.290 [main] INFO  c.p.m.a.batch.BulkCassandraReader - split - 52653823936598659324985752464905867108 : 53666243390660291830842663894184766908
21:02:29.290 [main] INFO  c.p.m.a.batch.BulkCassandraReader - split - 53666243390660291830842663894184766908 : 54679285704932468135374743350323835866
21:02:29.290 [main] INFO  c.p.m.a.batch.BulkCassandraReader - split - 54679285704932468135374743350323835866 : 55681782994511360383246832524957504246
21:02:29.291 [main] INFO  c.p.m.a.batch.BulkCassandraReader - split - 55681782994511360383246832524957504246 : 56713727820156410577229101238628035242
21:09:06.910 [Thread-0] INFO  c.p.m.assembly.batch.TagGenerator - 100 records read so far at a rate of 00000.25/s
21:13:00.953 [Thread-0] INFO  c.p.m.assembly.batch.TagGenerator - 10100 records read so far at a rate of 00015.96/s
21:14:53.893 [Thread-0] INFO  c.p.m.assembly.batch.TagGenerator - 20100 records read so far at a rate of 00026.96/s
21:16:37.451 [Thread-0] INFO  c.p.m.assembly.batch.TagGenerator - 30100 records read so far at a rate of 00035.44/s
21:18:35.895 [Thread-0] INFO  c.p.m.assembly.batch.TagGenerator - 40100 records read so far at a rate of 00041.44/s

Как вы, вероятно, видите из журналов, Код перемещен в другой пакет, но кроме этого код не изменился. Он работает на том же оборудовании, и все настройки памяти одинаковы.

Я мог видеть некоторую разницу в производительности между версиями Cassandra, но что-то столь же потрясающее, как это (100-кратное падение производительности), похоже, что я упускаю что-то фундаментальное. Даже до настройки семейств столбцов и настроек памяти на 0.7.0 ЭТО никогда не было ТАКИМ медленным.

Кто-нибудь знает, что может объяснить это? Есть ли какие-то настройки, которые я мог бы пропустить, что могло бы вызвать это? Что-то изменилось с функциями Cassandra для поддержки hasoop, который просто недокументирован? Читая заметки о выпуске, я просто не могу найти ничего, что могло бы объяснить это. Буду признателен за любую помощь в исправлении этого, или даже просто объяснение того, почему он мог перестать работать.

Answer 1

Я решил, что мне следует замкнуть этот цикл, так как мы добрались до сути проблемы, и проблема была не в проблеме Кассандры, а в проблеме конфигурации.

Когда мы обновили до 0.7.2 одну частьКонфигурация, которая изменилась, и я пропустил, была Token Ring.В нашей конфигурации 0.7.0 у нас был первый токен как 2 ^ 127/12, а в нашей конфигурации 0.7.2 у нас был первый токен как 0. Это привело к тому, что один узел получил разделение 0: 0.0: 0 кажется магическим диапазоном, который просит Кассандру обо всем.Таким образом, у нас был один узел в кластере, извлекающий все данные по сети.Сетевой трафик к этому узлу - это то, что в конечном итоге привело нас к корню проблемы.

Исправление состояло в том, чтобы исправить код для проверки случая 0: 0 и обработать его, чтобы код теперь обрабатывал Cassandra.кластеры в любом случае разделены (первый узел как 0 или другой).

Короче говоря, не проблема Кассандры.Проблема конфигурации с моей стороны.

Answer 2

Не звонит здесь.Я предполагаю, что вы попали в регрессию честности к совершенству.

Вы можете попробовать переключить режим доступа к диску в стандартный режим.Вы также можете попробовать отключить JNA.(Они должны обходить 1713 и 1470 соответственно, которые являются наиболее вероятными виновниками. Но, «скорее всего» здесь только вопрос степени, я бы дал шансы на 20%.)

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

На будущееДля справки, список пользователей Cassandra - лучший форум, чем StackOverflow для дискуссий «Я думаю, я нашел ошибку».Там гораздо больше опыта.