Подготовлен первый экспериментальный выпуск СУБД EuclidesDB (https://github.com/perone/euclidesdb/), предоставляющей средства для использования моделей машинного обучения при индексировании и выборки данных. СУБД позволяет привязывать к различным классам информации отдельные модели машинного обучения, например, можно подключить модель для классификации изображений и применять СУБД для поиска похожих фотографий или выборки изображений, на которых присутствует определённый объект. Проект написан на языке С++ и распространяется под лицензией Apache 2.0. Модели машинного обучения обрабатываются при помощи библиотеки PyTorch (https://pytorch.org/) (используется C++-интерфейс libtorch (https://pytorch.org/cppdocs/)).СУБД EuclidesDB предоставляет универсальное решение для создания систем обработки данных с использованием моделей машинного обучения, образующее готовый каркас для подключения необходимых моделей и их применения для поиска похожих данных. Для каждой категории данных могут подключаться отдельные модели, например, для поиска туфель может использоваться одна модель, натренированная на изображениях обуви, а для поиска футболок - другая. На практике, данные модели могут применяться для рекомендации клиенту интернет-магазина туфель и футболок, наиболее похожих на те, что уже выбрал покупатель.
При добавлении новых данных в БД, например, изображения, вместе с данными указывается модель машинного обучения, которую следует применить для индексации. Результаты обработки сохраняются в локальное хранилище в формате ключ/значение, и используются при построении индекса запросов. При обработке запроса похожих элементов, переданный в запросе эталонный элемент обрабатывается с использованием одного из выбранных алгоритмов поиска похожих объектов. В запросе определяется допустимый диапазон моделей, которые следует использовать при поиске. На выходе для каждой из выбранных моделей возвращается список наиболее близких элементов с указанием уровня релевантности.Взаимодействие с СУБД осуществляется с использованием протокола gRPC (https://grpc.io/) c применением HTTP/2 для сетевого взаимодействия и Protocol Buffers для сериализации данных. Низкоуровневое хранение данных реализовано с использованием LevelDB (https://www.opennet.dev/opennews/art.shtml?num=31325). &...Логика обработки моделей задаётся на языке Python (TorchScript ) и оформляется в виде модулей к PyTorch. В комплекте поставляются три готовые модели (resnet101, resnet18 и vgg16), обеспечивающие распознавание и классификацию изображений. В дальнейшем планируется включить в состав модели для обработки других видов информации.
Поддерживается несколько методов индексации и поиска данных:
- annoy - движок нечёткого поиска на базе библиотеки Annoy (https://github.com/spotify/annoy) (Approximate Nearest Neighbors Oh Yeah), которая применяется для формирования рекомендаций в музыкальном сервисе Spotify. Библиотека реализует алгоритм решения
задачи поиска ближайшего соседа (https://ru.wikipedia.org/wiki/%D0%97%D0%... оптимизированный для снижения потребления оперативной памяти и использования подкачки данных с диска;- faiss - движок на основе библиотеки поиска похожих элементов Faiss (https://github.com/facebookresearch/faiss), развиваемой компанией Facebook. Faiss предлагает большой набор настроек, позволяющих добиться необходимого компромисса в отношении времени поиска, качества поиска, потребления оперативной памяти и длительности обучения;
- exact_disk - простейший движок, в котором применяется линейный поиск точных совпадений. Индекс сразу сохраняется на диск, что позволяет добиться минимального расхода оперативной памяти.
URL: https://news.ycombinator.com/item?id=18488042
Новость: https://www.opennet.dev/opennews/art.shtml?num=49664
SELECT COUNT(*) FROM Cats WHERE cat_image LIKE LOAD_FILE('mycat.jpeg')
Это когда-то в светлом будущем. Пока только так.:)SELECT COUNT(*) FROM Turtles WHERE turtle_image LIKE rifle
> SELECT COUNT(*) FROM Cats WHERE cat_image LIKE LOAD_FILE('mycat.jpeg')Скорее:
SELECT COUNT(*) FROM ReCaptcha WHERE fire_hydrant_image LIKE LOAD_FILE('green_traffic_light_for_my_bus.jpeg');
Не понимаю, зачем?
Неужели так сложно навесить над движком абсолютно любой БД ту жа самую логику и вместо INSERT (image) делать предвычисленные INSERT (image, attribute1, attribute2, attribute3)?
> Неужели так сложно...Простые пути не всегда лучшие. В новости же всё сказано: алгоритмы выполнения запросов заточены под определённые задачи AI. Всякие там SQL субд общего назначения менее заточены под эти задачи и будут сливать по производительности. Ну или точнее разработчики этой ЕвклиДБ полагают, что они будут сливать: тесты пока они судя по всему стесняются выкладывать.
Без прямой поддержки Julia - не жилец...
да, julia не жилец.
А есть тут возможность обработки логов и каких-либо метрик мониторинга?
Стесняюсь спросить, сколько ж она жрать то будет?
Две видяхи.
на завтрак, столько же на обед и ужин
>модели могут применяться для рекомендации клиенту интернет-магазина туфель и футболок, наиболее похожих на те, что уже выбрал покупательИдиотское предположение, что покупателю нужна еще одна такая же вещь. Обычно это не так.
> Идиотское предположение, что покупателю нужна еще одна такая же вещь. Обычно это
> не так.Выбрал не значит, что уже купил. На Ali, например, одна из самых удобных штук, когда в момент помещения в корзину товара он показывает кучи похожих вещей и можно сразу найти лучше или дешевле.
а как они в gRPC очередь запросов хранят? а что если операции изменяют состояние сервера? выходит нужно хранить операции в надежном хранилище. клиент может запросить сервер статус операции по определенному id? выходит нужно запросы вечно хранить или требовать от клиента их аннулировать (но тупой клиент например web может их потерять и не аннулировать). как бы вы все это организовали?