Что такое длина шингла

Что такое шингл, для чего он нужен и на что он влияет? Говоря простым языком, шингл – это текстовые фрагменты определённой длины, участвующие в процессе определения уникальности текста. Данная поисковая технология используется во всех сервисах и приложениях. Метод шинглов позволяет с высокой достоверностью определить неуникальные участки, последовательно сверяя их с результатами из интернета или подключаемых модулей Антиплагиата.

Что такое длина шингла?

Это количество слов, по которым производится проверка. Сначала Антиплагиат берёт первые три слова и проверяет наличие аналогичных последовательностей. На следующем шаге берётся следующий шингл – со второго по четвёртое слово. Следующий шингл включает слова с третьего по пятой, следующий – с четвёртого по шестой. Если они постоянно совпадают с каким-либо другим текстом из базы, Антиплагиат принимает решение о низкой или нулевой уникальности текста. Если количество неуникальных шинглов мало, уникальность высокая. Так как их длина составляет три слова, то уникальным должно быть каждое третье слово в проверяемом документе.

Как сбить шаг шингла в Антиплагиате?

Классические приложения и сервисы проверки уникальности используют длину шингла в 5-6 слов. За счёт этого уникальным окажется даже лёгкий рерайт. Чем меньше длина, тем больше придётся трудиться над текстом, переделывая его «от и до». Алгоритм шинглов неумолим, из-за чего студентам приходится выжимать из себя все соки, чтобы сделать курсовую, диплом, реферат или диссертацию максимально уникальной – в среднем требуется не менее 80%, но для рефератов планка снижается до 50-70%. Зато от диссертаций требуется уникальность не менее 80-90%.

Также как Адвего, Text.ru или Content-Watch, Антиплагиат.Ру использует в своей работе всё тот же метод шинглов. Ситуация осложняется тем, что к этому сервису подключаются дополнительные модули:

1. Модули поиска Интернет Плюс.
2. Модуль поиска переводных заимствований.
3. Сводная коллекция ЭБС.
4. Кольцо ВУЗов.
5. Модуль поиска общеупотребительных выражений.
6. Модуль поиска перефразирований Интернет и многие другие.

Если классические системы проверки уникальности работают только с выдачей поисковых систем, то Антиплагиат использует дополнительные модули. И если простой рерайт способен сбить с толку классические системы, с Антиплагиатом такой трюк не пройдёт – он прекрасно распознаёт поверхностный рерайт.

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

Как сделать работу уникальной без использования метода шингла?

Зная, что такое шинглы текста, можно существенно поднять уникальность работы. Но проблема заключается в том, что Антиплагиат использует всё более сложные алгоритмы оценки уникальности. И метод шингла – далеко не единственный алгоритм.

Чтобы поднять уникальность курсовой или дипломной работы, диссертации или реферата, воспользуйтесь нашим сервисом. Он избавит от бессонных ночей и бесконечных попыток уникализировать материал. Загрузите файл, оплатите 100 рублей, укажите желаемый порог уникальности и получите на выходе работу, полностью готовую к сдаче – теперь можно смело заняться любимыми студенческими делами и развлечениями. Проверка двух страниц – бесплатная.

Источник

Что такое шингл

Шингл (от англ. shingle «черепица», «кирпичик») – это отдельный элемент текста, состоящий из нескольких подряд идущих слов. Используется в большинстве современных программ для проверки уникальности текста. Наиболее распространенная длина шингла, используемая для проверки уникальности, находится в диапазоне от 4 до 10 слов. Наиболее функциональные программы для проверки уникальности позволяют задать в настройках любую длину шингла, что делает анализ текста более подробным. В ходе проверки приложение берет отрезок текста из слов, количество которых равно длине шингла, и проверяет его уникальность, сравнивая его с документами, уже находящимися в интернете.

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

Указать длину шингла для проверки уникальности текста можно в программах Etxt Антиплагиат и Advego Plagiatus.

Какой должна быть длина шингла?

Чем короче шингл, тем точнее проверка уникальности текста, оптимальная длина для проверки не превышает 5-7 слов. Большая длина приведет к тому, что даже текст, состоящий из полностью скопированных частей предложений, будет иметь уникальность 100%. А проверка с шинглом 3 приведет к тому, что даже авторский текст будет иметь низкую уникальность, так как в интернете найдется множество одинаковых словосочетаний из трех слов. Именно поэтому некоторые биржи текста даже запрещают требовать от авторов 100%-ной уникальности текста при длине шингла 3.

