Индекс в СУБД

Индекс лишним не бывает? Чем больше индексов, тем лучше? А не проиндексировать ли это измерение на всякий случай? Если подобные вопросы иногда возникают в вашей голове, то эту статью прочитать было бы весьма полезно.

Итак, традиционное мнение, что «Индекс это хорошо, а блокировка это плохо», часто бывает неверным до противоположности.

Картинка выше, которую я выбрал для заголовка статьи, очень часто напоминает многие базы 1С, которые неожиданно начинают «быстро расти»и «тормозить».

Но прежде чем перейти к сути, придется немного покопаться в теории.

Что такое индексы, для чего они нужны, какие они бывают?

Далее будет немного теории, объясняемой простым языком. Если все эти вопросы вам давно известны и вы считаете, что нет необходимости в таком примитивном объяснении, то вы, наверное, слишком редко заглядывали в доработки конфигураций, да что и говорить, в типовые конфигурации 3-4 летней давности, в любом случае, этот раздел всегда можно пропустить.

📌 Реклама Отключить

Итак, как работает индекс? Наверное, все в детстве играли в игру «угадай число»? Кто-то загадал число от 1 до 50, а вам его нужно угадать за наименьшее число вопросов.

Т.е. поступите примерно так, как показано на картинке:

В ВУЗ-е мы уже узнаем, что подобные структуры называются графами, вернее, даже разновидностью графа — деревьями. Бывают еще более вырожденные разновидности деревьев, так называемые B-деревья.

Собственно, они и лежат в основе большей части индексов.

Хотя, конечно, не большей. Индексы делятся на два типа: кластерные и не кластерные.

📌 Реклама Отключить

Конечно, можно вспомнить, что есть битовые индексы, функциональные индексы, XML индексы.

Но принципиальным отличаем будем считать физическую организацию и принцип работы.

Кластерный индекс — это по сути дела не индекс, а определенным образом организованная таблица. В Oracle его, к примеру, вообще называют Index Organized Table или IOT.

Некластерный индекс — это отдельная структура, как правило, вида B-дерева, которая создается дополнительно к основной таблице.

Если вы сейчас думаете, что эти два вида индексов придумали ИТ специалисты, то вы сильно ошибаетесь.

Вот так выглядит кластерный индекс, который появился еще до появления компьютера:

А как-то вот так, соответственно, некластерный:

📌 Реклама Отключить

Данная аналогия оказывается на удивление полной.

Каким образом вам бы удобнее было искать? Сразу выбрать страницу, начиная с той буквы, которая указана на срезанных полях,

или сначала заглянуть в предметный указатель, потом узнать там номер страницы и уже искать нужную страницу по номеру?

Конечно, первый способ куда удобнее. Но вот только не очень он гибкий… обычно на полях ставят только буквы.

Нельзя написать целое слово или несколько слов, в то время как в предметном указателе их можно организовать как угодно.

Кроме того, предметный указатель по сути ссылается на номера страниц книги, на которых расположена нужная информация.

Сами номера страниц являются при этом по сути кластерным индексом.

Теперь давайте посмотрим уже более детально, применительно к MS SQL Server:

В MS SQL существуют 2 физических операции Index Seek и Index Scan. Index Seek — это хорошо, Index Scan — плохо.

📌 Реклама Отключить

Index seek означает просмотр индекса в порядке упорядочивания, либо по B-Дереву, Index Scan — обычная операция просмотра всех

записей таблицы, аналогичная всем известной Table Scan. Чаще всего данная операция присутствует в случае «неполного покрытия» индекса,

Если в индексе, к примеру, есть поле «Контрагент, Номенклатура» а отобрать записи надо по «контрагенту, номенклатуре и заказу покупателя».

В этом случае в плане запроса MS SQL можно будет увидеть что-то вида:

Т.е. сначала по индексу были выбраны записи, соответствующие покрытию, а остаток записей был получен полным последовательным просмотром таблицы.

А если мы сделаем у таблицы не кластерный индекс, то в итоге увидим примерно следующую картину:

📌 Реклама Отключить

Тут есть еще одна интересная операция — RID Lookup, занимающая целых 50% времени — столько же, сколько поиск по индексу.

Собственно, дополнительная операция трубуется из-за того, что некластерный индекс не производит выборку по самой физической таблице, следовательно, требуется еще сам поиск нужной физической страницы, чтобы считать сами данные.

