{"id":263,"date":"2016-02-02T19:19:31","date_gmt":"2016-02-02T18:19:31","guid":{"rendered":"https:\/\/www.carajandb.com\/2016\/02\/02\/inmemory-on-oracle-rac-en\/"},"modified":"2018-02-09T10:20:19","modified_gmt":"2018-02-09T09:20:19","slug":"inmemory-on-oracle-rac-en","status":"publish","type":"post","link":"https:\/\/carajandb.com\/en\/2016\/02\/02\/inmemory-on-oracle-rac-en\/","title":{"rendered":"inMemory on Oracle RAC"},"content":{"rendered":"<p>In my last <a href=\"index.php?option=com_content&amp;view=article&amp;id=258:oracle-inmemory-first-experiences-en&amp;catid=27:johannes-ahrends-en&amp;Itemid=170\" target=\"_blank\" rel=\"noopener\">blog <\/a>I described my first experience with inMemory at a customer side. I was really impressed about the massive performance gain and the ease of use. Now it&#8217;s time for a second trial. As stated earlier the customer was using a single instance database as test environment but the production and preproduction were running on Oracle RAC. This again shows how important it is to have the same environment for preproduction and production &#8211; or better for test as well as that whould have shown the non comparable results early enough and not just before it went to production.<br \/>\n<!--more--><br \/>\nAs with the first blob we had a couple of simple and complex queries which I&#8217;m unfortunately not allowed to use here. So I will use my own environment again.<br \/>\nThe first query is a simple count on a simple table while the more complex is a join with 4 dimension tables and one fact table so a simple star scheme. At the customer we had some more complex snowflake schemes with up to 4 facts and couple of dimensions but the results where exactly the same as described here.<br \/>\nFirst we again load the tables with the fact table as the most critical and the dimensions with priority &#8220;high&#8221;.<br \/>\nAs usual I was not reading the entire document first so to my suprise after loading the tables the first query (SELECT COUNT(*) FROM umsaetze&#8221; took more than 10 (!) minutes. Remember the query on a single instance without inMemory was using about 40 seconds and with inMemory around one! So what did we do wrong? Lets look for the data population:<\/p>\n<pre>\r\nSELECT inst_id, segment_name,  inmemory_size, bytes, bytes_not_populated, populate_status\r\n  FROM v$im_user_segments\r\n\r\nSEGMENT_NAME         INMEMORY_SIZE      BYTES BYTES_NOT_POPULATED POPULATE_\r\n-------------------- ------------- ---------- ------------------- ---------\r\nREGION                     1179648     393216                   0 COMPLETED\r\nKUNDEN                    11665408   83886080            40189952 COMPLETED\r\nUMSAETZE                1452670976 6978273280          3163938816 COMPLETED\r\nZEITEN                     1179648     131072                   0 COMPLETED\r\n<\/pre>\n<p>Okay, no wonder: While REGION and ZEITEN (TIMES) have been entirely loaded KUNDEN (CUSTOMERS) and the fact table UMSAETZE (REVENUE) have only been loaded partly. After talking to the DBA (we had no direct access to the database so had to phone the DBA) we found that we really did not had sufficient memory. So he increased the parameter inmemory_size so it should be suitable for the all tables.<\/p>\n<p>Second trial &#8211; no difference, again 400 seconds and the query on v$im_user_segments shows the same result. But we are on a RAC database. So v$ is probably not the right view but gv$ is:<\/p>\n<pre>\r\nSELECT inst_id, segment_name,  inmemory_size, bytes, bytes_not_populated, populate_status\r\n  FROM gv$im_user_segments\r\n\r\n   INST_ID SEGMENT_NAME         INMEMORY_SIZE      BYTES BYTES_NOT_POPULATED POPULATE_\r\n---------- -------------------- ------------- ---------- ------------------- ---------\r\n         2 REGION                     1179648     393216                   0 COMPLETED\r\n         2 KUNDEN                    11665408   83886080            40189952 COMPLETED\r\n         2 UMSAETZE                1452670976 6978273280          3163938816 COMPLETED\r\n         2 ZEITEN                     1179648     131072                   0 COMPLETED\r\n         1 KUNDEN                    12713984   83886080            39043072 COMPLETED\r\n         1 UMSAETZE                1237254144 6978273280          3740106752 COMPLETED\r\n<\/pre>\n<h2>Parallelism<\/h2>\n<p>As you can see, the tables KUNDEN and UMSATZE are completely populated but distributed between the two instances. Okay if I had read the documentation I would have realized that the tables will be distributed between the instances when using RAC. This implies that you have to use inter instance parallelism for your queries.<\/p>\n<p>So next trial with the parameter &#8220;parallel_degree_policy=AUTO;&#8221;<\/p>\n<p>So let&#8217;s execute the query again:<\/p>\n<pre>\r\nSELECT count(*)\r\nFROM\r\n umsaetze\r\n\r\nSQL&gt;\r\n  COUNT(*)\r\n----------\r\n 144500000\r\n\r\nElapsed: 00:00:00.93\r\n\r\n\r\ncall     count       cpu    elapsed       disk      query    current        rows\r\n------- ------  -------- ---------- ---------- ---------- ----------  ----------\r\nParse        1      0.01       0.01          0          2          0           0\r\nExecute      1      0.01       0.27          0          5          0           0\r\nFetch        2      0.05       0.56          0          0          0           1\r\n------- ------  -------- ---------- ---------- ---------- ----------  ----------\r\ntotal        4      0.08       0.85          0          7          0           1\r\n\r\nMisses in library cache during parse: 1\r\nOptimizer mode: ALL_ROWS\r\nParsing user id: 103\r\nNumber of plan statistics captured: 1\r\n\r\nRows (1st) Rows (avg) Rows (max)  Row Source Operation\r\n---------- ---------- ----------  ---------------------------------------------------\r\n         1          1          1  SORT AGGREGATE (cr=5 pr=0 pw=0 time=784786 us)\r\n        14         14         14   PX COORDINATOR  (cr=5 pr=0 pw=0 time=479066 us)\r\n         0          0          0    PX SEND QC (RANDOM) :TQ10000 (cr=0 pr=0 pw=0 time=0 us)\r\n         0          0          0     SORT AGGREGATE (cr=0 pr=0 pw=0 time=0 us)\r\n         0          0          0      PX BLOCK ITERATOR (cr=0 pr=0 pw=0 time=0 us cost=2183 size=0 card=144500000)\r\n         0          0          0       TABLE ACCESS INMEMORY FULL UMSAETZE (cr=0 pr=0 pw=0 time=0 us cost=2183 size=0 card=144500000)\r\n\t\t <\/pre>\n<p>Impressive: less than one second!<\/p>\n<p>So the result is to use parallelism when using RAC (actually the documentation just says that).<\/p>\n<h2>Complex Query<\/h2>\n<p>But I didn&#8217;t had a good feeling. What about a more complex query that might not benefit from parallelism? Let me run the complex query (again with automatic parallelism):<\/p>\n<pre>SELECT sum(u.umsatz) as gesamtumsatz,\r\n       a.artikelgruppe,\r\n       z.monat_des_jahres,\r\n       z.jahreszahl,\r\n       r.region,\r\n       k.plz,\r\n       k.ort\r\n  FROM region r\r\n       INNER JOIN umsaetze u ON (r.region_id = u.region_id)\r\n       INNER JOIN kunden k ON (k.kunden_id = u.kunden_id)\r\n       INNER JOIN artikel a ON (a.artikel_id = u.artikel_id)\r\n       INNER JOIN zeiten z ON (zeiten_id = zeit_id)\r\n WHERE r.region = 'Nord'\r\n   AND z.jahreszahl in (2014,2015)\r\n   AND z.monat_des_jahres = 12\r\n GROUP BY a.artikelgruppe, z.monat_des_jahres, z.jahreszahl, k.plz, k.ort, r.region\r\n FETCH FIRST 10 PERCENT ROWS ONLY\r\n\r\ncall     count       cpu    elapsed       disk      query    current        rows\r\n------- ------  -------- ---------- ---------- ---------- ----------  ----------\r\nParse        1      0.20       0.52          1          5          0           0\r\nExecute      1      0.00       0.05          0          0          0           0\r\nFetch       88     78.74     309.07     602615     626637          0        1304\r\n------- ------  -------- ---------- ---------- ---------- ----------  ----------\r\ntotal       90     78.94     309.64     602616     626642          0        1304\r\n\r\nMisses in library cache during parse: 1\r\nOptimizer mode: ALL_ROWS\r\nParsing user id: 103\r\nNumber of plan statistics captured: 1\r\n\r\nRows (1st) Rows (avg) Rows (max)  Row Source Operation\r\n---------- ---------- ----------  ---------------------------------------------------\r\n      1304       1304       1304  VIEW  (cr=626637 pr=602615 pw=0 time=309120365 us cost=61732 size=188525563 card=1376099)\r\n     13031      13031      13031   WINDOW BUFFER (cr=626637 pr=602615 pw=0 time=309125958 us cost=61732 size=112840118 card=1376099)\r\n     13031      13031      13031    HASH GROUP BY (cr=626637 pr=602615 pw=0 time=309111308 us cost=61732 size=112840118 card=1376099)\r\n    511356     511356     511356     HASH JOIN  (cr=626637 pr=602615 pw=0 time=302369604 us cost=35455 size=112840118 card=1376099)\r\n       374        374        374      TABLE ACCESS INMEMORY FULL ARTIKEL (cr=5 pr=3 pw=0 time=18590 us cost=1 size=5984 card=374)\r\n    511356     511356     511356      HASH JOIN  (cr=626632 pr=602612 pw=0 time=302126752 us cost=35451 size=90822534 card=1376099)\r\n   1000000    1000000    1000000       TABLE ACCESS INMEMORY FULL KUNDEN (cr=4770 pr=4766 pw=0 time=75903 us cost=115 size=22000000 card=1000000)\r\n    511356     511356     511356       HASH JOIN  (cr=621862 pr=597846 pw=0 time=300198624 us cost=30075 size=60548356 card=1376099)\r\n      1351       1351       1351        TABLE ACCESS INMEMORY FULL REGION (cr=41 pr=37 pw=0 time=9573 us cost=1 size=12159 card=1351)\r\n   3128202    3128202    3128202        HASH JOIN  (cr=621821 pr=597809 pw=0 time=302970633 us cost=30058 size=217609035 card=6217401)\r\n        32         32         32         JOIN FILTER CREATE :BF0000 (cr=14 pr=0 pw=0 time=626 us cost=1 size=594 card=54)\r\n        32         32         32          TABLE ACCESS INMEMORY FULL ZEITEN (cr=14 pr=0 pw=0 time=492 us cost=1 size=594 card=54)\r\n   3128202    3128202    3128202         JOIN FILTER USE :BF0000 (cr=621807 pr=597809 pw=0 time=301926572 us cost=29693 size=3468000000 card=144500000)\r\n   3128202    3128202    3128202          TABLE ACCESS INMEMORY FULL UMSAETZE (cr=621807 pr=597809 pw=0 time=301826778 us cost=29693 size=3468000000 card=144500000)\r\n<\/pre>\n<p>Frustrating! Even though both inMemory and BloomFilter (BF) have been used the query took about 300 seconds (instead of 70 without inMemory and 3 seconds with single instance and inMemory). Very disappointing!<\/p>\n<p>So queries which cannot benefit from the parallelism will take much longer than on a single instance database. Looking in the documentation I found that there is an option &#8220;DUPLICATE&#8221; with the ALTER TABLE INMEMORY command (e.g. ALTER TABLE umsaetze INMEMORY DUPLICATE PRIORITY CRITICAL). Unforunately that parameter is for engineered systems only. So even though the parameter is correctly shown in the v$im_user_segments it does not work. The tables will always be distributed.<\/p>\n<p>We validate that inMemory works on that platform in principial we asked the DBA to shut down one instance and as expected the query run in the expected time:<\/p>\n<pre>\r\ncall     count       cpu    elapsed       disk      query    current        rows\r\n------- ------  -------- ---------- ---------- ---------- ----------  ----------\r\nParse        1      0.25       0.27          0          5          0           0\r\nExecute      1      0.00       0.00          0          0          0           0\r\nFetch       88      1.50       1.61          0         17          0        1304\r\n------- ------  -------- ---------- ---------- ---------- ----------  ----------\r\ntotal       90      1.76       1.89          0         22          0        1304\r\n\r\nMisses in library cache during parse: 1\r\nOptimizer mode: ALL_ROWS\r\nParsing user id: 103\r\nNumber of plan statistics captured: 1\r\n\r\nRows (1st) Rows (avg) Rows (max)  Row Source Operation\r\n---------- ---------- ----------  ---------------------------------------------------\r\n      1304       1304       1304  VIEW  (cr=17 pr=0 pw=0 time=1606149 us cost=18577 size=1785247 card=13031)\r\n     13031      13031      13031   WINDOW BUFFER (cr=17 pr=0 pw=0 time=1611588 us cost=18577 size=1068542 card=13031)\r\n     13031      13031      13031    HASH GROUP BY (cr=17 pr=0 pw=0 time=1600326 us cost=18577 size=1068542 card=13031)\r\n    511356     511356     511356     HASH JOIN  (cr=17 pr=0 pw=0 time=1432922 us cost=14973 size=41931192 card=511356)\r\n       374        374        374      TABLE ACCESS INMEMORY FULL ARTIKEL (cr=5 pr=0 pw=0 time=157 us cost=1 size=5984 card=374)\r\n    511356     511356     511356      HASH JOIN  (cr=12 pr=0 pw=0 time=1335242 us cost=14971 size=33749496 card=511356)\r\n    511356     511356     511356       HASH JOIN  (cr=9 pr=0 pw=0 time=827741 us cost=11851 size=22499664 card=511356)\r\n      1351       1351       1351        TABLE ACCESS INMEMORY FULL REGION (cr=3 pr=0 pw=0 time=21736 us cost=4 size=12159 card=1351)\r\n   3128202    3128202    3128202        HASH JOIN  (cr=6 pr=0 pw=0 time=705636 us cost=11839 size=118395025 card=3382715)\r\n        32         32         32         JOIN FILTER CREATE :BF0000 (cr=3 pr=0 pw=0 time=29789 us cost=4 size=594 card=54)\r\n        32         32         32          TABLE ACCESS INMEMORY FULL ZEITEN (cr=3 pr=0 pw=0 time=29723 us cost=4 size=594 card=54)\r\n   3128202    3128202    3128202         JOIN FILTER USE :BF0000 (cr=3 pr=0 pw=0 time=189813 us cost=11471 size=3468000000 card=144500000)\r\n   3128202    3128202    3128202          TABLE ACCESS INMEMORY FULL UMSAETZE (cr=3 pr=0 pw=0 time=180968 us cost=11471 size=3468000000 card=144500000)\r\n   1000000    1000000    1000000       TABLE ACCESS INMEMORY FULL KUNDEN (cr=3 pr=0 pw=0 time=30677 us cost=151 size=22000000 card=1000000)\r\n<\/pre>\n<p>Less than two seconds for the query.<\/p>\n<h2>Conclusion<\/h2>\n<p>But what is the outcome?<br \/>\nI don&#8217;t see any benefit of distributing tables across cluster instances. Yes a simple query might use parallelism but I cannot rely on it and on the opposite the query might run 10 times slower than without inMemory.\u00a0Users with ngineered systems might want to use the option &#8220;DUPLICATE&#8221; to populate the entire tables on all RAC instances. That&#8217;s for sure the most effective way of using inMemory with RAC as you can distribute the connections.\u00a0In the event of an instance failure the tables will be automatically redistributed so inMemory is fail safe.\u00a0Customers with RAC on non engineered systems need a workaround!<\/p>\n<h2>Workaround<\/h2>\n<p>Actually there are two workarounds available. I&#8217;ve tested one hat it works okay: There is an undocumented parameter named &#8220;_inmemory_auto_distribute&#8221;. If you set this parameter on both instances you can reload the tables on both instances. So it looks like it is similar to the DUPLICATE parameter &#8211; no idea why Oracle doesn&#8217;t make that documented. Another solution will be use a parallel instance group service (paralle_instance_group) that is bound to one instance. I will test that and let you know if that&#8217;s preferrable or not. In the meantime I would appreciate your feedback and experience.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In my last blog I described my first experience with inMemory at a customer side. I was really impressed about the massive performance gain and the ease of use. Now it&#8217;s time for a second trial. As stated earlier the customer was using a single instance database as test environment but the production and preproduction were running on Oracle RAC. This again shows how important it is to have the same environment for preproduction and production &#8211; or better for test as well as that whould have shown the non comparable results early enough and not just before it went [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","_uag_custom_page_level_css":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[],"tags":[221,22,41,73,75],"class_list":["post-263","post","type-post","status-publish","format-standard","hentry","tag-inmemory","tag-oracle","tag-oracle-12c","tag-rac","tag-real-application-clusters"],"acf":{"occupation":"Write the Occupation of the Person","person_can-be-speaker":true,"person_is-team":true,"person_related-user-account":null,"person_ordering-number":50,"publication_speakers":null,"publication_content-language":["de"],"publication_files":null,"publication_event":"","publication_date":null},"spectra_custom_meta":{"_fgj2wp_old_id":["263"],"_yoast_wpseo_metadesc":["Oracle inMemory"],"_yoast_wpseo_metakeywords":["Oracle, inMemory, RAC, Real Application Clusters, Oracle 12c"],"_fgj2wp_translation_association_key":["3b100210969d8cdf2ab692d16de73b10"],"layout_show-author-box":["1"],"_layout_show-author-box":["field_5a64ee9cc6490"],"_edit_lock":["1518168058:3"],"_yoast_wpseo_content_score":["90"],"_edit_last":["3"],"_vc_post_settings":["a:1:{s:10:\"vc_grid_id\";a:0:{}}"],"layout_header":["light"],"_layout_header":["field_5a48111185e5f"],"layout_background":[""],"_layout_background":["field_5a481193c0995"],"layout_hide_services":["0"],"_layout_hide_services":["field_5a4811c5c0996"],"layout_show-categories-tags":["1"],"_layout_show-categories-tags":["field_5a64eee4c6491"],"blogpost_related-publications":[""],"_blogpost_related-publications":["field_5a480debdac62"],"blogpost_related-files":[""],"_blogpost_related-files":["field_5a480f377db29"],"_yoast_wpseo_primary_category":[""],"_wpml_location_migration_done":["1"],"rank_math_primary_category":[""],"rank_math_description":["Oracle inMemory"],"rank_math_news_sitemap_robots":["index"],"rank_math_robots":["a:1:{i:0;s:5:\"index\";}"],"rank_math_internal_links_processed":["1"],"astra_style_timestamp_css":["1777776219"],"wpil_sync_report3":["1"],"wpil_links_inbound_internal_count":["0"],"wpil_links_inbound_internal_count_data":["eJxLtDKwqq4FAAZPAf4="],"wpil_links_outbound_internal_count":["1"],"wpil_links_outbound_internal_count_data":["eJx1UU1vwjAM\/S897FZoC6zICO08aR\/HHaM08WggdaI0HSDEf59TKsQOu9kv79nPLxJKuBgoNp9QriD78saKd6fRijdDhwzKBVx6qCGz3Aqjs00i97CAbAg246qsWdfG6GE+D2jlQKqtimo5UzLIvSTdzJTr5oY0nma+9S\/OR+Noy6BQjiJSfJKd3\/wYPG5liEZZHAGjt9VqDS5IRnJDHXYunPNvE\/qY48ljMEgK+xxp5CsZk6SGvWslET\/INiDpO+E1YseMsi6S7yW7dn1MZfUM2f\/WE2MNmWGrgSTf3EB50\/tR\/8END5AsdmGa3Fi3G8PhbKTWqEVzFt4OO0NJX9xGWpc8O0pMjnhKY3RUTIkfW9PzpUIFlBHv8ZclG+qFHKJLtEc4cl4HQ7uHz0pw5\/RgUfxhV9OScfEp3vDr9Rc5ZLH3"],"wpil_links_outbound_external_count":["0"],"wpil_links_outbound_external_count_data":["eJxLtDKwqq4FAAZPAf4="],"wpil_sync_report2_time":["2024-08-27T11:47:28+00:00"],"copied_media_ids":["a:0:{}"],"referenced_media_ids":["a:0:{}"],"_uag_css_file_name":["uag-css-263.css"]},"uagb_featured_image_src":{"full":false,"thumbnail":false,"medium":false,"medium_large":false,"large":false,"1536x1536":false,"2048x2048":false},"uagb_author_info":{"display_name":"Johannes Ahrends","author_link":"https:\/\/carajandb.com\/en\/author\/9aa6cdb2095bd409\/"},"uagb_comment_info":4,"uagb_excerpt":"In my last blog I described my first experience with inMemory at a customer side. I was really impressed about the massive performance gain and the ease of use. Now it&#8217;s time for a second trial. As stated earlier the customer was using a single instance database as test environment but the production and preproduction&hellip;","_links":{"self":[{"href":"https:\/\/carajandb.com\/en\/wp-json\/wp\/v2\/posts\/263","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/carajandb.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/carajandb.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/carajandb.com\/en\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/carajandb.com\/en\/wp-json\/wp\/v2\/comments?post=263"}],"version-history":[{"count":0,"href":"https:\/\/carajandb.com\/en\/wp-json\/wp\/v2\/posts\/263\/revisions"}],"wp:attachment":[{"href":"https:\/\/carajandb.com\/en\/wp-json\/wp\/v2\/media?parent=263"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/carajandb.com\/en\/wp-json\/wp\/v2\/categories?post=263"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/carajandb.com\/en\/wp-json\/wp\/v2\/tags?post=263"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}