Performance results

Note: Performance was measured using 20,000 iterations (3 runs) in tests/measure\_performance.py, with randomly generated vectors of dimension 3072.

Benefits ‘orlson’ vs ‘json’

• Up to ~20× faster compared to the standard json library on generate vector data
• Up to ~8× faster compared to the standard json library on response vector data

Benefits of ‘binary’ on response vector data

• Up to ~16× faster compared to the standard json library
• About ~2× faster compared to orjson

Testing output

Warming for 3 seconds

decode_binary start testing...
binary: 1.8913245666384075 [1.9641265999525785, 1.8629208999918774, 1.846926199970767]

decode_orjson_str start testing...
json_str: 3.804304266697727 [4.095871299970895, 3.7040354000637308, 3.6130061000585556]

decode_json_str start testing...
json_str: 30.897333099972457 [30.78853879997041, 31.119306599954143, 30.784153899992816]
* decode binary is fastest than json in 16.34 times
* decode binary is fastest than orjson in 2.01 times
* decode orjson is fastest than json in 8.12 times

encode_orjson_str start testing...
orjson_str: 2.32788303331472 [2.455615399987437, 2.2925777999917045, 2.235455899965018]

encode_json_str start testing...
json_str: 51.04346506666237 [50.961705199908465, 50.88195970002562, 51.28673030005302]
* encode orjson is fastest than json in 21.93 times

Reference

🔗 DEMO Django application of usage library ‘django-mariadb-vector’ (MariaDB Vector)

🔗 Django MariaDB Vector package on pypi - ‘django-mariadb-vector’

🔗 Repo library: https://github.com/lexxai/django-mariadb-vector

🔗 Repo Demo: https://github.com/lexxai/django-mariadb-vector-demo

📒 Django MariaDB Vector DEMO application 

A minimal demo project showing how to build article recommendations using vector similarity in Django with MariaDB as the database.

The app stores articles, embeds their content into vectors, and then finds similar articles based on vector distance.

🔗 Repo: https://github.com/lexxai/django-mariadb-vector-demo
🔗 Examples: https://github.com/lexxai/django-mariadb-vector-demo/tree/main/docs

🔗 Repo library: https://github.com/lexxai/django-mariadb-vector

Features

• Django application using MariaDB as the primary database
• Article model with text content
• Vector-based similarity search for recommendations
• Simple UI:

• List of all articles

• “Similar articles” view for a selected article
• Admin interface to add and manage articles

Features Demonstrated:

• MariaDBVectorField: Storing vector embeddings as a specialized field in Django models.
• MariaDBVectorIndex: Creating HNSW (Hierarchical Navigable Small World) indexes for efficient similarity search.
• RecommendationManager: Using a custom manager to perform similar_to() queries based on vector similarity.

Examples

List of all articles

List of articles similar to Article with pk=1

Adding new article data through the Django admin

Simple example of usage:

!pip install django-mariadb-vector

from django.db import models
from django_mariadb_vector import MariaDBVectorField, MariaDBVectorIndex, VecDistance


class MyModel(models.Model):
    embedding = MariaDBVectorField(dimensions=3)

    class Meta:
        indexes = [
            # Vector index (MariaDB 11.8.2+)
            MariaDBVectorIndex(fields=["embedding"], dimensions=3)
        ]

# Find 5 most similar records to a reference vector
reference_vector = [0.1, 0.2, 0.3]
results = MyModel.objects.annotate(
    distance=VecDistance("embedding", reference_vector)
).order_by("distance")[:5]

Using a Recommendation Manager can simplify vector searches in your application:

models.py:

from django.db import models

from django_mariadb_vector import MariaDBVectorField, MariaDBVectorIndex
from django_mariadb_vector.managers import RecommendationManager


class MyModel(models.Model):
    embedding = MariaDBVectorField(dimensions=3)
    
    objects = RecommendationManager(vector_field="embedding")
    
    class Meta:
        indexes = [
            # Vector index (MariaDB 11.8.2+)
            MariaDBVectorIndex(fields=["embedding"], dimensions=3, m=16),
        ]

reference vector:

from .models import MyModel

reference_vector:list[float] = [0.1, 0.2, 0.3]

# Find 5 most similar records to a reference vector
results = MyModel.objects.similar_to_vector(reference_vector, limit=5)