Но в данном случае есть еще одна специфика — это слово «Heap», указанное в скобках операции. Но о нем далее.

Чем плохи индексы?

1) Накладные затраты при записи данных

Очевидно, что для поддержаиня какой-либо дополнительной структуры данных, либо определенной организации данных, требуется совершать дополнительные действия.

Действий не так много, накладные затраты на них небольшие. Но плохо то, что эти затраты и действия возникают при записи данных. А запись данных происходит в транзакции.

📌 Реклама Отключить

Хуже если в транзакции происходит и запись и чтение данных (контроль остатков). В этом случае индекс должен быть всегда в актуальном состоянии.

Затраты на запись или чтение в транзакции намного «дороже» внетранзакционных издержек. Дело в том, что запись может вестись строго последовательно, и время на фиксацию изменений в БД сократить достаточно сложно. Более мощное оборудование тут не всегда помогает.

Внетранзакционное же чтение данных может вполне успешно выполняться параллельно, при этом в случае увеления количества запросов на чтение данных, к примеру, вследствие роста количества пользователей, то они вполне могут решиться наращиванием аппаратных ресурсов.

2) Накладные затраты на обслуживание индексов

При интенсивной записи данных в таблицу данные индексов к ней не всегда распологаются на той странице, на которой должны. Появляются «пропуски», физическая структура индексов становится неэффективной. Поэтому иногда бывает необходимо производить дефрагментацию индексов. Производительность запросов к СУБД во время дефрагментации, соответственно, падает. Есть еще процесс полного перестроения индексов — но в современных версиях MS SQL необходимости выполнения данной операции по регламенту нет.

📌 Реклама Отключить

3) Влияние индексов на размер базы

Не самое страшное последствие, но так или иначе если база весит 150-200 ГБ, то об этом надо уже задуматься. Для средней OLTP базы размер индексов, как правило, превышает объем самой базы.

Не верите? Вполне можете воспользоваться какой-либо обработкой вроде этой: http://infostart.ru/public/19463/ и посмотреть, сколько же в вашей базе места занимают индексы.

4) Затраты на создание и поддержание актуальной статистики

Статистику в базе нужно регулярно обновлять при интенсивных операциях вставки и обновления. Это занимает вычислительные ресурсы, хоть и не влияет непосредственно на процесс.

Неактуальная статистика может привести к проблемам производительности системы.

Но это не значит, что индексы — это плохо, без них СУБД были бы бесполезны. Плохи индексы, которые не используются.

📌 Реклама Отключить

Как оптимизатор выбирает, какой индекс ему использовать? (статистика, плотность, селективность, кардинальность)

Итак, про то, что «статистика должна быть» и «ее нужно обновлять», слышали, наверное, все.

Многие даже знают, что нужно обновлять статистику, наизусть помнят запрос:

EXEC sp_MSForEachTable ‘UPDATE STATISTICS ? WITH FULLSCAN;’

Главное — не забыть, что хитрый MS SQL кэширует планы запроса, котьорые он уже раз посчитал. Даже если статистика изменится,

для того, чтобы что-то заработало по-другому, надо бы выполнить:

DBCC FREEPROCCACHE

Но гораздо реже люди заморачиваются с тем, чтобы посмотреть статистику БД. Давайте попробуем это сделать на тестовой таблице:

Сделаем в БД простейшую таблицу следующего вида:

Потом выполним:

DBCC SHOW_STATISTICS(‘TAB’, NAME)

📌 Реклама Отключить

Оказывается, сколько всего сохраняется для такой маленькой таблицы. Интересен еще тот факт, что вы же не выполняли никакого кода по созданию статистики.

Если статистика для таблицы не отключена, то она создается сама. И это тоже ложится на накладные расходы.

Сейчас нам интересен в этой таблице столбец Density — Плотность записей. Плотность рассчитывается как

Плотность = Число дубликатов в колонке / Общее число записей в таблице

И является одним из самых выжных статистических показателей данных в таблице. Очевидно, что чем меньше плотность записей, тем эффективнее можно будет воспользоваться индексом.

А при плотности 0.5, как в приведенном примере, индекс в принципе вообще не нужен. Чем ниже в таблице значение Density, тем более правильно спроектирована данная таблица.

📌 Реклама Отключить

Для СУБД лучше всего таблицы с уникальными записями. Обратите внимание на столбец All density — его значение уже 0.25. Это означает, что в таблице есть ещ одна колонка. Для MS SQL этот показатель важен, когда вы пишете «СГРУППИРОВАТЬ ПО».