В последнее время многие SEO-оптимизаторы и web-аналитики приходят к мысли, что «допиливание» текстов до необходимого процента уникальности приводит только к их неестественности и снижению качества. Качественная статья «для людей» не может не содержать словосочетаний, устойчивых выражений и цитат, которые являются основными причинами снижения уникальности. Особенно сильно это касается медицинских, юридических и технических тематик, где копирайтеры, зажатые требованиями 100%-ной уникальности текста при длине шингла 3, вынуждены перевирать термины и сложившиеся синтаксические обороты, в результате чего Рунет заполняется тысячами бесполезных и даже вредных статей, не несущих в себе никакой информации.

Длина шингла и размножение текста

Источник

Что такое шингл – простыми словами

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

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

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

Алгоритм шингла. Шиг шингла

ЧТО ТАКОЕ ШИНГЛ?

Шингл – это определенные фрагменты текста, по которым производится проверка оригинальности документа, сайтами проверяющими текст на антиплагиат.

Более просто, понятие шингл можно будет понять, если рассмотреть такое понятие. как шаг шингла.

АЛГОРИТМ ШИНГЛА. ШАГ ШИНГЛА

При проверке текста на уникальность, системы антиплагиата(такие как антиплагиат ру, Антиплагиат ВУЗ, ЕТХТ, Адвего, текст ру и другие) используют определенный алгоритм проверки.

Этот алгоритм основан, как раз таки, на шаге шингла. Что это значит? Что такое алгоритм шингла?

Рассмотрим на примере сайта антиплагиат ру, который на протяжении долгого времени использует шаг шингла 3.

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

Если же каждое третье слово в тексте отличается от исходного текста, то оригинальность текста считается высокой для антиплагиата.

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

МЕТОД ШИНГЛА – КАК ЭТО РАБОТАЕТ?

Более наглядно продемонстрируем метод шингла на рисунке.

Данный текст имеет уникальность 0%. Он полностью скачен с интернета.

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

То есть антиплагаит будет анализировать каждое третье слово в тексте(шаг шингла 3).

Соответственно, если все эти слова оставить на своем месте и ничего в тексте не поменять, то уникальность текста покажет уникальность 0%.

Мы подготовили специальное видео, в котором показываем, как именно пользоваться методом Шаг шингла. Посмотрите на примере, как он эффективно работает.

ШАГ ШИНГЛА В АНТИПЛАГИАТЕ – КАК ИСПОЛЬЗОВАТЬ ДЛЯ ПОВЫШЕНИЯ УНИКАЛЬНОСТИ

Для того чтобы повысить уникальность текста, нужно сбить шаг шингла. Это реальный способ повысить оригинальность текста в антиплагиате.

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

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

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

Если система использует шаг шингла 2 – то, соответственно нужно менять не каждое третье, а каждое второе слово в тексте.

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

Представим результаты исследования в виде таблицы.

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

Источник

Что такое шингл для проверки на антиплагиат

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

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

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

Проверить текст на уникальность

1. Что такое шингл?

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

1.1. Алгоритм шингла, шаг шингла.

Антиплагиат, когда проверяет на сколько уникален текст пользуются определенным алгоритмом, он то и основан на шаге шингла. Разберем на примере, как это будет выглядеть.

Для примера возьмем сайт «antiplagiat.ru», данный сайт, продолжительное время пользуется шагом шингла3. Как это понять? Все очень просто, проверяться будет только каждое третье слово. Исходя из вышесказанного, если там найдется что-то похожее, сайт выдаст нам, что данный материал мы скопировали. А вот если каждое третье слово не относится к исходнику, то «antiplagiat.ru» поставит высокую оригинальность данному материалу.

2. Метод шингла, как это работает?

Подробнее рассмотрим, как будет действовать метод шингла на данной картинке. Материал, показанный на рисунке уникален на 0%. Почему так получилось? Все просто, это скопировано с какого-то известного источника.

Предположим, что антиплагиат проверяет данный материал, на выходе мы получаем такой алгоритм шингла. (красные слова)

Получается, что антиплагиат проверяет каждое третье слово. (шаг шингла 3)

Исходя из вышенаписанного получаем, что, если не менять порядок слов и не заменив какие-то слова синонимами, получим 0% уникальности.

3. Шаг шингла в антиплагиате

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

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

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

Исходя из этого, если на сайте будет использоваться шаг шингла 2, замене будет подлежать каждое второе слово. Шаг шингла 4 – четвертое и т.д.

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

Интересные статьи:

А Вы готовы получить уникальный текст за 30 минут?

Источник

Триллион маленьких шинглов

Если кто-то еще не знает, где на этой картинке шинглы, добро пожаловать…

Шинглы, индекс и зачем их искать

Шингл — это кусочек текста, размером в несколько слов. Шинглы идут внахлёст друг за другом, отсюда и название (англ., shingles — чешуйки, черепички). Конкретный их размер — секрет Полишинеля — 4 слова. Или 5? Well, it depends. Впрочем, даже эта величина мало что даёт и зависит от состава стоп-слов, алгоритма нормализации слов и прочих подробностей, которые в рамках настоящей статьи не существенны. В конце концов, мы вычисляем на основании этого шингла 64-битный хэш, который в дальнейшем и будем называть шинглом.

По тексту документа можно сформировать множество шинглов, число которых сопоставимо с числом слов в документе:

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

Индекс шинглов позволяет выполнять две основные операции:

Индексировать в себе шинглы документов с их идентификаторами:

Искать в себе и выдавать ранжированный список идентификаторов пересекающихся документов:

index.Search(shingles) → (docId, score)[]

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

Индекс шинглов сильно отличается от известных полнотекстовых собратьев, таких как Sphinx, Elastic или более крупных: Google, Yandex и т.д… С одной стороны, он не требует никакого NLP и прочих радостей жизни. Вся текстовая обработка вынесена наружу и не влияет на процесс, как и порядок следования шинглов в тексте. С другой — поисковым запросом является не слово или фраза из нескольких слов, а до нескольких сотен тысяч хэшей, которые имеют значение все в совокупности, а не по отдельности.

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

Для чего нам так заморачиваться? А вот зачем.

И это всё на одной машине! Да, мы умеем реплицировать, постепенно подходим к динамическому шардингу на кластер, но с 2005 года и по сей день индекс на одной машине при бережном уходе способен справляться со всеми вышеперечисленными трудностями.

Странный опыт

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

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

Велосипеды, как известно, никто не любит, а LevelDB ещё не была достоянием общественности, так что в 2010 году взор наш пал на BerkeleyDB. Все круто — персистентная встраиваемая key-value-база с подходящими методами доступа btree и hash и многолетней историей. Всё с ней было замечательно, но:

Время шло. В 2014 году пробовали LMDB и LevelDB, но не внедряли. Ребята из нашего Отдела исследований в Антиплагиате в качестве индекса задействовали для своих нужд RocksDB. На первый взгляд, это была находка. Но медленное пополнение и посредственная скорость поиска даже на небольших объёмах свела всё на нет.

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

Слои индекса

В итоге что мы сейчас имеем? Фактически, индекс шинглов представляет собой несколько слоёв (массивов) с элементами постоянной длины — от 0 до 128 бит, — которая зависит не только от слоя и не обязательно кратна восьми.

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

1. Массив индекса

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

Поменяем элементы пары местами (инвертируем, ведь индекс-то на самом деле «инвертированный»!),

Отсортируем по значениям шинглов и сформируем слой. Т.к. размеры шингла и идентификатора документа постоянны, то теперь любой, кто понимает бинарный поиск, сможет найти пару за O(logn) чтений файла. Что много, чертовски много. Но это лучше, чем просто O(n).

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

2. Массив групп

Аккуратно разобьём элементы индекса из предыдущего шага на группы любым удобным образом. Например, чтобы они влезали в сектор кластер блок allocation unit (читай, 4096 байт) с учётом числа бит и прочих хитростей и сформируем эффективный словарь. У нас получится простой массив позиций таких групп:

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

Словарь позиций групп занимает на несколько порядков меньше места, чем сам индекс, его часто можно просто выгрузить в память. Тем самым чтений будет не два, а одно. Итого, O(1).

3. Фильтр Блума

На собеседованиях кандидаты часто решают задачки, выдавая уникальные решения с O(n^2) или даже O(2^n). Но мы глупостями не занимаемся. Есть ли O(0) на свете, вот в чём вопрос? Давайте попробуем без особой надежды на результат.

Обратимся к предметной области. Если студент молодец и написал работу сам, либо просто там не текст, а белиберда, то значительная часть его шинглов будет уникальна и в индексе встречаться не будет. В мире отлично известна такая структура данных как фильтр Блума. Перед поиском проверим шингл по нему. Если шингла в индексе нет, дальше можно не искать, в ином случае идём дальше.

Сам по себе фильтр Блума достаточно прост, но задействовать вектор хэш-функций при наших объёмах бессмысленно. Достаточно использовать одну: +1 чтение из фильтра Блума. Это даёт -1 или -2 чтений из последующих стадий, в случае если шингл уникальный, и в фильтре не было ложноположительного срабатывания. Следите за руками!

Вероятность ошибки фильтра Блума задаётся при построении, вероятность неизвестного шингла определяется честностью студента. Несложными расчётами можно прийти к следующей зависимости:

С доверием к студентам у нас действует принцип «доверяй, но проверяй», и практика показывает, что профит от фильтра Блума всё-таки есть.

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

4. Тяжёлые хвосты

Есть шинглы, которые встречаются почти везде. Доля их от общего числа мизерная, но, при построении индекса на первом шаге, на втором могут получиться группы размером в десятки и сотни МБ. Запомним их отдельно и будем сразу выбрасывать из поискового запроса.

Когда впервые в 2011 году задействовали этот тривиальный шаг, размер индекса сократился вдвое, ускорен был и сам поиск.

5. Прочие хвосты

Даже несмотря на это, на шингл может приходиться много документов. И это нормально. Десятки, сотни, тысячи… Хранить их внутри основного индекса становится накладно, в группу они тоже могут не влезть, от этого объём словаря позиций групп раздувается. Вынесем их в отдельную последовательность с более эффективным хранением. Как показывает статистика, такое решение более чем оправдано. Тем более что различные побитовые упаковки позволяют и количество обращений к диску снизить, и объём индекса уменьшить.

В итоге для удобства обслуживания запечатаем все эти слои в один большой файл — chunk. Всего слоёв в нём таких десять. Но часть не используется при поиске, часть совсем небольшие и всегда хранятся в памяти, часть активно кэшируются по мере необходимости/возможности.

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

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

Как пришли туда, не знали куда

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

Изначально индекс у нас состоял из двух частей — постоянной, описанной выше, и временной, в роли которой выступал либо SQL, либо BDB, либо свой журнал обновлений. Эпизодически, например, раз в месяц (а иногда и год), временный сортировался, фильтровался и сливался с основным. В результате получался объединённый, а два старых удалялись. Если временный не мог влезть в оперативную память, то процедура шла через внешнюю сортировку.

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

Это были времена первых и довольно дорогих SSD. До сих пор в дрожь берёт от воспоминаний, как 31 декабря отвалился единственный SSD на продакшене и судорожно пришлось в новогоднюю ночь писать wcf-балансировщик и распределять нагрузку на наши девелоперские машины. Пот схлынул, но балансировщик тот до сих пор жив и отлично работает. Впрочем, мы отвлеклись.

Чтобы и SSD не особо напрягался, и индекс актуализировался почаще, в 2012 году задействовали цепочку из нескольких кусков, chunk’ов по следующей схеме:

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

У алгоритма LSM в нашем случае есть очень подходящие черты:

Вообще, велосипеды иногда и для саморазвития изобретать полезно.

Макро-, микро-, нано-оптимизации

Заметим заранее, что часто всё очень сильно зависит от вашего конкретного железа, данных или режима использования. Подкрутив в одном месте, мы вылетаем из кэша CPU, в другом — упрёмся в пропускную способность SATA-интерфейса, в третьем — начнём зависать в GC. А где-то и вовсе в неэффективность реализации конкретного системного вызова.

Работа с файлом

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

Начнём с простого. Чтобы прочитать заветный, байт нужно:

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

Single open, multiple read

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

Очевидно, следует один раз открыть файл и последовательно вычитывать с него все миллионы наших значений, что мы и делаем

Получение размера файла, текущей позиции в нём — также достаточно тяжёлые операции. Даже если файл не менялся.

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

Далее. Увы, FileStream по сути однопоточен. Если вы хотите читать файл параллельно, придётся создавать/закрывать новые файловые потоки.

Пока не создадут что-то типа aiosync, придётся изобретать собственные велосипеды.

Мой совет – создайте пул файловых потоков на файл. Это позволит избежать траты времени на открытие/закрытие файла. А если его объединить с ThreadPool и учесть, что SSD выдаёт свои мегаIOPS’ы при сильной многопоточности… Ну вы меня поняли.

