Download to read offline
![Rendezvous affinity
22
• Consistent hashing [1]
• Rendezvous hashing (HRW) [2]
[1] https://en.wikipedia.org/wiki/Consistent_hashing
[2] https://en.wikipedia.org/wiki/Rendezvous_hashing](https://image.slidesharecdn.com/jpoint2017ozerov-170407114537/85/in-memory-22-320.jpg)
Uploaded byVladimir Ozerov
Масштабируемость в распределенных in-memory системах
Документ обсуждает технологии шардирования и co-location в распределенных in-memory системах, включая алгоритмы и синхронизацию в кластере. Он подчеркивает важность оптимизации архитектуры и распределения задач для достижения баланса между эффективностью и стабильностью. Кроме того, охватываются аспекты многопоточности и работа с данными, возникающие в контексте разработки и применения данных технологий.
Масштабируемость в распределенных in-memory системах
- 1. Владимир Озеров GridGain Масштабируемость в распределенныхin-memory системах
- 2.
- 3.
- 4.
- 5.
- 6. План 6 • Алгоритмы шардирования •Data co-location
- 7. План 7 • Алгоритмы шардирования •Data co-location • Синхронизация в кластере
- 8. План 8 • Алгоритмы шардирования •Data co-location • Синхронизация в кластере • Локальная архитектура многопоточности
- 9. План 9 • Алгоритмы шардирования •Data co-location • Синхронизация в кластере • Локальная архитектура многопоточности
- 10.
- 11.
- 12.
- 13. Affinity 13 key => partition=> node
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21. Naïve affinity 21 node =f(partition, nodes.size(), ...)
- 22. Rendezvous affinity 22 • Consistenthashing [1] • Rendezvous hashing (HRW) [2] [1] https://en.wikipedia.org/wiki/Consistent_hashing [2] https://en.wikipedia.org/wiki/Rendezvous_hashing
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30. План 30 • Алгоритмы шардирования •Data co-location • Shared-nothing архитектура • Синхронизация в кластере
- 31. Без co-location: транзакции 31 1:class Customer { 2: long id; 3: City city; 4: }
- 32.
- 33. Без co-location: транзакции 33 2(2 узла)
- 34. Без co-location: транзакции 34 2(2 узла) 2 (primary + backup)
- 35. Без co-location: транзакции 35 2(2 узла) 2 (primary + backup) 2 (two-phase commit)
- 36. Без co-location: транзакции 36 2(2 узла) 2 (primary + backup) 2 (two-phase commit) 2 (request-response)
- 37. Без co-location: транзакции 37 2(2 узла) 2 (primary + backup) 2 (two-phase commit) 2 (request-response) -- 16 сообщений
- 38.
- 39. Co-location: транзакции 39 1: classCustomer { 2: long id; 3: 4: @AffinityKeyMapped 5: City city; 6: }
- 40.
- 41.
- 42. Co-location: транзакции 42 1 (1узел) 2 (primary + backup)
- 43. Co-location: транзакции 43 1 (1узел) 2 (primary + backup) 1 (one-phase commit)
- 44. Co-location: транзакции 44 1 (1узел) 2 (primary + backup) 1 (one-phase commit) 2 (request-response)
- 45. Co-location: транзакции 45 1 (1узел) 2 (primary + backup) 1 (one-phase commit) 2 (request-response) -- 4 сообщения
- 46.
- 47. Без co-location: fullscan 47
- 48. Без co-location: fullscan 48
- 49. Без co-location: fullscan 49 • 1/3x latency!
- 50. Без co-location: fullscan 50 • 1/3x latency! • 3x capacity!
- 51. Индексы 51 А с индексамиже еще круче будет?
- 52.
- 53. Индексы 53 1 node Nnodes
- 54.
- 55. Посчитаем сложность 55 log 1_000_000≈ 20 vs log 333_333 ≈ 18 log 333_333 ≈ 18 log 333_333 ≈ 18
- 56. Посчитаем сложность 56 log 𝑁< 𝑀 ∗ log 𝑁 𝑀
- 57. Без co-location: indexseek 57
- 58. Без co-location: indexseek 58 • такой же latency? • такой же capacity?
- 59.
- 60.
- 61. Co-location: index seek 61 •такой же latency? • но 3x capacity!
- 62.
- 63.
- 64.
- 65.
- 66. План 66 • Алгоритмы шардирования •Data co-location • Синхронизация в кластере • Локальная архитектура многопоточности
- 67. Счетчик: локально 67 1: AtomicLongctr; 2: 3: long getNext() { 4: return ctr.incrementAndGet(); 5: }
- 68. Счетчик: локально, велосипедно 68 1:AtomicLong ctr; 2: ThreadLocal<Long> localCtr; 3: 4: long getNext() { 5: long res = localCtr.get(); 6: 7: if (res % 1000 == 0) 8: res = ctr.getAndAdd(1000); 9: 10: localCtr.set(++res); 11: 12: return res; 13: }
- 69.
- 70.
- 71. Счетчик: в кластере 71 •Локально: миллионы • Распределенно: тысячи
- 72. Разумные требования: счетчик 72 Уникальный,монотонно возрастающий, 8 байт!
- 73. Разумные требования: счетчик 73 Уникальный,монотонно возрастающий, 8 байт!
- 74. Разумные требования: счетчик 74 Уникальный,монотонно возрастающий, 8 байт!
- 75. Разумные требования: счетчик 75 Уникальный,монотонно возрастающий, 8 байт!
- 76.
- 77.
- 78.
- 79.
- 80.
- 81.
- 82.
- 83.
- 84.
- 85.
- 86.
- 87. Данные к коду 87 1:Account acc = cache.get(accKey); 3: 3: acc.add(100); 4: 5: cache.put(accKey, acc);
- 88. Данные к коду 88 1:Account acc = cache.get(accKey); 3: 3: acc.add(100); 4: 5: cache.put(accKey, acc);
- 89.
- 90. Данные к коду 90 1:cache.invoke(accKey, (entry) -> { 1: Account acc = entry.getValue(); 3: 3: acc.add(100); 4: 5: entry.setValue(acc); 6: });
- 91. Данные к коду:а если баг? 91
- 92. Код к данным:а если баг? 92
- 93. Код к данным:а если баг? 93
- 94. План 94 • Алгоритмы шардирования •Data co-location • Синхронизация в кластере • Локальная архитектура многопоточности
- 95.
- 96.
- 97.
- 98.
- 99.
- 100.
- 101.
- 102.
- 103.
- 104. Итого 104 • Шардинг: баланси стабильность
- 105. Итого 105 • Шардинг: баланси стабильность • Co-location: баланс vs эффективность
- 106. Итого 106 • Шардинг: баланси стабильность • Co-location: баланс vs эффективность • Модель данных должна быть адаптирована
- 107. Итого 107 • Шардинг: баланси стабильность • Co-location: баланс vs эффективность • Модель данных должна быть адаптирована • Координация – аккуратно
- 108. Итого 108 • Шардинг: баланси стабильность • Co-location: баланс vs эффективность • Модель данных должна быть адаптирована • Координация – аккуратно • Thread-per-partition – ускоряет простые сценарии, может замедлить сложные
- 109.
- 110.