Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Chronicle Map — key-value хранилище для трейдинга на Java / Левентов Роман (Chronicle Software)

1,203 views

Published on

Сфера финансовых приложений и трейдинга выдвигает особые требования к системам обработки данных: ультракороткие задержки, конкурентные обновления (в т.ч. из разных процессов), репликация высокочастотных обновлений.

Существовавшие открытые key-value хранилища не справлялись, поэтому мы сделали свое — Chronicle Map.

В докладе я отвечу на вопросы:
+ Почему бывает эффективнее разбить систему, работающую с общим состоянием, на несколько отдельных процессов?
+ Зачем вам может захотеться распилить JVM на несколько частей?
+ Как добиться от key-value хранилища медианной latency меньше 1 микросекунды?
+ Как сделать репликацию, если она упирается в пропускную способность сети из-за слишком частых обновлений?

Развею миф о том, что Java — это медленно :)
Также, в докладе будет сравнение Chronicle Map с redis, one-nio и ConcurrentHashMap.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Chronicle Map — key-value хранилище для трейдинга на Java / Левентов Роман (Chronicle Software)

  1. 1. Chronicle Map Роман Левентов
  2. 2. Chronicle Software ПО для высокопроизводительных систем на Java • Финтех, трейдинг • Ставки • Туризм
  3. 3. Chronicle Map Key‐value store в памяти github.com/OpenHFT/Chronicle-Map LGPL v3
  4. 4. Зачем?
  5. 5. Нужды трейдинга (1) Задержки = деньги Обычные реляционные БД Out-of-process кеши (redis) Chronicle Map: медианная задержка (latency) < 1 микросекунды
  6. 6. Нужды трейдинга (2) Много источников событий из разных процессов Пример: агрегация данных из нескольких бирж
  7. 7. Зачем еще нужен доступ из нескольких процессов?
  8. 8. Тренды в железе Сотни ГБ памяти Несколько сокетов ⇒ NUMA
  9. 9. NUMA
  10. 10. NUMA Доступ к памяти «чужого» сокета на ~30% медленнее
  11. 11. NUMA: архитектура 1 NUMA node 1 core core core NUMA node 2 core core core Процесс
  12. 12. NUMA: архитектура 2 NUMA node 1 core core core NUMA node 2 core core core Процесс 1 Процесс 2 Выигрыш до 30% / 2 = 15%
  13. 13. Зачем несколько JVM? Сборка мусора • Меньше heap — меньше паузы • Garbage-free подсистемы – Без пауз – Цена барьеров
  14. 14. Compressed Oops Зачем несколько JVM? Heap = 40 GB 64-битные ссылки Heap = 15 GB 32-битные ссылки Heap = 15 GB 32-битные ссылки Профит
  15. 15. Зачем несколько JVM? Конфигурация на уровне ОС • Affinity • Приоритеты • cgroups
  16. 16. Нужды трейдинга (2) Много источников событий из разных процессов Hazelcast Большинство IMDG MapDB
  17. 17. Много источников Chronicle Map: Доступ из нескольких процессов Масштабирование записи ограничено кол-вом ядер в системе
  18. 18. Нужды трейдинга (3) Очень большая частота событий ⇒ обновлений базы Репликация: 200k RPS × 3 KB state updates = 5 Gbit
  19. 19. Нужды трейдинга (3) Сеть не тянет ⇒ очереди репликации переполняются Нужна «фильтрация» Chronicle Map: репликация без очередей, гарантия прогресса
  20. 20. Не серебряная пуля Multi‐key запросы изолированы, но не атомарны Не durable, только persistent Только асинхронная репликация
  21. 21. Как?
  22. 22. Как сделать доступ из нескольких процессов?
  23. 23. Loopback, sockets JVM 1 DB process JVM 2 Kernel DB memory
  24. 24. Loopback, sockets Поход в ядро: 100s of ns × 4 2…∞ лишних копирований данных Непредсказуемые задержки: 1..10 микросекунд
  25. 25. Loopback, sockets • Redis, Memcached
  26. 26. Разделяемая память БД на C + JNI БД на Java • sun.misc.Unsafe
  27. 27. БД на C + JNI Java code DB code JNIJVM 1 Kernel DB shared memory JVM 2
  28. 28. БД на Java (Unsafe) Java code DB code Unsafe JVM Kernel DB shared memory JVM 2
  29. 29. Конечно, Unsafe! Минусы JNI • 50 ns • 2 лишних копирования • putIfAbsent(лямбда) Минус Unsafe: геморрой с блокировками
  30. 30. Блокировки не нужны
  31. 31. Блокировки LockSupport.parkNanos(1000) 8000 Context switches — зло Spin loops, жжем CPU
  32. 32. Бенчмарк: Chronicle Map*, one-nio*, ConcurrentHashMap Спасибо Андрею Барюдину и Андрею Пангину
  33. 33. Ответы на заявки Запрос: orderId, instrument, price, ± amount + покупка, − продажа Key-value хранилище: instrument, price → orderId, ± leftover 4, 8 → 8, 8 байтов 28 байтов всего
  34. 34. Пример #1, AAPL, $600, +10 AAPL, $600 → #1, +10 #2, AAPL, $600, −7 AAPL, $600 → #1, +3 #3, AAPL, $600, −5 AAPL, $600 → #3, −2
  35. 35. Реалистичные данные 5000 инструментов Расп. Ципфа Цены: биномиальное
  36. 36. Бенчмарк 10 млн заявок, 8 потоков ~ 160 тыс. различных пар (instrument, price) Xeon E5-2650 v2 @ 2.60GHz 8 Cores / 16 HW Threads, 2 NUMA nodes, L3: 20MB
  37. 37. Скорость 174 296 367 Chronicle Map one-nio ConcurrentHashMap В среднем наносекунд на запрос, меньше — лучше
  38. 38. Память 7.5 10.1 14.4 Chronicle Map one-nio ConcurrentHashMap Общее потребление памяти, MB, меньше — лучше
  39. 39. Потребление памяти определяет скорость
  40. 40. Память 7.5 10.1 14.4 15 20 Chronicle Map one-nio CHM redis 32-bit, approx. redis 64-bit, approx. Общее потребление памяти, MB, меньше — лучше Payload — 4,5 MB
  41. 41. Репликация
  42. 42. Репликация: боль Сеть не тянет частые обновления ⇒ Очередь переполняется ⇒ Надо делать сжатие • Сложно • Задержки
  43. 43. Репликация без логов Записи помечаются на репликацию в bit maps Потребление памяти не меняется Но: только асинхронная, eventually consistent репликация
  44. 44. Кратко По процессу на сокет Аffinity, приоритеты syscalls, JNI Context switches IPC через shared memory Меньше памяти
  45. 45. Ссылки http://chronicle.software/ key-value-stories.blogspot.com @leventov leventov@ya.ru

×