Въведение в модела на данните в Касандра
Apache Cassandra се превърна в една от най-мощните бази данни NoSQL. Това е правилният избор, когато искате висока наличност и мащабируемост, без да правите компромиси с производителността, особено за приложения, които не могат да си позволят да губят данни. В тази тема ще научим за модела на данни в Касандра.
Бърз факт, инженерите на Касандра са сред най-високоплатените технологични специалисти днес. Компании като Netflix, Instagram и Apple използват Cassandra, за да осигурят силно индивидуализирано клиентско изживяване. За да постигнете правилната производителност, трябва внимателно да проектирате схемата, специфична за бизнес проблема. В тази статия ще разгледаме модела на данни на Касандра, който е значително различен от този, който виждаме в RDBMS.
Правила за модел на данни на Касандра
С прости думи, Моделът на данните е логическата структура на база данни. Той описва как се съхраняват и достъпват данни и връзките между различните типове данни.
Избирането на правилния модел на данни може да бъде най-трудната част от използването на база данни NoSQL като Cassandra. Както споменах по-рано, моделирането на данни в Касандра е различно от това, което виждаме в RDBMS.
Разделителният ключ и кластерният клавиш са условията, които всеки, който се занимава с Касандра, трябва да знае. Преди да се потопим в основните правила за моделиране на данни в Касандра, нека да разгледаме бързо какво означават тези термини,
дял
Cassandra е разпределена база данни, в която данните се разделят и съхраняват в различни възли в клъстер. Данните се разделят с помощта на дял ключ - който може да бъде едно или повече полета за данни. Този ключ на дяла се използва за създаване на хеширащ механизъм за равномерно разпространение на данни във всички възли.
струпване
Клъстерът е съвкупност от възли, които представляват единна логическа база данни. Кластеризиращият ключ се състои от едно или повече полета, които се използват за групиране на данни в дял.
В тази ресторанта на таблицата данните ще бъдат разделени с помощта на код на държава, име на държава и име на град, а в рамките на тази информация за дяла ще бъдат групирани и сортирани въз основа на отваряне на данни и име на ресторант.
Сега, нека разгледаме двете правила за моделиране на данни, които трябва да се имат предвид.
- Данните се разпределят равномерно в целия клъстер
- Прочетете от възможно най-малко дялове
Нека да разгледаме какво се опитват да предадат тези правила
- Знаем какъв клъстер е правилен? Клъстерът се състои от множество възли. Искаме да разпределим данните между тези възли, така че всеки възел да има приблизително еднакво количество данни. Както знаем, данните се разделят на различни възли с помощта на хеш на разделителния ключ (който е първият ключ на Първичния ключ), така че накратко - „Трябва да изберете добър първичен ключ“.
- Всеки дял пребивава в различен възел, така че когато извличате данни, искате да сте сигурни, че данните са извлечени от възможно най-малко дялове. Ако вашето запитване изисква данни от различни дялове, ще бъде издадена команда за отделни възли, за да получите тези данни, които ще бъдат над главата и ще доведат до закъснение.
Ключът към ефективен модел на данни би бил баланс между тези две правила.
Справяне с отношенията в Касандра
Едно нещо, което трябва да се има предвид, е моделирането на данни в Касандра да се извършва с използване на заявка подход, за разлика от RDBMS, където първо идентифицирате единици, създавате таблици и след това формирате заявки, използвайки JOINS за извличане на данни.
Казано с прости думи, ние не моделираме около отношения или обекти, ние моделираме около заявки.
1. Връзка едно към едно
Помислете, че в университет студентът може да се регистрира само за един семинар. Това е връзка един към един. Спазвайки правило №1, мислим за исканията, които искаме. Искам да потърся семинара, който студент посещава. В този случай ще направим само една таблица. Таблицата трябва да съдържа подробности за студентите и подробности за семинара.
2. Връзка един към много
В същия контекст какво ще стане, ако искам да потърся всички студенти, посещаващи семинар. Вместо да използвам една и съща таблица и да повтарям над всеки ред, за да получа името на студента за този конкретен семинар, мога да направя друга таблица, която разделя данните по име на семинара. Така че, когато издавам заявката, тя удря само един възел, а не отива на всички възли, за да получи името на семинара.
3. Връзка много към много
Сега, нека помислим, един студент може да посети много семинари, а семинар може да присъства от много студенти. Тук имаме много до много отношения. В този случай можете да използвате горните две таблици, за да правите заявки, без да имате разходи за извършване на сложни заявки с помощта на Joins, които обикновено правите в RDBMS.
Значение на Касандра
С бързото разширяване на цифровите данни става все по-важно да има изградена високо мащабируема база данни, устойчива на откази. Нека изброя няколко точки за това, защо трябва да използвате Cassandra
- Операции за бързо четене: Обсъдихме как правилното моделиране на вашите данни може да оптимизира операциите за четене с масивен мащаб.
- Толерантни към откази: Данните се репликират през възли, така че дори и ако един възел слиза надолу, вашите данни са безопасни.
- Персонализирана настройка: Можете да настроите Cassandra да работи в зависимост от натовареността ви. Ако пишете много данни, като логване, можете да го ощипвате, за да боравите с тежки системи. Налични са няколко други опции за настройка.
- Справяне с големи обеми от данни: Въз основа на размера на клъстера, Касандра може да се справи с огромните обеми от данни.
Как да моделираме данните в Касандра?
Доброто моделиране на данни следва тези стъпки
- Концептуализирайте заявките, изисквани от вашата кандидатура
- Създаване на таблици за задоволяване на тези заявки
Преди да приложим тези правила, едно нещо, което трябва да се има предвид, е „Ние се фокусираме върху оптимизирането на нашите операции за четене, дори ако това изисква дублиране на данни“. Можем да имаме много таблици, които могат да съдържат почти подобни данни.
Сега, помислете, че искаме база данни, която съхранява информация за ресторантите. Нека поставим ограничение, че имената на ресторантите трябва да бъдат уникални.
Таблицата по-долу може да се използва, когато искаме да търсим въз основа на името на ресторанта:
Сега, ако искаме да потърсим ресторантите за определено място, бихме написали заявка, която се повтаря през всички редове и извлича имената на ресторантите.
Вместо това, имайки предвид правило №2, лесно можем да създадем друга таблица, която да обслужва нуждите ни.
Сега нашите данни ще бъдат разделени по начин, че възел в клъстера да има ресторанти за определено място. Това ще оптимизира нашите заявки за четене, тъй като търсенето на заявки ще се случи само на един възел с много по-малко редове от първата таблица, която създадохме.
Ами ако искахме да търсим ресторанти в определен град, можем да направим друга таблица, а не да повтаряме през всички редове в един дял на горната таблица.
заключение
В тази статия разгледах няколко най-добри практики, които можете да следвате, как да подходите към моделиране на данни в Касандра. Ако разбирате тези понятия и можете ефективно да разпознаете вида на заявките, от които се нуждае вашето приложение, можете да създадете страхотен модел на данни, за да получите висока производителност от вашата база данни.
Препоръчителни статии
Това е ръководство за Модел на данни в Касандра. Тук обсъждаме как да моделираме нашите данни в Касандра, заедно с правилата и значението на моделите данни на Касандра. Можете да разгледате и другите ни предложени статии, за да научите повече -
- Какво е моделиране на данни?
- Модели на данни в СУБД
- Въпроси за интервю за моделиране на данни
- Касандра моделиране на данни