CodeGym /Java курс /All lectures for BG purposes /Апач Касандра

Апач Касандра

All lectures for BG purposes
Ниво , Урок
На разположение

4.1 Описание

Apache Cassandra е система за управление на разпределена база данни, която принадлежи към класа на NoSQL системите и е предназначена да създава високо мащабируеми и надеждни хранorща на огромни масиви от данни, представени под формата на хеш.

Първоначално проектът е разработен в недрата на Facebook и през 2009 г. прехвърлен под крилото на Apache Software Foundation, тази организация продължава да развива проекта. Индустриалните решения, базирани на Cassandra, се внедряват, за да предоставят услуги на компании като Cisco, IBM, Cloudkick, Reddit, Digg, Rackspace, Huawei, Netflix, Apple, Instagram, GitHub, Twitter и Spotify. До 2011 г. най-големият сървърен клъстер, обслужващ една база данни под Cassandra, имаше повече от 400 машини и съдържаше повече от 300 TB данни.

Написан на езика Java , той прилага разпределена хеш система, подобна на DynamoDB, която осигурява почти линейна мащабируемост с увеличаване на обема на данните. Той използва модел за съхранение на данни, базиран на семейство колони, което се различава от системи като MemcacheDB, които съхраняват данни само в двойка ключ-стойност, по способността да съхранява хешове с няколко нива на влагане.

Принадлежи към категорията на устойчиви на грешки СУБД: данните, поставени в базата данни, се репликират автоматично в няколко възела на разпределена мрежа or дори равномерно разпределени в няколко центъра за данни. Когато даден възел се повреди, неговите функции се подхващат в движение от други възли, добавянето на нови възли към клъстера и актуализирането на versionта на Cassandra се извършва в движение, без допълнителна ръчна намеса и преконфигуриране на други възли.

Силно се препоръчва обаче повторно генериране на ключове (етикети) за всеки възел, включително съществуващите, за да се запази качеството на балансиране на натоварването. Генерирането на ключ за съществуващи възли може да бъде избегнато в случай на многократно увеличаване на броя на възлите (2 пъти, 3 пъти и т.н.).

4.2 Модел на данни

В терминологията на Cassandra приложението работи с ключово пространство, което съответства на концепцията за схема на база данни в релационния модел. Това ключово пространство може да съдържа няколко семейства колони, което съответства на концепцията за релационна table.

На свой ред фамorите колони съдържат колони (колона), които се комбинират с помощта на ключа (ключ ред) в записа (ред). Колоната се състои от три части: име (име на колона), клеймо за време (timestamp) и стойност (стойност). Колоните в записа са подредени. За разлика от релационна база данни, няма ограничения за това дали записите (а по отношение на базата данни това са редове) съдържат колони със същите имена като в другите записи - не.

Семействата колони могат да бъдат няколко вида, но в тази статия ще пропуснем тази подробност. Също така в най-новите версии на Cassandra стана възможно да се изпълняват заявки за дефиниране и промяна на данни (DDL, DML) с помощта на езика CQL, Howто и създаване на вторични индекси.

Конкретната стойност, съхранявана в cassandra, се идентифицира от:

  • keyspace е обвързване към приложението (домейн). Позволява ви да хоствате данни от различни applications в един и същи клъстер;
  • семейство колони е обвързване към заявка;
  • ключ е обвързване към клъстерен възел. Ключът определя на кои възли ще попаднат запазените колони;
  • името на колоната е обвързване към атрибут в записа. Позволява ви да съхранявате множество стойности в един запис.

Всяка стойност е свързана с клеймо за време, определено от потребителя число, което се използва за разрешаване на конфликти по време на запис: колкото по-голямо е числото, по-новата колона се взема предвид и при сравняване презаписва старите колони.

4.3 Типове данни

По типове данни: keyspace и column family са низове (имена); timestamp е 64-битово число; и ключът, името на колоната и стойността на колоната е масив от byteове. Cassandra също има концепцията за типове данни. Тези типове могат да бъдат посочени (по избор) от разработчика при създаване на семейство колони.

За имена на колони това се нарича компаратор, за стойности и ключове се нарича валидатор. Първият определя Howви стойности на byteовете са разрешени за имена на колони и How да ги подредите. Второто е кои стойности на byte са валидни за стойностите на колона и ключ.

Ако тези типове данни не са зададени, тогава cassandra съхранява стойностите и ги сравнява като byteови низове (BytesType), тъй като всъщност те се съхраняват вътрешно.

Типовете данни са:

  • BytesType : всяHowви byteови низове (без проверка)
  • AsciiType : ASCII низ
  • UTF8Type : UTF-8 низ
  • IntegerType : число с произволен размер
  • Int32Type : 4-byteово число
  • LongType : 8-byteово число
  • UUIDType : UUID тип 1 or 4
  • TimeUUIDType : Тип 1 UUID
  • DateType : 8-byteова стойност на клеймото за време
  • BooleanType : две стойности: true = 1 or false = 0
  • FloatType : 4-byteово число с плаваща запетая
  • DoubleType : 8-byteово число с плаваща запетая
  • DecimalType : число с произволен размер и плаваща запетая
  • CounterColumnType : 8 byteов брояч

В cassandra всички операции за писане на данни винаги са операции за пренаписване, т.е. ако колона със същия ключ и име, които вече съществуват, дойде в семейството на колоните и клеймото за време е по-голямо от това, което е запазено, тогава стойността се презаписва . Записаните стойности никога не се променят, просто идват по-нови колони с нови стойности.

Писането в cassandra е по-бързо от четенето. Това променя подхода, възприет в дизайна. Ако разгледаме cassandra от гледна точка на проектиране на модел на данни, тогава е по-лесно да си представим семейство колони не като table, а като материализиран изглед - структура, която представя данните на няHowва сложна заявка, но ги съхранява на диск.

Вместо да се опитвате да композирате данни по няHowъв начин с помощта на заявки, по-добре е да опитате да съхраните всичко, което може да е необходимо за тази заявка в целевото семейство. Тоест, необходимо е да се подходи не от страна на връзките между обекти or връзки между обекти, а от страната на заявките: кои полета трябва да бъдат избрани; в Howъв ред трябва да вървят записите; Howви данни, свързани с основните, трябва да бъдат поискани заедно - всичко това вече трябва да се съхранява в семейството на колоните.

Броят на колоните в запис теоретично е ограничен до 2 мorарда. Това е кратко отклонение, а повече подробности можете да намерите в статията за техниките за проектиране и оптимизация. А сега нека се задълбочим в процеса на запазване на данни в cassandra и четенето им.

Коментари
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION