Все ИТ-специалисты в общих чертах представляют себе тенденции развития информатизации и знают, что в этом контексте является прогрессивным решением, а что нет. Так, например, считается, что консолидация информационного ресурса в компании является благом. Однако следует признать, что это самое благо оценивается в основном с точки зрения прикладного аспекта ИТ-поддержки бизнеса.
В этом смысле действительно централизованно хранящийся и приведенный в непротиворечивое состояние информационный ресурс, к которому в современном бизнесе часто имеет одновременный доступ целый ряд приложений, как правило, представляет собой наиболее оптимальный вариант ИТ-архитектуры. С позиций же проблем более низкого, инфраструктурного уровня та же ситуация выглядит куда менее радужно. Именно вследствие растущего количества самостоятельных ИТ-систем, получающих доступ к единому ресурсу, узким местом неминуемо становится скорость выборки данных сервером БД, а в бизнес-терминах — скорость проведения отдельных транзакций. И чем больше ИТ-систем входит в этот пул, чем больше оборудования (коммутационного в том числе) задействовано при построении централизованных дисковых хранилищ, тем острее проблема.
На все это накладываются последствия практического освоения небезызвестной концепции больших данных. Если раньше в многочисленных логах систем слежения за теми или иными объектами в лучшем случае пытались отловить крупинки критически важной информации, то сегодня появляется техническая возможность находить в этих логах скрытые закономерности, обрабатывая огромные массивы первичных данных целиком. Всё это усугубляет проблему «бутылочного горлышка», образующегося на этапе доступа к данным.
И наконец играют свою роль тенденции самого бизнеса. Вопервых, в целом ряде отраслей бизнес укрупняется, что элементарно приводит к увеличению количества информации. Характерно и то, что консолидация бизнеса нередко происходит на рынке розничных продаж, где весьма значима концепция клиенториентированности. Транзакции же, производимые с целью выявить неявные закономерности о существующих или потенциальных клиентах, часто требуют данных, порождаемых различными системами. А это значит, что в процессе укрупнения бизнес скорее всего будет консолидировать ИТ-ресурс в едином хранилище. Причем даже в том случае, если он прекрасно понимает не только достоинства, но и недостатки этого подхода.
Поиск решения
О том, что то самое «бутылочное горлышко» доступа к большим централизованным ресурсам в соответствии со случайными (читай SQL) запросами реально существует, стало известно не вчера. И для решения этой проблемы имеется по крайней мере два направления.
Первое напрашивается само собой — это кэширование информации. Но если под этим термином понимать не те архитектурные приемы, которые «зашиты» внутри отдельных аппаратных решений, а кэш корпоративного уровня (назовем его так), то тут проблема если и решалась, то всегда с массой побочных эффектов. Один из основных состоит в том, что подобные решения весьма громоздки, насыщены независимыми аппаратными компонентами (часто с элементами механики) и, как следствие, склонны к отказам оборудования. Именно с такими характеристиками долго ассоциировалась двухуровневая архитектура хранения «магнитная лента — магнитный диск». Более современные двухуровневые системы с массовым применением дисков SSD и магнитных носителей (где первые выполняют роль быстрой памяти, а вторые — медленной) сняли часть упомянутых проблем, но не полностью. К тому же такое решение по сей день остаётся весьма дорогим. Не дешевыми и весьма ограниченно масштабируемыми являются и новейшие решения, построенные по технологии in-memory.
Вторым направлением, призванным снять проблему доступа, является программная оптимизация запросов, которая по понятным причинам почти всегда привязана к конкретному программному продукту. А если проанализировать рынок таких систем, можно заметить, что объектом оптимизации чаще всего становится Microsoft SQL-сервер.
Почему речь идет конкретно об этой системе? Дело прежде всего в её простоте и как следствие большой популярности в корпоративном мире. За эту простоту неминуемо приходится расплачиваться заметной ограниченностью возможностей настройки, а значит, невозможностью достичь производительности штатными средствами.
Дополнительным бонусом к системе оптимизации запросов можно считать также сервисы, обеспечивающие более удобную и эффективную работу, как правило, реализуемые в определенных часто встречающихся ситуациях.
Решение существует
Здесь хотелось бы рассказать о новом решении, по сути сочетающем все положительные факторы имеющихся способов повышения производительности случайных запросов при минимизации их недостатков. С архитектурной точки зрения речь идет о плате ZD-XL SQL Accelerator стандарта PCI Express компании OCZ Technology, устанавливаемой (фактически по технологии plug&play) в соответствующий разъем сервера БД.
Решение совмещает в себе флэшпамять, используемую в качестве кэша, встроенную программно-аппаратную логику (firmware) и программные драйверы, оптимизируя производительность запросов к Microsoft SQL-серверу. Иными словами, в данном случае мы сочетаем технологии кэширования и программной оптимизации под конкретный продукт, что существенно повышает эффективность решения как целого.
Рассмотрим каждое направление более подробно. С флэшпамятью всё в общем понятно и без комментариев. Ее использование на ZD-XL SQL Accelerator позволяет наследовать все преимущества современных SSD-дисков — высокую скорость отклика и компактные размеры. Очень важно и то, что выход из строя накопителей этой категории (в отличие от жестких дисков) гораздо более предсказуем, поскольку основан на известных физических законах деградации физической структуры носителя.
Но все-таки карта ZD-XL SQL Accelerator — это не просто флэшдиск, а устройство с более высокоуровневой организацией пространства памяти. На нем, в частности, можно формировать тома (volumes), на которых в свою очередь могут размещаться программные объекты в виде, например, временных БД (tempDB), индексных файлов или даже отдельных активных на тот или иной момент приложений.
Но все же куда более интересны технологии оптимизации, реализуемые с помощью данной карты при тех или иных вариантах ИТ-архитектуры.
Как уже было сказано, использование ZD-XL SQL Accelerator оптимизировано для Microsoft SQL сервера, о чем более подробно можно сказать следующее:
- настройка при инсталляции позволяет, условно говоря, нажатием одной кнопки определить режим оптимизации MS SQL-сервера, ориентированный либо на аналитические, либо на транзакционные запросы;
- обеспечена возможность ускорения запросов в отказоустойчивых конфигурациях групп MS SQL-серверов AlwaysOn Availability Groups или SQL Server Failover Cluster Instances. В этих случаях вторая, обычно резервная база может использоваться не в транзакционном режиме обновления, а как источник only read для аналитических запросов при соответствующей конфигурации, привязанной ко второму серверу карты ZD-XL SQL Accelerator. Надо сказать, что такая схема оптимизации крайне востребована в коммерческих компаниях.
И наконец, надо сказать об уже упомянутых сопутствующих сервисах, которые также являются частью современных схем оптимизации доступа к БД. Здесь можно упомянуть технологию так называемого прогрева кэша, по сути являющуюся частным случаем популярной при планировании загрузки инфраструктурных решений технологии workload management. Причем прогрев этот может производиться и в автоматическом режиме, что предполагает некий процесс самообучения системы, основанный на анализе предыдущего профиля нагрузки на сервер. В этом случае в течение, скажем, нескольких часов устройство ZD-XL SQL Accelerator адаптируется к профилю и самостоятельно без участия администратора способно вывести систему на максимальные характеристики производительности запросов.
В заключение еще раз отметим, что основными бенефициарами описанной технологии являются компании с объемными и при этом централизованными информационными ресурсами, в составе ИТ-архитектуры которых присутствует MS SQL Server. Разнообразные испытания и реальные примеры позволяют говорить о существенном повышении производительности — в ряде случаев до 25 крат и даже более.
