Мы уже рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа и все основные методы доступа, как то: хеш-индексы, B-деревья, GiST, SP-GiST и GIN. А в этой части посмотрим на превращение джина в ром.

RUM

Хоть авторы и утверждают, что джин — могущественный дух, но тема напитков все-таки победила: GIN следующего поколения назвали RUM.

Этот метод доступа развивает идею, заложенную в GIN, и позволяет выполнять полнотекстовый поиск еще быстрее. Это единственный метод в этой серии статей, который не входит в стандартную поставку PostgreSQL и является сторонним расширением. Есть несколько вариантов его установки:

• Взять пакет yum или apt из репозитория PGDG. Например, если вы ставили PostgreSQL из пакета postgresql-10, то поставьте еще postgresql-10-rum.
• Самостоятельно собрать и установить из исходных кодов на github (инструкция там же).
• Пользоваться в составе Postgres Pro Enterprise (или хотя бы читать оттуда документацию).

Ограничения GIN

Какие ограничения индекса GIN позволяет преодолеть RUM?

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

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

Метод доступа RUM в первом приближении можно рассматривать как GIN, в который добавлена позиционная информация, и который поддерживает выдачу результата в нужном порядке (аналогично тому, как GiST умеет выдавать ближайших соседей). Пойдем по порядку.

Друзья! Мы решили запустить дайджест свежих новостей, статей, релизов и событий из мира PostgreSQL, который будет выходить раз в две недели. В подборке вы найдете ссылки на наиболее интересные материалы по PostgreSQL, вышедшие за период. Если мы пропустили что-то важное для вас – пишите в комментариях!

Релизы

• Вышел Postgres Pro Standard 10.1.1. В эту версию перенесены все ключевые доработки и новые возможности СУБД Postgres Pro Standard 9.6, исправлены некоторые найденные ошибки. Также вышла сборка PostgreSQL 10.1 под Windows
• Вышла версия PgBouncer 1.8.1. Исправлена ошибка в 1.8: добавлен недостающий файл, теперь PgBouncer без проблем собирается из тарбола.
• Появилась версия драйвера psqlODBC 10.01.0000. Некоторые поправки и усовершенствования по сравнению с версией 10.00.0000. Например, ликвидированы утечки памяти.

Статьи

• В статье Jsonb: few more stories about the performance
  Дмитрий Долгов (Zalando) обнародовал производительность PostgreSQL, MySQL и MongoDB на тестах YCSB. Сравнивалась производительность обработки бинарных JSON-ов (JSONB и BSON). Методика тестирования (в облаке) расписана подробно, есть выводы и рекомендации.
  До этого тема обсуждалась на PGConf.EU 2017 в Варшаве и на других конференциях. Например, в презентации Олега Бартунова по результатам YCSB-тестирования в Postgres Professional (слайд 81 и далее). В этих тестах на выделенных мощных серверах сравнивались только MongoDB и PostgreSQL, а акцент был сделан на высокую нагрузку (тысячи клиентов одновременно).

Добраться до самых верхних обитаемых этажей Лахта Центра – дело секундное. На лифте-шаттле путь до обзорной площадки займет 45 секунд. 45 секунд – и вы уже над городом, над облаками, над петербургским дождем и туманом. Можно ли жалеть, что поездка окончилась так быстро? Да, ведь и лифт повезет такой, что покидать его не захочется. Другие лифты, составляющие систему вертикального транспорта Лахта Центра, тоже тоже отличаются от собратьев – строением, грузоподъемностью, функционалом. Посмотрим на них поближе.


Не очевидный побочный функционал лифтов Лахта Центра — поездки за солнечной погодой. Фото Михаила Проскалова

С 1 января ФНС перестанет обновлять адресный справочник КЛАДР. Он официально устареет, останется один ФИАС. Но многие промышленные системы до сих пор работают с КЛАДР. Поставщики не собираются их обновлять, а переделывать своими руками бизнесу выходит долго и дорого.

Мы послушали клиентов и придумали решение: взять ФИАС, который живее всех живых, и написать перекодировщик в КЛАДР.

Со стороны задача кажется легкой. Нам так и говорили: «То есть вы просто берете ФИАС и переделываете в КЛАДР?». На деле никакого «просто» нет. У справочников совсем разные структуры и непонятно, как из подкачанного ФИАС раскидать данные в неказистый КЛАДР. При этом общей документации для справочников нет.

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

