{"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\/fr\/blog\/cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle","title":{"rendered":"Cassandra. Comment ne pas mourir si vous ne connaissez qu'Oracle","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bonjour, Habr.<\/p>\n

Je m'appelle Misha Boutrimov, je voudrais parler un peu de Cassandra. Mon expos\u00e9 sera utile \u00e0 ceux qui n'ont jamais \u00e9t\u00e9 confront\u00e9s aux bases de donn\u00e9es NoSQL, car il y a beaucoup de particularit\u00e9s et de pi\u00e8ges \u00e0 conna\u00eetre. Et si vous n'avez vu que Oracle ou d'autres bases relationnelles, ces \u00e9l\u00e9ments vous sauveront la vie.<\/p>\n

Qu'est-ce qui rend Cassandra si int\u00e9ressante ? C'est une base de donn\u00e9es NoSQL, con\u00e7ue sans point de d\u00e9faillance unique, qui se scale bien. Si vous devez ajouter quelques t\u00e9raoctets pour une base quelconque, vous ajoutez simplement des n\u0153uds au cluster. Vous souhaitez l'\u00e9tendre \u00e0 un autre datacenter ? Ajoutez des n\u0153uds au cluster. Augmentez les RPS trait\u00e9s ? Ajoutez des n\u0153uds au cluster. Cela fonctionne \u00e9galement dans l'autre sens. <\/p>\n

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

En quoi est-elle encore performante ? Dans la gestion de nombreux requ\u00eates. Mais beaucoup, c'est combien ? 10, 20, 30, 40 mille requ\u00eates par seconde, c'est peu. 100 mille requ\u00eates par seconde \u00e0 l'\u00e9criture, c'est peu \u00e9galement. Certaines entreprises affirment qu'elles g\u00e8rent 2 millions de requ\u00eates par seconde. \u00c0 elles, il va falloir y croire. <\/p>\n

Et en principe, Cassandra a une grande diff\u00e9rence par rapport aux donn\u00e9es relationnelles : elle n'y ressemble pas du tout. Et c'est tr\u00e8s important de s'en souvenir.
\n<\/a><\/noindex><\/p>\n

Tout ce qui a l'air identique ne fonctionne pas de fa\u00e7on identique.<\/h2>\n

\nUn jour, un coll\u00e8gue est venu me voir et a demand\u00e9 : \u00ab Voici le langage de requ\u00eate CQL de Cassandra, et il y a une instruction select, il y a un where, il y a un and. J'\u00e9cris des lettres, et \u00e7a ne fonctionne pas. Pourquoi ? \u00bb. Si vous consid\u00e9rez Cassandra comme une base de donn\u00e9es relationnelle, c'est un moyen id\u00e9al de finir votre vie par un suicide brutal. Et je ne fais pas la promotion de cela, c'est interdit en Russie. Vous finirez simplement par concevoir quelque chose de mal.<\/p>\n

Par exemple, un client vient et dit : \u00ab Construisons une base de donn\u00e9es pour des s\u00e9ries, ou une base de donn\u00e9es pour un r\u00e9pertoire de recettes. Nous aurons des plats avec des ingr\u00e9dients ou une liste de s\u00e9ries et d'acteurs dedans \u00bb. Nous r\u00e9pondons avec enthousiasme : \u00ab Allons-y ! \u00bb. C'est deux octets \u00e0 transf\u00e9rer, quelques tables et tout est pr\u00eat, \u00e7a fonctionnera tr\u00e8s vite et de mani\u00e8re fiable. Tout va bien tant que les clients ne reviennent pas en disant que les m\u00e9nag\u00e8res ont aussi un probl\u00e8me inverse : elles ont une liste d'ingr\u00e9dients et veulent savoir quel plat elles peuvent pr\u00e9parer. Vous \u00eates fichu.<\/p>\n

Tout cela parce que Cassandra est une base de donn\u00e9es hybride : elle fonctionne \u00e0 la fois comme une base de donn\u00e9es cl\u00e9-valeur et stocke des donn\u00e9es dans de larges colonnes. Si l'on parle en termes de Java ou de Kotlin, cela pourrait \u00eatre d\u00e9crit comme suit :<\/p>\n

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

C'est-\u00e0-dire une carte, \u00e0 l'int\u00e9rieur de laquelle se trouve \u00e9galement une carte tri\u00e9e. La premi\u00e8re cl\u00e9 de cette carte est la Row key ou Partition key \u2014 la cl\u00e9 de partitionnement. La deuxi\u00e8me cl\u00e9, qui est la cl\u00e9 de la carte d\u00e9j\u00e0 tri\u00e9e, est la Clustering key.<\/p>\n

Pour illustrer la r\u00e9partition de la base de donn\u00e9es, dessinons trois n\u0153uds. Nous devons maintenant comprendre comment r\u00e9partir les donn\u00e9es sur les n\u0153uds. Parce que si nous mettons tout dans un seul (il peut y en avoir mille, deux mille, cinq \u2014 autant que vous voulez), cela ne parle pas vraiment de r\u00e9partition. C'est pourquoi nous avons besoin d'une fonction math\u00e9matique qui renvoie un nombre. Juste un nombre, un int long, qui tombera dans une certaine plage. Et un n\u0153ud sera responsable d'une plage, un autre d'une autre, le n-i\u00e8me d'une n-i\u00e8me. <\/p>\n

\"Cassandra.
\n
\nCe nombre est obtenu gr\u00e2ce \u00e0 une fonction de hachage, qui s'applique justement \u00e0 ce que nous appelons la Partition key. C'est la colonne indiqu\u00e9e dans la directive Primary key, et c'est celle qui sera la premi\u00e8re et la plus importante cl\u00e9 de la carte. Elle d\u00e9termine quelles donn\u00e9es iront sur quel n\u0153ud. Une table est cr\u00e9\u00e9e dans Cassandra presque avec la m\u00eame syntaxe que dans 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 cl\u00e9 primaire dans ce cas se compose d'une seule colonne, et elle est aussi la cl\u00e9 de partitionnement.<\/p>\n
Comment nos utilisateurs seront-ils r\u00e9partis ? Une partie ira sur un n\u0153ud, une autre partie sur un autre, et une autre encore sur le troisi\u00e8me. Cela devient une simple table de hachage, \u00e9galement appel\u00e9e carte, qui en Python est un dictionnaire, c'est-\u00e0-dire une simple structure cl\u00e9-valeur, \u00e0 partir de laquelle nous pouvons lire toutes les valeurs, lire et \u00e9crire par cl\u00e9.<\/p>\n
\"Cassandra.
\n<\/p>\n
Select : lorsque allow filtering se transforme en full scan, ou comment ne pas faire<\/h2>\n
\n\u00c9crivons une instruction select : select * from users where userid = <\/code>. Cela ressemble un peu \u00e0 Oracle : nous \u00e9crivons un select, sp\u00e9cifions des conditions et tout fonctionne, les utilisateurs sont r\u00e9cup\u00e9r\u00e9s. Mais si nous choisissons, par exemple, un utilisateur avec une ann\u00e9e de naissance sp\u00e9cifique, Cassandra se plaint qu'elle ne peut pas ex\u00e9cuter la requ\u00eate. Parce qu'elle ne sait absolument rien sur la mani\u00e8re dont nos donn\u00e9es sur l'ann\u00e9e de naissance sont distribu\u00e9es - elle a en tant que cl\u00e9 uniquement une seule colonne. Elle dit alors : \u00ab Tr\u00e8s bien, je peux toujours ex\u00e9cuter cette requ\u00eate. Ajoutez allow filtering \u00bb. Nous ajoutons la directive, tout fonctionne. Et \u00e0 ce moment, cela devient terrible. <\/p>\n
Lorsque nous ex\u00e9cutons des tests avec des donn\u00e9es de test, tout va bien. Mais lorsque vous ex\u00e9cutez une requ\u00eate en production, o\u00f9 nous avons, par exemple, 4 millions d'enregistrements, cela ne va pas tr\u00e8s bien. Parce que allow filtering est une directive qui permet \u00e0 Cassandra de collecter toutes les donn\u00e9es de cette table sur tous les n\u0153uds, tous de centres de donn\u00e9es<\/a> (s'il y en a beaucoup dans ce cluster), et ensuite seulement de les filtrer. C'est l'\u00e9quivalent d'un Full Scan, et il est peu probable que quelqu'un soit ravi de cela. <\/p>\n
Si nous avions besoin des utilisateurs uniquement par identifiants, cela nous conviendrait. Mais parfois, nous devons \u00e9crire d'autres requ\u00eates et imposer d'autres restrictions sur la s\u00e9lection. Donc, rappelons-nous : tout cela est une carte, qui a une cl\u00e9 de partitionnement, mais \u00e0 l'int\u00e9rieur se trouve une carte tri\u00e9e. <\/p>\n
Et elle a aussi une cl\u00e9, que nous appelons Clustering Key. Cette cl\u00e9, qui est en fait compos\u00e9e des colonnes que nous choisirons, permet \u00e0 Cassandra de comprendre comment ses donn\u00e9es seront physiquement tri\u00e9es et stock\u00e9es sur chaque n\u0153ud. Autrement dit, pour une cl\u00e9 de partition, la cl\u00e9 de regroupement indique comment exactement stocker les donn\u00e9es dans cet arbre, quel espace elles occuperont.<\/p>\n
C'est vraiment un arbre, un comparateur est simplement appel\u00e9, dans lequel nous transmettons un certain ensemble de colonnes sous forme d'objet, et il est \u00e9galement d\u00e9fini sous forme d'\u00e9num\u00e9ration de colonnes. <\/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
Attention \u00e0 la directive Primary key, son premier argument (dans notre cas l'ann\u00e9e) est toujours la cl\u00e9 de partition. Il peut \u00eatre compos\u00e9 d'une ou plusieurs colonnes, peu importe. S'il y a plusieurs colonnes, il faut les mettre entre parenth\u00e8ses encore une fois, afin que le pr\u00e9processeur du langage comprenne que c'est bien la cl\u00e9 primaire, suivie par toutes les autres colonnes \u2014 Clustering key. Celles-ci seront transmises au comparateur dans l'ordre dans lequel elles apparaissent. Donc, la premi\u00e8re colonne est plus significative, la deuxi\u00e8me l'est moins, et ainsi de suite. Comme nous l'\u00e9crivons pour les data classes, par exemple, les champs equals : nous \u00e9num\u00e9rons les champs et pr\u00e9cisons lesquels sont plus importants que d'autres. En Cassandra, ce sont, pour ainsi dire, les champs de la data class auxquels l'equals \u00e9crit pour elle s'appliquera.<\/p>\n
D\u00e9finissons le tri, imposons des contraintes<\/h2>\n
\nIl faut se rappeler que l'ordre de tri (d\u00e9croissant, croissant, peu importe) est d\u00e9fini au m\u00eame moment que la cr\u00e9ation de la cl\u00e9, et qu'il ne pourra pas \u00eatre chang\u00e9 ensuite. Cela d\u00e9termine physiquement comment les donn\u00e9es seront tri\u00e9es et comment elles seront stock\u00e9es. Si l'on souhaite modifier la Clustering key ou l'ordre de tri, il faudra cr\u00e9er une nouvelle table et y transf\u00e9rer les donn\u00e9es. Cela n'est pas possible avec une table existante.<\/p>\n
\"Cassandra.
\n
\nNous avons rempli notre table avec des utilisateurs et avons constat\u00e9 qu'ils se sont organis\u00e9s en anneau d'abord par ann\u00e9e de naissance, puis \u00e0 l'int\u00e9rieur sur chaque n\u0153ud par salaire et par ID utilisateur. Maintenant, nous pouvons faire des s\u00e9lections en imposant des contraintes. <\/p>\n
Notre fonctionnel r\u00e9appara\u00eet o\u00f9, et<\/code>, et les utilisateurs nous sont accessibles, tout est de nouveau en ordre. Mais si nous essayons d'utiliser seulement une partie de la Clustering key, et en plus une partie moins significative, Cassandra va imm\u00e9diatement signaler qu'elle ne peut pas trouver dans notre carte l'endroit o\u00f9 cet objet avec ces champs pour le comparateur est null, et cet autre que nous venons de d\u00e9finir \u2014 o\u00f9 il se trouve. Je devrai \u00e0 nouveau extraire toutes les donn\u00e9es de ce n\u0153ud et les filtrer. C'est l'\u00e9quivalent d'un Full Scan dans le cadre du n\u0153ud, ce qui est mauvais.<\/p>\n
Dans toute situation confuse, cr\u00e9ez une nouvelle table.<\/h2>\n
\nSi nous voulons pouvoir r\u00e9cup\u00e9rer des utilisateurs par ID, par \u00e2ge ou par salaire, que faire ? Rien. Il suffit d'utiliser deux tables. S'il faut r\u00e9cup\u00e9rer des utilisateurs de trois mani\u00e8res diff\u00e9rentes, il y aura trois tables. Le temps o\u00f9 nous \u00e9conomisions de l'espace sur le disque est r\u00e9volu. C'est la ressource la moins ch\u00e8re. Elle co\u00fbte beaucoup moins cher que le temps de r\u00e9ponse, qui peut \u00eatre pr\u00e9judiciable pour l'utilisateur. Il est beaucoup plus agr\u00e9able pour l'utilisateur de recevoir quelque chose en une seconde plut\u00f4t qu'en dix minutes.<\/p>\n
Nous \u00e9changeons l'espace de stockage excessif, des donn\u00e9es d\u00e9normalis\u00e9es contre la possibilit\u00e9 de bien \u00e9voluer et de fonctionner de mani\u00e8re fiable. En effet, un cluster compos\u00e9 de trois centres de donn\u00e9es, chacun avec cinq n\u0153uds, avec un niveau acceptable de conservation des donn\u00e9es (o\u00f9 rien ne sera perdu), est capable de survivre \u00e0 la perte d'un centre de donn\u00e9es entier. Et avec encore deux n\u0153uds dans chacun des deux centres restants. Et ce n'est qu'apr\u00e8s cela que les probl\u00e8mes commenceront. C'est une bonne redondance, cela co\u00fbte quelques disques SSD et processeurs suppl\u00e9mentaires. Ainsi, pour utiliser Cassandra, qui n\u2019est pas du tout SQL et qui n'a pas de relations ni de cl\u00e9s \u00e9trang\u00e8res, il faut conna\u00eetre des r\u00e8gles simples.<\/p>\n
Nous concevons tout \u00e0 partir de la requ\u00eate. Ce ne sont pas les donn\u00e9es qui sont les plus importantes, mais comment l'application va travailler avec elles. Si elle a besoin d'obtenir des donn\u00e9es diff\u00e9rentes de diff\u00e9rentes mani\u00e8res ou les m\u00eames donn\u00e9es de mani\u00e8res diff\u00e9rentes, nous devons les organiser de mani\u00e8re \u00e0 ce que cela convienne \u00e0 l'application. Sinon, nous tomberons dans un Full Scan et Cassandra ne nous apportera aucun avantage.<\/p>\n
D\u00e9normaliser les donn\u00e9es est la norme. Oublions les formes normales, nous n'avons plus de bases de donn\u00e9es relationnelles. Mettons quelque chose 100 fois, il sera stock\u00e9 100 fois. C'est toujours moins co\u00fbteux que de ralentir. <\/p>\n
Nous choisissons les cl\u00e9s pour le partitionnement de mani\u00e8re \u00e0 ce qu'elles soient bien r\u00e9parties. Nous n'avons pas besoin que le hachage de nos cl\u00e9s tombe dans une plage \u00e9troite. Par exemple, l'ann\u00e9e de naissance dans l'exemple ci-dessus est un mauvais exemple. En effet, il est bon si nos utilisateurs sont r\u00e9partis uniform\u00e9ment par ann\u00e9e de naissance, mais mauvais s\u2019il s'agit d'\u00e9l\u00e8ves de cinqui\u00e8me \u2014 cela ne se partitionnera pas tr\u00e8s bien. <\/p>\n
Le tri est s\u00e9lectionn\u00e9 une seule fois lors de la cr\u00e9ation de la cl\u00e9 de clustering. Si cela doit \u00eatre modifi\u00e9, il faudra transf\u00e9rer notre table avec une autre cl\u00e9.<\/p>\n
Et le plus important : si nous devons r\u00e9cup\u00e9rer les m\u00eames donn\u00e9es de 100 mani\u00e8res diff\u00e9rentes, cela signifie que nous aurons 100 tables diff\u00e9rentes.
\n
Source : 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. Comment ne pas mourir si vous ne connaissez que Oracle | ProHoster","description":"Bonjour, Habr. Je m'appelle Misha Boutrinov, je voudrais vous parler un peu de Cassandra.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/41081","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=41081"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/41081\/revisions"}],"predecessor-version":[{"id":164523,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/41081\/revisions\/164523"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/41082"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=41081"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=41081"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=41081"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}