{"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\/it\/blog\/cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle","title":{"rendered":"Cassandra. Come non morire se sai solo Oracle","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, Habr.<\/p>\n

Mi chiamo Misha Butrimov e vorrei raccontarvi un po' di Cassandra. Il mio racconto sar\u00e0 utile a chi non ha mai avuto a che fare con i database NoSQL, poich\u00e9 presenta molte peculiarit\u00e0 di implementazione e insidie di cui \u00e8 importante essere a conoscenza. E se oltre a Oracle o ad un altro database relazionale non avete mai visto altro, queste informazioni vi salveranno la vita.<\/p>\n

Cosa ha di buono Cassandra? \u00c8 un database NoSQL progettato senza un singolo punto di errore, che si scalda bene. Se avete bisogno di aggiungere un paio di terabyte per un database, basta aggiungere nodi al cluster. Volete espanderlo a un altro data center? Aggiungete nodi al cluster. Volete aumentare il RPS elaborato? Aggiungete nodi al cluster. Funziona allo stesso modo anche in direzione opposta. <\/p>\n

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

In cosa \u00e8 ancora eccellente? Nella capacit\u00e0 di gestire molte richieste. Ma molte \u2014 quanto \u00e8? 10, 20, 30, 40 mila richieste al secondo \u2014 \u00e8 poco. 100 mila richieste al secondo in scrittura \u2014 \u00e8 poco. Ci sono aziende che hanno dichiarato di gestire 2 milioni di richieste al secondo. A loro bisogna crederci. <\/p>\n

In linea di principio, Cassandra ha una grande differenza rispetto ai dati relazionali: non assomiglia affatto a loro. \u00c8 molto importante tenerlo a mente.
\n<\/a><\/noindex><\/p>\n

Non tutto ci\u00f2 che appare uguale funziona allo stesso modo.<\/h2>\n

\nUna volta un collega \u00e8 venuto da me e ha chiesto: \u00abEcco il linguaggio di query Cassandra SQL, e ci sono le istruzioni di selezione, c'\u00e8 il where, c'\u00e8 l'and. Scrivo le lettere e non funziona. Perch\u00e9?\u00bb. Se si tratta Cassandra come un database relazionale, questo \u00e8 il modo perfetto per finire la propria vita in modo crudele e senza speranza. E non sto propagandando, \u00e8 vietato in Russia. Semplicemente progettate qualcosa nel modo sbagliato.<\/p>\n

Ad esempio, un cliente viene da noi e dice: \u00abCostruiamo un database per le serie TV, o un database per un ricettario. Avremo piatti con ingredienti o un elenco di serie e attori\u00bb. Noi rispondiamo felici: \u00abFacciamo!\u00bb. Sono solo due byte da trasferire, un paio di tabelle e il gioco \u00e8 fatto, tutto funzioner\u00e0 molto velocemente e in modo affidabile. E tutto va bene finch\u00e9 i clienti non arrivano e non dicono che le casalinghe devono anche risolvere il problema inverso: hanno un elenco di ingredienti e vogliono sapere quale piatto vogliono cucinare. Siete spacciati.<\/p>\n

Tutto perch\u00e9 Cassandra \u00e8 un database ibrido: \u00e8 sia una chiave-valore, sia memorizza i dati in colonne ampie. Parlando il linguaggio di Java o Kotlin, questo potrebbe essere descritto cos\u00ec:<\/p>\n

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

Cio\u00e8 una mappa, all'interno della quale si trova anche un'altra mappa ordinata. La prima chiave di questa mappa \u00e8 la Row key o Partition key \u2014 la chiave di partizionamento. La seconda chiave, che \u00e8 la chiave della mappa gi\u00e0 ordinata, \u00e8 la Clustering key.<\/p>\n

Per illustrare la distribuzione del database, disegniamo tre nodi. Ora dobbiamo capire come distribuire i dati sui nodi. Perch\u00e9 se mettiamo tutto in uno (che, per la cronaca, possono essere mille, duemila, cinque \u2014 quanti desideriamo), non si tratta realmente di distribuzione. Di conseguenza, abbiamo bisogno di una funzione matematica che restituisca un numero. Solo un numero, un intero lungo, che rientri in un certo intervallo. E un nodo risponder\u00e0 a un intervallo, il secondo a un altro, e cos\u00ec via. <\/p>\n

\"Cassandra.
\n
\nQuesto numero viene ottenuto attraverso una funzione hash, applicata a ci\u00f2 che chiamiamo Partition key. Questa \u00e8 la colonna specificata nella direttiva Primary key, ed \u00e8 la colonna che sar\u00e0 la prima e la principale chiave della mappa. Determina quale nodo ospiter\u00e0 quali dati. La tabella viene creata in Cassandra con una sintassi quasi identica a quella di 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
La chiave primaria in questo caso consiste di una sola colonna, che \u00e8 anche la chiave di partizionamento.<\/p>\n
Come verranno distribuiti gli utenti? Parte andr\u00e0 a un nodo, parte a un altro, e parte a un terzo. Risultando in una normale tabella hash, ovvero una mappa, ovvero in Python un dizionario, ovvero una semplice struttura chiave-valore, da cui possiamo leggere tutti i valori e leggere e scrivere per chiave.<\/p>\n
\"Cassandra.
\n<\/p>\n
Select: quando allow filtering si trasforma in full scan, o come non si dovrebbe fare<\/h2>\n
\nScriviamo una dichiarazione select: select * from users where userid = <\/code>. Sembra funzionare come in Oracle: scriviamo select, specifichiamo le condizioni e tutto funziona, gli utenti vengono recuperati. Ma se scegliamo, ad esempio, un utente con un anno di nascita specifico, Cassandra si lamenta di non poter eseguire la query. Perch\u00e9 non sa nulla su come sono distribuiti i dati riguardo all'anno di nascita \u2014 l'unica colonna specificata come chiave \u00e8 una sola. Allora dice: \u00abVa bene, posso comunque eseguire questa query. Aggiungi allow filtering\u00bb. Aggiungiamo la direttiva e tutto funziona. E in quel momento succede qualcosa di terribile. <\/p>\n
Quando testiamo con i dati di prova, va tutto magnificamente. Ma quando eseguiamo una query in produzione, dove abbiamo, per esempio, 4 milioni di record, le cose non vanno molto bene. Perch\u00e9 allow filtering \u00e8 una direttiva che consente a Cassandra di raccogliere tutti i dati da questa tabella da tutti i nodi, tutti di data center<\/a> (se ce ne sono molti in questo cluster), e solo dopo filtrarli. \u00c8 come un Full Scan, e nessuno potrebbe esserne entusiasta. <\/p>\n
Se ci servissero utenti solo per gli identificatori, saremmo a posto. Ma a volte dobbiamo scrivere altre query e applicare altre restrizioni sulla selezione. Quindi ricordiamo: questo \u00e8 tutto una mappa, di cui abbiamo una chiave di partizionamento, ma al suo interno c'\u00e8 una mappa ordinata. <\/p>\n
E anche questa ha una chiave che chiamiamo Clustering Key. Questa chiave, che a sua volta \u00e8 composta da colonne che sceglieremo, permette a Cassandra di capire come i dati saranno fisicamente ordinati e disposti su ogni nodo. Cio\u00e8, per un certo Partition key, la Clustering key spiegher\u00e0 come esattamente immettere i dati in questo albero, quale posto occuperanno l\u00ec.<\/p>\n
\u00c8 realmente un albero, in cui viene chiamato un comparatore, a cui forniamo un insieme di colonne sotto forma di oggetto, e anche questo viene impostato sotto forma di elenco di colonne. <\/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
Si prega di notare la direttiva Primary key, il cui primo argomento (in questo caso l'anno) \u00e8 sempre la Partition key. Pu\u00f2 consistere in una o pi\u00f9 colonne, non importa. Se ci sono pi\u00f9 colonne, \u00e8 necessario racchiuderle di nuovo tra parentesi, affinch\u00e9 il preprocessore del linguaggio capisca che si tratta di una Primary key, e che tutte le altre colonne sono Clustering key. Queste ultime verranno passate nel comparatore nell'ordine in cui si presentano. Cio\u00e8, la prima colonna \u00e8 pi\u00f9 significativa, la seconda \u00e8 meno significativa e cos\u00ec via. Come facciamo per le classi di dati scrivendo, ad esempio, i campi equals: elenchiamo i campi e indichiamo quali sono pi\u00f9 importanti e quali meno. In Cassandra, questo \u00e8, per cos\u00ec dire, il campo della data class a cui verr\u00e0 applicato il metodo equals scritto per essa.<\/p>\n
Impostiamo l'ordinamento, imponiamo restrizioni<\/h2>\n
\n\u00c8 importante ricordare che l'ordine di ordinamento (decrescente, crescente, non importa) \u00e8 stabilito nel momento in cui viene creato il key, e modificarlo in seguito non sar\u00e0 possibile. Esso determina fisicamente come verranno ordinati i dati e come saranno disposti. Se sar\u00e0 necessario modificare il Clustering key o l'ordine di ordinamento, sar\u00e0 necessario creare una nuova tabella e trasferirvi i dati. Non si pu\u00f2 fare cos\u00ec con una tabella gi\u00e0 esistente.<\/p>\n
\"Cassandra.
\n
\nAbbiamo riempito la nostra tabella con utenti e abbiamo visto che sono stati disposti in cerchio prima per anno di nascita e poi all'interno di ciascun nodo per stipendi e per user ID. Ora possiamo fare delle selezioni, imponendo delle restrizioni. <\/p>\n
Ritorna di nuovo il nostro funzionante dove, e<\/code>, e gli utenti ci vengono assegnati, e tutto torna a posto. Ma se proviamo a utilizzare solo una parte del Clustering key, quella meno significativa, Cassandra immediatamente segnaler\u00e0 che non pu\u00f2 trovare nella nostra mappa il posto dove si trova questo oggetto, il quale ha questi campi per il comparatore null, mentre quest'altro, che abbiamo appena definito, - dove si trova. Dovr\u00f2 sollevare nuovamente tutti i dati da questo nodo e filtrarli. Questo equivale a una Full Scan all'interno del nodo, e non \u00e8 una buona cosa.<\/p>\n
In qualsiasi situazione poco chiara, crea una nuova tabella<\/h2>\n
\nSe vogliamo avere la possibilit\u00e0 di recuperare gli utenti per ID, et\u00e0 o stipendio, cosa fare? Nulla. Basta usare due tabelle. Se dobbiamo recuperare gli utenti in tre modi diversi, ci saranno tre tabelle. I tempi in cui cercavamo di risparmiare spazio su disco sono finiti. Questo \u00e8 il risorsa pi\u00f9 economica. Costa molto meno del tempo di risposta, che pu\u00f2 essere devastante per l'utente. \u00c8 molto pi\u00f9 piacevole per l'utente ricevere qualcosa in un secondo piuttosto che in 10 minuti.<\/p>\n
Scambiamo lo spazio occupato in eccesso, dati denormalizzati, con la possibilit\u00e0 di scalare bene e funzionare in modo affidabile. Infatti, un cluster composto da tre data center, ognuno con cinque nodi, in grado di mantenere un livello accettabile di integrit\u00e0 dei dati (quando nulla viene perso), pu\u00f2 sopportare la completa perdita di un data center. E ne restano altri due con due nodi ciascuno. Solo dopo inizieranno i problemi. Questo \u00e8 un buon tipo di ridondanza, che costa un paio di SSD o CPU in pi\u00f9. Pertanto, per utilizzare Cassandra, che non \u00e8 SQL, in cui non ci sono relazioni n\u00e9 chiavi esterne, \u00e8 necessario conoscere alcune semplici regole.<\/p>\n
Progettiamo tutto a partire dalla richiesta. I dati non sono pi\u00f9 al centro, ma piuttosto come l'applicazione lavorer\u00e0 con essi. Se deve recuperare dati diversi in modi diversi o gli stessi dati in modi diversi, dobbiamo organizzarli in modo che siano comodi per l'applicazione. Altrimenti, ci ritroveremo a dover eseguire una scansione completa e Cassandra non ci dar\u00e0 alcun vantaggio.<\/p>\n
Denormalizzare i dati \u00e8 la norma. Dimentichiamo le forme normali, non abbiamo pi\u00f9 database relazionali. Se inseriamo qualcosa 100 volte, ci sar\u00e0 100 volte. \u00c8 comunque pi\u00f9 economico che rallentare. <\/p>\n
Scegliamo le chiavi per il partizionamento in modo che siano distribuite normalmente. Non vogliamo che l'hash delle nostre chiavi cada in un intervallo ristretto. Cio\u00e8, l'anno di nascita nell'esempio precedente \u00e8 un cattivo esempio. Gi\u00e0, \u00e8 buono se i nostri utenti sono distribuiti normalmente per anno di nascita, ed \u00e8 cattivo se si parla di studenti di quinta elementare, dove sar\u00e0 difficile effettuare il partizionamento. <\/p>\n
Il tipo di ordinamento viene scelto una sola volta durante la creazione della Clustering Key. Se \u00e8 necessario modificarlo, sar\u00e0 necessario riversare la nostra tabella con un'altra chiave.<\/p>\n
E la cosa pi\u00f9 importante: se abbiamo bisogno di estrarre gli stessi dati in 100 modi diversi, avremo 100 tabelle diverse.
\n
Fonte: 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\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. Come non morire se conosci solo Oracle | ProHoster","description":"Ciao, Habr. Mi chiamo Misha Butrimov e vorrei raccontare un po' di Cassandra.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/41081","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=41081"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/41081\/revisions"}],"predecessor-version":[{"id":164523,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/41081\/revisions\/164523"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/41082"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=41081"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=41081"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=41081"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}