უკან დაბრუნება

Jepsen-მა ParticleDB-ის 1.1.4-დან 1.1.18-მდე ვერსიებში 96 პრობლემა აღმოაჩინა
SiTech AI Team2 წთ. საკითხავი

Jepsen-მა ParticleDB-ის 1.1.4-დან 1.1.18-მდე ვერსიებში 96 პრობლემა აღმოაჩინა

Jepsen-მა ParticleDB-ის 1.1.4-დან 1.1.18.11.rc-22-მდე ვერსიებში 96 პრობლემა გამოავლინა: კრახებიდან და deadlock-ებიდან დაწყებული committed ჩაწერების დაკარგვითა და იზოლაციის ანომალიებით დამთავრებული, მიუხედავად Full ACID-ის მტკიცებისა.

Jepsen-მა ParticleDB-ის 1.1.4-დან 1.1.18.11.rc-22-მდე ვერსიები შეამოწმა და ბაზაში 96 პრობლემა იპოვა: კრახებიდან და deadlock-ებიდან დაწყებული, მონაცემების დაკარგვითა და ანომალიური მოთხოვნის შედეგებით დამთავრებული. პრობლემების უმეტესობა ერთ სერვერზე, ერთ კლიენტთან და ხარვეზების გარეშე გამოვლინდა. 1.1.18.11.rc-22 ვერსიისთვის ამ პრობლემებიდან ყველა, გარდა ათისა, მოგვარებულად ჩანდა, მაგრამ ParticleDB კვლავ კარგავდა committed ჩაწერებს ნორმალური მუშაობის დროს ნაგულისხმევი occ რეჟიმით და უშვებდა შიდა ანომალიებსა და Lost Update-ს serializable რეჟიმში, მის უძლიერეს პარამეტრში.

უსაფრთხოების მტკიცებები და დოკუმენტაცია

ParticleDB არის მულტიმოდელური მონაცემთა ბაზა AI დატვირთვებისთვის, რომელიც გთავაზობს ტრანზაქციულ SQL-ს, key-value საცავს, ვექტორულ ძიებას, ცოცხალ ანალიტიკას და მომხმარებლის მიერ განსაზღვრულ ფუნქციებს, რომლებსაც Particles ეწოდება. ბაზა მხარს უჭერს Postgres-ისა და Redis-ის პროტოკოლებს, ასევე gRPC-ისა და HTTP2-ის API-ებს და Rust-ზეა დაწერილი. მთავარ გვერდზე მითითებული იყო Full ACID და TLA+ მტკიცებულება, თუმცა თანამშრომლობის დროს TLA+ სპეციფიკაცია ხელმისაწვდომი არ იყო. დოკუმენტაცია ასევე არათანმიმდევრული იყო WAL sync რეჟიმებისა და ტრანზაქციის რეჟიმების შესახებ და უგულებელყოფდა ან უარყოფდა SET TRANSACTION ISOLATION LEVEL ბრძანებებს.

ტესტირების მოცულობა

ტესტირება ჩატარდა Debian 13-ის კვანძებზე, კონტეინერებსა და EC2 VM-ებში, Jepsen-ის დატვირთვებითა და ParticleDB-ისთვის სპეციფიკური ახალი დატვირთვებით. ჰარნესს შეეძლო პროცესის კრახების, LazyFS-ით ჯერ არ სინქრონიზებული (fsync-ამდე) ჩაწერების დაკარგვის და დისკის ფაილების შეკვეცის ან დაზიანების სიმულაცია. შემოწმდა WAL sync-ის სამივე რეჟიმი და თითოეული ტრანზაქციის რეჟიმი. რეპლიკაცია არ შემოწმდა, რადგან მოწოდებული build-ები მას არ უჭერდნენ მხარს.

აღმოჩენები

პრობლემებს შორის იყო table-2pl-ის უკიდურესად დაბალი მუშაობის სისწრაფე, მოულოდნელი იდუმალი კრახები, deadlock-ები, Postgres-ის ფუნქციების ნაკლებობა, არასწორად ფორმირებული prepared statement-ის პასუხები, ავთენტიფიკაციის ხარვეზები და პრედიკატებთან დაკავშირებული შეცდომები, მაგალითად: SELECT უგულებელყოფს WHERE პირობას, WHERE 4 = 5 აბრუნებს ერთ რიგს და ტრანზაქციებში SELECT იძლევა უაზრო შედეგებს. Orkes-მა მას შემდეგ გამოუშვა 1.1.19-rc.13 და აცხადებს, რომ ეს ვერსია აგვარებს ანგარიშში განხილულ ყველა დარჩენილ პრობლემას. ეს კვლევა დაფინანსდა Orkes, Inc.-ის მიერ.

წყაროები: Lobsters

გააზიარე ციფრული გამოცდილება

SiTech

SiTech — AI-გაძლიერებული ვებ დეველოპმენტი

ვქმნით სწრაფ, თანამედროვე ვებსაიტებს და AI-ს ვაერთიანებთ ქართული ბიზნესებისთვის. გაქვთ პროექტი ან კითხვა? სიამოვნებით დაგეხმარებით.