Но плотности записей оптимизатору недостаточно. Основная задача оптимизатора — «догадаться», сколько строк вернет запрос.

Допустим, у нас в базе куча складов по всем регионам — небольшие торговые точки + виртуальные склады. И есть один центральный склад.

Плотность по складу будет достаточно неплохая. Но вот число строк по центральному складу, которое вернет запрос, и по региональному будет различаться в тысячи раз.

Для этого есть показатель селективности:

Селективность=число строк удовлетворяющих предикату/всего строк в таблице

Предикат — определенное условие.

Из картинки выше селективность определяется в третьей таблице. Там указан «ключ» — RANDE_HI_KEY и соответственно количество строк ему соответствующее… и количество значений, ему соответствующее в таблице.

📌 Реклама Отключить

Ну, и остался последний показатель статистики:

Кардинальность — это и есть предположительное число строк, которое вернет запрос

В каждом элементе плана запроса этот показатель присутствует.

Если навести на элемент плана запроса курсор, то его можно увидеть во всплывающей подсказке примерно так:

Итак, если итоговый запрос возвращает половину таблицы или около того, то индекс тут совсем не нужен.

Индекс также бесполезен, если оптимизатор MS SQL решает, что итоговый запрос вернет половину таблицы или вроде того.

Почему MS SQL так может решить, вроде разобрались.

Теперь самое время разобраться, какие индексы есть в 1С:

📌 Реклама Отключить

Все просто. Все объекты 1С делятся на ссылочные (у которых есть ссылка и, соответственно, GUID) и табличные (регистры).

У всех таблиц 1С есть кластерный индекс.

У ссылочных кластерный индекс создается по ссылке (GUID) — это самая быстрая выборка, которая только может быть.

У табличных кластерный индекс создается по всем изменениям. Что тоже предельно логично. И, конечно, этот индекс уникальный.

А как же затраты на запись? Зачем создавать кластерный индекс везде?

Дело тут в том, что так работает MS SQL. В стандартной таблице просто должен быть кластерный индекс.

Без него выборка из этой таблицы будет приводить к тому, что операция поиска записи по индексу (как было на картинке выше) будет занимать непростительно много времени.

В MS SQL таблицы без кластерного индекса называеют Heap Table — куча. Что примерно соответствует их физической организации.

📌 Реклама Отключить

Тем не менее, такие таблицы могут быть важны. Если у вас 99% операций в этой таблице — запись, а для анализа этих данных вы, к примеру, применяете отдельное OLAP решение.

Поэтому возможность убирать кластерные индексы из таблиц очень бы не помешала разработчикам 1С.

Когда вы ставите у какого либо реквизита, ресурса или измерения объекта 1С признак «индексировать» — создается дополнительный или обновляется существующий не кластерный индекс для этой таблицы.

Включая реквизиты объекта в критерий отбора, вы также создаете по ним отдельный индекс.

Это лишь общие правила, по которым платформа создает индексы на уровне СУБД. В каких-то деталях они могут отличаться, тем более в разных версиях платформы.

К счастью, 1С не пожадничали и дали нам инструмент, чтобы структуру БД просматривать — я про фукнкцию «ПолучитьСтруктуруХранения()».

📌 Реклама Отключить

Умельцы этой функцией воспользовались и сделали для нее неплохой интерфейс, которым можно вопспользоваться, чтобы точно посмотреть, какие же есть индексы у таблицы:

Зачем я все это прочитал?

Что делать простому разработчику 1С?

Простой разработчик в отличие от оптимизатора MS SQL может заранее предсказать, какие будут данные в запросе, какие будут предикаты и какие нужны индексы.

Что же нужно делать, чтобы ваши запросы выполнялись быстро и при этом при записи данных в БД это не приводило к перезаписи нескольких десятков бесполезных индексов.

  1. Делайте индексы, покрывающие предикаты, если данный запрос планируется к использованию достаточно часто. Но не забудьте, что уже существуют кластерные индексы.
  2. Если находится индекс, уже покрывающий предикат в запросе, не создавайте нового индекса.
  3. Если индекс покрывает почти все условие запроса — оцените число записей, которое придется перебрать СУБД при данной выборке, если оно невелико (менее нескольких тысяч) — не создавайте нового индекса
  4. Определите селективность и/или плотность записей в выборке так, как их определит в данном случае оптимизатор. Если в итоговой выборке получится много записей по отношению к общему числу записей в таблице — не создавайте индекса, он лишний
  5. Когда пишете запрос, думайте о том, как его будет анализировать оптимизатор, сможет ли он корректно посчитать ориентировочное число строк, возвращаемое каждой частью запроса.
  6. В конце концов проверьте план полученного запроса, если он вам действительно важен, особенно если данный запрос нужно выполнять в транзакции.

Многие слышали о том, что индексы в базах данных это весьма полезная штука. Но, одно дело слышать, а другое представлять себе их устройство хотя бы на базовом уровне. Поэтому в рамках данной статьи для начинающих, я рассмотрю этот вопрос, применяя простые и понятные каждому выражения и аналогии из жизни.

Что такое индекс базы данных и зачем он нужен?

Чтобы понять зачем нужны индексы в базе данных и что он собой представляет, сейчас рассмотрим простой пример.

Представьте себе, что у вас есть полочка для книг. При этом изначально эта полочка с книгами пуста. Книги вам то приносят, то уносят, то делают в них какие-то корректировки (к примеру, мемуары или может быть черновики) и тому подобное.

Так как полочка маленькая, то вы как-то не особо задумывались о какой-либо системе классификации, а просто вставляете книги в любые пустые места.

Каждый раз когда-то вам или кому-то необходимо найти определенную книгу, возникает необходимость просматривать все книги с самого начала полочки до первой попавшейся (если нужна только одна книга) или полностью все (если нужно собрать все копии). В принципе, для одной полочки это весьма необременительно.

Теперь, представьте себе, что речь идет не об одной полочке, а об огромном помещении, где находятся тысячи книг.

Тут-то вы и начинаете задумываться о том, что неплохо бы ввести какую-то систему классификации, например, по названию книги. Конечно, полностью сортировать все эти тысячи книг в алфавитном порядке вы не собираетесь, плюс с этим возникло бы куча других вопросов (как добавить книгу в уже заполненную полку и прочие).

Поэтому вы поступаете проще, вы берете каталог, где возможно добавлять листочки. При этом каждую страницу выделяете только под одно название книги, а сами страницы располагаете в каталоге в порядке возрастания названий. Содержание этих страниц весьма просто — вы записываете в каком стеллаже, на какой полке и какой по счету является книга. Если книг несколько, то строчек в этой странице становится несколько.

Таким образом, чтобы найти одну или все нужные книги по названию, вам достаточно открыть этот каталог и быстро пролестнуть до нужной страницы, а затем пройтись по всем указанным стеллажам. При этом для упрощения, вы так же можете первые буквы названий так же индексировать. То есть добавляете наклейку на каждую первую страницу с указанной буквой (таким образом можете сразу перейти, например, к букве «Р», не пролистывая все названия до нее).

Конечно, для поддержки такой системы требуется дополнительное время, но все же оно существенно меньше, чем попытка найти вслепую книгу из тысячи (пара минут против нескольких часов и более).

Так вот, в данном примере, если переносить это в базу данных:

Помещение — это таблица в базе данных. Если чуть проще, то любое скопище однотипных данных (тех же книг), по сути, представляет собой таблицу.

Поиск книги — это sql-запросы получения данных. При этом важно отметить, что сами по себе они не меняются. То есть вам как нужно было найти «Термодинамику», так и осталось нужным найти «Термодинамику». Другое дело, как вы будете это осуществлять — прочесывая тысячи книг или открыв каталог.

Каталог — это и есть упрощенный вариант индекса в базе данных. То есть, индекс это набор дополнительных данных, записанных в удобном виде, который позволяет существенно быстрее осуществлять поиск, хоть и требующий дополнительных усилий для поддерживания его актуальности.

Имя книги (страничка) — это ключ в индексе. То уникальное значение, которое может ссылаться как на одну какую-то запись, так и на несколько. Стоит отметить, что даже если записей для каждого значения будет несколько, это все равно быстрее, чем полный перебор всех данных.

Если суммировать, то можно увидеть, что наличие индекса может быть весьма выгодным. Например, для одной домашней полочки с десятком книг — индекс в общем-то не сильно нужен, а вот когда речь заходит о более больших объемах, то индекс будет весьма полезным.

Так же можно заметить, что добавление индекса не требует того, чтобы сами sql-запросы были переписаны, так как последние являются лишь выражением на упрощенном языке для базы данных. Если продолжить аналогию, то это как попросить кого-то найти вам «Флора и фауна». При этом каким образом и сколько этот кто-то будет искать книгу, будет решать сам этот человек. В данном примере «найти книгу» — это sql-запрос, а этот «кто-то» это база данных.

Какие бывают индексы?

Вообще, в зависимости от типов баз данных, индексы могут быть очень разными и реализоваться за счет специфических математических механизмов. Но, наиболее частым является древовидный индекс, так как поддерживать такой индекс относительно просто и максимальная скорость поиска в нем составляет логарифм по числу максимального количества дочерних узлом от общего количества записей (плюс минус некоторые технические моменты).

Немного поясню.

Дерево (древовидный индекс) — это специального вида структура, у которой есть корневая вершина и у каждого узла может быть несколько дочерних узлов. При этом каждый узел встречается только один раз и может иметь всего один родительский узел. Выглядит это так:

Как видите, очень похоже на перевернутое обычное зеленое дерево, у которого ветки растут не вверх, а вниз.

Максимальное количество дочерних узлов, как вероятно уже догадались по картинке, это то количество дочерних узлов, больше которого у одного узла не может быть.

Теперь поясню откуда берется логарифм. Дело в том, что дерево обычно заполняется по определенным правилам. К примеру, если у узла максимально может быть всего два дочерних узла (так называемое бинарное дерево), то обычно левый дочерний узел имеет значение меньше текущего, а правый большее значение. Поэтому если вам нужно найти, например, число 30 в дереве с рисунка чуть выше, то вам понадобится всего 4 сравнения (40 — 25 — 32 — 30). Именно из-за этой особенности поиска и берется логарифм (так как каждое сравнение сокращает количество проверяемых элементов в два раза). При этом обычно значение логарифма округляют в большую сторону.

Так же отмечу, что такая скорость достигается за счет того, что дерево строится специальным образом, чтобы не возникало таких ситуаций, как на картинке ниже, где максимальная скорость поиска будет сравнима с простым перебором всех записей.

Как видите, чтобы здесь найти запись с ключом «3» понадобится 4 сравнения (40 — 25 — 10 — 3), хотя всего записей 5.

Практически во всех базах данных, существует деление по уникальности:

Уникальный индекс — это такой индекс, у которого все значения встречаются только один раз. Проводя аналогию, когда каждая книга присутствует только в одном экземпляре и никогда названия книг не совпадают.

Неуникальный индекс — это такой индекс, у которого значения могут повторяться. Проводя аналогию, существуют книги с одними и теми же названиями, но разными авторами, или же просто встречаются копии.

Важно отметить, что если для таблицы создается уникальный индекс, то это означает, что при попытке добавить запись со значением, которое уже встречалось, или же изменить значение какой-то записи на существующее, то база данных не позволит сделать такое действие и будет ругаться (выдавать ошибки). В случае же с неуникальным индексом таких проблем нет.

Так же стоит знать, что индексы делятся по количеству входящих в них полей:

Обычные индексы — состоят из одного поля. Здесь, вероятно, все понятно. Обычный каталог страничек.

Составные индексы — строятся по нескольким полям, при этом расположение полей является важным.

Чуть подробнее про составные индексы. Рассмотрим аналогию с теми же книгами. До этого индекс строился только по названию. Теперь же представим, что книги с одинаковыми названиями часто встречаются. В такой ситуации, легко может получится, что страничка каталога будет состоять из координат сотен книг (десятки авторов и у каждого по десять копий). Бегать их всех проверять — так же немалое количество времени. Поэтому вместо того, чтобы страничка просто перечисляла все местонахождения книг, можно сделать так, чтобы странички с именами книг указывали на дополнительные каталоги, где аналогичным образом проиндексированы авторы.

Немного упрощая, поиск будет выглядит примерно так.

1. Вначале вы ищите в каталоге с именами необходимую страничку с названием.

2. Затем в этой страничке смотрите, где находится соответствующий каталог с авторами.

3. Берете этот каталог и уже в нем находите страничку, где указано месторасположение всех книг с этим автором и названием.

При этом важно понимать, что для каждого названия будет создаваться собственный каталог авторов. То есть в обратном порядке, к сожалению, поиск не осуществить. Если же требуется поиск вначале по автору, а уже затем по названиям книг, то необходимо создавать отдельный составной каталог (составной индекс).

Существуют и другие моменты, но чаще всего достаточно знать хотя бы эти базовые знания.

Индекс Хирша, или h-индекс, принадлежит к главным показателям научных изысканий. Сегодня в России, равно как и во всем мире, h-индекс служит для оценки активности ученого в плане публикаций. Значение h-индекса возрастает, когда необходимо произвести перемены в кадровом секторе, а также при получении научных званий и выделении грантов. Предлагаем вам вникнуть в суть понятия и разобраться в его необходимости.

Собственно, понятие

Механизм действия индекса Хирша основывается на количестве цитирования научных статей. Однако, от обычного подсчета цитирований всех работ, которые автор успел опубликовать, его отличает удельный вес. Говоря иными словами, h-индекс выделяет работы автора, которые оказались наиболее востребованными светилами научного мира за последние годы.

Разработку индекса выполнил ученый Хорхе Хирше, аргентино-американец, на базе расположенного в Сан-Диего Калифорнийского университета. Произошло событие в 2005 году. Нынче индекс применяют для оценки продуктивности работ организаций, коллективов и отдельных ученых – в плане их научности.

Как сделать расчет индекса Хирша

Он производится, исходя из аналитического подхода к цитированию работ отдельного ученого по отношению к их количеству.

Методика Х.Хирше говорит о том, что ученому присваивается индекс h, если из общего количества статей N цитируется n статей минимум по n раз каждая, при условии что статьи, которые остались (N — n) имеют количество цитирований, не превышающее n раз. К примеру, если ученый имеет сотню опубликованных статей, и каждая из них была процитирована по одному разу, то h-индекс будет равен 1. Аналогичной будет цифра у автора, который издал всего один труд, но который процитировали 100 раз.

Рассмотрим еще одну разновидность подсчета, которая гораздо чаще реализуется в жизни. Допустим, научный работник напечатал 5 статей научного значения. Первый труд был процитирован минимум 5 раз, второй — 4 раза, и далее по нисходящей. Рассчитаем h-индекс для этого эрудита.

Первый труд имеет 5 упоминаний, второй – всего 4. Это значит, что магистр, кандидат наук или доктор наук уже имеет минимум 2 статьи, о которых значатся упоминания не менее 4 раз.

Статья №3 ученого была упомянута в трудах других научных деятелей 3 раза. Получается, что у эксперта в выбранной тематике есть уже 3 статьи, с цитированием каждой минимум по 3 раза (производится подсчет и всех предыдущих статей).

В результате, мы получаем h-индекс, приравнивающийся к 3: это обозначает, что автору удалось собрать минимум 3 статьи, каждая из которых была процитирована минимум 3 раза.

Поскольку остальные статьи имеют меньше 3 цитирований – они не учитываются при расчете индекса Хирша.

В результате, чтобы получить значение h-индекса, необходимо выстроить статьи от большего к меньшему количеству их цитирований. Далее следует отыскать научный труд, номер которого идентичен количеству ссылок на него. Это число и станет индексом Хирша. Его определение в базах данных происходит автоматически: выполняется анализ всех публикаций представителя научных кругов и анализ всех их цитирований.

Калькулятор разработанный компанией Big Time

Ваш текущий индекс

Желаемый индекс Хирша

Определение личного числа

Узнать своё h-число можно на сайте elibrary.ru, для этого даже не нужно регистрироваться. Когда откроется главная страница, выберите пункт меню «Навигатор», а в нём подпункт «Авторский указатель». Далее ищите свою фамилию. При вычислении h-индекса учитываются только те статьи, которые проиндексированы библиографической базой данных РИНЦ.

При помощи h-индекса можно более точно понять, насколько популярной является работа исследователя. Индекс Хирша более точен по сравнению с общим числом напечатанных работ и общим количеством их упоминаний.

Однако, существует важный нюанс: h-индекc может сильно отличаться в зависимости от выбранной области знаний. Это можно объяснять разными подходами к цитированию. Например, медицинские труды цитируют чаще, чем труды физиков. Учитывая подобное несоответствие, традиция определять по h-индексу научный уровень теоретика или практика, а также его соответствие должности, еще находится в стадии совершенствования. В университетах и научно-исследовательских центрах пока принимают во внимание и другие показатели.

