მონაცემთა ბაზებში პირველად გასაღებად (primary key) შემთხვევითი UUID-ების გამოყენება გავრცელებული პრაქტიკაა. თუმცა, ანდერს მერფის ბოლოდროინდელი კვლევა ცხადყოფს, რომ ამ მიდგომას შესრულების სერიოზული ხარჯები ახლავს თან.
მთავარი პრობლემა UUID4-ის შემთხვევით ბუნებაშია. როდესაც მონაცემებს B-tree სტრუქტურაში შემთხვევითი თანმიმდევრობით ვამატებთ, სისტემას მუდმივად უწევს ბალანსის ხელახლა დაცვა, რაც ზედმეტ დატვირთვას იწვევს.
SQLite-ში ჩვეულებრივი ცხრილები იყენებენ 64-ბიტიან მთელი რიცხვის ტიპის გასაღებს, რომელსაც rowid ეწოდება. ეს არის ეფექტური, კლასტერული ინდექსი, რომელიც მონაცემების ფიზიკურ შენახვას განსაზღვრავს. შედარებისთვის, WITHOUT ROWID ცხრილებში, სადაც თავად ვუთითებთ პირველად გასაღებს, B-tree სტრუქტურა განსხვავებულად მუშაობს.
| total rows | time in ms |
|---|---|
| 10000000 | 838 |
| 20000000 | 762 |
| 30000000 | 819 |
| 40000000 | 713 |
| 50000000 | 721 |
| 60000000 | 757 |
| 70000000 | 692 |
| 80000000 | 702 |
| 90000000 | 696 |
| 100000000 | 715 |
კვლევის ფარგლებში ჩატარებულმა ტესტმა აჩვენა, რომ 10 მილიონი ჩანაწერის დამატებისას, სტანდარტული rowid-ის შემთხვევაში სისტემა წამში დაახლოებით მილიონ ოპერაციას ასრულებს.
| total rows | time in ms |
|---|---|
| 10000000 | 2649 |
| 20000000 | 5644 |
| 30000000 | 7137 |
| 40000000 | 8352 |
| 50000000 | 9359 |
| 60000000 | 9817 |
| 70000000 | 10490 |
| 80000000 | 11130 |
| 90000000 | 11668 |
| 100000000 | 12586 |
როდესაც იგივე ოპერაცია UUID4-ით ჩატარდა, შედეგი გამანადგურებელი აღმოჩნდა: პროცესი 14-16-ჯერ შენელდა. პროფილერით ჩატარებულმა ანალიზმა დაადასტურა, რომ სისტემა მთელ რესურსს ხარჯავს ხის სტრუქტურის ბალანსირებაზე, კითხვასა და წერაზე.
პრობლემის გადასაჭრელად მერფი UUID7-ის გამოყენებას გვთავაზობს. ვინაიდან UUID7 დროზეა დამოკიდებული, ის გამორიცხავს UUID4-ისთვის დამახასიათებელ არეულობას. მიუხედავად იმისა, რომ ეს მეთოდი უფრო სწრაფია, ის მაინც ჩამოუვარდება სტანდარტულ rowid-ს, ძირითადად 16-ბაიტიანი UUID-ის ზომის გამო (8-ბაიტიან მთელ რიცხვთან შედარებით).
| total rows | time in ms |
|---|---|
| 10000000 | 1372 |
| 20000000 | 1280 |
| 30000000 | 1365 |
| 40000000 | 1250 |
| 50000000 | 1256 |
| 60000000 | 1270 |
| 70000000 | 1246 |
| 80000000 | 1257 |
| 90000000 | 1245 |
| 100000000 | 1258 |
კიდევ ერთი ვარიანტია UUID4-ის გამოყენება rowid-თან ერთად. თუმცა, ამ შემთხვევაშიც ვიღებთ „ჩაწერის ამპლიფიკაციას“, რადგან ცხრილს უკვე ორი ინდექსი აქვს, რაც საერთო მუშაობაზე ნეგატიურად აისახება.
დასკვნა ნათელია: სანამ UUID-ს პირველად გასაღებად აირჩევთ, გაითვალისწინეთ შესრულების ის ხარჯები, რომელსაც SQLite-ის არქიტექტურული თავისებურებები განაპირობებს.
| total rows | time in ms |
|---|---|
| 10000000 | 2003 |
| 20000000 | 2324 |
| 30000000 | 3285 |
| 40000000 | 4399 |
| 50000000 | 5194 |
| 60000000 | 5659 |
| 70000000 | 6215 |
| 80000000 | 6467 |
| 90000000 | 6924 |
| 100000000 | 7119 |
დისკუსია
0 კომენტარი
ჯერ კომენტარი არ არის — იყავი პირველი.