for item in results:
    print(f"{item.name} - Distance: {item.distance}")

reference id:

from .models import MyModel

reference_id:int = 1
# Find 5 most similar records to a reference object by id
results = MyModel.objects.similar_to(reference_id, limit=5)

for item in results:
    print(f"{item.name} - Distance: {item.distance}")

#Django #MairaDB #VectorDatabase #DjangoORM

📒 Django MariaDB Vector

The Vector field, introduced in MariaDB 11.7, now has a simple library called ‘django-mariadb-vector’ that adds Django ORM support for it.

Created by me and shared for everyone to use.

🔸 pip install django-mariadb-vector

🔗 Repo: https://github.com/lexxai/django-mariadb-vector
🔗 Demo: https://github.com/lexxai/django-mariadb-vector-demo
🔗 Examples: https://github.com/lexxai/django-mariadb-vector-demo/tree/main/docs

MariaDB introduced native vector support, allowing you to store embeddings and perform similarity search directly in the database.

However, Django currently lacks:

• a native VECTOR model field
• ORM support for vector queries
• automatic migration
• support for vector indexes

This project fills that gap by providing a clean, Django-native way to work with MariaDB vectors.

Simple example of usage:

!pip install django-mariadb-vector

from django.db import models
from django_mariadb_vector import MariaDBVectorField, MariaDBVectorIndex, VecDistance


class MyModel(models.Model):
    embedding = MariaDBVectorField(dimensions=3)

    class Meta:
        indexes = [
            # Vector index (MariaDB 11.8.2+)
            MariaDBVectorIndex(fields=["embedding"], dimensions=3)
        ]

# Find 5 most similar records to a reference vector
reference_vector = [0.1, 0.2, 0.3]
results = MyModel.objects.annotate(
    distance=VecDistance("embedding", reference_vector)
).order_by("distance")[:5]

#Django #MairaDB #VectorDatabase #DjangoORM

Я вирішив отримати практичний досвід роботи з GitHub Actions та GitHub Pages.

Мій блог має RSS-стрічку, і це дало ідею: якщо автоматично обробляти RSS-сторінки, можна отримати повну резервну копію блогу у форматі Markdown.

А вже цей Markdown легко опублікувати в репозиторії GitHub Pages / Jekyll.

Таким чином я отримую:

• автоматичний бек-ап контенту
• контроль над контентом у Git
• можливість міграції з Blogger без втрат
• статичну версію блогу

Приклад використання

Блоґ котрий копіюється

Результат копіювання на GitHub pages

Опис продукту

Це Python-утиліта, яка синхронізує пости з RSS-стрічки Blogger у репозиторій GitHub Pages / Jekyll.

Вона автоматично:

• завантажує зображення,
• переписує внутрішні посилання,
• генерує коректно оформлені Markdown-файли з YAML frontmatter.

Можливості

• Automated Sync
  Отримує пости з RSS-стрічки Blogger та синхронізує їх із репозиторієм.
• Image Handling
  Завантажує зображення блогу та зберігає їх локально в:
  assets/images/blog/
• Link Rewriting
  Оновлює старі доменні посилання, замінюючи їх на нову адресу GitHub Pages.
• Jekyll-compatible Output
  Генерує Markdown-файли з правильно оформленим YAML frontmatter, сумісним із Jekyll.
• Dry Run Mode
  Дозволяє попередньо переглянути зміни без фактичного створення або перезапису файлів.
• Configurable
  Гнучка конфігурація через змінні середовища.

Як це працює

Утиліта працює як простий пайплайн обробки даних:

Отримання RSS

Скрипт підключається до RSS-стрічки Blogger та отримує список постів.

З RSS витягується:

• заголовок
• дата публікації
• HTML-контент
• категорії (labels)
• постійне посилання (permalink)

Обробка HTML-контенту

Отриманий HTML проходить декілька етапів трансформації:

• очищення зайвих тегів
• конвертація HTML → Markdown
• переписування внутрішніх посилань на новий GitHub Pages домен
• пошук усіх зображень

Завантаження зображень

Усі знайдені зображення:

• завантажуються локально
• зберігаються у assets/images/blog/
• перейменовуються за безпечним шаблоном
• їхні шляхи автоматично оновлюються в Markdown-файлі
• Таким чином блог стає повністю автономним і не залежить від зовнішнього CDN Blogger.

