Там помимо фамилии есть имя и отчество. А в реальном продукте ещё и куча других параметров. Но если предложите методику испытаний для оценки качества поиска, я прогоню. И, кстати, буду благодарен за такой алгоритм.
Рассматривался, пока не увидел алгоритм русского Метафона. Я его посмотрел и он показался мне вполне логичным в плане нивелирования ошибок, плюс его тестировали в бою. А транслитерация и последующая обработка фонетическими алгоритмами показалась мне чересчур сложной и потенциально дающей больше ошибок. Но я не тестировал.
Чтобы просто разрезать на лексемы без модификаций — это более простой аналог регуляризация по пробелам. А russian может для ряда фамилий убрать окончания или увидеть в них стоп-слова
Автор не потерял в качестве, информация из первых рук. Во всех выборках возвращалось менее 10 результатов при лимите в 10.
Кстати, то количество строк для разных выборок, которе вы написали, не имеет отношения к результатам. Это количество строчек в выводе плана explain (analyze, buffers) — можете сами посчитать))
Отлично, время создания индекса уменьшилось на 40%, размер почти такой же (разница в 1 Мб — думаю, тут случайный фактор как расщеплялись странички при создании индекса), скорость поиска аналогичная.
Я вначале тоже думал транслитерировать имена в индекс и дальше использовать того же Дейча-Мокотоффа или двойной Метафон. Но нашёл на хабре ту забавную реализацию русского Метафона и был приятно удивлён ее селективностью. Так что дополнительный оверхед не городил. А вот у вас интересный опыт был, может расскажете в статье и с подробностями?)
Я смотрел алгоритм Дейча-Мокотоффа, но нашёл его реализацию только для английского алфавита. У вас были иностранные имена в латинице? Или вы русские имена транслитерируете?
Да, но в данном случае это было как из пушки по воробьям. Во-первых, лишняя сложность решения. Во-вторых, для транзакционных реализаций внешней индексации из PostgreSQL в ElasticSearch я нашёл только Zombodb. Но он умеет только pg 9.3,9.4,9.5 и es 1.7.1… остальные варианты сопряжения были сложнее и не оправданы на текущем объеме данных
Согласен, качество выдачи надо было добавить. Но на всех запросах, кроме варианта с триграммы + полнотекстовый поиск по «смернов дин онатол» успешно находился «Смирнов Денис Анатольевич». В озвученном варианте (триграмм и полнотекст) по лексеме «дин» нашлась «дина», но не «денис». Во всех остальных случая селективность просто потрясающая и вызывает желание перекреститься)
Это действительно упрощенная модель в статье. В реальности есть и дата рождения, и енп, снилс, паспорта, документы. Есть история изменений и архивный поиск по девичьей фамилии. Это я не тащил в статью, чтобы не загромождать запросы — история была именно про опечатки
А вот за абзац про экранирование строки через $$ вам от меня благодарность! Я писал функции и не понимал, что просто описываю тело функции в виде обычного текстового поля в ddl команде create function .... as $$ ... $$. По факту я могу смело писать
Кстати, PostgresPro вроде имеет свой сертифицированный форк. А расскажите про Линтер, что за зверь такой? А то в интернетах про него внятных технических подробностей не нашёл при поверхностном поиске. И раз вы сказали, что сильная сторона pg — это mvcc, то что тогда у Линтера? Блокировщик?
Ну понятно, что нормального мультимастера пока нет и раньше 12-13 версии pg его ждать глупо. По поводу костыльной реализации мультимастера на базе логической репликации здесь и сейчас… можете попробовать на двух серверах создать родительскую таблицу с двумя партициями. Ключом партицирования будет id сервера. На первом сервере при вставке в родительскую таблицу данные попадут в первую партицию, на втором сервере — во вторую. Первая партиция на втором сервере будет подписана на первую партицию на первом сервере. Вторая партиция на первом сервере будет подписана на вторую на втором. По факту такая конструкция может пережить сплит брейн за счёт того, что данные вносятся на каждом сервере в свою партицию и уникальность им обеспечит id сервера (поэтому конфликтов не возникает). Ну и делать такие вещи есть смысл не через нативное партицирование десятки, а через pathman. Но это так, теория, подобные костыли я не проверял.
А реализация S3-совместимого хранилища в облаке КРОК поддерживает S3 Select? И, если не секрет, какое вы используете решение для хранения в S3?
Замечу, что всех описанных в статье страданий можно было избежать, просто посмотрев битую страницу через расширение pageinspect (https://www.postgresql.org/docs/current/pageinspect.html)
Рассматривался, пока не увидел алгоритм русского Метафона. Я его посмотрел и он показался мне вполне логичным в плане нивелирования ошибок, плюс его тестировали в бою. А транслитерация и последующая обработка фонетическими алгоритмами показалась мне чересчур сложной и потенциально дающей больше ошибок. Но я не тестировал.
Чтобы просто разрезать на лексемы без модификаций — это более простой аналог регуляризация по пробелам. А russian может для ряда фамилий убрать окончания или увидеть в них стоп-слова
Автор не потерял в качестве, информация из первых рук. Во всех выборках возвращалось менее 10 результатов при лимите в 10.
Кстати, то количество строк для разных выборок, которе вы написали, не имеет отношения к результатам. Это количество строчек в выводе плана explain (analyze, buffers) — можете сами посчитать))
Это действительно упрощенная модель в статье. В реальности есть и дата рождения, и енп, снилс, паспорта, документы. Есть история изменений и архивный поиск по девичьей фамилии. Это я не тащил в статью, чтобы не загромождать запросы — история была именно про опечатки
А вот за абзац про экранирование строки через $$ вам от меня благодарность! Я писал функции и не понимал, что просто описываю тело функции в виде обычного текстового поля в ddl команде
create function .... as $$ ... $$. По факту я могу смело писатьвместо идущего в примерах
ведь это одно и то же.
Ну понятно, что нормального мультимастера пока нет и раньше 12-13 версии pg его ждать глупо. По поводу костыльной реализации мультимастера на базе логической репликации здесь и сейчас… можете попробовать на двух серверах создать родительскую таблицу с двумя партициями. Ключом партицирования будет id сервера. На первом сервере при вставке в родительскую таблицу данные попадут в первую партицию, на втором сервере — во вторую. Первая партиция на втором сервере будет подписана на первую партицию на первом сервере. Вторая партиция на первом сервере будет подписана на вторую на втором. По факту такая конструкция может пережить сплит брейн за счёт того, что данные вносятся на каждом сервере в свою партицию и уникальность им обеспечит id сервера (поэтому конфликтов не возникает). Ну и делать такие вещи есть смысл не через нативное партицирование десятки, а через pathman. Но это так, теория, подобные костыли я не проверял.