Наконец-то я доделал игру, которая работает на видеокарте. Она несколько месяцев повисела в раннем доступе на стиме, и теперь я её окончательно выпустил. Основная фишка игры в том, что она представляет собой физическую симуляцию, которая выполняется на графическом процессоре. Основной код игры — это огромный compute shader, 6 тысяч строк на HLSL. Десятки тысяч взаимодействующих частиц обрабатываются параллельно, и выходит довольно быстро. Всё в игре сделано из этих частиц. Вот несколько гифок о том, как это работает:

В прошлые разы мы рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа, и два метода: хеш-индекс и B-дерево. В этой части займемся индексами GiST.

GiST

GiST — сокращение от «generalized search tree». Это сбалансированное дерево поиска, точно так же, как и рассмотренный ранее b-tree.

В чем же разница? Индекс b-tree жестко привязан к семантике сравнения: поддержка операторов «больше», «меньше», «равно» — это все, на что он способен (зато способен очень хорошо!). Но в современных базах хранятся и такие типы данных, для которых эти операторы просто не имеют смысла: геоданные, текстовые документы, картинки…

Тут на помощь и приходит индексный метод GiST. Он позволяет задать принцип распределения данных произвольного типа по сбалансированному дереву, и метод использования этого представления для доступа по некоторому оператору. Например, в GiST-индекс можно «уложить» R-дерево для пространственных данных с поддержкой операторов взаимного расположения (находится слева, справа; содержит и т. п.), или RD-дерево для множеств с поддержкой операторов пересечения или вхождения.

За счет расширяемости в PostgreSQL вполне можно создать совершенно новый метод доступа с нуля: для этого надо реализовать интерфейс с механизмом индексирования. Но это требует продумывания не только логики индексации, но и страничной структуры, эффективной реализации блокировок, поддержки журнала упреждающей записи — что подразумевает очень высокую квалификацию разработчика и большую трудоемкость. GiST упрощает задачу, беря на себя низкоуровневые проблемы и предоставляя свой собственный интерфейс: несколько функций, относящихся не к технической сфере, а к прикладной области. В этом смысле можно говорить о том, что GiST является каркасом для построения новых методов доступа.

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

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

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

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

Зачем этот рассказ? Когда я изучал blockchain по открытым источникам, например по Википедии, информация казалась отрывочной и бессвязной. Прошло время, прежде чем она сложилась в целостную картину. Кажется, я знаю, в каком порядке и какими словами описать введение в blockchain, чтобы любой профессиональный разработчик смог понять общую картину за 1—1,5 часа. В тексте будут некоторые упрощения. Понятно, что в любой теме есть много деталей, куда можно при желании погрузиться.

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

Часто довольно трудно найти в базе нетипичную фамилию, например:

— Леха, поищи в нашей базе Адольфа Швардсенеггера,
— Шворцинегира? Нет такого!

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

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

В этой статье я рассмотрю наиболее известные алгоритмы, такие как Soundex, Daitch-Mokotoff Soundex, NYSIIS, Metaphone, Double Metaphone, русский Metaphone, Caverphone.

Сентября 17го года купил в личное пользование сервер стоимостью 7680$ у поставщика Тиском.
Поставил в Московский ЦОД tech.ru и приступил к эксплуатации.

Фото-отчёт в наличии. Статья состоит из 5 частей:

1. Зачем мне сервер.
2. Выбор конфигурации.
3. Выбор у кого покупать.
4. Выбор у кого размещать.
5. Проблемы с настройкой данного сервера.

Тема полезных приёмов работы в терминале Linux неисчерпаема. Казалось бы — всё устроено очень просто: приглашение оболочки, да введённые с клавиатуры команды. Однако, в этой простоте кроется бездна неочевидных, но полезных возможностей. Именно поэтому мы регулярно публикуем материалы, посвящённые особенностям работы в командной строке Linux. В частности, сегодня это будет перевод статьи, автор которой увлечён экономией времени через повышение продуктивности труда.



Если вас интересует работа в командной строке Linux — вот некоторые из наших материалов на эту тему:

• [ +114 ] Самые полезные приёмы работы в командной строке Linux
  
• [ +70 ] 10 приёмов работы в терминале Linux, о которых мало кто знает
  
• [+65 ] Удивительно полезный инструмент: lsof
  
• [ +32 ] Linux: перенаправление
  
• [ +29 ] PDF-версия статей про Bash-скрипты
  

Регистрация на конференцию PG Day’16 в разгаре, а мы продолжаем публиковать перевод статей Hubert Lubaczewski об explain и его основных компонентах.

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

Введение