Генерація Markdown-файлу

Для кожного поста створюється файл у форматі: YYYY-MM-DD-post-slug.md

Файл містить:

• YAML frontmatter (title, date, tags, layout)
• основний Markdown-контент
• оновлені локальні шляхи до зображень
• Формат повністю сумісний з Jekyll.

Dry Run режим

У режимі dry-run:

• файли не записуються
• зображення не зберігаються
• показується список змін, які будуть виконані

Це дозволяє безпечно перевірити результат перед реальною синхронізацією.

Інтеграція з GitHub Actions

Скрипт можна запускати:

• локально
• через cron
• автоматично через GitHub Actions

У випадку GitHub Actions:

• Виконується запуск утиліти
• Генеруються / оновлюються Markdown-файли
• Зміни комітяться у репозиторій
• GitHub Pages автоматично перебудовує сайт

У результаті отримуємо повністю автоматизований процес резервного копіювання та публікації.

GitHub Actions

Підсумок процесу

RSS → HTML → Markdown → Download Images → Rewrite Links → Commit → GitHub Pages Build

Посилання

• GitHub repository - BLOG2GHP
• Маємо те, що маємо. Усе що відбувається - на краще
• https://lexxai.github.io/

Я маю віддалений сервер із GPU, на якому запущена Ollama.

Водночас середовище розробки зазвичай очікує, що Ollama доступна локально - наприклад, за адресою http://localhost:11434 або в межах локальної мережі (http://192.168.0.111:11434).

Класичні рішення

Найпростіший варіант — SSH-тунель:

ssh remote@server -L 11434:localhost:11434

Після цього локальний localhost:11434 проксуватиметься на віддалений сервер.

Якщо ж розробників декілька і вони працюють з різних офісів або через інтернет — можна використати VPN. Це теж робоче рішення, але воно потребує додаткової інфраструктури та адміністрування.

Проблема з авторизацією

У моєму випадку Ollama використовується разом із OpenWebUI, який проксіює доступ до Ollama через власний API з токен-авторизацією.

Однак більшість застосунків, що інтегруються з Ollama, очікують простий доступ до http://localhost:11434 без жодної авторизації. Через це вони не можуть напряму працювати через OpenWebUI.

Рішення — Ollama DeProxy

Щоб спростити інтеграцію, я написав невеликий застосунок - Ollama DeProxy.

Його ідея проста:

• локально він виглядає як звичайна Ollama (localhost:11434);
• всередині - проксіює запити на віддалений сервер;
• за потреби додає авторизацію;
• дозволяє централізовано керувати доступом.

Таким чином:

• розробникам не потрібно налаштовувати SSH-тунелі;
• не обов’язково піднімати VPN;
• клієнтські застосунки продовжують працювати так, ніби Ollama запущена локально.

У результаті віддалений GPU-сервер використовується прозоро, без змін у клієнтському коді.

Репозиторій:

Ollama DeProxy - https://github.com/lexxai/ollama-deproxy

Приклади використання:

Docker container Ollama DeProxy

VS Code + Continue + Ollama DeProxy

VS Code + Copilot GitHub (Old version) + Ollama DeProxy

VS Code + Copilot GitHub (0.37.9) + Ollama DeProxy (CORRECT_NUMBERED_MODEL_NAMES=True)

PyCharm  AI Assistant + Ollama + Ollama DeProxy

pypi:

Додано проєкт до репозиторію pypi:

pip install ollama-deproxy

За матеріалами:

• Оllama
• openwebui.com - api proxy
• ollama-deproxy
• pip install ollama-deproxy

Docker у Windows працює через WSL (Windows Subsystem for Linux), яка в свою чергу використовує віртуалізацію Hyper‑V. Це означає, що всі дані зберігаються у файлах образів віртуальних дисків .vhdx.

З часом диск починає стрімко розростатися, і рано чи пізно місце на системному SSD закінчується. Тоді виникає питання: куди ж воно поділося?

На допомогу приходить утиліта WinTree (diskanalyzer.com), яка дозволяє швидко побачити, що саме займає простір.

Саме так я й з’ясував, що проблема була у Docker. Але коли перевірив сам Docker - там усе вже очищено, а файл .vhdx продовжував залишатися гігантським.