Индекс Хирша можно обсчитать в наукометрических базах, платных и бесплатных. Можно узнать свой h-индекс Скопус, если ваши статьи индексируются этой базой. Чтобы ответ был утвердительным, нужно опубликовать научный труд в журнале базы данных Scopus. Дополнительный нюанс: в каждой базе данных h-индекс отдельно взятого ученого может отличаться, так как неравнозначен объём данных, взятых для анализа.

Влияние h-индекса на рейтинг исследователя

Каким же должен быть индекс Хирша для определенного звания в России? Ниже поданы приблизительные диапазоны оценки для ученых разных категорий:

  • Всемирно известный ученый, председатель Диссертационного Совета – 16 и выше;
  • член Диссертационного Совета – 10-15;
  • доктор наук – 7-10;
  • кандидат наук – 3-6;
  • аспирант или молодой исследователь – 0-2.

Как сделать индекс Хирша более высоким?

Сделать это нелегко. Довольно распространенной можно считать ситуацию, когда в РИНЦ проанализированы не все авторские труды, и не все основанные на исследовательских статьях цитаты. Случается, что заслуги одного автора приписываются другому. Так может произойти в результате совместного написания труда либо подобия фамилий разных авторов.

Чтобы достойно выйти из сложившейся ситуации, следуйте нашим советам:

  1. Печатайте те статьи, которые написаны лично вами, и которые имеют большое значение для науки.

  2. Начиная путь исследователя, старайтесь писать материалы в соавторстве с известными людьми, имеющими высокие показатели в науке.

  3. Публикуйте статьи не только в журналах ВАК, но и в изданиях на английском языке (Web of Science, Scopus).

  4. Выполняйте обмен ссылками со своими коллегами.

  5. Уделяйте должное внимание библиографическому списку, оформляйте его по правилам.

  6. Подавая заявку на публикацию научного труда, проверьте, правильно ли написаны ваши личные данные.

  7. Следите за индексацией ваших работ в разных базах.

Выполнение этих простых правил не только поможет повысить вам h-индекс, но и повысит ваш авторитет среди представителей научных кругов!

Если у Вас остались, какие либо вопросы, или же Вы нуждаетесь в помощи по повышению индекса Хирша — пишите нашему менеджеру в форме ниже, который бесплатно проконсультирует Вас.

Табличная селективность или селективность строк – соотношение количества строк, возвращаемых запросом к общему количеству строк в таблице.

Индексная селективность — отношение числа строк соответствующих конкретному ключевому значению к общему числу строк в индексе. Селективность индекса – это показатель того, сколько строк от общего числа приходится на одно ключевое значение индекса. Построим формулу. Селективность индекса = ( NUM_ROWS/DISTINCT_KEY) / NUM_ROWS = 1/DISTINCT_KEY

Таким образом, чтобы рассчитать селективность индекса довольно посмотреть значение DISTINCT_KEYS в динамическом представлении ALL_INDEXES. Селективность чаще вычисляют в процентах. Чем больше этот процент, тем меньше (хуже) селективность. Селективность хороша, если мало строк имеют одинаковые ключевые значения.

Индексный доступ к данным имеет смысл при хорошей селективности. Это утверждение верно при равномерном распределении данных. Однако для ситуации с неравномерным распределением данных такой подход не оправдан. Рассмотрим пример. Предположим у нас есть только два ключевых значения: 1 и 2. Только у одной записи нашей таблицы ключевое поле равно 2. Все остальные записи имеют ключевое поле равное 1. Для нашего случая distinct_key=2, а значит селективность 0,5! Но реально для доступа по предикату ключ=2 использование индекса вполне оправдано. А для предиката ключ=1 индексный доступ вообще не имеет смысла.

Селективность блоков определяется как соотношение числа блоков, содержащих хотя бы одну строку, удовлетворяющую условию запроса к общему количеству блоков данных ниже high-water mark . Обратите внимание, что селективность строк практически всегда лучше блочной селективности.

Вас заинтересует / Intresting for you:

Экстенты 2564 просмотров Ольга Потемкина Tue, 21 Nov 2017, 13:18:46 Индексы, листовые блоки, перес… 5620 просмотров Tue, 21 Nov 2017, 13:31:33 Основные новшества версий СУБД… 872 просмотров Игорь Воронов Tue, 21 Nov 2017, 13:28:01 Как переименовать таблицу в Or… 11744 просмотров Боба Tue, 21 Nov 2017, 13:31:33 Author: Anna Другие статьи автора:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *