1675
https://combot.org/chat/-1001043143583 Ссылки на полезные ресурсы: https://ruhaskell.org/links.html ; Информация о мероприятиях: https://gist.github.com/qnikst/a96cac661be80d126d0829f2ced1916e
я добавил себе If-None-Match для PUT и доп. функцию которая PUT делает стримом
Я не дополз поглубиться в x509, но разве там нет идентификатора в подписи, который позволил бы сразу нужный для проверки сертификат вытащить?
Насколько сложно в LMDB индексировать сертификаты и на каждую проверку делать в куче в Хаскеле копию нужного сертификата или ключа? Мне кажется, что в такой конфигурации вполне может быть лучше утилизация ресурсов за счёт оптимизаций на уровне OS (page cache, mmap) и отсутствия необходимости проводить проверку на каждый сертификат (если я правильно понял как оно работает?)
Затея в том, чтобы обходить много X509-серфтификатов и подписанных ими объектов с их валидацией. У них у всех полно таких вот полей, которые часто имеют статически известную длину, поэтому, если можно, добавив чуть-чуть кода, уменьшить кучу, я бы уменьшил
Читать полностью…
Приходят либо из парсинга ASN1, либо в качестве ключей и значений в LMDB
Читать полностью…
Ну у меня никакого кликхауза нет, эти объекты в памяти, но их много и поэтому хочется избавиться по максимуму от оверхеда и индирекшена
Читать полностью…
Их PUT всегда целиком выгружает в память (ещё попутно делая конвертации conduit -> lazy bs -> strict bs -> lazy bs -> conduit)
Читать полностью…
я уже давно не оцениваю чужой код, иначе можно свихнуться
Читать полностью…
скоро наверное сделаю третий, чтобы vhosted можно было не только для aws
Читать полностью…
А нет, я наврал, в логах аж 9 уникальных адресов, то есть целых 9 юзеров. Для хаскеля дофига так-то
Читать полностью…
Ну это такое аутичное хобби параллельно с работой и на тему работы. Зарплату мне платят за другое, а это для поддержания инженерного тонуса
Читать полностью…
Там все намного сложнее
https://github.com/lolepezy/rpki-prover
В лмдб лежит куча разных данных, в основном, какие-то сериализованные структуры, использовать ммап без копирования в память тут не получится. Оно уже довольно быстро шевелится, но я думаю повыжимать перфоманс на каких-то часто встречающихся данных
Инфра была раздута и я далеко не за счет таких оптимизаций её ужимал. Я больше наперед думал, чтобы предсказуемо несильно раздуться при мастштабировании важной бизнес логики: проверка аггрегированных признаков по истории, желательно поближе к событиям в real-time
В целом там вполне реально могло быть ~3млн уникальных ключей на статичный признак, про который нужно индивидуально хранить факт вхождения. Битовая маска помогала один и тот же идентификатор не дублировать под каждый признак в структуре под лукапы
Но когда ты материализуешь в памяти отсортированный жирный вектор с идентификаторами, то становится труднее в него ключи добавлять, ну и один и тот же идентификатор долго держать в памяти нужно почти никогда. А при добавлении динамичных параметров в битовой маске это решение еще больше становится похоже на выстрел себе в ногу
А в чем именно затея в оперативке держать много хэшей в обход LMDB?
Читать полностью…
А приходят они с диска? Кликхаус здесь как абстрактный интерфейс записи векторов на диск - чтобы основное хранение было не в оперативке, а все же на дисках. Насколько я понимаю, похожие распределенные архитектуры строят в т.ч. на всяких встраиваемых KV СУБД
Читать полностью…
Я, когда прикручивал битовые маски для рекламных таргетингов, тестировал хранение MAC-адресов и UUID в парах с масками разных размеров (8, 16, 32, 64 бит) в Unboxed векторе c лукапом через бинарный поиск. Работало хорошо: на тех же 48битных MAC-адресах экономилось 16бит, оверхэд по ссылкам убирался, порядки перфоманса на поиск не помню какие были (вроде бы, как минимум сильно лучше интмапы)
Но в рамках моей задачи интуиция заставляла сомневаться, не ерундой ли я занимаюсь, т.к. у меня еще могла возникнуть проблема шардирования во всем из-за роста числа данных и сложности обработки. Сейчас кажется, что лучше было бы шардированный кэш сделать напрямую над Кликхаусом, т.к. на диске хранение у него отличное и можно было бы под разные таски лучше масштабироваться (в т.ч. используя механизмы шардирования/репликации на уровне СУБД)