Сфера финансовых приложений и трейдинга выдвигает особые требования к системам обработки данных: ультракороткие задержки, конкурентные обновления (в т.ч. из разных процессов), репликация высокочастотных обновлений. Существовавшие открытые key-value хранилища не справлялись, поэтому мы сделали свое — Chronicle Map. В докладе я отвечу на вопросы: + Почему бывает эффективнее разбить систему, работающую с общим состоянием, на несколько отдельных процессов? + Зачем вам может захотеться распилить JVM на несколько частей? + Как добиться от key-value хранилища медианной latency меньше 1 микросекунды? + Как сделать репликацию, если она упирается в пропускную способность сети из-за слишком частых обновлений? Развею миф о том, что Java — это медленно :) Также, в докладе будет сравнение Chronicle Map с redis, one-nio и ConcurrentHashMap.

1. Chronicle Map
Роман Левентов

2. Chronicle Software
ПО для
высокопроизводительных
систем на Java
• Финтех, трейдинг
• Ставки
• Туризм

3. Chronicle Map
Key‐value store в памяти
github.com/OpenHFT/Chronicle-Map
LGPL v3

4. Зачем?

5. Нужды трейдинга (1)
Задержки = деньги
Обычные реляционные БД
Out-of-process кеши (redis)
Chronicle Map: медианная
задержка (latency)
< 1 микросекунды

6. Нужды трейдинга (2)
Много источников событий
из разных процессов
Пример: агрегация данных
из нескольких бирж

7. Зачем еще нужен
доступ
из нескольких
процессов?

8. Тренды в железе
Сотни ГБ памяти
Несколько сокетов
⇒ NUMA

9. NUMA

10. NUMA
Доступ к памяти «чужого»
сокета на ~30% медленнее

11. NUMA: архитектура 1
NUMA node 1
core core core
NUMA node 2
core core core
Процесс

12. NUMA: архитектура 2
NUMA node 1
core core core
NUMA node 2
core core core
Процесс 1 Процесс 2
Выигрыш до 30% / 2 = 15%

13. Зачем несколько JVM?
Сборка мусора
• Меньше heap — меньше
паузы
• Garbage-free подсистемы
– Без пауз
– Цена барьеров

14. Compressed Oops
Зачем несколько JVM?
Heap = 40 GB
64-битные ссылки
Heap = 15 GB
32-битные ссылки
Heap = 15 GB
32-битные ссылки
Профит

15. Зачем несколько JVM?
Конфигурация на уровне ОС
• Affinity
• Приоритеты
• cgroups

16. Нужды трейдинга (2)
Много источников событий
из разных процессов
Hazelcast
Большинство IMDG
MapDB

17. Много источников
Chronicle Map:
Доступ из нескольких
процессов
Масштабирование записи
ограничено кол-вом ядер в
системе

18. Нужды трейдинга (3)
Очень большая частота
событий ⇒ обновлений базы
Репликация:
200k RPS
× 3 KB state updates
= 5 Gbit

19. Нужды трейдинга (3)
Сеть не тянет ⇒ очереди
репликации переполняются
Нужна «фильтрация»
Chronicle Map: репликация
без очередей, гарантия
прогресса

21. Не серебряная пуля
Multi‐key запросы
изолированы,
но не атомарны
Не durable, только persistent
Только асинхронная
репликация

23. Как?

24. Как сделать доступ
из нескольких
процессов?

25. Loopback, sockets
JVM 1 DB process
JVM 2
Kernel
DB memory

26. Loopback, sockets
Поход в ядро: 100s of ns
× 4
2…∞ лишних копирований
данных
Непредсказуемые задержки:
1..10 микросекунд

27. Loopback, sockets
• Redis, Memcached

28. Разделяемая память
БД на C + JNI
БД на Java
• sun.misc.Unsafe

29. БД на C + JNI
Java code DB code
JNIJVM 1
Kernel
DB shared memory
JVM 2

30. БД на Java (Unsafe)
Java code
DB code
Unsafe
JVM
Kernel
DB shared memory
JVM 2

31. Конечно, Unsafe!
Минусы JNI
• 50 ns
• 2 лишних копирования
• putIfAbsent(лямбда)
Минус Unsafe:
геморрой с блокировками

32. Блокировки
не нужны

33. Блокировки
LockSupport.parkNanos(1000)
8000
Context switches — зло
Spin loops, жжем CPU

34. Бенчмарк:
Chronicle Map*,
one-nio*,
ConcurrentHashMap
Спасибо Андрею Барюдину
и Андрею Пангину

35. Ответы на заявки
Запрос:
orderId, instrument, price, ± amount
+ покупка, − продажа
Key-value хранилище:
instrument, price → orderId, ± leftover
4, 8 → 8, 8 байтов
28 байтов всего

36. Пример
#1, AAPL, $600, +10
AAPL, $600 → #1, +10
#2, AAPL, $600, −7
AAPL, $600 → #1, +3
#3, AAPL, $600, −5
AAPL, $600 → #3, −2

37. Реалистичные данные
5000
инструментов
Расп. Ципфа
Цены:
биномиальное

38. Бенчмарк
10 млн заявок, 8 потоков
~ 160 тыс. различных пар
(instrument, price)
Xeon E5-2650 v2 @ 2.60GHz
8 Cores / 16 HW Threads,
2 NUMA nodes, L3: 20MB

39. Скорость
174
296
367
Chronicle Map one-nio ConcurrentHashMap
В среднем наносекунд на запрос, меньше — лучше

40. Память
7.5
10.1
14.4
Chronicle Map one-nio ConcurrentHashMap
Общее потребление памяти, MB, меньше — лучше

41. Потребление памяти
определяет скорость

42. Память
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

43. Репликация

44. Репликация: боль
Сеть не тянет частые
обновления
⇒ Очередь переполняется
⇒ Надо делать сжатие
• Сложно
• Задержки

45. Репликация без логов
Записи помечаются на
репликацию в bit maps
Потребление памяти
не меняется
Но: только асинхронная,
eventually consistent
репликация

46. Кратко
По процессу на сокет
Аffinity, приоритеты
syscalls, JNI
Context switches
IPC через shared memory
Меньше памяти

48. Ссылки
http://chronicle.software/
key-value-stories.blogspot.com
@leventov
leventov@ya.ru