[devel] Еще раз о правильном аналоге packages.altlinux.org

Mikhail Novosyolov mikhailnov на altlinux.org
Пт Фев 12 21:02:29 MSK 2021


12.02.2021 20:25, Anton Farygin пишет:
> On 12.02.2021 12:38, Eugene Prokopiev wrote:
>> вт, 9 февр. 2021 г. в 11:26, Anton Farygin <rider на basealt.ru>:
>>
>>>> curl
>>>> https://repodb.basealt.space/package_info?name=kernel-image-un-def |jq
>>>>
>>>> Мне понравилось. Отдаёт всё очень шустро. :-)
>>>> Использует rpmlib или данные лежат в какой-то базе?
>>> Лежит в clickhouse.
>>>
>>> в rpmlib невозможно в принципе держать данные для почти трёх миллионов
>>> пакетов.
>> Антон, а нельзя ли это переложить в elasticsearch и за счет некоторого
>> снижения производительности и/или увеличения требований к железу (вряд
>> ли критичному) получить возможность писать запросы к этой БД через
>> довольно удобный DSL over HTTP и рисовать в Kibana (и не только)
>> различные дашборды
>
> Мне не нравится эластик, Его практически невозможно упакетить. Поэтому после некоторых экспериментов мы взяли clickhouse и сейчас залили туда почти три миллиона пакетов (метаданных) включая списки файлов с контрольными суммами и правами.
>
> Т.е. - все метаданные, которые можно было взять из rpm.
>
> при этом структура базы содержит ошибки, которые нужно исправить перед публикацией. Ну и надо переосмыслить некоторые моменты с хранением.
>
> Например, мне не нравится как мы храним информацию о том, какой пакет в каком репозитории находится/находился. Сейчас это делается влоб - в отдельной таблице лежат пары <uuid репозитория> <hash rpm пакета>.
>
> А т.к. мы ничего не удаляем и добавляем в базу ежедневные срезы всех репозиториев (если менялись), то эта таблица пухнет и сейчас в ней около 500 миллионов записей.
>
> Благодаря clickhouse, конечно, с ними работать получается довольно быстро, но на мой взгляд тут есть куда работать над оптимизацией хранения, в первую очередь в сторону хранения только изменений репозитория. Такая табличка будет очень маленькая (около 4 миллионов записей) и  должна будет вся помещаться в память, что очень сильно ускорит практически все запросы.
>
> ну и можно писать отдельные парсеры, заливающую разную полезную информацию в CH - например, данные из bugzilla, логи и статусы пересборки, активность ментейнеров в рассылках и т.д.
>
>>
>> Ок, я в курсе лицензионных вопросов по эластику, СlickHouse тоже
>> неплох - особенно если структура БД будет опубликована и к ней можно
>> будет писать SQL-запросы через HTTP
>>
>> На самом деле вопрос сводится к:
>> и и
>> * вменяемому HTTP API для поиска по репозиториям/пакетам
>
> Это уже есть, вменяемость API нужно обсуждать.
>
> curl https://repodb.basealt.space/|jq
> выводит HELP.
Выглядит очень круто. Было бы полезно, чтобы build_dependency_set мог вывести имена не только binary, но и source пакетов. Описание не очень понятное, если правильно понял, речь про список пакетов, использованных для сборки заданного пакета, т.е., грубо говоря, всех пакетов, установленных в чрут.
>
>> * возможности связать вывод такого API и сборочные логи/таски
> Тоже есть, API уже можно обсуждать.
>> * удобному фронтенду (но уже потом)
>>
>> Мне было бы интересно принять в этом посильное участие - но для начала
>> нужен какой-то список требований с приоритетами + понимание откуда
>> брать исходные данные
>>
>>
> Жень, сейчас Данил Шеин смотрит что у нас наработано по clickhouse и после рефакторинга структуры и базовового кода выложит все наработки в паблик. Не знаю, честно, сколько времени на это уйдёт, надеюсь что немного ;)
>
> Конечно, идея как раз в этом и заключается, что бы со стороны можно было ходить к базе и спрашивать у неё разные полезные ништяки, в том числе графики рисовать при необходимости.
>
> Код написан на питоне.
>
>
>
> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel


Подробная информация о списке рассылки Devel