{"id":41081,"date":"2020-02-05T21:30:11","date_gmt":"2020-02-05T18:30:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle"},"modified":"2020-02-05T21:30:11","modified_gmt":"2020-02-05T18:30:11","slug":"cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle","title":{"rendered":"Cassandra. Hvordan man ikke d\u00f8r, hvis man kun kender Oracle","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej, Habr.<\/p>\n

Jeg hedder Misha Butrimov, og jeg vil gerne fort\u00e6lle lidt om Cassandra. Min fort\u00e6lling vil v\u00e6re nyttig for dem, der aldrig har stiftet bekendtskab med NoSQL-databaser, da der er mange implementing kendetegn og faldgruber, man skal v\u00e6re opm\u00e6rksom p\u00e5. Og hvis du kun har set Oracle eller en hvilken som helst anden relationsdatabase, vil disse ting redde dit liv.<\/p>\n

Hvad er godt ved Cassandra? Det er en NoSQL-database, designet uden et enkelt fejlpunk, som skalerer godt. Hvis du har brug for at tilf\u00f8je et par terabyte til en database, tilf\u00f8jer du simpelthen noder til ringen. Vil du udvide den til endnu et datacenter? Tilf\u00f8jer noder til klyngen. Vil du \u00f8ge den behandlede RPS? Tilf\u00f8jer noder til klyngen. Det fungerer ogs\u00e5 p\u00e5 den anden m\u00e5de. <\/p>\n

\"Cassandra.<\/a><\/noindex><\/p>\n

Hvad er den anden fordel? At kunne h\u00e5ndtere mange foresp\u00f8rgsler. Men mange \u2014 hvor mange er det? 10, 20, 30, 40 tusinde foresp\u00f8rgsler i sekundet \u2014 det er lidt. 100 tusinde foresp\u00f8rgsler i sekundet p\u00e5 skrivning \u2014 det er ogs\u00e5 lidt. Der er virksomheder, der siger, at de holder 2 millioner foresp\u00f8rgsler i sekundet. Det m\u00e5 man nok tro p\u00e5. <\/p>\n

Og grundl\u00e6ggende har Cassandra en stor forskel fra relationelle data \u2014 den ligner overhovedet ikke dem. Og det er meget vigtigt at huske.
\n<\/a><\/noindex><\/p>\n

Ikke alt, der ser ens ud, fungerer ens.<\/h2>\n

\nEn gang kom en kollega til mig og spurgte: \u201eHer er SQL Cassandra query language, og det har en select statement, der har where, og den har and. Jeg skriver bogstaver, og det fungerer ikke. Hvorfor?\u201c. Hvis man forholder sig til Cassandra som en relationsdatabase, er det den perfekte m\u00e5de at afslutte sit liv p\u00e5 en brutal m\u00e5de. Og jeg fremmer ikke det, det er forbudt i Rusland. Du vil bare designe noget forkert.<\/p>\n

For eksempel kommer en kunde til os og siger: \u201eLad os bygge en database til tv-serier, eller en database til en opskriftsguide. Vi vil have retter med ingredienser eller en liste over tv-serier og skuespillere i dem\u201c. Vi svarer gl\u00e6deligt: \u201eLad os g\u00f8re det!\u201c. Det er to bytes at sende, et par tabeller, og s\u00e5 er alt klar, det vil fungere meget hurtigt og p\u00e5lideligt. Og alt er perfekt, indtil kunderne kommer og siger, at husholdningerne ogs\u00e5 l\u00f8ser den omvendte opgave: de har en liste over ingredienser, og de vil vide, hvilken ret de \u00f8nsker at lave. Du er f\u00e6rdig.<\/p>\n

Altogether, it is because Cassandra is a hybrid database: it acts as both a key-value store and stores data in wide columns. In Java or Kotlin terms, it could be described like this:<\/p>\n

Map<RowKey, SortedMap><\/code><\/p>\n

This means a map that contains another sorted map inside. The first key to this map is the Row key or Partition key \u2014 the partitioning key. The second key, which is the key to the already sorted map, is the Clustering key.<\/p>\n

To illustrate the distributed nature of the database, let's draw three nodes. Now we need to understand how to distribute the data across the nodes. Because if we shove everything into one (and there can be a thousand, two thousand, five \u2014 as many as you want), that doesn't really represent distribution. So we need a mathematical function that returns a number. Just a number, a long int, that will fall within some range. One node will be responsible for one range, the second for another, the n-th for the n-th. <\/p>\n

\"Cassandra.
\n
\nThis number is obtained using a hash function, which is applied precisely to what we call the Partition key. This is the column specified in the Primary key directive, and this is the column that will be the primary and most significant key of the map. It determines which data will go to which node. A table in Cassandra is created almost with the same syntax as in SQL: <\/p>\n

CREATE TABLE users (\n\tuser_id uuid,\n\tname text,\n\tyear int,\n\tsalary float,\n\tPRIMARY KEY(user_id)\n\n)\n<\/code><\/pre>\n
In this case, the Primary key consists of a single column, which is also the partitioning key.<\/p>\n
How will our users be arranged? Some will go to one node, some to another, and some to the third. This results in a regular hash table, also known as a map, or in Python \u2014 a dictionary, or a simple key-value structure from which we can read all values, read and write by key.<\/p>\n
\"Cassandra.
\n<\/p>\n
Select: when allow filtering turns into a full scan, or how not to do it<\/h2>\n
\nLet's write some select statement: select * from users where userid = <\/code>. Det virker n\u00e6sten som i Oracle: vi skriver select, angiver betingelserne, og alt fungerer, brugerne hentes. Men hvis vi v\u00e6lger en bruger med et bestemt f\u00f8dsels\u00e5r, klager Cassandra over, at den ikke kan udf\u00f8re foresp\u00f8rgslen. Fordi den overhovedet ikke ved noget om, hvordan vores data om f\u00f8dsels\u00e5r er fordelt - den har kun \u00e9n kolonne angivet som n\u00f8gle. S\u00e5 siger den: \u00abOkay, jeg kan stadig udf\u00f8re denne foresp\u00f8rgsel. Tilf\u00f8j allow filtering\u00bb. Vi tilf\u00f8jer direktivet, alt fungerer. Og p\u00e5 dette tidspunkt sker der noget skr\u00e6mmende. <\/p>\n
N\u00e5r vi k\u00f8rer p\u00e5 testdata, fungerer alt perfekt. Men n\u00e5r du udf\u00f8rer en foresp\u00f8rgsel i produktionen, hvor vi har for eksempel 4 millioner poster, s\u00e5 fungerer det ikke s\u00e5 godt. Fordi allow filtering - det er et direktiv, der tillader Cassandra at samle alle data fra denne tabel fra alle noder, alle datacentre<\/a> (hvis der er mange i denne klynge), og kun derefter filtrere. Det er analogt med en Full Scan, og n\u00e6ppe nogen er begejstrede for det. <\/p>\n
Hvis vi kun havde brug for brugere efter identifikatorer, ville det v\u00e6re acceptabelt. Men nogle gange skal vi skrive andre foresp\u00f8rgsler og p\u00e5l\u00e6gge andre begr\u00e6nsninger p\u00e5 udv\u00e6lgelsen. S\u00e5 vi husker: dette er alle vores mappe, som har en partitioneringsn\u00f8gle, men inde i den - en sorteret mappe. <\/p>\n
Og den har ogs\u00e5 en n\u00f8gle, som vi kalder Clustering Key. Denne n\u00f8gle best\u00e5r af de kolonner, vi v\u00e6lger, som g\u00f8r det muligt for Cassandra at forst\u00e5, hvordan dens data fysisk skal sorteres og opbevares p\u00e5 hver node. Det vil sige, for en bestemt Partition key vil Clustering key fort\u00e6lle, hvordan dataene skal placeres i dette tr\u00e6, hvilket plads de vil tage.<\/p>\n
Det er et rigtigt tr\u00e6, der bare kalder en komparator, hvor vi sender et s\u00e6t kolonner som et objekt, og det angives ogs\u00e5 som et opregnet s\u00e6t kolonner. <\/p>\n
CREATE TABLE users_by_year_salary_id (\n\tuser_id uuid,\n\tname text,\n\tyear int,\n\tsalary float,\n\tPRIMARY KEY((year), salary, user_id)\n<\/code><\/pre>\n
V\u00e6r opm\u00e6rksom p\u00e5 direktivet Primary key, hvor den f\u00f8rste parameter (i vores tilf\u00e6lde \u00e5ret) altid er partition key. Den kan best\u00e5 af en eller flere kolonner; det er ikke vigtigt. Hvis der er flere kolonner, skal de placeres i parentes for at preprocessoren for sproget kan forst\u00e5, at dette er Primary key, efterfulgt af de \u00f8vrige kolonner \u2014 Clustering key. Disse vil s\u00e5ledes bliver sendt i comparator i den r\u00e6kkef\u00f8lge, de optr\u00e6der. Det vil sige, at den f\u00f8rste kolonne er mere betydningsfuld, den anden mindre betydningsfuld osv. Ligesom vi for data classes skriver, for eksempel, felterne equals: vi angiver felterne og pr\u00e6ciserer, hvilke der er st\u00f8rre, og hvilke der er mindre. I Cassandra er dette, betinget set, felterne i data class, som den skrevne equals vil blive anvendt p\u00e5.<\/p>\n
Vi angiver sortering og p\u00e5l\u00e6gger betingelser.<\/h2>\n
\nDet er vigtigt at huske, at sorteringsr\u00e6kkef\u00f8lgen (faldende, stigende, ligegyldigt) angives p\u00e5 samme tid som n\u00f8glen oprettes, og det kan ikke \u00e6ndres senere. Dette bestemmer fysisk, hvordan data vil blive sorteret og hvordan de vil v\u00e6re opdelt. Hvis det bliver n\u00f8dvendigt at \u00e6ndre Clustering key eller sorteringsr\u00e6kkef\u00f8lge, skal der oprettes en ny tabel og data skal overf\u00f8res til denne. Det vil ikke kunne g\u00f8res med en allerede eksisterende.<\/p>\n
\"Cassandra.
\n
\nVi har fyldt vores tabel med brugere og set, at de ligger i en ring f\u00f8rst efter f\u00f8dsels\u00e5r, og derefter inden for hver node efter l\u00f8n og bruger-ID. Nu kan vi v\u00e6lge, mens vi p\u00e5l\u00e6gger betingelser. <\/p>\n
Vores fungerende hvor, og<\/code>, og vi f\u00e5r brugerne, og alt er godt igen. Men hvis vi pr\u00f8ver at bruge kun en del af Clustering key, som er mindre betydningsfuld, vil Cassandra straks brokke sig og sige, at den ikke kan finde stedet i vores map, hvor den objekt, der har disse felter for comparator null, og denne, som lige er blevet angivet, \u2014 hvor den ligger. Jeg bliver n\u00f8dt til igen at hente alle data fra denne node og filtrere dem. Og dette svarer til en Full Scan inden for noden, hvilket er d\u00e5rligt.<\/p>\n
I enhver uklar situation, opret en ny tabel.<\/h2>\n
\nHvis vi \u00f8nsker at kunne hente brugere efter ID, alder eller l\u00f8n, hvad g\u00f8r vi s\u00e5? Intet. Bare brug to tabeller. Hvis vi skal kunne hente brugere p\u00e5 tre forskellige m\u00e5der, bliver der tre tabeller. De dage, hvor vi sparem\u00e6ssigt vurderede plads p\u00e5 harddisken, er ovre. Det er den billigste ressource. Det koster meget mindre end svartiden, som kan v\u00e6re skadelig for brugeren. Det er meget mere behageligt for brugeren at f\u00e5 noget p\u00e5 et sekund end p\u00e5 10 minutter.<\/p>\n
Vi bytter det overskydende optagede plads, den denormaliserede data for muligheden for godt at skalere og arbejde p\u00e5lideligt. For i virkeligheden kan et cluster best\u00e5ende af tre datacentre, hvoraf hver har fem noder, ved acceptabel databevaringsniveau (n\u00e5r der bestemt ikke g\u00e5r noget tabt), overleve \u00f8del\u00e6ggelsen af et datacenter helt. Og derudover to noder i hver af de to resterende. F\u00f8rst herefter vil der opst\u00e5 problemer. Det er en ret god reservel\u00f8sning, som koster et par ekstra SSD-drev og processorer. Derfor, for at kunne bruge Cassandra, som ikke er SQL, der ikke har relationer eller fremmedn\u00f8gler, er det n\u00f8dvendigt at kende simple regler.<\/p>\n
Vi designer alt ud fra foresp\u00f8rgslen. Hovedfokus er ikke dataene, men hvordan applikationen skal arbejde med dem. Hvis den har brug for at hente forskellige data p\u00e5 forskellige m\u00e5der eller de samme data p\u00e5 forskellige m\u00e5der, skal vi arrangere dem p\u00e5 en m\u00e5de, der er praktisk for applikationen. Ellers vil vi ende i Full Scan, og Cassandra vil ikke give os nogen fordel.<\/p>\n
At denormalisere data er en norm. Vi glemmer de normale former; vi har ikke l\u00e6ngere relationelle databaser. Vi kan placere noget 100 gange, og det vil v\u00e6re der 100 gange. Det er stadig billigere end at stoppe op. <\/p>\n
Vi v\u00e6lger n\u00f8gler til partitionering, s\u00e5 de fordeles ordentligt. Vi \u00f8nsker ikke, at hashen fra vores n\u00f8gler falder i et sn\u00e6vert interval. Med andre ord, f\u00f8dsels\u00e5ret i ovenst\u00e5ende eksempel - det er et d\u00e5rligt eksempel. Det vil sige, det er godt, hvis vi har brugere, der er j\u00e6vnt fordelt efter f\u00f8dsels\u00e5r, og d\u00e5rligt, hvis det drejer sig om 5. klasses elever - der vil det ikke v\u00e6re meget godt at partitionere. <\/p>\n
Sorteringen v\u00e6lges \u00e9n gang under oprettelsen af Clustering Key. Hvis den skal \u00e6ndres, skal vi omstrukturere vores tabel med en anden n\u00f8gle.<\/p>\n
Og det vigtigste: hvis vi har brug for at hente de samme data p\u00e5 100 forskellige m\u00e5der, s\u00e5 vil vi have 100 forskellige tabeller.
\n
Kilde: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440. \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041c\u0438\u0448\u0430 \u0411\u0443\u0442\u0440\u0438\u043c\u043e\u0432, \u044f \u0445\u043e\u0442\u0435\u043b \u0431\u044b \u0445\u043e\u0442\u0435\u043b \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043f\u0440\u043e Cassandra. \u041c\u043e\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0437 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u043b\u0435\u0437\u0435\u043d \u0442\u0435\u043c, \u043a\u0442\u043e \u043d\u0438\u043a\u043e\u0433\u0434\u0430 \u043d\u0435 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u043b\u0441\u044f \u0441 NoSQL-\u0431\u0430\u0437\u0430\u043c\u0438, \u2014 \u0443 \u043d\u0435\u0435 \u0435\u0441\u0442\u044c \u043e\u0447\u0435\u043d\u044c \u043c\u043d\u043e\u0433\u043e \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u0435\u0439 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0438 \u0438 \u043f\u043e\u0434\u0432\u043e\u0434\u043d\u044b\u0445 \u043a\u0430\u043c\u043d\u0435\u0439, \u043f\u0440\u043e \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0443\u0436\u043d\u043e \u0437\u043d\u0430\u0442\u044c. \u0418 \u0435\u0441\u043b\u0438 \u043a\u0440\u043e\u043c\u0435 Oracle \u0438\u043b\u0438 \u043b\u044e\u0431\u043e\u0439 \u0434\u0440\u0443\u0433\u043e\u0439 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u043e\u0439 \u0431\u0430\u0437\u044b \u0432\u044b \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u0432\u0438\u0434\u0435\u043b\u0438, \u044d\u0442\u0438 \u0432\u0435\u0449\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":41082,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10],"tags":[],"class_list":["post-41081","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Cassandra. Hvordan man ikke d\u00f8r, hvis man kun kender Oracle | ProHoster","description":"Hej, Habr. Mit navn er Misha Butrimov, og jeg vil gerne fort\u00e6lle lidt om Cassandra.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Cassandra. \u041a\u0430\u043a \u043d\u0435 \u0443\u043c\u0435\u0440\u0435\u0442\u044c, \u0435\u0441\u043b\u0438 \u0437\u043d\u0430\u0435\u0448\u044c \u0442\u043e\u043b\u044c\u043a\u043e Oracle | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440. \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041c\u0438\u0448\u0430 \u0411\u0443\u0442\u0440\u0438\u043c\u043e\u0432, \u044f \u0445\u043e\u0442\u0435\u043b \u0431\u044b \u0445\u043e\u0442\u0435\u043b \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043f\u0440\u043e Cassandra.","og:url":"https:\/\/prohoster.info\/da\/blog\/cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-02-05T18:30:11+00:00","article:modified_time":"2020-02-05T18:30:11+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"41081","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:24:40","updated":"2022-09-30 11:42:25","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/41081","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=41081"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/41081\/revisions"}],"predecessor-version":[{"id":164523,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/41081\/revisions\/164523"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/41082"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=41081"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=41081"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=41081"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}