Типичный случай — приложению работающему с БД некоторые объекты нужны так часто, то их необходимо кэшировать в памяти. В этом случае их кладут в структуру данных типа хэш. Однако, бывают случаи, когда даже поиск в этом хэше становится узким местом приложения и решения из стандартных библиотек перестают устраивать по своей производительности. Основной упор доклада будет не на конкретный алгоритм, а на та техниках дизайна быстрых алгоритмов — на что надо обращать внимание, как вообще подходить к решению подобных задач.

1. ПИШЕМ САМЫЙ БЫСТРЫЙ
хеш для кэширования данных
Роман Елизаров
Devexperts
http://elizarov.livejournal.com

2. Преждевременная оптимизация!
http://www.flickr.com/photos/lofink/4501610335/
http://odetocode.com/Blogs/scott/archive/2008/07/15/optimizing-linq-queries.aspx

3. Проблемы со скоростью?
Где?
Почему?
Какие?
Вам точно надо их решать?

4. Формулируем задачу
Четко. Кратко. Измеримо.

5. Пример задачи
1. Работаем с заявками
2. Их много, они нужны часто
3. Хотим их кэшировать в памяти

6. Моделируем нагрузку
http://www.vsemayki.ru/product/19329/woman/

7. Пример нагрузки
~1М заявок в кэше
10М запросов getById
Геометрическое распределение id

8. Что будем измерять?
Время Память

9. Избежим типичных ошибок
Помним
• JIT компиляция и оптимизация кода
• Сборка мусора

10. Так что будем измерять?
Среднее время одной итерации

11. Пишем код для замеров

12. Ищем готовые решения
http://gizmod.ru/2009/05/29/zweistil--universalnyj_velosiped_s_motorchikom/

13. Разные реализации хеш-таблиц
Время, нс на операцию
600
508
500 459
400
300
216
200 156
143
101
100
0
HashMap Guava high-scale-lib Trove Javolution HPPC

14. Не цифрами едиными! RTSL
http://www.cafepress.com/researchit.640209934

15. Что мешает скорости?
Время, нс на операцию
600
Функционал Гарантии real-time
500
400
300
200 Thread-safety
100
0
HashMap Guava high-scale-lib Trove Javolution HPPC

16. Вечный конфликт
Универсальность
Скорость

17. Дизайн своего решения
Производительность никогда
не появляется случайно,
только по замыслу авторов.

18. Из чего складывается скорость?
Алгоритм и
структуры Реализация Результат
данных

19. Выбираем алгоритм
• Д. Кнут
«Искусство программирования»
• Т. Кормен и др.
«Алгоритмы: построение и анализ»
• С. Скиена
«Алгоритмы. Руководство по
разработке»

20. Хеш-таблицы
Прямая
Открытая адресация
адресация
Линейное Двойное
исследование хеширование

21. Хеш-таблицы
И что работает быстрее?
Прямая А это зависит от
Открытая адресация
адресация
реализации и железа
Линейной Двойное
исследование хеширование

22. Что используют другие?
Время, нс на операцию
600
Прямая адресация
500 Открытая адресация
400
300
200
100
0
HashMap Guava high-scale-lib Trove Javolution HPPC

23. Память – это новый диск
http://www.flickr.com/photos/gudlyf/6687607947/lightbox/

24. Меньше памяти занимает –
быстрее работает*
* При прочих равных

25. Проверим …
Занимая память x100 KB
800
700
600
500
400
300
200
100
0
HashMap Guava high-scale-lib Trove Javolution HPPC

26. Меньше памяти использует –
быстрее работает*
* При прочих равных

27. Порядок оптимизации при дизайне
Занимаемая память
Используемая память
Другие детали

28. Выберем структуру данных
Открытая адресация – один массив

29. Оценим потребление памяти
Занимая память x100 KB
800
700
600
500
400
300
200
100
0

30. Выберем алгоритм (1)
Линейное исследование Двойное хеширование
• Проще • Больше кода
• Доступ к соседним • В случае промаха прыгает
ячейкам в новое место
• Более чувствительно к • Требует две независимые
качеству хеш-функции хеш-функции
• High-scale-lib, HPPC • Trove

31. Выберем алгоритм (2)
Хеш-функция умножением Хеш-функция делением
• Быстрая • Медленней
• Работает с таблицами – Но память еще медленней!
размером 2K • Лучше всего работает с
• Требует выбора таблицами простого
магического числа- размера
множителя • Trove
High-scale-lib – не использует хеш-функцию
HPPC – использует MurmurHash3

32. Как их комбинировать?
Проще всего
Линейное
исследование
Двойное
хеширование
Хеш-функция Хеш-функция
умножением делением

33. Напишем же!

34. Магия золотого сечения
5 1
2
Равномерно размазывает
последовательные числа по таблице

35. Замерим скорость
Время, нс на операцию
800
700
600 508
500 459
400
300 216
200 143 156
101 83
100
0

36. Важно распределение
вероятности доступа к разным
элементам
Наиболее часто используемые
заявки (последние)
имеют соседние id

37. Каждая деталь имеет значение
http://car-interior-supplies.carinteriorss.co.uk/detail/

38. А если набор часто используемых
id случаен?
Время, нс на операцию
800
700
600 529
500 463
400
300 253
200 162 125 158
81
100
0

39. Общий процесс
Формулировка Модель Готовые
задачи нагрузки решения
Структура Проверка и
Алгоритм
данных замеры*
* Повторить с начала по необходимости

40. Спасибо за внимание
Роман Елизаров
elizarov@devexperts.com
Специальная благодарность:
Денису Кисловскому

41. Хотите знать больше?
Все подробности, код и обсуждение:
http://elizarov.livejournal.com
Ваши комментарии важны для меня