6921
правка
Изменения
м
→Андрей Абрамов. ArangoDB: Transactional information retrieval
{{Conf-Ref}}
Собрал вместе свои заметки с [https://www.highload.ru/spb/2019 '''#SaintHighLoad2019 '''] 8-9 апреля в Петербурге. Если говорить о конференции в целом, то я на ней знакомился с современными технологиями, слушал доклады о нейронных сетях, современном мониторигемониторинге, ArangoDB и многом другом. Интересно, что на осенней #HighLoad2018 в Москве у меня такого не получилось, хотя технологические докладов там было большинствои часть из них я тоже слышал, это видно из моего '''отчета [[Highload-2018]]'''. Я там Но больше я слушал про про развитие менеджмента, управление счастьем и общую догику логику развития цифрового мира, включая управление задачами почти для миллиона участников Яндекс-толока, о чем можно прочесть в моем отчете [[Highload-2018]]и это дало другие впечатления. А в Питере случилось именно погружение в современные технологии. Так что, несмотря на название, это не клон Highload в Москве, а конференция со своим лицом.
Но начну я рассказ с двух постов, которые не про доклады, а про результат устных коммуникаций на конференции. Первый касается развилок в развитии технологий, а второй - про специализацию Site Reliable Engineer. А потом - перейду к докладам.
И это происходит не из абстрактной любви к совершенству, а следует за логикой работы приложений, в которых все это нужно вместе и потому сейчас организуется через развертывание нескольких кластеров с общими или дублирующимися данными (мы можем дублировать тексты в поисковом движке, а можем только индексировать, сохраняя ключи) и потоками синхронизации между ними, и порождая сложные системы. Технический результат понятен - один кластер, один DBA и сквозные запросы и приложения, особенно важно в распределенных данных. Но результат - не только технический, реально возникает синергетический эффект от объединения в одном движке. Как пример - если у вас слабоструктурированные данные в json, то через текстовый поиск ты все равно можешь эффективно искать, а разделение хранения при индексации потребует накладывать ограничения на структуру.
Дальше были технические особенности реализации поиска в ArangoDB, в частности разные варианты скоринга записей с кастомизацией алгоритма. И кейсы реальных внедрений. Первый - на больших медицинских данных. Раньше был Elastic + Kassandra, для конечных запросов все было неплохо, но еще был доступ по API, где надо было выдавать по 50k-100k записей, и вот это Elastic не тянул. Arango - потянул. Второй кейс - графовая задача. Тут сложность, что если за счет кластеризации граф получается распределенным по нодам, то поиск убивает производительность. Arango позволяет организовать smart-хранение, чтобы логические кластеры графа располагались на доном одном сервере. Если такие атрибуты связности есть, то можно их указать, если нет - в Arango есть встроенные средства анализа. Bio-IT World. Кейс на 4 базах данных: фенотип (состояние алгоритма), геном (наборы мутаций в генах, json), лекарства, ассоциации между ними - в виде статей, где эти базы данных упомянуты. Задача: учесть влияние генома на индивидуальные реакции на лекарства. Надо по первым трем данным найти релевантные статьи. Сложность, что когда выбираешь по заболеванию надо учитывать смежные, общие и частные.
= Евгений Потапов. Мониторинг сложных систем в 2019 году=