docker system df

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          2         2         329.2MB   0B (0%)
Containers      3         0         2B        2B (100%)
Local Volumes   62        1         2.309GB   2.125GB (92%)
Build Cache     0         0         0B

Чому VHDX росте безконтрольно.

Реальний розмір віртуального тому завжди більший за фактичні дані. Це відбувається тому, що .vhdx‑файл у WSL та Docker може лише збільшуватися у міру потреби.

Коли ти видаляєш образи чи очищаєш дані, простір всередині Linux‑файлової системи звільняється, але сам файл на диску не стискається автоматично.

Тому він продовжує залишатися гігантським, навіть якщо даних там майже немає.

Docker .vhdx before compact

Стискаємо образ диску

Виходимо з застосунку “Docker Desktop” та робимо завершення “WSL”:

wsl --shutdown

Стискаємо VHD файл відкриваючи консоль PowerShell як Administrator.

Optimize-VHD -Path "$env:LOCALAPPDATA\Docker\wsl\disk\docker_data.vhdx" -Mode Full

Тепер набагато краще.

Docker .vhdx after compact

У багатьох інсталяціях pfSense використовується не лише як firewall, а і як точка термінації HTTPS для внутрішніх вебсервісів. Типовий стек виглядає так:

• pfSense - firewall та reverse-proxy
• HAProxy - маршрутизація HTTP/HTTPS трафіку
• ACME (Let’s Encrypt) - автоматична генерація HTTPS сертифікатів
• Внутрішні вебсервери - працюють по HTTP у локальній мережі

У цій публікації як розгляну як коректно пройти ACME HTTP-01 валідацію, коли порт 80 вже зайнятий HAProxy, без зупинки сервісів і без DNS-01.

Вихідні умови

Інфраструктура

• pfSense firewall
• У локальній мережі є декілька вебсерверів, яким потрібні HTTPS сертифікати
• Доступ до них забезпечує HAProxy, що працює безпосередньо у pfSense

HAProxy

Прослуховує:

• 80/tcp (HTTP)
• 443/tcp (HTTPS)

Функції:

• HTTP → HTTPS redirect
• TLS termination
• Маршрутизація за доменним іменем (ACL по Host)
• Робота з HTTP backend (без TLS усередині LAN)

ACME

• Сертифікати генеруються через: Services → ACME → Certificates
• Використовується HTTP-01 validation
• Стандартний порт 80 недоступний, бо його вже використовує HAProxy

ПроблемаACME HTTP-01 завжди звертається на порт 80:

http://example.com/.well-known/acme-challenge/<token>

Але:

• порт 80 вже зайнятий HAProxy
• зупиняти HAProxy під час renew — погана ідея
• перенаправлення на інший порт (81, 8080) не підтримується Let’s Encrypt

Рішення: HAProxy як проксі для ACME standalone

Services Acme Certificate options

####

Ключова ідея

• HAProxy залишається на порту 80

• ACME під час валідації:

• піднімає тимчасовий standalone webserver

• на іншому локальному порту, наприклад 81

• HAProxy:

• перехоплює лише запити до /.well-known/acme-challenge/
• проксіює їх на 127.0.0.1:81

Let’s Encrypt нічого не знає про порт 81 — для нього все відбувається через порт 80

ACME standalone webserver

Приклад команди, яку використовує pfSense ACME package під час валідації:

/usr/local/pkg/acme/acme.sh --issue \    
  --domain example.com \  
  --standalone --httpport 81 --listen-v4

Особливості:

• вебсервер тимчасовий
• порт 81 відкритий лише на час валідації
• доступний тільки локально

Налаштування HAProxy

Services HAProxy Backend Edit

####

Backend для ACME

Services HAProxy Frontend Edit

Створюємо окремий backend, наприклад local_acme:

• Address: 127.0.0.1
• Port: 81
• Mode: http
• Health checks - вимкнені

Важливо: Standalone webserver не працює постійно. Якщо увімкнути health check - backend завжди буде в статусі DOWN і HAProxy повертатиме 503.

ACL правило

У frontend для HTTP (port 80) додаємо ACL:

path_beg /.well-known/acme-challenge/

Routing rule

Перше правило у frontend:

if path_beg /.well-known/acme-challenge/ use_backend local_acme

Порядок правил критичний — ACME правило має бути перед redirect на HTTPS. 

Повний потік запиту

