Elle's Blog

ბიტური ოპერაციები ორაკლში

29 აგვისტო, 201129 აგვისტო, 20114 კომენტარი

დღეს ზედმეტი მოვინდომე და ბაზაში მონაცემების ბიტმასკების სახით შენახვა გადავწყვიტე, რომელიც მერე ისევ თვითონ ბაზას უნდა დაემუშავებინა. შემდეგ ვნახე, რომ ორაკლში არ არის რეალიზებული ბიტური ოპერაციები და არის მხოლოდ ერთი – bitand() ფუნქცია, რომელიც ბიტურ “and”-ს აკეთებს რიცხვებზე.
“or” და “xor”-ის მიღებაც ამ ფუნქციის გამოყენებით მარტივად შეიძლება. მაგალითად a და b რიცხვებზე “or” ოპერაცია გამოვა

a + b - bitand(a,b)

ხოლო “xor”-ს მივიღებთ თუ კიდევ ერთხელ გამოვაკლებთ:

a + b - bitand(a,b) - bitand(a,b)

არც ბიტური წაძვრები (shift >>) აქვს, მაგრამ მაგის ჩანაცვლება 2-ზე გამრავლებით და გაყოფით შეიძლება.

MySQL-ში არ დამჭირვებია, მაგრამ ეხლა შევხედე და ჰქონია პირდაპირ &, |, ~, ^, <<, >> და თან bit_count() ფუნქციაც, რომელიც ჩართულ ბიტების რაოდენობას აბრუნებს. მათი გამოყენება პირდაპირ sql ქვერებშიც შეიძლება.

ბოლოს დამაინტერესა და სხვა ბაზებსაც გადავწვდი. PostgreSQL-ში უკანასკნელის მსგავსად ყველა არის რეალიზებული, MS SQL-ში კი მხოლოდ and, or და xor არიან.

პრინციპში დიდი გამოყენება ალბათ არ აქვთ, მაგრამ ზოგ შემთხვევაში ძალიან მოსახერხებელი გამოდის. მაგალითად, თუ ობიექტთან დაკავშირებული სტატიკური (თუნდაც არასტატიკური) პატარა სიმრავლის შენახვაა საჭირო, ანუ ამ ობიექტისთვის სიმრავლეში რომელი ელემენტებია ”ჩართული” და რომელი არა.

ფაილური სისტემის შეზღუდვები

10 აგვისტო, 20113 კომენტარი

ერთ-ერთი საიტის კოდში შემხვდა hack ლინუქსისთვის, რომელიც ფაილური სისტემის შეზღუდვის გათვალისწინების გამო იყო ჩამატებული. მივხვდი, აქამდე არასდროს მიფიქრია ასეთ წინააღმდეგობებზე და გადავწყვიტე ფაილური სისტემების აღწერისთვის მიმეძღვნა პოსტი, თუმცა იმდენნი არიან, ამ ერთი ჰეკით შემოვიფარგლები.

(ვიკიპედიაზე არის ქართული სტატიის ნაწილი მათ შესახებ, აქ კი სისტემების შედარების ცხრილებია)

კოდის ფრაგმენტი, რაც ზევით ვახსენე, საიტზე სურათების ატვირთვას ეხებოდა. როგორც ჩანს ლინუქსის ფაილურ სისტემებს (ext2/ext3) შეზღუდვა აქვთ, რომ ერთ საქაღალდეში 32000-ზე მეტი ქვე საქაღალდის შენახვა არ შეიძლება. ანუ თუ მაგალითად, მომხმარებლის ფოტოების შესანახად ერთი საქაღალდე გაქვთ გამოყოფილი და იქ თითოეული იუზერისთვის ქვესაქაღალდეს ქმნით, 32000-ზე მეტი იუზერის შექმნის შემთხვევაში ამ საქაღალდეებს ვეღარ შექმნის.

ერთი გამოსავალი ისაა, რომ ფაილური სისტემა შეცვალოთ (როგორც წერენ, ReiserFS-ს ასეთი შეზღუდვა არ აქვს და ასობით ათასს ფაილსსაც მარტივად უმკლავდება), მაგრამ თუ სხვა მხრივ ხელს არ გიშლით, ჩემი აზრით უკეთესია უბრალოდ სხვანაირად დაანაწილოთ ფაილები და ისე შეინახოთ.

მაგალითად, შეიძლება root ფოლდერში შეინახოთ საქალდეები სახელად 10000, 20000, 30000, ხოლო თითოეულში მაქსიმამუმ 10000 ცალი საქაღალდე რომელიც შესაბამისად არის გადანომრილი (1,2,3,.. ). როდესაც საჭირო იქნება იმის დადგენა თუ რომელ გარე საქაღალდეში უნდა მოიძებნოს თქვენი ფოლდერი, მისი სახელის 10000-ზე მთელი გაყოფით და შემდეგ ისევ 10000-ზე გამრავლებით გარე ფოლდერის სახელს მიიღებთ.

შეზღუდვები რომც არ იყოს, ზოგი ფაილური სისტემა არ არის ოპტიმიზირებული რომ ბევრ ფაილიან ფოლდერში სწრაფად ჩაამატოს, ამოშალოს ან წაიკითხოს ფაილები. მაგალითად ლინუქსის ext2 და ext3 დირექტორიების და ფაილების იერარქიას ბმული სიების სახით ინახავდნენ და შესაბამისად იქ ძებნას O(n) დრო სჭირდებოდა. ზოგ შემთხვევაში პრობლემა არაა, მაგრამ როცა, თუნდაც, კეშის მსგავსი სტრუქტურები იყო შესანახი, ძალიან ანელებდა ეს ყველაფერს. შემდეგ დაამატეს მარტივი ხის სტრუქტურა – HTree, რომელიც ext3-ში შეიძლება ”ჩაირთოს”, ext4-ს კი default-ად აქვს უკვე. სხვა ფაილური სისტემებიდან ბევრი B-tree-ის მონაცემთა სტრუქტურას იყენებს სწრაფი მუშაობისთვის. ამაზე ალბათ მოგვიანებით დავწერ.

იქით მივდიოდი, რომ უკეთესი წარმადობისთვის ჩვენმა აპლიკაციამაც შეიძლება შეუწყოს ხელი ოპერაციულ სისტემას. უკვე რამდენგანმე შემხვდა ჰეშირებას გამოყენება ფაილების მენეჯმენტის დროს. მაგალითად, რომ აიღოთ ფაილის სახელის ჰეში 910a90401e7bdc0452eea5630, ამ ჰეშის პირველი რამდენიმე სიმბოლო გამოიყენოთ საქაღალდეების იერარქიისთვის, ხოლო დანარჩენი ფაილის სახელისთვის.

91\0a\90401e7bdc0452eea5630.jpg

კარგი ჰეშ ფუნქციის შემთხვევაში საქაღალდეები და ფაილები დაახლოებით თანაბრად განაწილდება და ფოლდერები არ გადაიტვირთება. არც ფაილის მოძებნა იქნება მძიმე.

მაგალითად, Squid (web proxy cache) ინახავს კეშირებულ ფაილებს მსგავსი სახით.

Case sensitivity MySQL-ში

18 ივლისი, 201118 იანვარი, 20121 კომენტარი

ორ ასოზე მეტის დაწერა ქართულად ვერ მოვახერხე.. 😀

ბოლო დროს ერთ პრობლემაზე იმდენი დრო დავკარგე, რომ დამამახსოვრდა. სინამდვილეში არაკორექტული ლოგირების გამო უფრო იყო, მაგრამ ეს არაა ახლა მთავარი. MySQL-ში როცა რამეს აღვწერთ, თითქმის ყველაფერი case-insensitive არის, ანუ არ აქვს მნიშვნელობა ველის სახელს დიდი ასოებით დავწერთ თუ პატარით.

კონკრეტულად, არ აქვს მნიშვნელობა ველის, ფუნქციის, პროცედურის, ინდექსის და ალიასის შემთხვევაში. ტრიგერი ამ მხრივ გამონაკლისია.

ხოლო რაც შეეხება ცხრილის და ბაზის სახელებს – მათი ქეის სენსითივობა ოპერაციულ სისტემაზეა დამოკიდებული.

კი, ვერ მივხვდი ლინუქსში რატომ აღარ მუშაობდა 😀

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

შეიძლება lower_case_table_names პარამეტრის გამოყენებაც, თუმცა ამას ყველაფერი პატარა რეგისტრში გადაჰყავს და თუ მიგრაციას აკეთებთ, მაშინ არსებული ცხრილების და ბაზების სახელების კონვერტაცია იქნება საჭირო წინასწარ.

ჩემი სემინარი თსუ-ში 2: ვებ სერვისები (SOAP, REST)

27 იანვარი, 201116 აპრილი, 20164 კომენტარი

🙂 როგორც ჩემს წინა პოსტში ვწერდი, წინა შაბათს – 22 იანვარს სტუდენტურ სემინარებზე ჩემი ”მოხსენება” იყო ვებ აპლიკაციის უსაფრთხოებაზე.

ეს არის დაპირებული ბმული პრეზენტაციაზე, ხოლო ეს არის თვითონ სემინარის შინაარსი. თუ ვინმე ნახავს და შენიშვნები ექნება ან ჩათვლის რომ ვიტყუები 😀 გთხოვთ, დამიკომენტარეთ და გავასწორებ.

ამ შაბათს კი (29 იანვარს ისევ 5 საათზე) ისე მოხდა, რომ ისევ მე ვკითხულობ სემინარს და თემა შეეხება ვებ სერვისებს.

ისევ დავიწყებ შედარებით საბაზო სტრუქტურით და შესავლით, ხოლო შემდეგ ვისაუბრებ SOAP და REST არქიტექტურის მქონე სერვისებზე.

ჩემი სემინარი თსუ-ში: ვებ აპლიკაციის უსაფრთხოება

20 იანვარი, 201116 აპრილი, 20168 კომენტარი

რამდენიმე თვის წინ თბილისის სახელმწიფო უნივერსიტეტის კომპიუტერული მეცნიერების მიმართულების სტუდენტებმა ერთ საინტერესო წამოწყებას ჩაუყარეს საფუძველი : D

სტუდენტები ამზადებენ მათთვის სასურველ თემას და შემდეგ სხვა სტუდენტებს უტარებენ სემინარს.

მაგალითად აქამდე ჩატარდა სემინარები:

HTML5-სა და HTML4–ს შორის განსხვავება და ახალი API–ები (ნინო ლომინეიშვილი)
HTML5: Drag & Drop (მარიამ ხუნჯგურუა)
HTML5 Web Storage (შოთა ბაკურაძე, არჩილ ვარშანიძე)
Mobile Device Game Architecture (გიორგი აბელაშვილი)
Introduction to Android development (ირაკლი მანაგაძე)
Facebook for developers (დავით თვალჭრელიძე, გიორგი მაისურაძე)

სემინარების შესახებ ინფორმაცია ქვეყნდება ხოლმე facebook-ზე.

ამ შაბათს, ანუ 22 იანვარს (როგორც ყოველთვის 17:00 საათზე ბიოლოგების კორპუსის 421-ე აუდიტორიაში) იქნება ჩემი სემინარი 😀

რომელიც ვებ აპლიკაციის უსაფრთხოებას შეეხება.

დავიწყებ სულ საბაზო სტრუქტურის მიმოხილვით, თუ როგორ არის ქსელში მოწყობილი კლიენტისა და ვებ აპლიკაციის ურთიერთობა და რატომ არის ისეთი, როგორიც არის (HTTP პროტოკოლი, HTTP request / response, სესიები).

ხოლო შემდეგ განვიხილავ რა საფრთხე შეიძლება იყოს სისტემის თითოეულ ფენაზე – ვებ სერვერის მხარეს, გზაში, კლიენტის მხარეს.

შევეხები თემებს: Injecting OS commands / SQL / scripting languages, Directory traversal, Remote file inclusion, Persistent / Non-persistent XSS attack, Cross-site tracing და საშიში HTTP მეთოდები, DDoS attack, Brute force, და კიდევ რამდენიმე, თუ არ გამომაგდეს აუდიტორიიდან 😀

ესეც ანონსი..

p.s. იმედი მაქვს ვინმე არ გადაწყვეტს დაამტკიცოს რომ აზრზე არ ვარ უსაფრთხოების და ხვალ ჩემი ბლოგი ცოცხალი დამხვდება : D ჩვეულებრივი ვორდპრესია და ბეკაპების გარდა არაფრისთვის ვიწუხებ თავს.