Comparing Performance After Optimization in django-mariadb-vector

Since version v0.2.0, the 'django-mariadb-vector' library includes several optimization options. Here are the results from performance tests.

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

DEMO Django application of usage library 'django-mariadb-vector' (MariaDB Vector)

pip install django-mariadb-vector

📒 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

Django MariaDB Vector package on pypi - 'django-mariadb-vector'

pip install django-mariadb-vector

📒 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

Blogger to GitHub Pages Sync Tool (blog2ghp)

Навіщо?

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

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

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

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

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

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

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

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

Ollama DeProxy або як отримати локальний доступ до віддаленої Ollama

Ollama DeProxy

Я маю віддалений сервер із 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.

Windows Docker. Virtual image file just only grow size of .vhds file.

Куди зникає місце на диску?

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