(Возврат на основную страницу)
Editorial
Нейл Давидсон
Парадокс посредника
Programming
Кевин Кляйн
Как использует пространство TempDB
Эрланд Соммарског
Условия динамического поиска в T-SQL. Часть 2
Кален Делани
Оптимальное использование автоматического обновления статистических данных 16
DB Design & Warehousing
Кален Делани
Расширяя предельно допустимые для строки 8K
Парадокс посредника
Чем сильнее нас захлестывает информационная волна, тем большую необходимость мы испытываем в средствах фильтрации данных и возможностей выбора. Парадокс заключается в том, что чем больше у нас шансов избавиться от посредника, тем сильнее мы в нем нуждаемся.
За те два месяца, что он был доступен на сайте, свыше миллиона человек скачали альбом In Rainbows группы Radiohead. В 2000 году, когда Стивен Кинг выложил роман Riding the Bullet на своем сайте, серверы рухнули под нагрузкой. Сет Годин (Seth Godin) оценивает, что свыше 2 миллионов человек скачали Unleashing the Ideavirus, когда он выпустил эту книгу в электронном формате в свободный доступ. Эти примеры демонстрируют, как успешно Интернет позволяет нам избавиться от посредника. У процесса даже есть (довольно некрасивое) название: Disintermediation. По крайней мере так говорит здравый смысл. А вот я не уверен, что это так. Полагаю, нужда в посреднике не исчезнет, в посреднике, который лучше, умнее, просто в другом посреднике. Несомненно, традиционные агенты по продаже туристических путевок, книжные магазины и музыкальные компании исчезнут, но это только первая стадия в цикле созидательного разрушения.
Вот пример того, как убийца посредника старого типа выступает повивальной бабкой нового. Положим, вы покупаете автомобиль. Подержанный. Вы можете купить у дилера, а можете у владельца машины. В прошлом, если вы покупали у дилера, ваш выбор был богаче. На демонстрационной площадке стоит множество машин. Точно также продать машину проще дилеру, чем конкретному человеку. Все изменилось с появлением eBay: вы минуете посредника и покупаете напрямую у продавца, причем выбор гораздо больше, чем может предложить любой дилер.
Однако возникает необходимость в посреднике нового типа. Рынок подержанных машин хорошо известен проблемой качества. Покупатель знает про выставленные машины гораздо меньше дилера. Соответственно, он предполагает определенное качество и готов платить только в определенных пределах суммы. Если цена подержанных автомобилей держится на определенном уровне в зависимости от качества, продавцу нет необходимости продавать качественные машины. Все равно покупатель приходит с определенным предубеждением относительно качества. В результате некачественные автомобили вытесняют хорошие. Следует понимать, что описанная ситуация основана на диспропорции информации у продавца и покупателя. Если покупатель владеет тем же объемом информации, что и продавец, проблема исчезает. Это идеальная роль для посредника. И речь не идет об реинкарнации Артура Дали (Arthur Daley — персонаж сериала, беспринципный и жуликоватый торговец. — Прим. пер.), но о комто, кто продает информацию и чей товар хорош и достоин доверия. Вы готовы заплатить посреднику за поиск подержанного автомобиля, проверку качества и предоставление гарантий? Я — да.
Второй пример — наем на работу. В попытке избавиться от посредника сайты типа Monster выродились в мясной рынок нанимателей и кандидатов. К сожалению, в этом случае закон Старджина (Sturgeon’s law), гласящий, что 90 % любого предложения — мусор, работает безукоризненно. Этот принцип распространяется в обе стороны: 90 % кандидатов и 90 % предлагаемых позиций — мусор. Если рассматривать Monster в качестве единственного примера — это 100 миллионов негодных кандидатов и 50 миллионов никому не нужных предложений. Но в этом мусоре зарыты бриллианты и просеивание мусора — ценнейший дар. Иными словами, рекрутеры, хорошие рекрутеры, в наше время важны как никогда.
Все это касается не только физически реальных товаров, для которых нужен хороший посредник. С виртуальными та же самая ситуация. Интернет предлагает легкие пути связи писателей с читателями, музыкантов со слушателями и актеров со зрителями, что позволяет обойтись без традиционных посредников, таких как журналы, книги и газеты. Но бесконечно нарастающий объем информации сталкивается с нашими конечными возможностями эту информацию потреблять. У нас нет возможности фильтровать бесконечный поток данных, приводя его к конечному объему. В результате, люди, посредники, способные выполнить это за нас, становятся все более ценны. Меня очень привлекают неожиданные подходы, которые реализует BBC, Slashdot или Boing, применительно к информационному хаосу, по сравнению с тем, что предлагает нивелирующая до низшего уровня «мудрость масс» или холодная логика алгоритмов Google.
И я не думаю, что эти примеры изолированы. По мере того как Интернет снимает потребность в «тупых» посредниках, он создает потребность в интеллектуальных посредниках. По мере того как нас захлестывает информационная волна, нам все больше нужна помощь в фильтрации данных. Чем старательнее мы избавляемся от посредника, тем больше мы в нем нуждаемся…
Посредник мертв. Да здравствует посредник!
Как использует пространство TempDB
Aaron Bertrand, ведущий блог на SQLBlog.com и работающий в команде поддержки сайта http://www.aspfaq.com/, является одним из SQL Server MVP, материалы которых в моем списке обязательных для чтения. Он разработал действительно полезный запрос для определения пространства, занимаемого объектами из TempDB:
SELECT
SPID = s.session_id,
s.[host_name],
s.[program_name],
s.status,
s.memory_usage,
granted_memory = CONVERT(INT, r.granted_query_memory*8.00),
t.text,
sourcedb = DB_NAME(r.database_id),
workdb = DB_NAME(dt.database_id),
mg.*,
su.*
FROM sys.dm_exec_sessions s
INNER JOIN sys.dm_db_session_space_usage su
ON s.session_id = su.session_id
AND su.database_id = DB_ID('tempdb')
INNER JOIN sys.dm_exec_connections c
ON s.session_id = c.most_recent_session_id
LEFT OUTER JOIN sys.dm_exec_requests r
ON r.session_id = s.session_id
LEFT OUTER JOIN (
SELECT
session_id,
database_id
FROM sys.dm_tran_session_transactions t
INNER JOIN sys.dm_tran_database_transactions dt
ON t.transaction_id = dt.transaction_id
WHERE dt.database_id = DB_ID('tempdb')
GROUP BY session_id, database_id
) dt
ON s.session_id = dt.session_id
CROSS APPLY sys.dm_exec_sql_text(COALESCE(r.sql_handle,
c.most_recent_sql_handle)) t
LEFT OUTER JOIN sys.dm_exec_query_memory_grants mg
ON s.session_id = mg.session_id
WHERE (r.database_id = DB_ID('tempdb')
OR dt.database_id = DB_ID('tempdb'))
AND s.status = 'running'
ORDER BY SPID;
Вы можете посчитать нужным написать свой запрос, основанный на dm_db_session_space_usage, но этот работает действительно хорошо. Спасибо, Aaron, что поделился!
Условия динамического поиска в T-SQL. Часть 2*
* См. Эрланд Соммарског. Условия динамического поиска в T-SQL. Часть 1 // SQL Server для профессионалов. 2008. №5.
DOWNLOAD
Оптимальное использование автоматического обновления статистических данных
Настройте производительность, используя UPDATE STATISTICS и флаги трассировки для улучшения индексных статистических данных
DOWNLOAD
Microsoft SQL Server 2005 обладает возможностью автоматического обновления данных статистики, для помощи в обеспечения оптимального выполнения SQL Server-запросов. В дальнейшем вы сможете улучшить качество индексных статистических данных SQL Server — для настройки производительности запросов — используя UPDATE STATISTICS и два новых в Microsoft SQL Server 2005 SP1 флагов трассировки.
Если вы когданибудь занимались настройкой производительности, вы хорошо осведомлены, что правильное индексирование, наверное основное средство, с помощью которого вы пытаетесь повлиять на производительность. Для хорошей производительности нужны хорошие индексы, но чтобы оптимизатор SQL Server распознал бесполезность индекса, вам потребуются высококачественные статистические данные. Начиная с версии SQL Server 7.0, SQL Server обновляет индексные статистические данные автоматически, что увеличивает вероятность того, что ваши данные будут актуальными. До версии 7.0 статистические данные можно было обновлять только вручную; таким образом, первой задачей в списке условий повышения производительности было обновление статистических данных для всех таблиц, используемых проблемными запросами.
Возможность автоматического обновления ваших индексных статистических данных — это великолепная возможность, но и она несовершенна. Посмотрим, как SQL Serverоптимизатор определяет необходимость обновления статистических данных, а затем узнаем коечто о новых флагах трассировки в SQL Server 2005 SP1, это поможет вам контролировать функцию автоматического обновления статистических данных.
Расширяя предельно допустимые для строки 8K
Узнайте, как SQL Server 2005 хранит данные, превышающие размер строки
DOWNLOAD
В течение нескольких последних месяцев я обсуждала, как SQL Server 2005 отслеживает пространство, занимаемое таблицами и индексами, говорила о том, что новые структуры метаданных немного сложнее по сравнению с SQL Server 2000, но они и гораздо более гибкие. В «Управлении пространством данных» я объяснила, что каждая таблица (или индекс) может хранить данные трех видов: обычные данные (IN_ROW), большие объекты (LOB) и данные, превышающие размер строки (ROW_OVERFLOW) — это новинка в SQL Server 2005.Особенно вам может пригодиться возможность превышения размера строки, если в ваших таблицах много столбцов разной длины, общий размер которых обычно умещается в максимальный размер строки, равный 8060 байтам, но может случайно оказаться и больше. Давайте рассмотрим, как SQL Server работает с новыми данными, переполняющими строку.
(Возврат на основную страницу)