{"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\/de\/blog\/cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle","title":{"rendered":"Cassandra. Wie man nicht stirbt, wenn man nur Oracle kennt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, Habr.<\/p>\n

Ich hei\u00dfe Misha Butrimov und m\u00f6chte ein wenig \u00fcber Cassandra erz\u00e4hlen. Mein Vortrag wird f\u00fcr diejenigen n\u00fctzlich sein, die noch nie mit NoSQL-Datenbanken in Ber\u00fchrung gekommen sind, da es viele Besonderheiten bei der Implementierung und Fallstricke gibt, die man kennen sollte. Und wenn Sie au\u00dfer Oracle oder einer anderen relationalen Datenbank nichts gesehen haben, werden Ihnen diese Dinge das Leben retten.<\/p>\n

Was macht Cassandra so gut? Es ist eine NoSQL-Datenbank, die ohne einen einzigen Ausfallpunkt entworfen wurde und sich gut skalieren l\u00e4sst. Wenn Sie ein paar Terabyte f\u00fcr eine Datenbank hinzuf\u00fcgen m\u00fcssen, f\u00fcgen Sie einfach Knoten zum Ring hinzu. M\u00f6chten Sie sie auf ein weiteres Rechenzentrum erweitern? F\u00fcgen Sie Knoten zum Cluster hinzu. M\u00f6chten Sie die bearbeiteten RPS erh\u00f6hen? F\u00fcgen Sie Knoten zum Cluster hinzu. Es funktioniert auch in die andere Richtung. <\/p>\n

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

Was ist noch gut daran? Dass sie viele Anfragen verarbeiten kann. Aber wie viele? 10.000, 20.000, 30.000, 40.000 Anfragen pro Sekunde \u2013 das ist nicht viel. 100.000 Anfragen pro Sekunde f\u00fcr Schreibvorg\u00e4nge \u2013 auch nicht. Es gibt Unternehmen, die sagen, dass sie 2 Millionen Anfragen pro Sekunde verarbeiten. Deren Aussage m\u00fcssen wir wohl glauben. <\/p>\n

Im Grunde hat Cassandra eine gro\u00dfe Abweichung von relationalen Daten \u2013 sie ist \u00fcberhaupt nicht \u00e4hnlich. Und das ist sehr wichtig zu beachten.
\n<\/a><\/noindex><\/p>\n

Nicht alles, was gleich aussieht, funktioniert gleich.<\/h2>\n

\nEines Tages kam ein Kollege zu mir und fragte: \u201eHier ist das SQL Cassandra Query Language, und es gibt ein SELECT-Statement, es gibt ein WHERE und es gibt ein AND. Ich schreibe die Buchstaben, und es funktioniert nicht. Warum?\u201c. Wenn man Cassandra wie eine relationale Datenbank behandelt, ist das der ideale Weg, um ein schlimmes Selbstmordurteil zu f\u00e4llen. Und ich propagiere das nicht, es ist in Russland verboten. Sie werden einfach etwas falsch konzipieren.<\/p>\n

Zum Beispiel kommt ein Kunde zu uns und sagt: \u201eLass uns eine Datenbank f\u00fcr Serien bauen oder eine Datenbank f\u00fcr ein Rezeptregister. Wir haben da Gerichte mit Zutaten oder eine Liste von Serien und den Schauspielern darin\u201c. Wir sagen fr\u00f6hlich: \u201eLass uns machen!\u201c. Es sind nur zwei Bytes zu \u00fcbertragen, ein paar Tabellen und alles ist bereit, es wird sehr schnell und zuverl\u00e4ssig funktionieren. Und alles ist gro\u00dfartig, bis die Kunden kommen und sagen, dass Hausfrauen auch die Umkehrfrage l\u00f6sen: sie haben eine Liste von Zutaten und wollen wissen, welches Gericht sie zubereiten m\u00f6chten. Dann sind Sie erledigt.<\/p>\n

Das liegt daran, dass Cassandra eine hybride Datenbank ist: Sie ist gleichzeitig eine Key-Value-Datenbank und speichert Daten in breiten Spalten. Wenn wir in der Sprache Java oder Kotlin sprechen, k\u00f6nnte man es so beschreiben:<\/p>\n

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

Das hei\u00dft, eine Map, in der sich noch eine sortierte Map befindet. Der erste Schl\u00fcssel dieser Map ist der Row-Key oder Partition-Key \u2013 der Partitionierungsschl\u00fcssel. Der zweite Schl\u00fcssel, der den Zugriff auf die bereits sortierte Map erm\u00f6glicht, ist der Clustering-Key.<\/p>\n

Um die Verteilung der Datenbank zu veranschaulichen, zeichnen wir drei Knoten. Jetzt m\u00fcssen wir verstehen, wie wir die Daten auf die Knoten verteilen. Denn wenn wir alles in einen Knoten stecken (es k\u00f6nnen \u00fcbrigens tausend, zweitausend oder f\u00fcnf \u2013 so viele wie n\u00f6tig \u2013 sein), ist das nicht wirklich verteilungsorientiert. Daher ben\u00f6tigen wir eine mathematische Funktion, die eine Zahl zur\u00fcckgibt. Einfach eine Zahl, ein langes int, das in einen bestimmten Bereich f\u00e4llt. Und ein Knoten wird f\u00fcr einen Bereich verantwortlich sein, der zweite f\u00fcr den n\u00e4chsten, der n-te f\u00fcr den n-ten. <\/p>\n

\"Cassandra.
\n
\nDiese Zahl wird mithilfe einer Hash-Funktion ermittelt, die auf den Partition-Key angewendet wird. Das ist die Spalte, die in der Direktive f\u00fcr den Prim\u00e4rschl\u00fcssel angegeben ist, und das ist die Spalte, die der erste und wichtigste Schl\u00fcssel in der Map sein wird. Sie bestimmt, auf welchen Knoten welche Daten gelangen. Die Tabelle wird in Cassandra nahezu mit der gleichen Syntax wie in SQL erstellt: <\/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
Der Prim\u00e4rschl\u00fcssel besteht in diesem Fall aus einer einzigen Spalte, die auch der Partitionierungsschl\u00fcssel ist.<\/p>\n
Wie werden unsere Benutzer verteilt? Ein Teil gelangt in einen Knoten, ein anderer Teil in einen weiteren und ein Teil in den dritten. Das ergibt eine gew\u00f6hnliche Hash-Tabelle, auch Map genannt, in Python ein Dictionary, also eine einfache Key-Value-Struktur, aus der wir alle Werte lesen k\u00f6nnen, und wir k\u00f6nnen nach Schl\u00fcssel lesen und schreiben.<\/p>\n
\"Cassandra.
\n<\/p>\n
Select: Wenn Allow Filtering zu Full Scan wird, oder wie man es nicht machen sollte<\/h2>\n
\nLass uns eine Select-Anweisung schreiben: select * from users where userid = <\/code>Es funktioniert so \u00e4hnlich wie bei Oracle: Wir schreiben ein select, geben die Bedingungen an und alles funktioniert, die Benutzer werden abgerufen. Aber wenn wir beispielsweise einen Benutzer mit einem bestimmten Geburtsjahr ausw\u00e4hlen, beschwert sich Cassandra, dass sie die Anfrage nicht ausf\u00fchren kann. Denn sie wei\u00df \u00fcberhaupt nichts dar\u00fcber, wie unsere Daten zum Geburtsjahr verteilt sind - sie hat nur eine Spalte als Schl\u00fcssel angegeben. Dann sagt sie: \u201eGut, ich kann diese Anfrage trotzdem ausf\u00fchren. F\u00fcgen Sie allow filtering hinzu.\u201c Wir f\u00fcgen die Direktive hinzu, alles funktioniert. Und in diesem Moment geschieht das Unheil. <\/p>\n
Wenn wir mit Testdaten arbeiten, l\u00e4uft alles wunderbar. Aber wenn Sie die Anfrage in der Produktion ausf\u00fchren, wo wir zum Beispiel 4 Millionen Datens\u00e4tze haben, dann sieht es nicht gut aus. Denn allow filtering ist eine Direktive, die es Cassandra erlaubt, alle Daten aus dieser Tabelle von allen Nodes zu sammeln, allen Rechenzentren<\/a> (falls es viele in diesem Cluster gibt), und erst dann zu filtern. Das ist vergleichbar mit einem Full Scan, und es gibt kaum jemanden, der davon begeistert w\u00e4re. <\/p>\n
Wenn wir nur Benutzer nach IDs br\u00e4uchten, w\u00e4re das akzeptabel. Aber manchmal m\u00fcssen wir andere Anfragen formulieren und andere Einschr\u00e4nkungen auf die Abfrage anwenden. Deshalb erinnern wir uns: Das ist alles eine Map, die einen Partitionierungsschl\u00fcssel hat, aber darin gibt es eine sortierte Map. <\/p>\n
Und sie hat auch einen Schl\u00fcssel, den wir Clustering Key nennen. Dieser Schl\u00fcssel besteht seinerseits aus den Spalten, die wir ausw\u00e4hlen, durch den Cassandra versteht, wie die Daten physisch sortiert werden und auf jeder Node gespeichert werden. Das hei\u00dft, f\u00fcr einen bestimmten Partition key sagt der Clustering key, wie genau die Daten in diesen Baum eingeordnet werden und welchen Platz sie dort einnehmen.<\/p>\n
Es ist wirklich ein Baum, da wird einfach ein Comparator aufgerufen, dem wir eine bestimmte Menge von Spalten in Form eines Objekts \u00fcbergeben, und er wird ebenfalls in Form einer Aufz\u00e4hlung von Spalten definiert. <\/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
Beachten Sie die Direktive Primary key, bei der das erste Argument (in unserem Fall das Jahr) immer der Partition key ist. Er kann aus einer oder mehreren Spalten bestehen, was nicht wichtig ist. Falls es mehrere Spalten gibt, m\u00fcssen diese erneut in Klammern gesetzt werden, damit der Pr\u00e4prozessor der Sprache versteht, dass es sich um den Primary key handelt, gefolgt von allen anderen Spalten \u2014 Clustering key. Diese werden im Comparator in der Reihenfolge \u00fcbergeben, in der sie erscheinen. Das hei\u00dft, die erste Spalte ist relevanter, die zweite weniger relevant und so weiter. Wie wir f\u00fcr Datenklassen schreiben, zum Beispiel die Felder equals: wir listen die Felder auf und geben an, welche wichtiger und welche weniger wichtig sind. In Cassandra sind dies, vereinfacht gesagt, die Felder der Datenklasse, auf die der geschriebene equals angewendet wird.<\/p>\n
Wir legen die Sortierung fest und bringen Einschr\u00e4nkungen an.<\/h2>\n
\nEs ist wichtig zu beachten, dass die Sortierreihenfolge (absteigend, aufsteigend, ganz egal) genau zum Zeitpunkt der Erstellung des Schl\u00fcssels festgelegt wird und sp\u00e4ter nicht mehr ge\u00e4ndert werden kann. Sie bestimmt physisch, wie die Daten sortiert werden und wie sie gespeichert werden. Wenn der Clustering key oder die Sortierreihenfolge ge\u00e4ndert werden m\u00fcssen, muss eine neue Tabelle erstellt und die Daten dorthin \u00fcbertragen werden. Mit einer bereits bestehenden Tabelle funktioniert das nicht.<\/p>\n
\"Cassandra.
\n
\nWir haben unsere Tabelle mit Benutzern gef\u00fcllt und gesehen, dass sie zun\u00e4chst nach Geburtsjahr und dann innerhalb jeder Node nach Gehalt und Benutzer-ID angeordnet sind. Jetzt k\u00f6nnen wir Daten abfragen und Einschr\u00e4nkungen hinzuf\u00fcgen. <\/p>\n
Unser funktionierender where, und<\/code>, und die Benutzer stehen uns zur Verf\u00fcgung, und alles ist wieder gut. Aber wenn wir versuchen, nur einen Teil des Clustering keys zu verwenden, und zwar den weniger relevanten, wird Cassandra sofort darauf hinweisen, dass es in unserem Mapping keinen Platz finden kann, wo sich dieses Objekt befindet, dessen Felder f\u00fcr den Comparator null sind, und wo sich dieses, das wir gerade festgelegt haben, befindet. Ich muss alle Daten von dieser Node erneut abrufen und filtern. Das ist vergleichbar mit einem Full Scan innerhalb der Node, was schlecht ist.<\/p>\n
In jeder unklaren Situation erstelle eine neue Tabelle.<\/h2>\n
\nWenn wir die M\u00f6glichkeit haben wollen, Benutzer nach ID, Alter oder Gehalt abzurufen, was tun wir dann? Nichts. Einfach zwei Tabellen verwenden. Wenn wir Benutzer auf drei verschiedene Arten abrufen m\u00fcssen, werden es drei Tabellen sein. Die Zeiten, in denen wir Speicherplatz auf der Festplatte sparen konnten, sind vorbei. Das ist die g\u00fcnstigste Ressource. Sie kostet viel weniger als die Antwortzeit, die f\u00fcr den Benutzer verheerend sein kann. Es ist viel angenehmer f\u00fcr den Benutzer, etwas in einer Sekunde zu erhalten, als in 10 Minuten.<\/p>\n
Wir tauschen den \u00fcberm\u00e4\u00dfigen Speicherbedarf, den denormalisierten Daten, gegen die M\u00f6glichkeit, gut zu skalieren und zuverl\u00e4ssig zu arbeiten. Denn tats\u00e4chlich kann ein Cluster, das aus drei Rechenzentren besteht, von denen jedes f\u00fcnf Knoten hat, bei einem akzeptablen Datenbewahrungsniveau (wenn garantiert nichts verloren geht) den Tod eines Rechenzentrums vollst\u00e4ndig \u00fcberstehen. Und zus\u00e4tzlich zwei Knoten in jedem der beiden verbleibenden. Und erst dann beginnen die Probleme. Das ist eine ziemlich gute Redundanz, die ein paar zus\u00e4tzliche SSD-Laufwerke und Prozessoren kostet. Daher m\u00fcssen wir einfache Regeln kennen, um Cassandra, das \u00fcberhaupt kein SQL ist und in dem es keine Beziehungen oder Fremdschl\u00fcssel gibt, zu nutzen.<\/p>\n
Wir entwerfen alles mit dem Fokus auf die Abfrage. Es sind nicht die Daten entscheidend, sondern wie die Anwendung damit arbeitet. Wenn sie verschiedene Daten auf verschiedene Arten oder dieselben Daten auf verschiedene Arten erhalten muss, m\u00fcssen wir sie so ablegen, wie es f\u00fcr die Anwendung g\u00fcnstig ist. Andernfalls fallen wir in einen vollst\u00e4ndigen Scan hinein und Cassandra wird uns keinen Vorteil bringen.<\/p>\n
Denormalisierte Daten sind die Norm. Vergessen wir die normalen Formen, wir haben es nicht mehr mit relationalen Datenbanken zu tun. Wenn wir etwas 100 Mal ablegen, wird es 100 Mal abgelegt. Das ist immer noch billiger, als zu stocken. <\/p>\n
Wir w\u00e4hlen die Schl\u00fcssel f\u00fcr die Partitionierung so, dass sie sich gleichm\u00e4\u00dfig verteilen. Wir wollen nicht, dass die Hashes unserer Schl\u00fcssel in einen engen Bereich fallen. Das hei\u00dft, das Geburtsjahr im obigen Beispiel ist ein schlechtes Beispiel. Es ist gut, wenn unsere Benutzer nach Geburtsjahr gut verteilt sind, und schlecht, wenn es sich um Sch\u00fcler der 5. Klasse handelt \u2014 da wird die Partitionierung nicht gut funktionieren. <\/p>\n
Die Sortierung wird einmalig beim Erstellen des Clustering-Keys ausgew\u00e4hlt. Wenn sie ge\u00e4ndert werden muss, m\u00fcssen wir unsere Tabelle mit einem anderen Schl\u00fcssel umschreiben.<\/p>\n
Und das Wichtigste: Wenn wir die gleichen Daten auf 100 verschiedene Arten abrufen m\u00fcssen, haben wir 100 verschiedene Tabellen.
\n
Quelle: 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. Wie man nicht stirbt, wenn man nur Oracle kennt | ProHoster","description":"Hallo, Habr. Mein Name ist Misha Butrimov, ich m\u00f6chte ein wenig \u00fcber Cassandra erz\u00e4hlen.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/41081","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=41081"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/41081\/revisions"}],"predecessor-version":[{"id":164523,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/41081\/revisions\/164523"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/41082"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=41081"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=41081"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=41081"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}