Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Дмитрий Константинов — Cassandra, истории из жи...

Moscow JUG
October 23, 2019

Дмитрий Константинов — Cassandra, истории из жизни performance- инженера

Цель доклада — рассказать, какие есть проблемы, известные баги и подводные камни для Apache Cassandra и OSS DataStax Java driver.

Рассказ будет построен на основании практического опыта, полученного в рамках анализа проблем производительности для ряда проектов, в которых участвовал и участвует автор. В рамках доклада будут описаны известные проблемы и способы их решения или обхода, продемонстрированы возможные подходы и инструменты для анализа производительности, сравнительные замеры различных опций при работе Apache Cassandra.

Целевая аудитория — разработчики и архитекторы, которые уже используют или хотят использовать Cassandra для хранения данных, и для которых важен вопрос производительности.

Moscow JUG

October 23, 2019
Tweet

More Decks by Moscow JUG

Other Decks in Programming

Transcript

  1. 2 © 2019 NetCracker Technology Corporation. О себе • Дмитрий

    Константинов • Системный архитектор и, по-прежнему, практикующий Java разработчик в компании Netcracker J
  2. 3 © 2019 NetCracker Technology Corporation. О себе • Дмитрий

    Константинов • Системный архитектор и, по-прежнему, практикующий Java разработчик в компании Netcracker J • Активно работаю с различными OpenSource технологиями, такими как Apache Cassandra, Zookeeper, Kafka, Hazelcast • Профессиональные интересы: • распределенные системы • производительность • отказоустойчивость
  3. 4 © 2019 NetCracker Technology Corporation. План доклада • О

    чем вообще говорим, какого рода системы обсуждаем
  4. 5 © 2019 NetCracker Technology Corporation. План доклада • О

    чем вообще говорим, какого рода системы обсуждаем • Приложение / драйвер
  5. 6 © 2019 NetCracker Technology Corporation. План доклада • О

    чем вообще говорим, какого рода системы обсуждаем • Приложение / драйвер • Сервер • Запись • Чтение • Выводы
  6. 7 © 2019 NetCracker Technology Corporation. Этот доклад НЕ об

    этом Систематический подход / методология по тестированию производительности и оптимизации
  7. 8 © 2019 NetCracker Technology Corporation. Какого рода системы и

    нагрузку обсуждаем • Linux • Cassandra 3.x • Java based application, Java driver 3.x • Несколько датацентров
  8. 9 © 2019 NetCracker Technology Corporation. Какого рода системы и

    нагрузку обсуждаем • Linux • Cassandra 3.x • Java based application, Java driver 3.x • Несколько датацентров • Consistency level, обычно - LOCAL_QUORUM • Тип системы: OLTP или offline batch • ~100k запросов в секунду в базу, read/write: ~50% / 50%
  9. 10 © 2019 NetCracker Technology Corporation. Чем тестируем под нагрузкой,

    как собираем метрики • Нагрузка • E2E тесты – генератор нагрузки уровня бизнес-логики • Упрощенные тесты отдельных сценариев – свой генератор нагрузки для базы • Совсем простые бенчмарки - cassandra-stress • https://thelastpickle.com/blog/2017/02/08/Modeling-real- life-workloads-with-cassandra-stress.html
  10. 12 © 2019 NetCracker Technology Corporation. • Запустили тесты •

    Все плохо, e2e тормозит - в требования не укладываемся
  11. 13 © 2019 NetCracker Technology Corporation. Cобираем метрики • Метрики

    • CollectD - сбор • FastJMX plugin • CPU/память/диск/сеть • Clickhouse – хранилище метрик • Grafana - визуализация
  12. 14 © 2019 NetCracker Technology Corporation. Метрики драйвера • Встроенных

    - достаточно мало, очень общие • Но есть LatencyTracker интерфейс - точка расширения в драйвере • Можно сделать свои детальные метрики, например на базе HdrHistogram
  13. 16 © 2019 NetCracker Technology Corporation. Некоторые концепции в Cassandra

    за 5 минут • Keyspace • Контейнер для таблиц • Задает стратегию репликации - количество реплик в каждом датацентре
  14. 17 © 2019 NetCracker Technology Corporation. Структура первичного ключа •

    Таблицы имеют составной первичный ключ, состоящий из 2 частей: • Partition key – отвечает за распределение данных по кластеру. Каждая партиция имеет несколько реплик.
  15. 18 © 2019 NetCracker Technology Corporation. Структура первичного ключа •

    Таблицы имеют составной первичный ключ, состоящий из 2 частей: • Partition key – отвечает за распределение данных по кластеру. Каждая партиция имеет несколько реплик. • Clustering key – строки внутри каждой партиции упорядочены по данной части ключа. Дает возможность делать запросы по диапазону значений.
  16. 19 © 2019 NetCracker Technology Corporation. Tombstone • Tombstone –

    отметка в базе о том, что данные (ячейка, строка, диапазон строк, …) удалены
  17. 20 © 2019 NetCracker Technology Corporation. Tombstone • Tombstone –

    отметка в базе о том, что данные (ячейка, строка, диапазон строк, …) удалены • А зачем он нужен, почему не удалять сразу: 1. Модель хранения данных – во время записи существующие данные не читаются
  18. 21 © 2019 NetCracker Technology Corporation. Tombstone • Tombstone –

    отметка в базе о том, что данные (ячейка, строка, диапазон строк, …) удалены • А зачем он нужен, почему не удалять сразу: 1. Модель хранения данных – во время записи существующие данные не читаются 2. Чтобы избежать “зомби” (возвращения удаленных данных). Cassandra – распределённая система без выделенного лидера, использующая last-write-win стратегию разрешения конфликтов
  19. 22 © 2019 NetCracker Technology Corporation. Tombstone • Tombstone –

    отметка в базе о том, что данные (ячейка, строка, диапазон строк, …) удалены • А зачем он нужен, почему не удалять сразу: 1. Модель хранения данных – во время записи существующие данные не читаются 2. Чтобы избежать “зомби” (возвращения удаленных данных). Cassandra – распределённая система без выделенного лидера, использующая last-write-win стратегию разрешения конфликтов • Время жизни tombstone ограничено параметром на уровне таблицы - gc_grace_seconds
  20. 25 © 2019 NetCracker Technology Corporation. Базовые рекомендации Используем PreparedStatement

    • Уменьшаем накладные расходы на передачу запроса (передается только его id и параметры) • Убираем расходы на разбор запроса на стороне сервера-координатора • PreparedStatement в Cassandra driver потокобезопасен, создаем один раз и используем из всех потоков
  21. 26 © 2019 NetCracker Technology Corporation. Базовые рекомендации BatchStatement •

    Есть возможность объединять несколько INSERT/UPDATE/DELETE запросов в 1 сетевой запрос • BatchStatement бывают разные: • Logged – атомарность применения (используем, только если действительно нужно – есть существенные накладные расходы)
  22. 27 © 2019 NetCracker Technology Corporation. Базовые рекомендации BatchStatement •

    Есть возможность объединять несколько INSERT/UPDATE/DELETE запросов в 1 сетевой запрос • BatchStatement бывают разные: • Logged – атомарность применения (используем, только если действительно нужно – есть существенные накладные расходы) • Unlogged - просто пачка запросов, координатор их разделит и выполнит отдельно, лучше это сделать на клиенте
  23. 28 © 2019 NetCracker Technology Corporation. Базовые рекомендации BatchStatement •

    Есть возможность объединять несколько INSERT/UPDATE/DELETE запросов в 1 сетевой запрос • BatchStatement бывают разные: • Logged – атомарность применения (используем, только если действительно нужно – есть существенные накладные расходы) • Unlogged - просто пачка запросов, координатор их разделит и выполнит отдельно, лучше это сделать на клиенте • Single-partition
  24. 29 © 2019 NetCracker Technology Corporation. Базовые рекомендации Single-partition BatchStatement

    • Partition ключ у всех вложенных запросов совпадает • Keyspace у всех вложенных запросов совпадает
  25. 30 © 2019 NetCracker Technology Corporation. Базовые рекомендации Single-partition BatchStatement

    • Partition ключ у всех вложенных запросов совпадает • Keyspace у всех вложенных запросов совпадает • Плюсы: • Нет накладных расходов • Если имя таблицы совпадает - есть атомарность и изоляция
  26. 31 © 2019 NetCracker Technology Corporation. Базовые рекомендации Single-partition BatchStatement

    • Partition ключ у всех вложенных запросов совпадает • Keyspace у всех вложенных запросов совпадает • Плюсы: • Нет накладных расходов • Если имя таблицы совпадает - есть атомарность и изоляция • Если таблицы разные - есть атомарность с точки зрения применения, но нет изоляции (можно увидеть частичное изменение) Больше деталей: https://www.datastax.com/blog/2012/02/coming-cassandra-11-row-level-isolation
  27. 32 © 2019 NetCracker Technology Corporation. Базовые рекомендации Используем netty-transport-native-epoll

    для драйвера • Ниже CPU usage • Меньше выделений памяти
  28. 33 © 2019 NetCracker Technology Corporation. Драйвер • Справка •

    Базовые рекомендации • Анализ издержек на стороне драйвера
  29. 34 © 2019 NetCracker Technology Corporation. Приложение/драйвер • Наблюдение: приложение

    потребляет много CPU и выделяет довольно много объектов в памяти • Базовые рекомендации уже применили • Посмотрим детали: • Async profiler – CPU профиль • Java Flight Recorder - выделение памяти, конфликты при захвате блокировок • GC логи – как часто собираем мусор, какие паузы
  30. 35 © 2019 NetCracker Technology Corporation. Драйвер • Справка •

    Базовые рекомендации • Анализ издержек на стороне драйвера • Формирование запроса
  31. 36 © 2019 NetCracker Technology Corporation. Приложение / драйвер –

    создание запроса BoundStatement.set: 1. Ищем Codec для типа значения 2. Сериализуем значение в ByteBuffer, используя найденный Codec 3. Ищем по имени – позиции в ByteBuffer[] values 4. Результат кладем в ByteBuffer[] values
  32. 37 © 2019 NetCracker Technology Corporation. Приложение / драйвер –

    создание запроса BoundStatement.set: 1. Ищем Codec для типа значения 2. Сериализуем значение в ByteBuffer, используя найденный Codec 3. Ищем по имени – позиции в ByteBuffer[] values 4. Результат кладем в ByteBuffer[] values
  33. 38 © 2019 NetCracker Technology Corporation. Сodecs и накладные расходы,

    связанные с ними • “Ну, зачем ты, зачем ты туда полез?”
  34. 39 © 2019 NetCracker Technology Corporation. Сodecs и накладные расходы,

    связанные с ними • Все значения драйвер кодирует/декодирует через настраиваемые кодеки (Codec interface) • Кеш кодеков достаточно ресурсоемкий • Ускоряли: • 3.2.0 - JAVA-1308: CodecRegistry performance improvements. • 3.7.0 - JAVA-2002: Reimplement TypeCodec.accepts to improve performance. но все еще есть накладные расходы, особенно для UDT (User Defined Types) и коллекций
  35. 40 © 2019 NetCracker Technology Corporation. Сodecs и накладные расходы,

    связанные с ними • WA: можно указать кодеки явно, в горячих местах:
  36. 41 © 2019 NetCracker Technology Corporation. Сodecs и накладные расходы,

    связанные с ними • WA: можно указать кодеки явно, в горячих местах: • C UDT чуть сложнее:
  37. 42 © 2019 NetCracker Technology Corporation. Сodecs и накладные расходы,

    связанные с ними Простой запрос:
  38. 43 © 2019 NetCracker Technology Corporation. Сodecs и накладные расходы,

    связанные с ними SELECT, 8 строк * 9 колонок в результате 4,479 ns/op 3,881 ns/op
  39. 44 © 2019 NetCracker Technology Corporation. Сodecs и накладные расходы,

    связанные с ними SELECT, 8 строк * 9 колонок в результате • Общее время выполнения запроса меняется на уровне погрешности • CPU usage на стороне клиента: около -0.5% в случае с явных указанием codec • Практической пользы для свежей версии драйвера нет, нет смысла тут копать?! 4,479 ns/op 3,881 ns/op
  40. 46 © 2019 NetCracker Technology Corporation. Сodecs и накладные расходы,

    связанные с ними • SELECT, в результате 4 строки, в каждой - 4 элемента в udt_value списке • Время на get из result set: 50,096 ns/op 9,713 ns/op
  41. 47 © 2019 NetCracker Technology Corporation. Сodecs и накладные расходы,

    связанные с ними • Общее время выполнения запроса: • SELECT, в результате 4 строки, в каждой - 4 элемента в udt_value списке • Время на get из result set: • CPU usage на стороне клиента: -14% для случая с явных указанием codec 1,106 us/op 997 us/op 50,096 ns/op 9,713 ns/op
  42. 48 © 2019 NetCracker Technology Corporation. Приложение / драйвер BoundStatement.set:

    1. Ищем Codec для типа значения 2. Кодируем значение в ByteBuffer, используя найденный Codec 3. Ищем по имени – позиции в ByteBuffer[] values 4. Результат кладем в ByteBuffer[] values
  43. 49 © 2019 NetCracker Technology Corporation. Затраты на кодирование параметров

    • Если есть неравномерность для входных данных – можем кешировать ByteBuffer варианты для часто встречающихся параметров • (String -> ByteBuffer) cache • (Integer -> ByteBuffer) cache • (Date -> ByteBuffer) cache
  44. 50 © 2019 NetCracker Technology Corporation. Приложение / драйвер BoundStatement.set:

    1. Ищем Codec для типа значения 2. Кодируем значение в ByteBuffer, используя найденный Codec 3. Ищем по имени – позиции в ByteBuffer[] values 4. Результат кладем в ByteBuffer[] values
  45. 52 © 2019 NetCracker Technology Corporation. Классика: имена или индексы?

    • BoundStatement • Row • Индексы немного быстрее • Это не просто Map.get – тут еще накладные расходы от CQL спецификации: case-insensitive, кавычки, etc. • UDT
  46. 53 © 2019 NetCracker Technology Corporation. Классика: имена или индексы?

    • SELECT, 8 строк * 9 колонок в результате
  47. 54 © 2019 NetCracker Technology Corporation. Классика: имена или индексы?

    • SELECT, 8 строк * 9 колонок в результате • Общее время выполнения запроса меняется на уровне погрешности • CPU usage на стороне клиента: -1% в случае с указанием индекса 7,141 ns/op 4,993 ns/op
  48. 55 © 2019 NetCracker Technology Corporation. Драйвер • Справка •

    Базовые рекомендации • Анализ издержек на стороне драйвера • Формирование запроса • Выполнение запроса
  49. 63 © 2019 NetCracker Technology Corporation. Драйвер • Справка •

    Базовые рекомендации • Анализ издержек на стороне драйвера • Формирование запроса • Выполнение запроса • Сетевое взаимодействие
  50. 64 © 2019 NetCracker Technology Corporation. -Dcom.datastax.driver.CHECK_IO_DEADLOCKS=false • По умолчанию

    драйвер проверяет, не пытаемся ли мы выполнить блокирующий вызов в Netty Event Loop потоке • Если мы заблокируем этот поток – Netty не сможет обрабатывать сетевые события и Flusher очередь некоторое время, будут задержки и таймауты • Такое возможно, когда мы пытаемся выполнить синхронный запрос в callback вызове для асинхронного запроса
  51. 65 © 2019 NetCracker Technology Corporation. Сетевое взаимодействие • 1659

    (reduce epoll wait overheads) – версия драйвера 3.3.2 • По мотивам: CASSANDRA-13651 • -Dcom.datastax.driver.FLUSHER_SCHEDULE_PERIOD_NS=0 • Избегаем лишних системных вызовов epoll_wait() / timerfd_create() • com.datastax.driver.core.PoolingOptions#setConnectionsPerHost • Несколько TCP соединений к каждой из Cassandra нод
  52. 66 © 2019 NetCracker Technology Corporation. Сетевое взаимодействие • 1659

    (reduce epoll wait overheads) – версия драйвера 3.3.2 • По мотивам: CASSANDRA-13651 • -Dcom.datastax.driver.FLUSHER_SCHEDULE_PERIOD_NS=0 • Избегаем лишних системных вызовов epoll_wait() / timerfd_create() • com.datastax.driver.core.PoolingOptions#setConnectionsPerHost • Несколько TCP соединений к каждой из Cassandra нод • Есть свежие оптимизации со стороны Netty: • https://github.com/netty/netty/pull/9192 - Netty 4.1.37 • “a read on timerfd and eventfd when the EventLoop wakes up" • https://github.com/netty/netty/pull/7834 - Netty 4.1.41 • “timerfd_settime on each call to epoll_wait is expensive”
  53. 68 © 2019 NetCracker Technology Corporation. CHECK_IO_DEADLOCKS, FLUSHER_SCHEDULE_PERIOD_NS - замеры

    Тест CPU, usr CPU, sys CPU, total Baseline (driver 3.7.2) 23.6 15.5 39.1 CHECK_IO_DEADLOCKS=false 22.5 (-1.1) 15.5 38 (-1.1%) FLUSHER_SCHEDULE_PERIOD_NS=0 21 (-2.6) 13 (-2.5) 34 (-5.1%) • Простые SELECT запросы, возвращается 1 строка • Общее время выполнения запроса меняется на уровне погрешности • 50 потоков • CPU:
  54. 69 © 2019 NetCracker Technology Corporation. Драйвер • Справка •

    Базовые рекомендации • Анализ издержек на клиентской стороне • Формирование запроса • Выполнение запроса • Сетевое взаимодействие • Выделение памяти
  55. 70 © 2019 NetCracker Technology Corporation. Выделение памяти • https://datastax-oss.atlassian.net/browse/JAVA-1661

    • Избегаем лишних toLowerCase при работе с метаданными (имена колонок, поля UDT) • Доступно, начиная с версии драйвера 3.3.2 • https://github.com/datastax/java-driver/pull/1293 • Убираем излишние выделения памяти • В процессе
  56. 72 © 2019 NetCracker Technology Corporation. • int streamId •

    primitive type + varargs Выделение памяти – varArgs + primitive
  57. 74 © 2019 NetCracker Technology Corporation. Выделение памяти • Тест:

    SELECT, возвращающий 1 строку, GC allocation rate per operation • Driver 3.7.2 OOB • Driver 3.7.2 + memory allocation fixes • Driver 3.7.2 + -Dcom.datastax.driver.CHECK_IO_DEADLOCKS=false • Driver 3.7.2 + fixes + - Dcom.datastax.driver.CHECK_IO_DEADLOCKS=false 4,124 B/ops 3,831 B/ops 2,878 B/ops 3,211 B/ops
  58. 75 © 2019 NetCracker Technology Corporation. Драйвер • Справка •

    Базовые рекомендации • Анализ издержек на стороне драйвера • Формирование запроса • Выполнение запроса • Сетевое взаимодействие • Выделение памяти
  59. 77 © 2019 NetCracker Technology Corporation. Запись • Справка •

    Запись – что происходит внутри реплики
  60. 81 © 2019 NetCracker Technology Corporation. • Более детальная схема

    процесса записи • с деталями об очередях и потоках • с отображением на точки трассировки запросов есть в дополнительных слайдах к этому докладу Запись – что происходит внутри реплики
  61. 82 © 2019 NetCracker Technology Corporation. Запись • Справка •

    Запись – что происходит внутри реплики • Проблемы • Проблема при вставке списка
  62. 83 © 2019 NetCracker Technology Corporation. Проблема при вставке списка

    • Делаем вставку событий в таблицу, одна из колонок - список • Проблемы: • Запрос плохо масштабируется • Слабая утилизация ресурсов (CPU/disk/network)
  63. 86 © 2019 NetCracker Technology Corporation. UUIDGen - конфликты при

    захвате блокировки "SharedPool-Worker-296" #6150 daemon waiting for monitor entry [0x00007f3195a2a000] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.cassandra.utils.UUIDGen.createTimeSafe(UUIDGen.java:299) - waiting to lock <0x00007f9b6a0009c0> (a org.apache.cassandra.utils.UUIDGen) at org.apache.cassandra.utils.UUIDGen.getTimeUUIDBytes(UUIDGen.java:167) at org.apache.cassandra.cql3.Lists$Appender.doAppend(Lists.java:396) at org.apache.cassandra.cql3.Lists$Setter.execute(Lists.java:302) at org.apache.cassandra.cql3.statements.UpdateStatement.addUpdateForKey(UpdateStatement.java:94)
  64. 87 © 2019 NetCracker Technology Corporation. UUIDGen - конфликты при

    захвате блокировки • param_list = [e1, …, eN] - список
  65. 88 © 2019 NetCracker Technology Corporation. UUIDGen - конфликты при

    захвате блокировки • param_list = [e1, …, eN] - список • Коллекции в Cassandra могут быть frozen и non-frozen: • Frozen – всегда перезаписываются целиком, как blob • Non-frozen – могут быть обновлены инкрементально
  66. 89 © 2019 NetCracker Technology Corporation. UUIDGen - конфликты при

    захвате блокировки • param_list = [e1, …, eN] - список • Коллекции в Cassandra могут быть frozen и non-frozen: • Frozen – всегда перезаписываются целиком, как blob • Non-frozen – могут быть обновлены инкрементально • При добавлении элементов в non-frozen список Cassandra присваивает им внутренний идентификатор - CellPath в формате UUID
  67. 90 © 2019 NetCracker Technology Corporation. UUIDGen - конфликты при

    захвате блокировки • param_list = [e1, …, eN] - список • Коллекции в Cassandra могут быть frozen и non-frozen: • Frozen – всегда перезаписываются целиком, как blob • Non-frozen – могут быть обновлены инкрементально • При добавлении элементов в non-frozen список Cassandra присваивает им внутренний идентификатор - CellPath в формате UUID • UUID – генерируется при вставке на стороне сервера • UUID – на основе времени (type 1 UUID)
  68. 91 © 2019 NetCracker Technology Corporation. UUIDGen - конфликты при

    захвате блокировки • UUIDGen – конфликт при захвате блокировки (lock contention) • CASSANDRA-11517 • Проблема есть, начиная с 3.0.x • Исправлено, начиная с 3.8 • А если нельзя обновиться? – попробовать использовать frozen<list>
  69. 92 © 2019 NetCracker Technology Corporation. Запись • Справка •

    Запись – что происходит внутри реплики • Проблемы • Проблема при вставке списка • Скрытая стоимость TTL
  70. 93 © 2019 NetCracker Technology Corporation. Скрытая стоимость TTL •

    Делаем вставку событий в таблицу, используя TTL • Читаем данные по partition ключу и подмножеству clustering ключей • Симптомы: • Чтения со временем замедляются • CPU на стороне сервера и возрастает
  71. 94 © 2019 NetCracker Technology Corporation. Скрытая стоимость TTL •

    TTL = 1 (1 секунда) - просто для примера • flush • смотрим получилось в SSTable через sstabledump
  72. 96 © 2019 NetCracker Technology Corporation. Скрытая стоимость TTL Прошел

    compaction – на каждой ячейке выросли cell tombstones:
  73. 97 © 2019 NetCracker Technology Corporation. Скрытая стоимость TTL •

    Концептуально – row TTL в Cassandra обрабатываются на уровне cell (link)
  74. 98 © 2019 NetCracker Technology Corporation. Скрытая стоимость TTL •

    Концептуально – row TTL в Cassandra обрабатываются на уровне cell (link) • Non-frozen коллекция –> еще + 1 tombstone на каждый элемент
  75. 99 © 2019 NetCracker Technology Corporation. Скрытая стоимость TTL •

    Концептуально – row TTL в Cassandra обрабатываются на уровне cell (link) • Non-frozen коллекция –> еще + 1 tombstone на каждый элемент • Почему плохо: • Больше ресурсов требуется на объединение строк при чтении • Больше ресурсов требуется на объединение строк при compaction • Больше места на диске
  76. 100 © 2019 NetCracker Technology Corporation. Скрытая стоимость TTL Что

    можно сделать: • Не использовать без необходимости связку row TTL + non-frozen коллекции
  77. 101 © 2019 NetCracker Technology Corporation. Скрытая стоимость TTL Что

    можно сделать: • Не использовать без необходимости связку row TTL + non-frozen коллекции • Если есть возможность – использовать table level TTL • Работает через удаление SSTables • Но TTL – одинаковые для всех записей в таблице
  78. 102 © 2019 NetCracker Technology Corporation. Запись • Справка •

    Запись – что происходит внутри реплики • Проблемы • Проблема при вставке списка • Скрытая стоимость TTL • WriteTimeoutException при удалении
  79. 103 © 2019 NetCracker Technology Corporation. WriteTimeoutException при удалении •

    Вставляем и удаляем данные из различных приложений • Симптомы • WriteTimeoutException на стороне различных приложений, для разных keyspaces/tables • Высокая write latency у одной из таблиц
  80. 104 © 2019 NetCracker Technology Corporation. WriteTimeoutException при удалении •

    Вставляем и удаляем данные из различных приложений • Симптомы • WriteTimeoutException на стороне различных приложений, для разных keyspaces/tables • Высокая write latency у одной из таблиц • Метрики: ./nodetool tpstats Pool Name Active Pending Completed Blocked MutationStage 32 20926 32405275 0
  81. 105 © 2019 NetCracker Technology Corporation. WriteTimeoutException при удалении •

    Вставляем и удаляем данные из различных приложений • Симптомы • WriteTimeoutException на стороне различных приложений, для разных keyspaces/tables • Высокая write latency у одной из таблиц • Метрики: ./nodetool tpstats Pool Name Active Pending Completed Blocked MutationStage 32 20926 32405275 0 JMX: ...:type=ThreadPools,name=ActiveTasks,path=internal,scope=* ...:type=ThreadPools,name=PendingTasks,path=internal,scope=* ...:keyspace=*,name=WriteLatency,scope=*,type=Table
  82. 106 © 2019 NetCracker Technology Corporation. Thread dump: "SharedPool-Worker-10" #363

    daemon waiting for monitor entry [0x00007f4ced125000] java.lang.Thread.State: BLOCKED (on object monitor) at sun.misc.Unsafe.monitorEnter(Native Method) at org.apache.cassandra.utils.concurrent.Locks.monitorEnterUnsafe(Locks.java:46) at org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDelta(…) at org.apache.cassandra.db.Memtable.put(Memtable.java:254) "SharedPool-Worker-32" #383 daemon runnable [0x00007f4cecc51000] java.lang.Thread.State: RUNNABLE at org.apache.cassandra.db.ClusteringComparator.compare(ClusteringComparator.java:137) at org.apache.cassandra.db.RangeTombstoneList.insertFrom(RangeTombstoneList.java:536) at org.apache.cassandra.db.RangeTombstoneList.add(RangeTombstoneList.java:167) at org.apache.cassandra.db.RangeTombstoneList.addAll(RangeTombstoneList.java:207) at org.apache.cassandra.db.MutableDeletionInfo.add(MutableDeletionInfo.java:141) at org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDelta(...) at org.apache.cassandra.db.Memtable.put(Memtable.java:254) WriteTimeoutException при удалении
  83. 108 © 2019 NetCracker Technology Corporation. • RangeTombstoneList – структура

    данных, используемая для хранения range tombstones • Отдельная структура для каждого partition key WriteTimeoutException при удалении
  84. 109 © 2019 NetCracker Technology Corporation. • Упорядоченный список интервалов

    • У интервалов есть временная метка WriteTimeoutException при удалении
  85. 110 © 2019 NetCracker Technology Corporation. • При добавлении “большего”

    интервала – обновляются все существующие интервалы (но укрупнения не происходит) WriteTimeoutException при удалении
  86. 111 © 2019 NetCracker Technology Corporation. • При добавлении “большего”

    интервала – обновляются все существующие интервалы (но укрупнения не происходит) WriteTimeoutException при удалении
  87. 112 © 2019 NetCracker Technology Corporation. • При добавлении “меньшего”

    интервала – добавляется новый интервал WriteTimeoutException при удалении
  88. 113 © 2019 NetCracker Technology Corporation. • При добавлении “меньшего”

    интервала – добавляется новый интервал WriteTimeoutException при удалении
  89. 114 © 2019 NetCracker Technology Corporation. WriteTimeoutException при удалении •

    При добавлении “меньшего” интервала – добавляется новый интервал • При добавлении “большего” интервала – обновляются все существующие интервалы
  90. 115 © 2019 NetCracker Technology Corporation. WriteTimeoutException при удалении •

    При добавлении “меньшего” интервала – добавляется новый интервал • При добавлении “большего” интервала – обновляются все существующие интервалы • Проблема роста числа интервалов известна, была частично исправлена в 3.4.11, но на уровне чтения, а не записи (CASSANDRA-14894)
  91. 118 © 2019 NetCracker Technology Corporation. WriteTimeoutException при удалении •

    Несколько процессов –> clust_key значения могут быть не строго монотонными (граница интервала плавает) • В результате – число интервалов в RangeTombstoneList растет
  92. 119 © 2019 NetCracker Technology Corporation. WriteTimeoutException при удалении •

    Несколько процессов –> clust_key значения могут быть не строго монотонными (граница интервала плавает) • В результате – число интервалов в RangeTombstoneList растет • Как лечить? • Один из путей: делать более мелкие партиции
  93. 120 © 2019 NetCracker Technology Corporation. Запись • Справка •

    Запись – что происходит внутри реплики • Проблемы • Проблема при вставке списка • Скрытая стоимость TTL • WriteTimeoutException при удалении
  94. 128 © 2019 NetCracker Technology Corporation. Чтение • Справка •

    Чтение – уровень кластера • Проблемы • Количество колонок и стоимость чтения
  95. 129 © 2019 NetCracker Technology Corporation. Количество колонок и стоимость

    чтения • Вопрос: есть ли зависимость между скоростью чтения и числом читаемых колонок из таблицы? • Зачем: хотим уменьшить нагрузку на базу и снизить время отклика
  96. 130 © 2019 NetCracker Technology Corporation. Количество колонок и стоимость

    чтения • Вопрос: есть ли зависимость между скоростью чтения и числом читаемых колонок из таблицы? • Зачем: хотим уменьшить нагрузку на базу и снизить время отклика • Интересующие опции: • Колонки из кластерного ключа • Колонки со значениями
  97. 131 © 2019 NetCracker Technology Corporation. Количество колонок и стоимость

    чтения • Эксперимент: • Делаем таблицы с разным числом строковых колонок • Сохраняем суммарно один и тот же объем данных в строку
  98. 132 © 2019 NetCracker Technology Corporation. Количество колонок и стоимость

    чтения • Эксперимент: • Делаем таблицы с разным числом строковых колонок • Сохраняем суммарно один и тот же объем данных в строку • В партиции – 10 строк • Фиксированная нагрузка: 6000 чтений в секунду, читаем партицию целиком
  99. 133 © 2019 NetCracker Technology Corporation. Количество колонок и стоимость

    чтения • Эксперимент: • Делаем таблицы с разным числом строковых колонок • Сохраняем суммарно один и тот же объем данных в строку • В партиции – 10 строк • Фиксированная нагрузка: 6000 чтений в секунду, читаем партицию целиком • Кластерный ключ: • 1*64 байт, 2 * 32 байт, 4*16 байт, 8 * 8 байт, 16 * 4 байт • Колонки со значениями : • 1 * 512 байт, 2 * 256 байт, 4*128 байт, 8 * 64 байт, 16 * 32 байт, 32 * 16 байт
  100. 134 © 2019 NetCracker Technology Corporation. Стоимость чтения – кластерные

    ключи Число кластерных колонок Размер колонки, байт Среднее время ответа, мс 1 64 1.6 2 32 1.6 4 16 1.7 8 8 1.8 16 4 2.0
  101. 136 © 2019 NetCracker Technology Corporation. Стоимость чтения – колонки

    со значениями Число колонок со значениями Размер колонки, байт Среднее время ответа, мс 1 512 1.3 2 256 1.4 4 128 1.6 8 64 1.8 16 32 2.1 32 16 3.4
  102. 138 © 2019 NetCracker Technology Corporation. Количество колонок и стоимость

    чтения • Колонки с кластерными ключами • Есть рост по времени обработки и CPU • Колонки со значением • Есть существенный рост по времени обработки и CPU
  103. 139 © 2019 NetCracker Technology Corporation. Чтение • Справка •

    Чтение – уровень кластера • Проблемы • Количество колонок и стоимость чтения • Надо прочитать набор партиций, кто быстрее?
  104. 140 © 2019 NetCracker Technology Corporation. Надо прочитать набор партиций,

    кто быстрее? • В рамках batch логики периодически поступают пачки входных данных • Пачка состоит из записей, для каждой записи надо достать партицию из таблицы (“batch-table join”)
  105. 141 © 2019 NetCracker Technology Corporation. Надо прочитать набор партиций,

    кто быстрее? • В рамках batch логики периодически поступают пачки входных данных • Пачка состоит из записей, для каждой записи надо достать партицию из таблицы (“batch-table join”) • Цель – минимизировать суммарное время чтения записей для ключей из пачки
  106. 144 © 2019 NetCracker Technology Corporation. Вариант 3 - SELECT

    IN • SELECT * FROM testTable WHERE id IN ? • Попытка сэкономить на взаимодействиях между клиентом и сервером
  107. 145 © 2019 NetCracker Technology Corporation. Вариант 3 - SELECT

    IN • SELECT * FROM testTable WHERE id IN ? • Попытка сэкономить на взаимодействиях между клиентом и сервером • Вариант напрямую, по всем ключам – плохой, координатор будет взаимодействовать с несколькими репликами для разных партиций
  108. 146 © 2019 NetCracker Technology Corporation. Вариант 3 - SELECT

    IN • Стратегия: сгруппируем партиции по их репликам-владельцам • Распределение партиций по нодам: • cluster.getMetadata().getReplicas(keyspace, key)
  109. 147 © 2019 NetCracker Technology Corporation. Вариант 3 - SELECT

    IN • Стратегия: сгруппируем партиции по их репликам-владельцам • Распределение партиций по нодам: • cluster.getMetadata().getReplicas(keyspace, key) • Максимальное число таких групп: количество вариантов выбора RF реплик из N нод = С$ %&. Для 5 нод и RF = 3 => 10 • Для каждой группы - отдельный SELECT IN • ! Из минусов – больше нагрузка на координатор
  110. 148 © 2019 NetCracker Technology Corporation. Вариант 4 - SELECT

    IN with LIMIT • Делаем предварительные замеры – получаем скорость, аналогичную select sync • Смотрим по коду Cassandra , что происходит внутри:
  111. 149 © 2019 NetCracker Technology Corporation. Вариант 4 - SELECT

    IN with LIMIT • Делаем предварительные замеры – получаем скорость, аналогичную select sync • Смотрим по коду Cassandra , что происходит внутри:
  112. 150 © 2019 NetCracker Technology Corporation. Вариант 4 - SELECT

    IN with LIMIT • Делаем предварительные замеры – получаем скорость, аналогичную select sync • Смотрим по коду Cassandra , что происходит внутри:
  113. 151 © 2019 NetCracker Technology Corporation. Вариант 4 - SELECT

    IN with LIMIT • Делаем предварительные замеры – получаем скорость, аналогичную select sync • Смотрим по коду Cassandra , что происходит внутри: • Вопрос: а подзапросы в реплики для SELECT IN запросов - параллельные или последовательные?
  114. 152 © 2019 NetCracker Technology Corporation. Вариант 4 - SELECT

    IN with LIMIT • Делаем предварительные замеры – получаем скорость, аналогичную select sync • Смотрим по коду Cassandra , что происходит внутри: • Вопрос: а подзапросы в реплики для SELECT IN запросов - параллельные или последовательные? • Ответ: для одностраничных запросов – да, для многостраничных – нет • CASSANDRA-7805 • Ставим явно LIMIT <= page size (50000), чтобы получить одностраничный запрос
  115. 153 © 2019 NetCracker Technology Corporation. Вариант 5 - Async

    SELECT IN with limit • вариант 4 (SELECT IN with LIMIT) + вариант 2 (async SELECT)
  116. 154 © 2019 NetCracker Technology Corporation. Надо прочитать набор партиций,

    кто быстрее? • Тест: • Пачка - 100 партиций • В каждой партиции в таблице 50 строк, итого читаем 5000 строк • 5 Cassandra нод, RF = 3 • Время = время чтения пачки
  117. 155 © 2019 NetCracker Technology Corporation. Надо прочитать набор партиций,

    кто быстрее? • Тест: • Пачка - 100 партиций • В каждой партиции в таблице 50 строк, итого читаем 5000 строк • 5 Cassandra нод, RF = 3 • Время = время чтения пачки Вариант Среднее время ответа, мс sync select 187 async select 72 sync select IN 189 sync select IN + LIMIT 102 async select IN 94 async select IN + LIMIT 64
  118. 156 © 2019 NetCracker Technology Corporation. Чтение • Справка •

    Чтение – уровень кластера • Проблемы • Количество колонок и стоимость чтения • Надо прочитать набор партиций, кто быстрее? • Как подвесить Cassandra одним запросом
  119. 157 © 2019 NetCracker Technology Corporation. Как подвесить Cassandra одним

    запросом • Симптомы: • OperationTimedOutException у ряда приложений • Cassandra процессы живы • CPU load - всплеск • GC duration - всплеск • DroppedMessages метрика - всплеск
  120. 158 © 2019 NetCracker Technology Corporation. Как подвесить Cassandra одним

    запросом Одно из приложений выполняет запрос вида:
  121. 159 © 2019 NetCracker Technology Corporation. Как подвесить Cassandra одним

    запросом "Native-Transport-Requests-2" #71 daemon runnable at java.util.Arrays.copyOf at java.util.ArrayList.grow at java.util.ArrayList.ensureExplicitCapacity at java.util.ArrayList.ensureCapacityInternal at java.util.ArrayList.add at org.apache.cassandra.db.MultiCBuilder$MultiClusteringBuilder.addEachElementToAll at org.apache.cassandra.cql3.restrictions.SingleColumnRestriction$INRestriction.appendTo at org.apache.cassandra.cql3.restrictions.ClusteringColumnRestrictions.valuesAsClustering at org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumns at org.apache.cassandra.cql3.statements.SelectStatement.getRequestedRows at org.apache.cassandra.cql3.statements.SelectStatement.makeClusteringIndexFilter at org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands at org.apache.cassandra.cql3.statements.SelectStatement.getQuery at org.apache.cassandra.cql3.statements.SelectStatement.execute
  122. 160 © 2019 NetCracker Technology Corporation. Как подвесить Cassandra одним

    запросом == Кассандра приводит к форме, аналогичной следующей == >
  123. 161 © 2019 NetCracker Technology Corporation. Как подвесить Cassandra одним

    запросом == Кассандра приводит к форме, аналогичной следующей == > // N^3 комбинаций
  124. 162 © 2019 NetCracker Technology Corporation. Как подвесить Cassandra одним

    запросом • Еще одно напоминание, о том, что в Cassandra: • Нет изоляции по ресурсам между различными keyspace – пулы потоков общие
  125. 163 © 2019 NetCracker Technology Corporation. Как подвесить Cassandra одним

    запросом • Еще одно напоминание, о том, что в Cassandra: • Нет изоляции по ресурсам между различными keyspace – пулы потоков общие • Нет жёсткого ограничения на ресурсы для выполняемых запросов
  126. 164 © 2019 NetCracker Technology Corporation. Как подвесить Cassandra одним

    запросом • Еще одно напоминание, о том, что в Cassandra: • Нет изоляции по ресурсам между различными keyspace – пулы потоков общие • Нет жёсткого ограничения на ресурсы для выполняемых запросов • Нет жесткого ограничения на время выполнения запроса (по наследству от Java)
  127. 165 © 2019 NetCracker Technology Corporation. Как подвесить Cassandra одним

    запросом • Еще одно напоминание, о том, что в Cassandra: • Нет изоляции по ресурсам между различными keyspace – пулы потоков общие • Нет жёсткого ограничения на ресурсы для выполняемых запросов • Нет жесткого ограничения на время выполнения запроса (по наследству от Java) • DSE 6.x – thread per core архитектура с шардированием запросов между потоками еще более чувствительна к таким непредвиденным задержках
  128. 166 © 2019 NetCracker Technology Corporation. Чтение • Справка •

    Чтение – уровень кластера • Проблемы • Количество колонок и стоимость чтения • Надо прочитать набор партиций, кто быстрее? • Как подвесить Cassandra одним запросом
  129. 168 © 2019 NetCracker Technology Corporation. Итого • Cвежие версии

    базы и драйвера быстрее • В Cassandra нет жесткой изоляции запросов по ресурсам, каждый запрос может повлиять на общее состояние системы
  130. 169 © 2019 NetCracker Technology Corporation. Итого • Cвежие версии

    базы и драйвера быстрее • В Cassandra нет жесткой изоляции запросов по ресурсам, каждый запрос может повлиять на общее состояние системы • Драйвер • UDT/Collections - есть накладные расходы на Codec • Есть ряд ручек покрутить, можно сэкономить немного CPU
  131. 170 © 2019 NetCracker Technology Corporation. Итого • Cвежие версии

    базы и драйвера быстрее • В Cassandra нет жесткой изоляции запросов по ресурсам, каждый запрос может повлиять на общее состояние системы • Драйвер • UDT/Collections - есть накладные расходы на Codec • Есть ряд ручек покрутить, можно сэкономить немного CPU • Запись • Range tombstones могут вызвать WriteTimeoutException • TTL per row + unfrozen collections -> много tombstones
  132. 171 © 2019 NetCracker Technology Corporation. Итого • Cвежие версии

    базы и драйвера быстрее • В Cassandra нет жесткой изоляции запросов по ресурсам, каждый запрос может повлиять на общее состояние системы • Драйвер • UDT/Collections - есть накладные расходы на Codec • Есть ряд ручек покрутить, можно сэкономить немного CPU • Запись • Range tombstones могут вызвать WriteTimeoutException • TTL per row + unfrozen collections -> много tombstones • Чтение • Количество колонок со значениями имеет значение • Если нужно прочитать набор partitions, async select – самая простая и почти самая быстрая опция
  133. 175 © 2019 NetCracker Technology Corporation. Какого рода системы и

    нагрузку обсуждаем • Linux сервера • Cassandra • Версии: 3.0.x, 3.11.x, DSE 6.x • Java 8 • OSS DataStax Java driver 3.x • 2-3 датацентра в кластере • 5-7 инстансов в каждом датацентре • В каждом датацентре 3 или 5 реплик данных • Consistency level, обычно - LOCAL_QUORUM
  134. 176 © 2019 NetCracker Technology Corporation. Какого рода системы и

    нагрузку обсуждаем • Тип системы: OLTP • Нагрузки порядка 10k запросов в секунду уровня приложения • Время ответа: 95% персентиль <= 50 ms • ~ 5-10 запросов в базу на каждый запрос уровня приложения • ~100k запросов в базу в целом • Тип нагрузки: 50% чтений / 50% записей • Объемы данных ~ 100 Gb • Цель: приемлемое время ответа для заданного уровня нагрузки
  135. 177 © 2019 NetCracker Technology Corporation. Какого рода системы и

    нагрузку обсуждаем • Тип системы: пакетная обработка • Тип нагрузки: 40% чтений / 60% записей • Объемы данных ~ 1-10 TBs • Цель: пропускная способность
  136. 179 © 2019 NetCracker Technology Corporation. Метрики базы, избранное •

    Встроенные метрики уровня базы - RED (Rate, Errors, Duration) • Ошибки • org.apache.cassandra.metrics:type=ClientRequest,scope=*,name=Timeouts • org.apache.cassandra.metrics:type=ClientRequest,scope=*,name=Failures • org.apache.cassandra.metrics:type=ClientRequest,scope=*,name=Unavailables • • org.apache.cassandra.metrics:type=DroppedMessage,scope=*,name=Dropped • org.apache.cassandra.metrics:type=Storage,name=Exceptions
  137. 180 © 2019 NetCracker Technology Corporation. Метрики базы, избранное •

    Встроенные метрики уровня базы - RED (Rate, Errors, Duration) • Rate – производная от Count + Latency (среднее, персентили) • org.apache.cassandra.metrics:type=ClientRequest,scope=*,name=Latency • org.apache.cassandra.metrics:keyspace=*,name=WriteLatency,scope=*,type=Table • org.apache.cassandra.metrics:keyspace=*,name=ReadLatency,scope=*,type=Table • org.apache.cassandra.metrics:keyspace=*,name=CoordinatorReadLatency,scope=*,type=Table • CoordinatorWriteLatency – появится только в Cassandra 4.0 (CASSANDRA-14232)
  138. 181 © 2019 NetCracker Technology Corporation. Метрики базы, избранное •

    Пулы потоков • ...:type=ThreadPools,name=ActiveTasks,path=internal,scope=* • ...:type=ThreadPools,name=PendingTasks,path=internal,scope=* • ...:type=ThreadPools,name=TotalBlockedTasks,path=internal,scope=* • Количество SSTables, читаемых во время read операции • …:keyspace=*,name=SSTablesPerReadHistogram,scope=*,type=Table • Tombstones • …:keyspace=*,name=TombstoneScannedHistogram,scope=*,type=Table
  139. 182 © 2019 NetCracker Technology Corporation. Трассировка запросов • Трассировка

    % запросов • nodetool settraceprobability 0.0001 • Больше деталей: https://www.datastax.com/dev/blog/tracing-in-cassandra-1-2
  140. 183 © 2019 NetCracker Technology Corporation. Трассировка запросов - пример

    Tracing session: 6930c380-ddea-11e9-97f8-952ee9e78380 activity | timestamp |source | elapsed | --------------------------------------------------------------+-----------------+-------+---------+ Execute CQL3 query | 06:10:46.840000 | ...49 | 0 | Parsing query <skipped> ; [CoreThread-1] | 06:10:46.840001 | ...49 | 121 | Preparing statement [CoreThread-1] | 06:10:46.840001 | ...49 | 231 | Reading data from [/10.101.18.49] [CoreThread-1] | 06:10:46.840001 | ...49 | 362 | Executing single-partition query on test_table [CoreThread-4] | 06:10:46.840002 | ...49 | 691 | Acquiring sstable references [CoreThread-4] | 06:10:46.840003 | ...49 | 725 | Merged data from memtables and 0 sstables [CoreThread-4] | 06:10:46.841000 | ...49 | 763 | Read 1 live rows and 0 tombstone cells [CoreThread-4] | 06:10:46.841000 | ...49 | 782 | Request complete | 06:10:46.840918 | ...49 | 918 | • SELECT запрос, consistency_level = LOCAL_ONE
  141. 185 © 2019 NetCracker Technology Corporation. Трассировка записи ID Text

    1 Execute CQL3 prepared query <session started - initial timestamp is stored> 2 Determining replicas for mutation 3 Sending MUTATION message to %s 4 MUTATION message received from {} 5 Appending to commitlog 6 Adding to {} memtable 7 Enqueuing response to {} 8 Sending REQUEST_RESPONSE message to %s 9 REQUEST_RESPONSE message received from {} 10 Processing response from {}
  142. 186 © 2019 NetCracker Technology Corporation. Запись • Справка •

    Запись – что происходит внутри реплики • Проблемы • Проблема при вставке элементов списка • Скрытая стоимость TTL • WriteTimeoutException при удалении • Выделение памяти при записи
  143. 187 © 2019 NetCracker Technology Corporation. Выделение памяти • Mutation

    объекты сериализуются дважды 1) для того, чтобы определить размер буфера 2) для того, чтобы записать данные • Актуально для 3.0.x версий • Исправлено, начиная с 3.10 • https://issues.apache.org/jira/browse/CASSANDRA-12269
  144. 188 © 2019 NetCracker Technology Corporation. Выделение памяти • Mutation

    объекты сериализуются дважды 1) для того, чтобы определить размер буфера 2) для того, чтобы записать данные • Актуально для 3.0.x версий • Исправлено, начиная с 3.10 • https://issues.apache.org/jira/browse/CASSANDRA-12269 • Излишние выделения памяти при записи, например – при вычислении hashCode в рамках Memtable.put • Актуально для 3.0.x версий • Исправлено, начиная с 3.6 https://issues.apache.org/jira/browse/CASSANDRA-11428 • Дополнительно 3.10 - https://issues.apache.org/jira/browse/CASSANDRA-12269
  145. 189 © 2019 NetCracker Technology Corporation. Запись • Справка •

    Запись – что происходит внутри реплики • Проблемы • Проблема при вставке элементов списка • Скрытая стоимость TTL • WriteTimeoutException при удалении • Выделение памяти при записи
  146. 190 © 2019 NetCracker Technology Corporation. Чтение • Справка •

    Чтение – уровень кластера • Чтение – что происходит внутри реплики