NoSQL гэж юу вэ?

Сүүлийн үед NoSQL өгөгдлийн сангууд нилээн эрчимжих хандлага харагдаж байна. Гэхдээ өгөгдлийн сангийн нийт хэрэглээний 1% хувийг ч эзлэх эсэх нь эргэлзээтэй л дээ. RDBMS нь өгөгдлийг хүснэгт зохион байгуулалттайгаар хадгалж, SQL хэл ашиглаад бичлэгүүдийг холбож ханддаг. Жишээ нь JOIN хийх, WHERE нөхцөл ашиглах гэх мэт. SQL хэл өгөгдлийг үнэхээр гарын дор болгож чаддаг боловч нэг асуудалтай - Scale хйих буюу өргөтгөхөд хэцүү байдаг. Нэг машин дээр байсан өгөгдлийн сангаа 2, 3 эсвэл 10 машин дээр ажиллуулах шаардлага гарвал яах бол? Ингэж ажиллуулах нь хэцүү. Ажиллуулж чадлаа гэхэд JOIN, WHERE гээд сүпер түлхүүр үгс маань удаан ажиллаж эхлэнэ.

Харин SQL-гүй өгөгдлийн сангуудын хувьд энэ асуудал хялбар шийдэгддэг. Ихэнх нь анхнаасаа тархмал, өргөтгөхөд хялбар байхыг тооцож хийгдсэн учраас. Гэвч NoSQL өөрийн сул талтай. Жишээ нь, SQL-гүйгээр өгөгдлийн сан ашиглаад програм бичнэ гээд төсөөл дөө. Хачин санагдана, учир нь бид ямагт өгөгдлийг хүснэгт хэлбэрээр төсөөлөөд сурчихсанд байгаа юм. Ер нь ч ихэнх тохиолдолд мэдээлэл хүснэгт хэлбэрт байх нь ашиглахад амар байдгаас тэр. SQL-гүй програмыг зохиомжилно гэдэг системийг арай өөр өнцгөөс харахыг шаардана.

Зарим мэдээлэл заавал хүснэгт хэлбэрт байгаад, SQL ашиглаад байх шаардлагагүй ч байдаг. Чухам ийм л үед тэдгээрийг ашиглах нь зөв. Эсвэл системээ NoSQL өнцгөөс хараад шинээр зохиомжилж болох.

Эдгээрээс онцлогуудыг дурдвал:

  • Tokyo Cabinet - Маш хурдтай, тархаж ажиллах чадвартай, өргөн боломж бүхий key-value store юм. Түлхүүрээр нь ямар нэг мэдээллийг хадгалж, хандах бөгөөд мэдээлэлт нь ямар ч төрлийн өгөгдөл байж болно. Hash, B-Tree, Table гэсэн гурван төлөвт ажиллаж чаддаг. BerkeleyDB-тэй өрсөлдөхүйц key-value store гэхээр олон жилийн хөдөлмөр шингэсэн байхаас аргагүй. Японы Facebook болох Mixi санхүүжүүлдэг гэхээр тогтвортой гэдэг нь харагдана.
  • CouchDB - Бодит утгаараа concurrent байх боломжтой, учир нь Erlang дээр хийгдсэн. Мөн л key-value store боловч, value нь JSON төрөлтэй. REST интерфэйстэй учраас уян хатан. Бусдаасаа давуу тал нь нэг баазыг өөр тийш хуулах, хоёр баазыг синхрон хийхдээ маш гарамгай.
  • Cassandra - Анх Facebook хөгжүүлж эхлээд нээлттэй эх болгосон гэхээр юуг хийхэд бэлэн, нас бие гүйцсэн гэдэг нь баталгаатай. Хэд хэдэн давхар холбоост массиваас тогтоно. Tokyo Cabinet -ийн адилаар зүгээр key-value store байхаас гадна хүснэгт маягаар бүтэцлэж хадгалдаг. Олон машин дээр тархааж ажиллуулахаар зохиогдсон.
  • Redis - Tokyo Cabinet төстэй гэхдээ жагсаалт, олонлог гэсэн 2 төрлийн өгөгдлийн бүтцийг value тодроо хадгалах боломжтой. Ихэнх үйлдлийг санах ой дотор хийгээд диск руу байн байн хадгалдаг учраас маш хурдан, гэвч осолдож систем гэнэт зогсвол өгөгдөл алдагдах аюул бий. Тархсан байдлаар ажиллахад тийм сайн биш. Гэхдээ өгөгдлийн сан санах ойд багтах тохиолдолд эхний сонголт байж болох талтай.

Дээрхи жагсаалт нөлөө бүхий баазуудыг бүгдийг багтааж чадаагүй. Миний сонирхож амжсан баазууд л энэ юм.

Яг тохирох эсэхийг хэрэглэж байж л мэдэгддэг хойно, бодитоор хэрэглэж үзсэн хүн байвал сэтгэгдлээ хуваалцана гэдэгт найдаж байна.

Эх сурвалж: