search

Limych / GeniBase

2 stars 2 forks source link

Добавить небольшой набор данных для разворачивания тестовой системы #89

Closed VorontsovIE closed 7 years ago

VorontsovIE commented 7 years ago

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

Limych commented 7 years ago

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

VorontsovIE commented 7 years ago

И код новой версии закрыт, да? :)

Limych commented 7 years ago

Да нет, не закрыт, почему же?.. Просто, когда пишешь всё фактически в одиночку, намного проще хранить всё у себя под боком, чем где-то в сети... :) Хорошо, я выложу его в ближайшее время. Надо только чуть почистить...

VorontsovIE commented 7 years ago

Это было бы здорово, спасибо!

Limych commented 7 years ago

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

VorontsovIE commented 7 years ago

Хорошо, честно выкладываю карты на стол. :) У меня нет специального интереса именно к генеалогии, но есть желание поработать с историческими данными с точки зрения статистики (у меня профессия связана с обработкой и анализом данных, правда, биологических). Сейчас появляется множество источников открытых данных по разным историческим периодам: по второй мировой, по жертвам сталинских репрессий, по первой мировой - и есть желание эти данные а)добыть, б)обработать и дополнить для большего удобства исследовательской работы, в)провести несколько собственных исследований. Интерес к конкретно генеалогическим данным у меня появился с месяц назад на хакатоне Мемориала по жертвам политических репрессий. Я придумал и реализовал в простейшей форме (насколько позволяло время) проект по угадыванию семейных связей в списках репрессированных по ФИО и географическим данным. Этакая попытка сделать "социальную сеть" людей, живших когда-то давно. Сейчас потихоньку двигаюсь в том же направлении в проекте по жертвам второй мировой (который ОБД Мемориал).

Масштабные цели следующие:

VorontsovIE commented 7 years ago

Теперь немного про код и мысли по улучшению проекта.

Буквально вчера наткнулся на ваш проект и стал изучать, как получить данные для работы. Обнаружил несколько затруднений. Я сел читать код и обнаружил, как мне кажется, несколько проблем. Но я, конечно, мог ошибиться: изучал только код, без данных - и мог недоглядеть каких-то деталей. У меня нет представления, насколько описанные пункты реализуются в новой версии, поэтому считайте, что просто делюсь наблюдениями и соображениями про код старой версии.

Во-первых, с моей точки зрения, весьма важно было бы завести карточки людей. Без этого на результат поиска невозможно сослаться (и невозможно сохранить), т.е. исследователь не сможет вас даже процитировать. Для построения семантической сети это тоже нужно всенепременно. Сейчас нет никакого надежного способа сослаться на запись, потому что нумерация в поисковом легко может поменяться при обновлении базы; да и без обновления, кажется, тоже вычисляется местами недетерминировано, т.к. вычисляемое поле, по которому производится сортировка, может совпадать для нескольких записей. А сортировка в mysql, насколько я понимаю, не является стабильной (https://stackoverflow.com/a/16202126). Из-за этого, кстати, при передвижении по страницам часть записей может потеряться

Во-вторых, проект работает довольно нешустро. От 4 секунд на запрос до где-то 30-35. Думается, что есть несколько простых действий, которые могли бы ускорить работу сайта. Одна причина тормозов по моему мнению - таблица поискового индекса, которая ищет по фамилиям, но почему-то держит ещё и person_id. Если я правильно понял, из-за этого все варианты нормализации фамилии в индексе будут продублированы много раз подряд (для каждого однофамильца). Это раздует индекс до многих миллионов записей и сделает в нём поиск неэффективным. Тем более, что он производится по нечётким шаблонам. Думаю, более эффективным решением было бы удалить индексировать не людей, а фамилии: завести отдельную таблицу для фамилий + индекс поиска по этой таблице. А в таблице людей использовать вместо фамилий id-шники. Поиск производится сначала по индексу фамилий (долгий шаг), достаёт неколько референсных фамилий, а потом по небольшому числу id-шников этих референсных фамилий ищет людей (быстрый шаг).

Дальше, определенно, не хватает галочки "искать точное совпадение". Для многих фамилий (особенно частотных) это будет работать хорошо, ведь мала вероятность ошибиться в фамилии "Иванов". А скорость запроса увеличится, думаю, в сотни раз. Учитывая, что запрос выполняется не единожды, а при каждом перелистывании страницы, это имеет смысл.

Крошечное, но улучшение может касаться того места, где вы делаете пагинацию. Вы сначала загружаете все индексы из базы, а потом вырезаете кусок. Можно вместо этого прямо в запросе написать что-то типа LIMIT 20 OFFSET 1040.

Определенно, хорошо было бы иметь способ не перезапрашивать данные между запросами. Один вариант - это кэш, как описано в тудушке. Другой вариант - делать пагинацию на клиенте. Тогда данные можно запрашивать сразу для 10-50 страниц, например, ajax-запросом; там не настолько большой объём данных по каждому человеку, чтобы это грузило сеть; бутылочным горлышком всё равно является БД с большим перевесом). Третий вариант - избавиться от сортировки фамилий по степени сходства и сортировать их каким-то простым и быстрым способом (типа exact match вверху, звёздочка внизу остальное - где-то в середине, неважно в каком порядке). Возможно, быстрее будет это сделать даже не на уровне БД, а в коде движка. Три нечётких сравнения на запись, как сейчас, может влёгкую убить быстродействие.

В-третьих, конечно, идеально было бы иметь на сайте раздел downloads, куда повесить дамп таблички с людьми хоть в каком-то виде: одна мега-таблица со всей инфой или несколько маленьких нормализованных табличек. Зазипованные или нет. Вообще неважно: любые данные лучше, чем их отсутствие. :) Это реально помогло бы людям в digital humanities (включая меня :)). Не всем нужен поисковые движок, кому-то вполне достаточно просто данных в обычном csv-файле. Ещё одна причина беспокоиться о наличии дампа заключается в том, что сайты имеют свойство исчезать бесследно со всеми данными и тысячами часов вложенного в них труда. Например, сайт ЭЛАРа по данным Первой Мировой появился в сети, затем исчез. И как теперь людям пользоваться сканами документов, которых просто нигде больше нет? Говорят, что сайт был в тестовой версии и ещё воскреснет, но кто их знает... Дамп же не исчезнет никогда, копии разойдутся по десяткам исследователей и сотням любопытствующих и сохранят данные от потери надёжнее любого архива.

Limych commented 7 years ago

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

Обновил репозиторий: https://github.com/Limych/GeniBase/tree/3.0.x-dev

VorontsovIE commented 7 years ago

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

Limych commented 7 years ago

Сгенерировал (пока на коленке) документацию по коду: http://limych.github.io/GeniBase/

Limych commented 7 years ago

@VorontsovIE Я добавил в описание проекта инструкции по инсталляции. Также в корень поднимаемого сайта добавил ссылки на уже имеющиеся его части.

Limych commented 7 years ago

Добавлены тестовые данные :)

VorontsovIE commented 7 years ago

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

Limych commented 7 years ago

Супер! Сейчас тестирую корректность заливки данных в базу:

<gb:statistic xmlns:gb="http://genibase/v1/"> <agents>2</agents> <conclusions modified="2017-07-24T23:20:57+03:00">97046</conclusions> <facts modified="2017-07-24T23:20:57+03:00">14492</facts> <persons modified="2017-07-24T23:20:57+03:00">14500</persons> <sources modified="2017-07-24T23:20:56+03:00">14993</sources> <places modified="2017-07-24T23:20:56+03:00">10070</places> <events modified="2017-07-24T23:20:57+03:00">14500</events> </gb:statistic>

Судя по числу мест, которые уже образовались в базе, поле для деятельности будет условно безбрежным ;) А ведь загружено всего ничего — чуть больше 1% базы по ПМВ.

Limych commented 7 years ago

По нечёткому поиску замечу, что каждая запись о месте МОЖЕТ иметь

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

Limych commented 7 years ago

Результат мне уже начинает нравиться ;) place

Limych commented 7 years ago

Случайно наткнулся на статью о нечётком поиске географических мест. Сложу тут, чтобы не потерялась: https://www.cs.cf.ac.uk/Spirit.Info/publications/geoontology_DBA.pdf