NoSQL ma'lumot bazalari xususiyatlari

2.1 NoSQL atamasining paydo bo'lishi

Hozirgi vaqtda NoSQL haqida gapirish juda mashhur. Bu katta hajmdagi ma'lumotlar, chiziqli kengayuvchanlik, klasterlar, ishonchlilik va norelatsionlikni ta'minlaydi. Lekin ko'pchilik uning nima ekanligini, qanday paydo bo'lganligini va qanday xususiyatlarga ega ekanligini tushunmaydi. Buni batafsil ko'rib chiqaylik.

90-yillarning oxirida NoSQL atamasi paydo bo'ldi. Lekin bu so'zning to'g'ri ma'nosi faqat 2009 yilda paydo bo'ldi. Ilgari NoSQL ASCII fayllar shaklida ma'lumotlarni saqlovchi va SQL o'rniga shell skriptlaridan foydalangan ochiq manbali ma'lumotlar bazasi edi. Lekin hozirda bu umuman boshqacha ishlatilmoqda.

2009 yilning iyunida San-Frantsiskoda Yoxan Oskarsson tomonidan uchrashuv o'tkazildi, unda ma'lumotlarni saqlash va ishlov berish bo'yicha IT bozoridagi yangi tendensiyalarni muhokama qilish rejalashtirilgan edi. Uchta uchrashuv uchun yorqin ism topish va unga Twitter hashtagini topish kerak edi. RackSpace kompaniyasidan Erik Evans "NoSQL" degan atamani taklif qildi. Ushbu atama faqat bitta uchrashuv uchun ishlatilgan, biroq, shunga qaramasdan, tezda butun dunyo bo'ylab tarqaldi va IT-industriyada butun bir yo'nalishning nomiga aylandi. Uchrashuvda Voldemort (Amazon Dynamo kloni), Cassandra, Hbase (Google BigTable analogi), Hypertable, CouchDB va MongoDB namoyish etildi.

Shuni ta'kidlash lozimki, "NoSQL" atamasi tabiiy ravishda paydo bo'ldi va ortda ilmiy institut yoki umumiy qabul qilingan ta'rif yo'q. Bu relatsion ma'lumotlar bazalaridan uzoqlashish yo'nalishini aks ettiradi. Not Only SQL degan tushuncha mavjud bo'lsa ham, No SQL deb to'g'ridan-to'g'ri tarjima qilish ham mumkin. Pramod Sadalaj va Martin Fauler "NoSQL Distilled" kitoblarida NoSQL olamidagi bilimlar tizimlashtirishga harakat qilishdi.

2.2 NoSQL ma'lumot bazalarining asosiy xususiyatlari

Hamma NoSQL tizimlari uchun umumiy xususiyatlar kam. NoSQL yorlig'i ostida ko'plab turli tizimlar (to'liq ro'yxat NoSQL Database da) yashirilgan. Ba'zi xususiyatlar faqat ma'lum NoSQL bazalariga xos - bu haqida ham to'xtalib o'taman.

1. SQL ishlatilmaydi

Biz ANSI SQL DML haqida gapiryapmiz, chunki ko'p ma'lumot bazalari tanish sintaksisga o'xshash query languages ishlatishga harakat qilishadi. Ammo hech kim uni to'liq amalga oshira olmadi. Mish-mishlarga ko'ra, SQL'ni amalga oshirishga urinishlar qilayotgan startaplar mavjud, masalan, Drawn To Scale va hadapt.

2. Tuzilmasiz (schemaless)

NoSQL bazalarida ma'lumotlar reglamentsiz (yoki zaif tiplangan) bo'ladi, relatsion ma'lumotlar tuzilmalaridan farqli o'laroq. Alohida qatorda yoki hujjatda har qanday maydonni qo'shishingiz mumkin, butun jadval strukturasini o'zgartirmasdan. Ma'lumotlar modelini o'zgartirish uchun aplikatsiya kodiga o'zgarish kiritish kifoya.

Misol uchun, MongoDB'da maydon nomini o'zgartirishda:

BasicDBObject order = new BasicDBObject();
order.put("date", orderDate); // bu maydon avvaldan bor edi
order.put("totalSum", total); // ilgari biz faqat "sum"ni ishlatardik

Agar aplikatsiyaning logikasini o'zgartirsak, o'qish jarayonida yangi maydon qo'shishimiz kerak. Ammo totalSum maydoni boshqa mavjud Order obyektlarida yo'q, shuning uchun keyingi harakatlar uchun ikki variant mavjud.

