Этот пост - по работе, носит технический и исследовательский характер, составлен для потомков. Не рекомендуется к прочтению лицам со слабой психикой.Кэширование является эффективным методом для увеличения производительности процессов, которые имеют повторяющиеся вычислительные алгоритмы. Однако, существует ряд нюансов организации кэширования в базе данных. Аналитику различных методов кэширования проведем на прикладной базе процесса "отсрочка в рабочих днях", описанного мною ранее. Тем не менее, стремясь создать универсальный инструмент, заложим функционал кэширования любого типа данных, используя следующие параметры:
- тип кэшируемых данных (текстовый/числовой код в зависимости от варианта тестирования)
- ключ кэша (текстовый, числовой, два числовых в зависимости от варианта тестирования)
Исходные данные.Тест: Отсрочка в рабочих днях
Данные: таблица праздников
Алгоритм: собственный, с применением рекурсии, используются два параметра (начальная дата, число дней для отсрочки), на выходе - конечная дата для последующего кэширования.
Железо: AMD Athlon XP 1600+ (1.4GHz), 2x256 MB RAM, Chipset nForce2 Ultra (dual channel)
Софт: Windows XP, SQL Server 2005, MS Access 2003
Нагрузка: 20x365 = 7300 циклов тестирования (вычисление отсрочки в рабочих днях от 01.01.2010)
Условия: при всех изменениях таблицы производился пересчет индекса UPDATE STATISTICS. Все испытания проводились дважды с полным совпадением результатов.
Метод вычислений: замер времени в контрольных точках начала и конца заполнения и прочтения таблицы (7300 строк)
Погрешность вычислений: 0.5 секунды
Варианты тестирования.а) текстовый индекс.
поля таблицы:
cache_type varchar
cache_key varchar
cache_value varchar
индекс: (cache_type & cache_key)
б) primary & текстовый индексы
поля таблицы:
rid int
cache_type varchar
cache_key varchar
cache_value varchar
индексы: (rid), (cache_type & cache_key)
в) primary & числовые индексы ключа
поля таблицы:
rid int
cache_type varchar
cache_idx1 int
cache_idx2 int
cache_value varchar
индексы: (rid), (cache_type & cache_idx1 & cache_idx2)
г) primary & все числовые индексы
поля таблицы:
rid int
cache_type_id int
cache_idx1 int
cache_idx2 int
cache_value varchar
индексы: (rid), (cache_type_int & cache_idx1 & cache_idx2)
д) вариант "г" + использование подтаблицы типов кэша, ключ которых подставляется в cache_type_id
Результаты тестирования.
| Метод | Запись | Чтение |
| а) текстовый индекс | 2:57 | 2:10 |
| б) primary & текстовый индексы | --"-- | 2:30 |
| б) primary & текстовый индексы БЕЗ чтения самого primary индекса (rid) | --"-- | 0:33 |
| в) primary & числовой индекс ключа | --"-- | 0:35 |
| г) primary & все числовые индексы | --"-- | 0:34 |
| д) г + использование справочной таблицы типов кэша | 3:05 | 1:25 |
Анализ результатов.1. Изменение типа кэширования не влияет на скорость записи в кэш, за исключением использования дополнительных таблиц.
2. Использование PRIMARY INDEX значительно ускоряет чтение кэша, ОДНАКО ПРИ УСЛОВИИ, что самого чтения индекса не производится. В противном случае происходит сильное замедление чтения.
3. Использование одного сериализованного ключа кэша (составной ключ в одном поле) не замедляет чтение, хотя и увеличивает объем хранимых данных
4. Использование нескольких числовых ключей вместо одного сериализованного не дает преимущества в скорости, хотя сокращает объем данных
5. Использование дополнительной таблицы замедляет процессы записи и (в значительной степени) чтения кэша, тем не менее, сокращая объем данных.
Вывод.1. Для задач, требующих высокую скорость обработки кэша, рекомендуется использовать простую таблицу, состояющую из primary index, текстового (возможно-сериализованного) ключа кэша и значения кэша, однако, на этапе чтения, не следует читать из базы primary index.
2. Для задач, в которых помимо скорости критичен общий объем занимаемого базой данных места на диске, рекомендуется использование числовых индексов в кэше, с использованием нескольких полей. Числовой параметр типа кэша должен обрабатываться и задаваться программными средствами, чтобы избежать необходимости использования справочной подтаблицы, замедляющей процессы записи и чтения.
http://agneta.livejournal.com/91364.html
Фильм поражает и рвет башню :)
Купила эти ухи в подарок начальнику - у него день варенья скоро. Себе бы наверное не решилась, а он занимается музыкой, пишет гитару, барабаны и голос. 
Сразу хочу сказать, что звукоизоляция просто превосходная! Звукопоглощение тоже отличное. Уши полностью помещаются в амбажуры. Даже выключенные надеваешь - и вокруг почти полное пантомимо :) Материал амбажур приятный. Звук чистый с акцентом с центре. Басы насыщенные, верха достаточно четкие.
В магазине сравнивала с Beyerdynamic 770. У них более интересные верха - бархатистые такие, но низы менее ощутимые. Материал амбажур у них более мягкий и прилегание более аккуратное, но стоят они конечно на сто баксов дороже. Импеданс там кстати за двести, это чувствуется.
В целом, рекомендую обратить внимание на модель HD 280 Pro тем, кто ищет наушники в ценовой категории до 5 тысяч с хорошим звуком и прекрасной звукоизоляцией.
![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=1){kind=small}
ice_3000 за открытие :)
