Download as PDF, PPTX
Uploaded byRoman Leventov
Chronicle Map
Документ обсуждает особенности и преимущества использования Chronicle Map как хранилища ключ-значение для высокопроизводительных систем на Java, акцентируя внимание на низких задержках и эффективной обработке больших объемов данных в трейдинге и финансах. Chronicle Map позволяет уменьшить время отклика за счет доступа из нескольких процессов и обеспечивает асинхронную репликацию, что очень важно для обработки частых обновлений. В документе также рассматриваются проблемы, связанные с традиционными системами баз данных и их недостатками в контексте высоких требований к производительности.
Chronicle Map
- 1.
- 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.
- 10. NUMA Доступ к памяти«чужого» сокета на ~30% медленнее
- 11. NUMA: архитектура 1 NUMAnode 1 core core core NUMA node 2 core core core Процесс
- 12. NUMA: архитектура 2 NUMAnode 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 1DB 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.
- 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-nioConcurrentHashMap В среднем наносекунд на запрос, меньше — лучше
- 40. Память 7,5 10,1 14,4 Chronicle Map one-nioConcurrentHashMap Общее потребление памяти, MB, меньше — лучше
- 41.
- 42. Память 7,5 10,1 14,4 15 20 Chronicle Map one-nio CHMredis 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.