Реляциялық ДҚБЖ 30 жылдан астам уақыт бойы жетекші орында болды, бірақ бұл реляциялық деректер схемалары (немесе NoSQL сияқты дерекқорлар) жоқ дерекқорлардың танымалдылығына байланысты өзгеруі мүмкін. RDBMS дәстүрлі клиент-сервер архитектурасы бар жүйелерде сенімді деректерді сақтауды қамтамасыз етеді, өкінішке орай, жаңа есептеу түйіндерін қосу арқылы масштабтау әрқашан оңай және арзан емес. Бұл Facebook және Twitter сияқты веб-қосымшалар дәуірінде өте маңызды шектеуге айналады, мұнда жақсы масштабтау маңызды.
Масштабтау мәселесі реляциялық дерекқорларға ерте баламалармен шешілмеді (объектіге бағытталған дерекқорлар есіңізде ме?). Керісінше, Bigtable және SimpleDB (сәйкесінше Google және Amazon) сияқты NoSQL ДҚБЖ жоғары масштабталатын веб-қосымшалар үшін арнайы жасалған. NoSQL Web 2.0 дамыған сайын маңыздырақ болатын маңызды масштабтау мәселесінің шешімі болуы мүмкін.
Java Development Wave 2 сериясындағы бұл мақала сызбасыз дерекқорды жобалауға кіріспе береді, бұл бұрын NoSQL-ге көшу кезінде реляциялық дерекқорлармен жұмыс істеген әзірлеушілер үшін негізгі қиындықтардың бірі болып табылады. Сіз бұл процесте ең маңыздысы реляциялық модель емес, домен үлгісімен жобалауды бастау екенін көресіз. Bigtable бағдарламасымен жұмыс істегенде (төмендегі мысалдардағыдай) сіз Google App Engine платформасының мүмкіндіктерін кеңейтетін жеңіл құрылым Gaelyk көмегіне сене аласыз.
NoSQL: Бізге әлемге жаңа көзқарас керек пе?
Реляциялық емес дерекқорлар туралы айтқанда, көптеген әзірлеушілер алдымен өздерінің ой-өрісін өзгерту қажеттілігін атап өтеді. Дегенмен, менің ойымша, бұл олардың деректер үлгілерін жасаудағы сүйікті тәсіліне байланысты. Қолданбаларды әзірлеуді дерекқор құрылымын жасау арқылы, атап айтқанда, кестелер мен олардың арасындағы қатынастарды сипаттау арқылы бастауға дағдыланған болсаңыз, реляциялық емес деректер қоймасын жобалау, мысалы, Bigtable негізінде, жалпы көзқарасыңызды өзгертуді талап етеді. Егер сіз әдетте домендік модельдеу арқылы қолданбаларды құруды бастасаңыз, Bigtable бағдарламасының реляциялық емес құрылымы табиғирақ көрінуі керек.
Ауқымдылық олардың қанында бар
Жоғары масштабталатын веб-қосымшалардың қажеттіліктерінен туындаған қиындықтар жаңа шешімдерге әкелді. Атап айтқанда, Facebook ақпаратты сақтау үшін реляциялық деректер базасына сене алмайды. Оның орнына ол кілт-мән жұптарының қоймасын пайдаланады, яғни. шын мәнінде — өнімділігі жоғары хэш кестесі. Оған негізделген шешім (Кассандра жобасы) қазіргі уақытта Twitter және Digg компанияларында да қолданылады және жақында Apache бағдарламалық қамтамасыз ету қорына сыйға тартылды. Өсуі деректерді сақтаудың балама тәсілдерін қажет ететін компанияның тағы бір мысалы — Bigtable технологиясын жасаған Google.
Реляциялық емес дерекқорлар кесте біріктірулерін, негізгі немесе қосымша кілттерді пайдаланбайды (кілттер бар, бірақ қатаң емес пішінде). Осылайша, сіз NoSQL дерекқоры үшін деректер үлгісін жасау кезінде реляциялық модельдеуді қолдануға тырысқанда қатты ренжілесіз. Пән аймағын сипаттаудан бастау әлдеқайда оңай. Сонымен қатар, мен домен үлгісінің негізінде жатқан реляциялық емес дерекқор құрылымының икемділігін жеке өзім ұнатамын.
Осылайша, реляциялық емес деректер үлгісіне көшудің қиындығы қолданбаларды жобалауға деген көзқарасыңызға байланысты, атап айтқанда: реляциялық схемадан немесе тақырыптық аймақтың сипаттамасынан бастайсыз ба. CouchDB немесе Bigtable сияқты ДҚБЖ пайдалануды бастағанда, Hibernate сияқты ыңғайлы сақтау жүйелерімен қоштасуға тура келеді. Екінші жағынан, сіздің қажеттіліктеріңіз үшін мұндай технологияны өз бетіңізше жасауға кең мүмкіндіктер болады. Ал оны құру барысында сіз NoSQL деректер қорының қыр-сырымен танысасыз.
Басында
Субъектілер мен қатынастар
Реляциялық емес ДҚБЖ домен үлгісін Gaelyk сияқты заманауи шешімдермен жеңілдетілген мүмкіндіктер жиынтығы ретінде жасауға мүмкіндік береді. Келесі кезеңде жасалған модельді дерекқор құрылымымен салыстыру керек, бұл Google App Engine пайдалану жағдайында қиын емес.
Бұрын Google App Engine қолданбаларындағы Gaelyk Framework мақаласында сіз Google деректер қоймасымен жұмыс істеуді жеңілдететін Gaelyk, Groovy кітапханасымен таныстыңыз. Бұл мақалада Google-дағы Entity нысанына көп көңіл бөлінеді. 1-тізімде Gaelyk тіліндегі нысандармен жұмыс істеуді көрсететін алдыңғы мақаланың мысалы көрсетілген.
Листинг 1. Entity арқылы нысанды дерекқорға сақтау
def ticket = жаңа ұйым («билет»)
билет.офицер = парамс.офицер
ticket.license = params.plate
ticket.issuseDate = құқық бұзушылық күні
ticket.location = params.location
ticket.notes = params.notes
ticket.offense = params.offense
Объектінің дизайны
Реляциялық дерекқор дизайнына қарағанда нысанға артықшылық Grails және Ruby on Rails сияқты заманауи қолданбалы құрылымдарда айқын көрінеді. Бұл платформалар деректер базасының физикалық схемасын генерациялауды қабылдай отырып, модельді құруға ерекше көңіл бөледі.
Деректерді сақтаудың бұл тәсілі өте қолайлы, бірақ билеттермен қарқынды жұмыс істегенде, мысалы, оларды жасау немесе әртүрлі сервлеттерде іздеу қажет болса, оның қиын болатынын байқау оңай. Бұл тапсырманың бір бөлігін жалпы сервлет (немесе groovelet) пайдалану арқылы жеңілдетуге болады, бірақ одан да қисынды шешім бар — Ticket нысанын жасау. Ол төменде талқыланады.
Басында
Жарыстар
Бірінші Gaelyk мақаласындағы хабарландыру үлгісіне оралудың орнына, біз осы мақалада талқыланған әдістерді суреттейтін жаңа қосымшаны қарастырамыз. Ол жарыстар және олардың қатысушылары туралы деректерді өңдейді және 1-суреттегідей, бір стартта (Жарыс) бірнеше спортшы (Жүгіруші) қатысады және бір спортшы көптеген старттарға қатысушы бола алады.
Сурет 1. Жарыстар және олардың қатысушылары
Бұл қатынастарды реляциялық дерекқорда модельдеу кезінде бізге үш кесте қажет болады — үшінші кесте жарыстар мен қатысушыларды көптен көпке байланыстыру үшін қызмет етеді. Бақытымызға орай, біз мұны істеудің қажеті жоқ. Оның орнына, біз бұл модельді Google App Engine платформасы ұсынған Bigtable құрылымымен салыстыру үшін Groovy ішіндегі Gaelyk қолданбасын қолданамыз. Gaelyk ассоциативті кестелер (карта) сияқты нысандармен жұмыс істеуге мүмкіндік беретіндіктен, біздің міндетіміз айтарлықтай жеңілдетілген.
Масштабтау және сынықтар
Sharding – кестелер қайталанатын және ақпарат есептеу түйіндері арасында логикалық түрде таратылатын дерекқорды декомпозициялау нұсқасы. Мысалы, бір сайт Америка Құрама Штаттарындағы барлық пайдаланушы тіркелгілері үшін деректерді сақтай алады, ал екіншісі еуропалық пайдаланушылар үшін деректерді сақтай алады. Бөлінудің күрделілігі әртүрлі түйіндерде орналастырылған деректер арасындағы сілтемелердің болуына байланысты. Бұл кейбір жағдайларда шешілмейтін күрделі және күрделі мәселе (Google-дан Макс Росспен (Макс Росс) бөлісу және реляциялық дерекқорды масштабтау күрделілігі туралы менің пікірталасымның сілтемесі үшін Ресурстарды қараңыз).
Реляциялық емес деректер үлгілері туралы тамаша нәрселердің бірі — барлық мәліметтерді алдын ала ойластырудың қажеті жоқ — кейінгі өзгертулерді реляциялық схемаға қарағанда әлдеқайда жеңілдетуге болады. Мен реляциялық схеманы өзгерту мүмкін емес дегенді білдірмейтінімді ескеріңіз. Бұл, әрине, мүмкін, бірақ схема болмаған кезде тапсырма жеңілдетілген. Осы уақытта біз домен нысандарының қасиеттерін сипаттамаймыз — динамикалық Groovy тілі оларға қамқорлық жасайды (атап айтқанда, ол Entity-мен жұмыс істегенде объектілерді прокси ретінде пайдалануға мүмкіндік береді). Оның орнына біз дерекқордағы нысандарды және олардың арасындағы қатынасты табу сценарийлерін қарастырамыз. Қазіргі уақытта NoSQL ДҚБЖ және әртүрлі фреймворктар мұндай функционалдылықты жүзеге асыру үшін кірістірілген мүмкіндіктерді қамтамасыз етпейді.
Негізгі класс моделі
Біз нысандары Entity даналарын сақтайтын негізгі класс жасаудан бастаймыз. Оның еншілес сыныптарында Groovy ыңғайлы setProperty әдісі арқылы сәйкес Entity данасына қосылатын динамикалық сипаттар жиыны болуы керек. Бұл әдіс белгіленген әдіс жоқ әрбір сипаттың мәнін орнату кезінде шақырылады (бұл біртүрлі болып көрінуі мүмкін, бірақ алаңдамаңыз — бәрі жақын арада өз орнына келеді).
Листинг 2 демонстрациялық қолданбаның Үлгі класының бірінші нұсқасын көрсетеді.