Birinchi variant — barcha mavjud hujjatlarda maydonni yangilash. Ammo ma'lumotlar ko'p bo'lgani uchun bu jarayon blokirovka qilinmasdan o'tadi, yangilash vaqtida ma'lumotlar boshqa jarayonlar tomonidan o'qilishi mumkin. Shuning uchun ikkinchi variant — aplikatsiya kodida tekshirish — ham zarur.

BasicDBObject order =new BasicDBObject();
Double totalSum = order.getDouble("sum"); // Bu eski model
if (totalSum  == null)
totalSum = order.getDouble("totalSum"); // Bu yangilangan model

Qachonki biz yozib chiqadigan bo'lsak, biz ushbu maydonni ma'lumotlar bazasiga yangi formatda yozamiz.

Sxemasizlik foyda keltiradi: biz siyrak ma'lumotlar bilan samarali ishlay olamiz. Masalan, bitta hujjatda date_published maydoni mavjud bo'lsa, boshqasida esa yo'q bo'lsa, ikkinchi uchun bo'sh date_published maydoni yaratilmaydi. Shuningdek, NoSQL ma'lumotlar bazalarida biz jadval/ustun tushunchalaridan foydalanamiz. Ammo sxemasizlik tufayli, ustunlar deklaratsion ravishda e'lon qilinmaydi va ish vaqtida o'zgartirilishi yoki qo'shilishi mumkin. Bu ro'yxatlar uchun dinamik ustunlarni ishlatishga imkon beradi.

Nostrukturaviy sxemalarning muammolari ham bor: ma'lumotlar modeli o'zgartirilganda qimmatli ortiqcha xarajatlar va ma'lumotlar bazasining cheklovlarining yo'qligi (masalan, not null, unique, check constraint va boshqalar), shuningdek, turli loyihalar ma'lumotlar bazalari bilan parallel ishlashda ma'lumotlar tuzilmasini tushunish va nazorat qilishdagi qiyinchiliklar (asosiy lug'atlarsiz). Shunga qaramay, mavjud dunyoda moslashuvchanlik afzallikdir. Masalan, Twitter besh yil avval tvitlar bo'yicha vaqt, Twitter handle va metama'lumotlar kabi qo'shimcha ma'lumotlarni saqlardi, hozirda esa bazada bir necha kilobayt ma'lumot saqlanmoqda.

2.3. Ma'lumotlarni aggregatlar shaklida ifodalash (aggregates)

Relyatsion modeldan farqli o'laroq, bu ilovaning mantiqiy biznes obyektini turli fizik jadvallar bo'ylab normallashtirish uchun bo'linadi, NoSQL saqlagichlar bu obyektlarni butun ob'ektlar sifatida ko'rib chiqadi.

Bu misolda biz e-commerce relyatsion modelining aggregatlarini ko'rsatamiz, buyurtma, buyurtma pozitsiyalari, to'lovlar va mahsulot. Buyurtma va pozitsiyalar bitta mantiqiy ob'ekt sifatida bog'langan. Har bir pozitsiya mahsulot haqida ma'lumot saqlaydi, masalan, nomini. Bu bizga buyurtmalarni chiqarishda mahsulot so'rovlari qilishdan qochish uchun kerak, bu ob'ektlar orasidagi "join"lar minimum qoidalariga muvofiq.

Ba'zi hollarda to'lovlar buyurtmaga kiritilgan, boshqalarda esa alohida. Bu NoSQL ma'lumotlar bazalarini loyihalashning asosiy qoidasi - ma'lumotlar ilova so'rovlariga mos kelishi va optimallashtirilgan bo'lishi kerak. Agar to'lovlar tez-tez buyurtma bilan birga chiqarilsa, ularni umumiy ob'ektga kiritish kerak. Agar ko'plab so'rovlar faqat to'lovlar bilan ishlasa, ularni alohida entitiy qilish yaxshiroqdir.

Ko'pchilik katta, ko'pincha denormalizatsiyalangan obyektlar bilan ishlash ma'lum muammolarga olib kelishini ta'kidlaydi, ayniqsa, so'rovlar aggregatlar tuzilmasiga mos kelmasa.

Masalan, biznes bizdan o'tgan oyda qancha maxsus mahsulot sotilganligini hisoblashni istasa, biz NoSQL saqlagichidan barcha buyurtmalarni chiqarishimiz kerak, garchi bizga aksariyat ma'lumotlar kerak bo'lmasa ham. Bu murosadir: biz odatda taqsimlangan tizimda ma'lumotlarni normallashtirolmaymiz, chunki bu juda sekin bo'ladi.

Har ikkala yondashuvning ijobiy va salbiy jihatlarini quyidagi jadvalda ko'rish mumkin: