Программное обеспечение - не мой конек. Однако...
Проект компании Microsoft, родившийся несколько лет назад и по дороге вроде бы умиравший, реализовался, таки. Имя ему Hecaton и представляет он собой набор инструментов (систему обработки транзакций в реальном времени, OLTP) для работы с базами данных в оперативной памяти.
Тенденции последних лет - а) снижение стоимости оперативной памяти (RAM); б) резкое увеличение объема устанавливаемой в системе памяти (Супермикровая X9DR3-LN4F+ - до 1,5Tb, например. Со следующим поколением процессоров еще больше будет), позволяют обрабатывать довольно большие массивы данных без обращений к дисковой системе. Microsoft догоняющий в этом забеге, но хотя бы не аутсайдер!
Hecaton полностью интегрирован в Microsoft SQL Server (так же, впрочем, как продукты конкурентов - Sybase Adaptive Server Enterprise, Oracle In-Memory Database Cache, например). Самый ощутимый эффект виден, конечно же, при использовании "своих" таблиц - они по структуре отличаются от традиционных SQL, но солидную прибавку в производительности может дать и комбинированное сочетание двух подходов. Причем, перестроение может проводиться поэтапно, т.к. происходит все в рамках одного программного продукта. Управление таблицами в оперативной памяти осуществляется процедурами библиотеки T-SQL.
Что делали всегда для оптимизации производительности баз данных? Для временных таблиц и индексов выделяли отдельное быстрое хранилище или помещали их в эмулированный в оперативной памяти диск, если ее объем позволял. Теперь все может быть устроено за счет самой быстрой памяти совершенно естественным способом. В отличие от кэширования, которое ускоряет операции чтения, In-Memory Database позволяет как читать, так и записывать данные.
Сценарий. Понятно, что критически важные данные необходимо сохранять в энергонезависимой памяти (диски, флэш). При этом существуют данные, ценность которых невелика или может быть воспроизведена без больших затрат. Вот их мы и будем обрабатывать очень быстро. Возьмем интернет-магазин. Запись об оплате заказа не может быть потеряна при сбое системы. Но к этой записи мы шли через многочисленные выборки из обширного каталога товаров, сравнения характеристик и цен, наполнения и очищения корзины. Все эти промежуточные данные имеют невеликую ценность и вполне могут обрабатываться в оперативной памяти.
Железная поддержка. Помимо собственно пространства оперативной памяти, достаточного для размещения части или целой БД, используются некоторые механизмы, без которых эффект от от In-Memory Database был бы не столь впечатляющим. Транзакционная память (transactional memory) - механизм синхронизации записей на основе блокировки. Транзакция в данном случае - это частью кода, который выполняет считывание и запись в разделяемую (совместно используемую) память. Считывание и запись логически происходит в единичный момент времени, а промежуточные состояния невидимы для других транзакций. Аппаратная поддержка транзакционной памяти реализована Intel в микроархитектуре Haswell. Помимо основной памяти, приходится разбираться с конфликтами в кэшах, которых у процессора три - введен механизм когеррентности (Cache Coherency). И Intel и AMD используют для этого протокол MESI. Т.е., в обработку транзакций могут быть втянуты и кэш процессоров всех уровней!
Овчинка и выделка.
Данные испытаний взяты из материалов Microsoft.
"Native" - "родной" формат Hecaton. Структура несколько отличается от традиционной SQL. "Interop" - компромиссный вариант обработки. Таблицы традиционной структуры SQL, но обрабатываются в оперативной памяти.
Выводы:
- производительность, т.е. количество обработанных транзакций в секунду растет практически линейно вместе с количеством задействованных ядер процессоров. Средняя прибавка - 0,9...0,93 на ядро. Рост практически одинаков для всех вариантов расположения базы.
- переход на обработку в оперативной памяти дает очень солидную прибавку - от 7-кратной на двух ядрах до почти 16-кратной на 12 ядрах.
- производители "железа" подстраиваются под особенности ПО. Общими усилиями системы передвигаются на следующий уровень эффективности и производительности.
http://research.microsoft.com/pubs/193594/Hekaton%20-%20Sigmod2013%20final.pdf
http://www-db.in.tum.de/~leis/papers/HTM.pdf
http://www.sybase.ru/system/files/pdf/ase_getting_started_whitepaper_p2.pdf
http://oraclegis.com/temp/tat/In-memory%20DB%20cache%2011g%20rus.pdf
Проект компании Microsoft, родившийся несколько лет назад и по дороге вроде бы умиравший, реализовался, таки. Имя ему Hecaton и представляет он собой набор инструментов (систему обработки транзакций в реальном времени, OLTP) для работы с базами данных в оперативной памяти.
Тенденции последних лет - а) снижение стоимости оперативной памяти (RAM); б) резкое увеличение объема устанавливаемой в системе памяти (Супермикровая X9DR3-LN4F+ - до 1,5Tb, например. Со следующим поколением процессоров еще больше будет), позволяют обрабатывать довольно большие массивы данных без обращений к дисковой системе. Microsoft догоняющий в этом забеге, но хотя бы не аутсайдер!
Hecaton полностью интегрирован в Microsoft SQL Server (так же, впрочем, как продукты конкурентов - Sybase Adaptive Server Enterprise, Oracle In-Memory Database Cache, например). Самый ощутимый эффект виден, конечно же, при использовании "своих" таблиц - они по структуре отличаются от традиционных SQL, но солидную прибавку в производительности может дать и комбинированное сочетание двух подходов. Причем, перестроение может проводиться поэтапно, т.к. происходит все в рамках одного программного продукта. Управление таблицами в оперативной памяти осуществляется процедурами библиотеки T-SQL.
Что делали всегда для оптимизации производительности баз данных? Для временных таблиц и индексов выделяли отдельное быстрое хранилище или помещали их в эмулированный в оперативной памяти диск, если ее объем позволял. Теперь все может быть устроено за счет самой быстрой памяти совершенно естественным способом. В отличие от кэширования, которое ускоряет операции чтения, In-Memory Database позволяет как читать, так и записывать данные.
Сценарий. Понятно, что критически важные данные необходимо сохранять в энергонезависимой памяти (диски, флэш). При этом существуют данные, ценность которых невелика или может быть воспроизведена без больших затрат. Вот их мы и будем обрабатывать очень быстро. Возьмем интернет-магазин. Запись об оплате заказа не может быть потеряна при сбое системы. Но к этой записи мы шли через многочисленные выборки из обширного каталога товаров, сравнения характеристик и цен, наполнения и очищения корзины. Все эти промежуточные данные имеют невеликую ценность и вполне могут обрабатываться в оперативной памяти.
Железная поддержка. Помимо собственно пространства оперативной памяти, достаточного для размещения части или целой БД, используются некоторые механизмы, без которых эффект от от In-Memory Database был бы не столь впечатляющим. Транзакционная память (transactional memory) - механизм синхронизации записей на основе блокировки. Транзакция в данном случае - это частью кода, который выполняет считывание и запись в разделяемую (совместно используемую) память. Считывание и запись логически происходит в единичный момент времени, а промежуточные состояния невидимы для других транзакций. Аппаратная поддержка транзакционной памяти реализована Intel в микроархитектуре Haswell. Помимо основной памяти, приходится разбираться с конфликтами в кэшах, которых у процессора три - введен механизм когеррентности (Cache Coherency). И Intel и AMD используют для этого протокол MESI. Т.е., в обработку транзакций могут быть втянуты и кэш процессоров всех уровней!
Овчинка и выделка.
- Оперативная память все-таки дороже, чем SSD.
- Объем оперативной памяти, хоть и расширяется с каждым поколением процессоров, ограничен сверху. Максимальный объем набирается модулями DDR емкостью в 32Гб, которые пока еще стоят несусветных денег. Ускорителями PCI или накопителями SSD можно набрать больший объем.
- С другой стороны, как показывает статистика, большая доля баз данных не превышает в объеме 1Тб.
- !!!! Всегда надо помнить, что оперативная память все потеряет в случае сбоя или потери питиния системой. Критически значимые данные и результаты транзакций ДОЛЖНЫ обрабатываться традиционным способом - с использованием дисковых накопителей.
| Транзакций/сек | ||||||
| К-во ядер | 2 | 4 | 6 | 8 | 10 | 12 |
| SQL with contention | 984 | 1363 | 1645 | 1876 | 2118 | 2312 |
| SQL without contention | 1153 | 2157 | 3161 | 4211 | 5093 | 5834 |
| Interop | 1518 | 2936 | 4273 | 5459 | 6701 | 7709 |
| Native | 7078 | 13892 | 20919 | 26721 | 32507 | 36375 |
Данные испытаний взяты из материалов Microsoft.
"Native" - "родной" формат Hecaton. Структура несколько отличается от традиционной SQL. "Interop" - компромиссный вариант обработки. Таблицы традиционной структуры SQL, но обрабатываются в оперативной памяти.
Выводы:
- производительность, т.е. количество обработанных транзакций в секунду растет практически линейно вместе с количеством задействованных ядер процессоров. Средняя прибавка - 0,9...0,93 на ядро. Рост практически одинаков для всех вариантов расположения базы.
- переход на обработку в оперативной памяти дает очень солидную прибавку - от 7-кратной на двух ядрах до почти 16-кратной на 12 ядрах.
- производители "железа" подстраиваются под особенности ПО. Общими усилиями системы передвигаются на следующий уровень эффективности и производительности.
http://research.microsoft.com/pubs/193594/Hekaton%20-%20Sigmod2013%20final.pdf
http://www-db.in.tum.de/~leis/papers/HTM.pdf
http://www.sybase.ru/system/files/pdf/ase_getting_started_whitepaper_p2.pdf
http://oraclegis.com/temp/tat/In-memory%20DB%20cache%2011g%20rus.pdf
Комментариев нет:
Отправить комментарий