Cassandra Archiтекстура и фактор на репликация
Редакционен екип
⚡ Умно обобщение
Cassandra Архитектурата разпределя данни между равностойни възли без единна точка на отказ, използвайки gossip за координация и репликация за издръжливост. Тази страница обхваща всеки компонент, както стратегии за репликация, така и нива на консистентност и вътрешни пътища за запис и четене.
Cassandra е проектиран да се справя Голямо количество от данни. CassandraОсновната характеристика на е да съхранява данни на множество възли без нито една точка на отказ.
Причината за този вид CassandraАрхитектурата на е, че хардуерната повреда може да възникне по всяко време. Всеки възел може да не работи. В случай на повреда могат да се използват данни, съхранени в друг възел. следователно Cassandra е проектиран със своята разпределена архитектура.
Cassandra съхранява данни на различни възли с peer to peer разпределена модна архитектура.
Всички възли обменят информация помежду си, използвайки Клюкарски протокол. Клюките са протокол в Cassandra чрез които възлите могат да комуникират помежду си.
Компоненти на Cassandra Archiтекстура
Има следните компоненти в Cassandra Archiтекстура:
Диаграмата по-горе влага компонентите: възлите се намират в център за данни, центровете за данни се намират в клъстер, а логът на комитите, memtable и SSTable се намират във всеки отделен възел.
Възел
Node е мястото, където се съхраняват данните. Той е основният компонент на Cassandra.
Център за данни
Колекция от възли се нарича център за данни. Много възли са категоризирани като център за данни.
Cluster
Клъстерът е сбор от много центрове за данни.
Дневник на ангажиментите
Всяка операция за запис се записва в регистъра на записите. Регистрационният файл на записването се използва за възстановяване при срив.
Мем-таблица
След данните, записани в регистрационния файл на Commit, данните се записват в Mem-table. Данните се записват временно в Mem-table.
SSTable
Когато Mem-table достигне определен праг, данните се записват в SSTable дисков файл. SSTable-ите са непроменяеми, така че актуализацията записва нова версия, вместо да редактира старата, а фонов процес, наречен уплътняване, по-късно обединява тези версии и изхвърля заменените редове.
Репликация на данни в Cassandra
Тъй като може да възникне хардуерен проблем или връзката да не работи по всяко време по време на обработката на данни, е необходимо решение за осигуряване на резервно копие, когато проблемът е възникнал. Така данните се репликират, за да се гарантира, че няма нито една точка на повреда.
Cassandra поставя реплики на данни на различни възли въз основа на тези два фактора.
- Къде да поставите следващата реплика се определя от Стратегия за репликация.
- Докато общият брой реплики, поставени на различни възли, се определя от Фактор на репликация.
Един фактор на репликация означава, че има само едно копие на данни, докато три фактора на репликация означава, че има три копия на данните на три различни възела.
За да се гарантира, че няма нито една точка на повреда, репликационният фактор трябва да бъде три.
Има два вида стратегии за репликация Cassandra.
SimpleStrategy в Cassandra
SimpleStrategy се използва, когато имате само един център за данни. SimpleStrategy поставя първата реплика на възела, избран от устройството за разделяне. След това останалите реплики се поставят по посока на часовниковата стрелка в пръстена на възела.
Ето графичното представяне на SimpleStrategy:
NetworkTopologyStrategy in Cassandra
Мрежова топологияСтратегия се използва, когато имате повече от два центъра за данни. В NetworkTopologyStrategy репликите се задават за всеки център за данни поотделно. NetworkTopologyStrategy поставя реплики по посока на часовниковата стрелка в пръстена, докато достигне първия възел в друг стелаж. Тази стратегия се опитва да постави реплики на различни стелажи в един и същ център за данни.
Това се дължи на причината, че понякога може да възникне повреда или проблем в стелажа. Тогава репликите на други възли могат да предоставят данни.
Ето графичното представяне на стратегията за мрежова топология:
Коефициентът на репликация определя колко копия съществуват. Колко от тези копия трябва да отговорят на дадена заявка е отделна настройка, описана по-долу.
Нива на съгласуваност в Cassandra
Нивото на съгласуваност се задава за всяка заявка, а не за клъстер, което прави Cassandra настройваем. Той посочва колко реплики трябва да потвърдят запис или да отговорят на четене, преди координаторът да отговори на клиента. Ниското ниво връща по-бързо; високото ниво връща данни, които са по-сигурно актуални.
| ниво | Поведение | Типична употреба |
|---|---|---|
| ONE | Една реплика трябва да отговори. | Високопроизводително регистриране, при което е приемливо от време на време четене на остарели данни. |
| КВОРУМ | По-голямата част от всички реплики трябва да отговорят, изчислено като (RF / 2) + 1. | Универсалният избор за балансирана последователност и наличност. |
| МЕСТЕН_КВОРУМ | По-голямата част от репликите в локалния център за данни трябва да отговорят. | Клъстери с множество центрове за данни, защото избягват латентност между регионите. |
| ALL | Всяка реплика трябва да отговори. | Рядко. Един възел надолу прави заявката напълно неуспешна. |
| ВСЯКО (само пише) | Подсказаното предаване се счита за успех, дори ако няма достъпна реплика. | Максимална наличност на запис, където издръжливостта може да бъде намалена. |
Силна съгласуваност е гарантирана, когато нивото на четене плюс нивото на запис надвишава коефициента на репликация. При коефициент на репликация три, записът при QUORUM и четенето при QUORUM удовлетворяват това правило, защото две плюс две е по-голямо от три. Записът при ЕДИНСТВО и четенето при ЕДИНСТВО не удовлетворяват и следователно четенето може да върне по-стара стойност.
Когато реплика е недостъпна, координаторът съхранява намек и го възпроизвежда, след като възелът се върне, което е начинът, по който нивото ANY и голяма част от Cassandraсамолечебното поведение работи.
Пиша Operaция в Cassandra
Координаторът изпраща заявка за запис до репликите. Ако всички реплики са готови, те ще получат заявка за запис, независимо от нивото им на съгласуваност.
Ниво на консистенция определя колко възли ще отговорят с потвърждение за успех.
Възелът ще отговори с потвърждението за успех, ако данните са записани успешно в дневника на ангажиментите и memTable.
Например, в един център за данни с коефициент на репликация, равен на три, три реплики ще получат заявка за запис. Ако нивото на съгласуваност е едно, само една реплика ще отговори с потвърждение за успех, а останалите две ще останат неактивни.
Да предположим, че ако останалите две реплики загубят данни поради прекъсване на възела или някакъв друг проблем, Cassandra ще направи реда последователен чрез вградения механизъм за поправка Cassandra.
Тук е обяснено как протича процесът на запис Cassandra,
- Когато заявката за запис дойде до възела, първо се записва в дневника на записите.
- След това Cassandra записва данните в таблицата mem. Данните, записани в mem-таблицата при всяка заявка за запис, също се записват отделно в дневника на записите. Mem-table е временно съхранена информация в паметта, докато Commit log регистрира записите на транзакциите за целите на архивирането.
- Когато mem-table е пълна, данните се изхвърлят във файла с данни SSTable.
Тъй като SSTables никога не се редактират на място, изтриването не премахва реда веднага. Вместо това се използва маркер, наречен надгробен камък се записва и редът изчезва само когато уплътняването се изпълни след гратисния период. Ето защо големите натоварвания с изтриване забавят четенето, докато уплътняването не навакса.
Чети Operaция в Cassandra
Има три вида заявки за четене, които координаторът изпраща до репликите.
- Директна заявка
- Заявка за обобщение
- Прочетете заявката за ремонт
Координаторът изпраща директна заявка до една от репликите. След това координаторът изпраща заявката за обобщение до броя реплики, определени от нивото на съгласуваност, и проверява дали върнатите данни са актуализирани данни.
След това координаторът изпраща заявка за обобщение до всички останали реплики. Ако някой възел даде остаряла стойност, заявка за възстановяване на фоново четене ще актуализира тези данни. Този процес се нарича механизъм за възстановяване на четене.
Вътре в репликата, която получава директната заявка, редът на търсене е проектиран така, че да се избягва докосване на диск, където е възможно.
- - таблица с памет се проверява първо, тъй като най-новите записи все още не са изчистени.
- - кеш на редове, ако е активирано, може да отговори на цялата заявка без допълнителна работа.
- A филтър за блум се консултира за всяка SSTable. Отговаря „определено не е налично“ или „вероятно е налично“, което позволява повечето SSTables да бъдат пропуснати без да бъдат прочетени.
- - индекс на дял и неговото обобщение локализира точното байтово отместване във всяка SSTable, която оцелява след проверката на филтъра на Блум.
- Съвпадащите фрагменти от няколко SSTables се обединяват, като най-скорошният времеви отпечатък е предимство за всяка колона.
Филтърът на Блум е стъпката, която поддържа четенето бързо с нарастването на данните, защото премахва почти всяка SSTable от разглеждане, преди да се извърши търсене на диск. Прилагането на тези механики на няколко машини е разгледано в Cassandra група настойнически.