Алгоритмы нечеткого поиска (также известного как поиск по сходству или fuzzy string search) являются основой систем проверки орфографии и полноценных поисковых систем вроде Google или Yandex. Например, такие алгоритмы используются для функций наподобие «Возможно вы имели в виду …» в тех же поисковых системах.

В этой обзорной статье я рассмотрю следующие понятия, методы и алгоритмы:

• Расстояние Левенштейна
• Расстояние Дамерау-Левенштейна
• Алгоритм Bitap с модификациями от Wu и Manber
• Алгоритм расширения выборки
• Метод N-грамм
• Хеширование по сигнатуре
• BK-деревья

А также проведу сравнительное тестирование качества и производительности алгоритмов.

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

Анализ статистики GitHub показывает, что по показателям активных репозиториев и push-запросов, JavaScript находится на первом месте, да и в других категориях он показывает довольно высокие позиции.


Статистические сведения по JavaScript с GitHub

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

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

Как ни странно, существует множество разработчиков, которые регулярно пишут на JavaScript, но не знают, что происходит в его недрах. Пришло время это исправить: этот материал посвящён обзору JS-движка на примере V8, механизмов времени выполнения, и стека вызовов.

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

К сожалению, в ходе эксплуатации выяснилось, что pcre все равно являются узким местом, и на больших письмах этот набор правил работает слишком медленно. Выяснилось, например, что на письме размером в мегабайт pcre проверяет около гигабайта (!) текста. Различные трюки, вроде ограничения количества текста для регулярных выражений, оказывали негативное влияние на срабатывания правил, а оптимизации pcre путем интенсивного использования jit fast path через pcre_jit_exec оказались слишком опасными — некоторые старые выражения были откровенно некорректными и в сочетании с некорректным входным текстом, например, содержащим «битые» UTF8 символы, приводили к воспроизводимым багам с повреждением стека программы. Однако на конференции highload мы поговорили со Вячеславом Ольховченковым, и он мне посоветовал посмотреть на hyperscan. Далее я перейду к сути и расскажу, что из этого получилось.

С 1 июля 2017 года в соответствии с законом 54-ФЗ все онлайн-расчеты с помощью банковских карт должны проходить через кассу, выдающую электронные чеки. А значит, на онлайн-торговлю ложатся все тяготы, свойственные офлайн-ритейлу – регистрация касс, техобслуживание, замена фискальных накопителей, хранение старых ФН.  Упрощенный вариант — не приобретать все оборудование, а воспользоваться сервисом по аренде ККТ и ПО. Мы хотим рассказать о том, как мы придумывали и реализовывали наш сервис АТОЛ Онлайн, зачем нам понадобилось ломать и вновь строить бизнес-процессы, а также о самой проектной команде и принципе работы сервиса. За подробностями — под кат.

Прим. перев.: Неделю назад Aymen El Amri, руководящий компанией eralabs и создавший обучающий курс «Безболезненный Docker», опубликовал свой Docker Cheat Sheet — шпаргалку по основным командам Docker. Git-репозиторий этого документа на GitHub уже набрал 1000+ stars и несколько сторонних контрибьюторов, что подтвердило его актуальность и пользу.



Представленные здесь команды описаны минимально (с акцентом на читаемость как есть) и включают в себя установку Docker, работу с реестрами и репозиториями, контейнерами, образами, сетью, Docker Swarm. Ниже представлен перевод шпаргалки в её состоянии на 2 сентября с дополнениями из комментариев ниже.

Помните гель, которым вам мажут живот во время УЗИ? Это довольно интересная полимерная конструкция, которая продумана так, чтобы обеспечивать звукопроводящую среду и при этом минимум побочных шумов для аппарата. Аналогично — гель для ЭКГ, только там среда электропроводная. Технически эти гели не очень сильно отличаются от ряда гелей для аппаратной косметологии и для других узкоспецифических медицинских задач. Например, есть гели, которые сделаны так, чтобы максимально проникать через кожу (эпидермальный слой), они служат транспортом для медикаментов во время, например, процедур ультразвуковой обработки горла у отоларинголога.

Мы делаем такие специфические вещи в России уже примерно 20 лет. Сейчас я покажу старое мелкосерийное производство и расскажу про ряд его особенностей. Ещё у нас есть тоннажное производство для медицины, куда современнее по оборудованию, но там как раз заказы более стабильные и не требуют перестройки линий каждый день. А вот когда нужно 50 флаконов определённого геля на год для решения одной редкой медицинской задачи — это к нам. Давайте начнём.