1. Let’s Encrypt → http://example.com/.well-known/acme-challenge/…
2. Запит приходить на pfSense, порт 80
3. HAProxy:
   • бачить path_beg /.well-known/acme-challenge/
   • НЕ робить redirect
   • проксіює на 127.0.0.1:81
4. ACME standalone webserver віддає challenge
5. Сертифікат успішно згенеровано
6. Standalone webserver завершує роботу

Переваги рішення

• без зупинки HAProxy
• без відкриття порту 81 у WAN
• без DNS-01
• повністю автоматичне renew
• production-ready схема

Типові помилки

• redirect HTTP → HTTPS для ACME path
• увімкнені health checks у backend
• path rewrite або security filtering
• неправильний порядок ACL правил

Висновок

Ця схема дозволяє коректно використовувати ACME HTTP-01 validation, навіть якщо порт 80 повністю зайнятий HAProxy.
HAProxy виступає не як перешкода, а як тонкий маршрутизатор для ACME challenge, що робить рішення стабільним і безпечним.

(HTTP code 500) server error - ports are not available: exposing port TCP 0.0.0.0:8182 -> 127.0.0.1:0: listen tcp 0.0.0.0:8182: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

But nothing is using the port, it’s likely because Windows has excluded the port dynamically, especially after Docker was previously using it.

(HTTP code 500) server error - ports are not available

1. Verify Nothing Is Listening on the Port

netstat -aon | findstr :8181

If you see no output, the port is not in use by any application.

2. Check Excluded Port Ranges:

netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges

Start Port    End Port
----------    --------
      6575        6674
      7162        7261
      7262        7361
      7362        7461
      7462        7561
      7562        7661
      7681        7780
      7781        7880
      7881        7980
      7981        8080
      8081        8180
      8181        8280
      8281        8380
      8381        8480
      8481        8580
     30604       30703
     49690       49789
     49790       49889
     49890       49989
     50000       50059     *
     50160       50259
     50360       50459
     50460       50559
     50660       50759
     50760       50859
     50860       50959
     51064       51163
     51243       51342
     51344       51443

You’ll notice 8182 falls within the 8181–8280 range - without a * at the end, meaning it’s a dynamically excluded port.

You cannot remove dynamic exclusions manually.

3. Restart winnat Service to Clear Dynamic Exclusions:

This step clears dynamic port reservations created by services like Docker:

net stop winnat
net start winnat

* Run the above in Administrator Command Prompt

4. Recheck Excluded Ports:

netsh int ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges

Start Port    End Port
----------    --------
     50000       50059     *

* - Administered port exclusions.

If 8182 is no longer in the list, you’re good to go.

📌 What it does:

This script generates a docker-compose.yml file for setting up an ElasticSearch cluster using template files and environment variables. It creates a cluster with Docker containers, including:

• ElasticSearch nodes with different roles (master, data, ingest, coordinator)
• Kibana for visualization
• Additional service containers

🔧 How it works:

• Configure your cluster setup using a .env file.
• Run the script, and voilà! Your docker-compose.yml is ready.

📶 Test Environment:

The generated cluster was tested on a TrueNAS SCALE 24.10.2 server, deployed as a custom application by importing the YAML file. Storage was configured using ZFS Datasets, ensuring reliability and scalability.

💡 Why it’s awesome:

• Saves time and reduces errors in manual configuration.
• Flexible and customizable for different cluster setups.
• Perfect for DevOps engineers and developers working with ElasticSearch.

🔗 Script: https://github.com/lexxai/es_cluster_docker_helper🔗 Prototype: https://github.com/evermight/elastic-cluster-docker-compose

Responsible AI for Developers: Privacy & Safety

Progress “Machine Learning Engineer Learning Path”

Machine Learning Engineer Learning Path

Machine Learning Engineer Learning Path

A Machine Learning Engineer designs, builds, productionizes, optimizes, operates, and maintains ML systems.

21 activities

##

A Machine Learning Engineer designs, builds, productionizes, optimizes, operates, and maintains ML systems. This learning path guides you through a curated collection of on-demand courses, labs, and skill badges that provide you with real-world, hands-on experience using Google Cloud technologies essential to the ML Engineer role. Once you complete the path, check out the Google Cloud Machine Learning Engineer certification to take the next steps in your professional journey.

#