Далее. Устройства хранения данных (HDD, SSD, Optane) и файловая система оперируют файлами на уровне блоков (cluster, sector, allocation unit). Они могут не совпадать, но сейчас это почти всегда 4096 байт. Чтение одного-двух байтов на границе двух таких блоков в SSD происходит примерно в полтора раза медленнее, чем внутри самого блока.

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

Далее. FileStream по умолчанию использует буфер размером в 4096 байт. И есть плохая новость — его нельзя выключить. Тем не менее, если вы читаете данных больше, чем размер буфера, то последний будет в игноре.

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

Кроме случайных чтений, есть ещё и последовательные. Здесь буфер уже может стать полезным, если вы не хотите вычитывать всё разом. Советую для начала обратиться к этой статье. Какой размер буфера выставить, зависит от того, находится ли файл на HDD или на SSD. В первом случае оптимальным будет 1MB, во втором будет достаточно стандартных 4kB. Если размер вычитываемой области данных сравним с этими значениями, то лучше её вычитать разом, пропустив буфер, как и в случае случайного чтения. Буферы больших размеров не будут приносить профита по скорости, но начнут бить по GC.

При последовательном чтении больших кусков файла следует выставить буфер в 1MB для HDD и 4kB для SSD. Well, it depends.

MMF vs FileStream

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

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

Bits/Bytes

Не байтами мир един. Иногда нужно снизойти до уровня бита.

Для примера: представим, что у вас триллион частично упорядоченных чисел, жаждущих сохранения и частого чтения. Как со всем этим работать?

Идеального решения нет, но в конкретном случае простое сжатие диапазона с 32-х бит до необходимого хранить хвосты сэкономило на 12% больше (десятки ГБ!), чем VarInt (с сохранением только разницы соседних, само собой), а тот — в разы от базового варианта.

Другой пример. У вас в файле есть ссылка на некоторый массив чисел. Ссылка 64-битная, файл на терабайт. Всё вроде ок. Иногда чисел в массиве много, иногда мало. Часто мало. Очень часто. Тогда просто берём и храним весь массив в самой ссылке. Profit. Упаковать аккуратно только не забудьте.

Struct, unsafe, batching, micro-opts

Ну и прочие микрооптимизации. Я здесь не буду писать про банальные «стоит ли сохранять Length массива в цикле» или «что быстрее, for или foreach».

Есть два простых правила, и мы им будем придерживаться: 1. «бенчмаркай всё», 2. «больше бенчмаркай».

Struct. Используются повсеместно. Не грузят GC. И, как это модно нынче бывает, у нас тоже есть свой мегабыстрый ValueList.

Unsafe. Позволяет мапить (и размапить) структуры в массив байт при использовании. Тем самым нам не нужны отдельные средства сериализации. Есть, правда, вопросы к пинингу и дефрагментации кучи, но пока не проявлялось. Well, it depends.

Batching. Работать с множеством элементов следует через пачки/группы/блоки. Читать/писать файл, передавать между функциями. Отдельный вопрос — размер этих пачек. Обычно есть оптимум, и его размер часто находится в диапазоне от 1kB до 8MB (размер кэша CPU, размер кластера, размер страницы, размер чего-то ещё). Попробуйте прокачать через функцию IEnumerable или IEnumerable и прочувствуйте разницу.

Pooling. Каждый раз, когда вы пишите «new», где-то умирает котёнок. Разок new byte[85000] — и трактор проехался по тонне гусей. Если нет возможности задействовать stackalloc, то создайте пул каких-либо объектов и переиспользуйте его заново.

Inlining. Как созданием двух функций вместо одной можно ускорить всё в десять раз? Просто. Чем меньше размер тела функции (метода), тем больше шансов, что он будет заинлайнен. К сожалению, в мире dotnet пока нет возможности делать частичный инлайнинг, так что если у вас есть горячая функция, которая в 99% случаях выходит после обработки первых нескольких строк, а остальная сотня строк идёт на обработку оставшегося 1%, то смело разбивайте её на две (или три), вынося тяжёлый хвост в отдельную функцию.

What else?

Async/await — пока неоднозначно. Простейшие бенчмарки случайного чтения показали, что действительно потребление CPU падает, но вот скорость чтения также снижается. Надо смотреть. Внутри индекса пока не используем.

Заключение

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

Источник