Кластерные индексы по сравнению с некластерными индексами?
KVM по IP хорош, но в зависимости от того, где Вы работаете, это может быть навязывание товара, чтобы изложить доводы и заставить Ваше управление сокращать проверку. При использовании серверов HP ProLiant можно заказать им с МОТ, поглотив большинство удаленных затрат управления в цену сервера. Не забывайте планировать дополнительные сетевые порты, в которых Вы будете нуждаться. Если Вы модифицируете, лично мне нравится серия Raritan Dominion лучше всего.
Если это сводится к выбору между IPKVM и дистанционным управлением питанием, выберите дистанционное управление питанием. Сегодняшние операционные системы обрабатывают удаленные операции (SSH/RDP/VNC и др.) достаточно хорошо, что Вам редко было бы нужно другое средство KVM во всяком случае, и как часто необходимо действительно сделать модификации BIOS издалека? Вы могли бы уделить реальное внимание пропуску KVM в целом и использованию нескольких из них, мобильный ПК стоит. Если Вы делаете настоящего настоящего мужчину, отлаживающего по последовательному порту, можно сохранить помещенными ПК на него. В противном случае просто клавиатура и монитор. И возможно немного UPS.
мобильный монитор стоит http://imagescl.cyberguys.com/images/detail_thumb/p4356-4.jpg
Для дистанционного управления питанием мне нравятся они APC вертикальная коммутируемая стойка PDUs. Существует диапазон их для установки потребностям. Действительно хорошая функция - то, что они всегда показывают, сколько усилителей оттягивается, таким образом, Вы не перегружаете своих выключателей. Следует иметь в виду, что серверы имеют тенденцию потреблять больше энергии при запуске и когда они становятся горячими (думайте отказ ОВКВ), таким образом, Вы хотите выполнить свои схемы в 70-80% макс., или меньше. Эти PDUs сделают ступенчатый запуск так, чтобы, если по некоторым причинам Ваш включают целую стойку сразу, Вы сразу не смещались прерыватель. Наряду с вертикальным управлением питанием, не забывайте получать короткие шнуры питания в 1' и 3' длины - это сделает Ваши стойки намного более опрятными и легче справиться!
Удаленное питание и KVM - как я упомянул ранее, иногда жесткое продает. Но рано или поздно они повернут то, что было бы отключением электричества 4-12 часов во что-то, что это решено в течение 45 минут или меньше.
В сетевой части распределения комнаты, я - большой поклонник NeatPatch. В этом изображении действительно говорится все это:
NeatPatch http://g.imagehost.org/0081/1wave.jpg
Я должен также упомянуть эти вертикальные патч-панели, которые я не попробовал:
сопроводительный текст http://www.racksolutions.com/images/racks/tube/lan-pwr-left-angle-250h.gif
Наконец, это не смонтировано в стойке, но я думаю, что контроль серверной важен. Необходимо знать, когда ОВКВ отключает, и температура начинает повышаться! Можно также хотеть иметь один с камерой, таким образом, Вы получаете журнал безопасности того, кто там. Я был доволен NetBotz в прошлом, но если это твердо заставить босса платить за (цены, кажется, выросли, так как APC приобрел компанию), Вы могли бы взглянуть на Погодную Утку/Гуся/и т.д. от ITWatchDogs
Кластерный индекс определяет физический порядок данных в таблице и особенно эффективен на столбцах, которые часто ищутся диапазоны значений. Они также эффективны для нахождения определенной строки, когда индексируемое значение уникально.
Обычно (существуют исключения), кластерный индекс должен быть на столбце, который увеличивается монотонно - такие как столбец идентификационных данных или некоторый другой столбец, где значение увеличивается - и уникально. Во многих случаях первичный ключ является идеальным столбцом для кластерного индекса (но не помещайте кластерный индекс на uniqueidentifier/GUID столбец.)
Из этой статьи MSDN:
Прежде, чем создать кластерные индексы, поймите, как к Вашим данным получат доступ. Рассмотрите использование кластерного индекса для:
- Столбцы, которые содержат большое количество отличных значений.
- Запросы, которые возвращают диапазон операторов использования значений такой как МЕЖДУ,>,> =, <и <=.
- Столбцы, к которым получают доступ последовательно.
- Запросы, которые возвращают большие наборы результатов.
- Столбцы, к которым часто получают доступ запросы, включающие пункты GROUP BY или соединение; обычно это столбцы внешнего ключа. Индекс на столбце (столбцах), указанном в ORDER BY или пункте GROUP BY, избавляет от необходимости SQL Server сортировать данные, потому что строки уже отсортированы. Это улучшает производительность запросов.
- Приложения типа OLTP, где очень быстрый поиск одной строки требуется, обычно посредством первичного ключа. Создайте кластерный индекс на первичном ключе.
Кластерные индексы не являются хорошим выбором для:
- Столбцы, которые претерпевают частые изменения: Это приводит ко всему перемещению строки (потому что SQL Server должен сохранить значения данных строки в физическом порядке). Это - важный фактор в системах обработки крупной транзакции, где данные имеют тенденцию быть энергозависимыми.
- Широкие ключи: значения ключа от кластерного индекса используются всеми некластеризованными индексами в качестве ключей поиска и поэтому хранятся в каждой некластеризованной индексной листовой записи.
SQLServerpedia.com имеет некоторые хорошие статьи/учебные руководства для индексной настройки: Индексируйте Связанные Запросы DMV и Используя Правильные Индексы для Оптимальной Производительности.
-
1Спасибо за то, что убрали часть дыма. Спасибо за две ссылки также. – RateControl 7 July 2009 в 23:15
Я считал, что это - очень хорошая практика, чтобы использовать суррогатный ключ и использовать кластерный индекс на том столбце. Как правило, это будет международным столбцом, который будет автоинкремент (ИДЕНТИФИКАЦИОННЫЕ ДАННЫЕ), или uniqueidentifier (сделайте это последовательным GUID для предотвращения проблем производительности позже!).
При этом Ваши запросы сделают СОЕДИНЕНИЯ на тех суррогатных ключах через таблицы, давая Вам производительность и масштабируемость.
До других (некластеризованных) индексов тот выбор зависит от того, как Ваши клиенты используют Ваше приложение. Слишком много индексов записывают аварию для, вставляет/обновляет. Недостаточные индексы замедляют чтения. Необходимо будет найти баланс черно-белым два. Столбцы, которые используются в сочетании с поисками, являются логическими кандидатами на индексацию, включая составные (многостолбцовые) индексы (возражайте против своего порядка столбцов, в этом случае).
Если Вы хотите стать необычными, имейте отдельную базу данных OLAP для создания отчетов об исторических данных.