semadb
v2.0.2
No Fuss Multi-Index Hybrid Vector Database / Search Engine
SEMADB adalah multi-indeks, multi-vektor, database vektor berbasis dokumen / mesin pencari. Ini dirancang untuk menawarkan JSON Restful API yang jelas dan mudah digunakan. Komponen asli SEMADB dibangun untuk proyek manajemen pengetahuan di SEMAFIND sebelum dikembangkan menjadi proyek mandiri. Tujuannya adalah untuk menyediakan mesin pencari yang sederhana, modern, dan efisien yang dapat digunakan dalam berbagai aplikasi.
Mencari solusi yang di -host? SEMADB Cloud Beta tersedia di Rapidapi.
Untuk memulai dari sumber, silakan ikuti instruksi untuk menginstal GO. Itulah satu -satunya ketergantungan yang diperlukan untuk menjalankan SEMADB. Kami mencoba menjaga SEMADB sewak mandiri dan mutakhir dengan rilis GO terbaru.
SEMADB membaca semua konfigurasi dari file YAML, ada beberapa contoh yang terkandung dalam folder config . Anda dapat menjalankan satu server menggunakan:
SEMADB_CONFIG=./config/singleServer.yaml go run ./Jika Anda menggunakan kode VS sebagai editor Anda, maka sudah ada tugas yang sudah dibuat sebelumnya yang melakukan hal yang sama tetapi juga meluncurkan cluster secara lokal juga dalam mode debug.
Setelah Anda menjalankan server, Anda dapat menggunakan file sampel untuk melihat beberapa contoh permintaan yang dapat dilakukan ke server. Untuk memanfaatkannya sebaik -baiknya, instal ekstensi klien REST yang akan memungkinkan Anda untuk membuat permintaan langsung di editor dan menunjukkan hasilnya.
Anda dapat menjalankan versi terbaru SEMADB menggunakan gambar wadah repositori berikut:
docker run -it --rm -v ./config:/config -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data -p 8081:8081 ghcr.io/semafind/semadb:main
# If using podman
podman run -it --rm -v ./config:/config:Z -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data:Z -p 8081:8081 ghcr.io/semafind/semadb:mainyang akan menjalankan cabang utama. Ada juga versi yang ditandai untuk rilis spesifik. Lihat Container Registry dari Versi Stabil dan Produksi Repositori.
Anda dapat membangun dan menjalankan gambar wadah secara lokal menggunakan:
docker build -t semadb ./
docker run -it --rm -v ./config:/config -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data -p 8081:8081 semadb
# If using podman
podman build -t semadb ./
# The :Z argument relabels to access: see https://github.com/containers/podman/issues/3683
podman run -it --rm -v ./config:/config:Z -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data:Z -p 8081:8081 semadb Data Persistence: SEMADB menyimpan data dalam direktori pada disk yang ditentukan dalam file konfigurasi sebagai rootDir . Secara default, direktori data adalah ./data dan semadb Executable terletak di / memberi /data sebagai titik pemasangan dalam wadah.
Harap dicatat bahwa saat menggunakan Docker, nama host dan daftar putih IP mungkin perlu disesuaikan tergantung pada konfigurasi jaringan Docker. Meninggalkan nama host sebagai string kosong dan mengatur daftar putih ke '*' membuka semadb ke setiap koneksi seperti yang dilakukan di konfigurasi singleServer.yaml .
Kontribusi dipersilakan! Harap baca file panduan yang berkontribusi untuk informasi lebih lanjut. Panduan yang berkontribusi juga berisi informasi tentang arsitektur SEMADB dan bagaimana memulai pengembangan.
Algoritma pencarian inti inti SemadB didasarkan pada makalah penelitian yang sangat baik berikut:
Indeks lain seperti string, atau teks mengikuti pendekatan indeks terbalik. Indeks terbalik adalah struktur data yang menyimpan pemetaan dari konten, seperti kata atau angka, ke lokasi dalam file database, atau dalam dokumen atau satu set dokumen. Tujuan dari indeks terbalik adalah untuk memungkinkan pencarian teks lengkap cepat, pencarian awalan string, pencarian rentang integer dll.
SEMADB dengan nilai konfigurasi default pada Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz Workstation komoditas dengan RAM 16GB mencapai penarikan yang baik di seluruh tolok ukur standar, mirip dengan hasil yang dilaporkan:
| v1 | v2 | V2-PQ | v2-bq | |||||
|---|---|---|---|---|---|---|---|---|
| Dataset | Mengingat | QPS | Mengingat | QPS | Mengingat | QPS | Mengingat | QPS |
| Sarung Tangan-100-Angular | 0.924 | 973.6 | 0.853 | 773.9 | 0,526 | 628.6 | ||
| Dbpedia-Openai-100k-Angular | 0.990 | 519.9 | 0.920 | 240.8 | 0.766 | 978.6 | ||
| Sarung Tangan-25-Angular | 0.999 | 1130.3 | 0.992 | 914.4 | 0.989 | 805.8 | ||
| MNIST-784-Euclidean | 0.999 | 1898.6 | 0.999 | 1267.4 | 0.928 | 571.6 | 0.667 | 2369.7 |
| NYTIMES-256-Angular | 0,903 | 1020.6 | 0.891 | 786.7 | 0.438 | 983.6 | ||
| Sift-128-Euclidean | 0.999 | 1537.7 | 0.991 | 1272.9 | 0.696 | 967.4 |
Hasilnya diperoleh dengan menggunakan Ann-Benchmark. Kueri per detik (QPS) menggunakan cache memori penuh dengan satu utas yang mirip dengan metode lain tetapi bukan indikasi kinerja keseluruhan yang baik. Pipa penuh akan lebih lambat karena perjalanan dari ujung ke ujung permintaan memiliki overhead penanganan HTTP, pengkodean, decoding kueri, penguraian, validasi, rute cluster, panggilan prosedur jarak jauh, memuat data dari disk dll. Ini lebih tergantung pada perangkat keras, terutama SSD vs hard disk. Namun, kinerja mentah dari algoritma pencarian dalam satu beling tunggal akan, secara teori, mirip dengan yang dilaporkan dalam makalah penelitian.
Versi 1 (v1) adalah implementasi pencarian vektor murni asli dari SEMADB. Versi 2 (V2) adalah implementasi multi-indeks, hibrida, kata kunci, dll. Yang memiliki overhead decoding yang jauh lebih tinggi, mengirimkan data ke dalam indeks dan menggunakan kuantisasi. Versi 2 dengan kuantisasi produk (V2-PQ) dan kuantisasi biner (V2-BQ) menggunakan metode kuantisasi masing-masing untuk mengurangi penggunaan memori. Kami berharap penarikan menjadi lebih rendah karena metode kuantisasi lossy dan pencarian perkiraan.
Disk Cold dimulai bisa sangat lambat. Di bagian bawah rantai duduk disk di mana semua data disimpan. Ada dua cache dalam permainan: cache dalam memori dan cache file sistem operasi. Cache OS tidak ada dalam kendali kami dan diisi karena file dibaca atau ditulis. Ketika permintaan dibuat, grafik indeks akan dilalui dan poin dimuat dari disk ke cache sistem operasi dan diterjemahkan ke set poin dalam memori. Operasi pencarian sering melakukan bacaan acak dari disk saat melintasi grafik kesamaan; Oleh karena itu, selama awal yang dingin bisa memakan waktu lama (1 detik, 10 detik atau lebih) tergantung pada perangkat keras. Solid-State Disk (SSD) sangat disarankan karena alasan ini karena mereka melayani bacaan acak dengan lebih baik. Untuk penyebaran aplikasi tunggal, ini bukan masalah utama karena kami berharap sebagian dari data / indeks di-cache baik dalam memori atau oleh sistem operasi selama operasi. Alternatifnya adalah dengan menggunakan tata letak penyimpanan yang berorientasi pada grafik khusus pada disk sehingga blok / halaman lebih selaras dengan tetangga node dalam grafik kesamaan.
Penskalaan horizontal otomatis : Jumlah server di SEMADB dapat disesuaikan tetapi hanya disinkronkan pada startup. Hashing Rendezvous yang digunakan akan memindahkan jumlah data 1/N ke server baru atau memindahkan data server yang dihapus kembali ke yang tersisa. Karena ini hanya terjadi pada startup, itu lebih diarahkan untuk penskalaan atau penempatan di muka daripada di bawah beban langsung. Penskalaan otomatis langsung sulit dilakukan dengan aman saat database beroperasi karena kondisi balapan di seluruh server. Beberapa jebakan adalah: server yang tertinggal dalam konfigurasi mengirim data ke server lama, sementara transfer data terjadi permintaan pengguna harus ditangani, data yang salah disalurkan pada akhirnya harus tiba di server yang benar, sistem harus pulih dari skenario split-brain jika jaringan dipartisi. Banyak database terdistribusi menggabungkan mesin tambahan yang menambahkan kompleksitas yang signifikan untuk menangani ini seperti kunci versi, jam vektor dll. Saat ini, Anda dapat menyesuaikan server dan memulai kembali cluster untuk mendistribusikan kembali data.
Tidak Tulis Ketersediaan Tinggi : SEMADB dioptimalkan untuk pencarian beban kerja yang berat. Operasi pengumpulan dan penulisan poin memerlukan semua yang terlibat (server yang telah didistribusikan data) untuk berpartisipasi. Di jalur pencarian, kegagalan dapat ditoleransi karena merupakan pencarian stokastik dan penurunan kinerja sesekali karena pecahan yang tidak tersedia dapat diterima. Kami membongkar pemeliharaan sistem yang sehat di seluruh kegagalan server fisik ke alat orkestrasi kontainer seperti Kubernetes. Kami mengasumsikan bahwa status SEMADB yang dikonfigurasi akan dipertahankan secara aktif dan sebagai hasilnya tidak mengandung penemuan rekan atau algoritma konsensus dalam desain. Pilihan desain ini sekali lagi menyederhanakan arsitektur SEMADB dan membantu dengan perkembangan cepat. Desain asli termasuk mekanisme konsensus seperti rakit dan sistem terdistribusi sepenuhnya mandiri dengan penemuan rekan, tetapi ini dianggap berlebihan.
Ada banyak proyek pencarian vektor open-source dan mesin pencari di luar sana. Mungkin bermanfaat untuk membandingkan SEMADB dengan beberapa di antaranya untuk melihat apakah seseorang lebih cocok dengan kasus Anda:
