{"id":36737,"date":"2019-10-31T22:13:29","date_gmt":"2019-10-31T19:13:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov\/"},"modified":"2019-10-31T22:13:29","modified_gmt":"2019-10-31T19:13:29","slug":"kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov","title":{"rendered":"Hoe we verschillende tijdreeksdatabases hebben getest","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Hoe we verschillende tijdreeksdatabases hebben getest\" src=\"\/wp-content\/uploads\/2019\/08\/14e07eac02df8d1276c46c33276d8a26.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn de afgelopen jaren zijn tijdreeksdatabases (Time-series databases) ge\u00ebvolueerd van een vreemde product (specifiek toegepast in open monitoringssystemen of in Big Data-projecten) naar een 'consumptiegoed'. In Rusland verdienen Yandex en ClickHouse hiervoor een speciale vermelding. Tot dat moment, als je een grote hoeveelheid tijdreeksdata moest opslaan, moest je ofwel accepteren dat je een monsterlijke Hadoop-stack moest opzetten en onderhouden, ofwel omgaan met protocollen die specifiek waren voor elk systeem. <\/p>\n<p>Het kan lijken dat in het jaar 2019 een artikel over welke TSDB te gebruiken slechts uit \u00e9\u00e9n zin zou bestaan: 'gebruik gewoon ClickHouse'. Maar\u2026 er zijn nuances. <\/p>\n<p>Inderdaad, ClickHouse is actief in ontwikkeling, groeit de gebruikersbasis gestaag, en wordt de ondersteuning zeer actief verleend. Maar zijn we niet gevangen in het publieke succes van ClickHouse, dat misschien andere, mogelijk effici\u00ebntere\/meer betrouwbare oplossingen overschaduwt? <\/p>\n<p>Aan het begin van vorig jaar zijn we begonnen met het herontwerpen van ons eigen monitoringsysteem, waarbij de vraag naar een geschikte database voor gegevensopslag opkwam. Over het verhaal van deze keuze wil ik hier vertellen.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h4>Taakstelling<\/h4>\n<p>\nVoordat we beginnen, een noodzakelijke inleiding. Waarom hebben we eigenlijk ons eigen monitoringsysteem en hoe was het opgezet?<\/p>\n<p>We begonnen in 2008 met het bieden van ondersteuningsdiensten, en in 2010 werd het duidelijk dat het moeilijk werd om gegevens over de processen in de klantinfrastructuur te aggregeren met de oplossingen die destijds beschikbaar waren (we hebben het over, sorry voor het ongemak, Cacti, Zabbix en het opkomende Graphite).<\/p>\n<p>Onze belangrijkste vereisten waren:<\/p>\n<ul>\n<li>ondersteuning (op dat moment - tientallen, en in de toekomst - honderden) klanten binnen \u00e9\u00e9n systeem en tegelijkertijd een gecentraliseerd systeem voor meldingen;<\/li>\n<li>flexibiliteit in het beheer van het meldingssysteem (escalatie van meldingen tussen diensten, rekening houdend met schema's, kennisbank);<\/li>\n<li>de mogelijkheid voor diepgaande detaillering van grafieken (Zabbix tekende op dat moment grafieken als afbeeldingen);<\/li>\n<li>langdurige opslag van grote hoeveelheden data (een jaar of langer) en de mogelijkheid voor snelle querying.<\/li>\n<\/ul>\n<p>\nIn dit artikel is het laatste punt ons belangrijkste aandachtspunt.<\/p>\n<p>Als we het hebben over opslag, waren de vereisten als volgt:<\/p>\n<ul>\n<li>het systeem moet snel werken;<\/li>\n<li>het is wenselijk dat het systeem een SQL-interface heeft;<\/li>\n<li>het systeem moet stabiel zijn en een actieve gebruikersbasis en ondersteuning hebben (we hebben ooit te maken gehad met de noodzaak om dergelijke systemen te ondersteunen, zoals MemcacheDB, dat niet verder werd ontwikkeld, of het gedistribueerde opslagmiddel MooseFS, waarvan de bugtracker in het Chinees werd geleid: we wilden deze geschiedenis voor ons project niet herhalen);<\/li>\n<li>naleving aan de CAP-theorema: Consistentie (vereist) - de gegevens moeten actueel zijn, we willen niet dat het meldingssysteem geen nieuwe gegevens ontvangt en ons overspoelt met meldingen over het ontbreken van gegevens in al onze projecten; Partition Tolerance (vereist) - we willen geen Split Brain-systeem; Beschikbaarheid (niet kritisch, als er een actieve replica is) - we kunnen zelf overschakelen naar het reservesysteem in geval van een storing, via code.<\/li>\n<\/ul>\n<p>\nVerrassend genoeg bleek MySQL op dat moment de ideale oplossing voor ons te zijn. Onze datastructuur was uiterst eenvoudig: server-id, teller-id, timestamp en waarde; snelle selectie van belangrijke gegevens werd verzekerd door een grote bufferpool, en de selectie van historische gegevens gebeurde via SSD.<\/p>\n<p><img decoding=\"async\" alt=\"Hoe we verschillende tijdreeksdatabases hebben getest\" src=\"\/wp-content\/uploads\/2019\/08\/555bff26c74badf85131c4d9198871af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZo bereikten we de selectie van verse gegevens van twee weken oud, met een resolutie tot op de seconde voor 200 ms v\u00f3\u00f3r het volledig renderen van de gegevens, en we gebruikten dit systeem vrij lang.<\/p>\n<p>Ondertussen ging de tijd voorbij en groeide de hoeveelheid gegevens. Tegen 2016 had de hoeveelheid gegevens tientallen terabytes bereikt, wat een aanzienlijke kostenpost was in de huur van SSD-opslag.<\/p>\n<p>Op dat moment waren kolomgeori\u00ebnteerde databases in opkomst, waar we actief over gingen nadenken: in kolomgeori\u00ebnteerde databases worden gegevens, zoals je kunt begrijpen, in kolommen opgeslagen, en als je naar onze gegevens kijkt, zie je gemakkelijk een groot aantal duplicaten, die in het geval van het gebruik van een kolomgeori\u00ebnteerde database gecomprimeerd konden worden.<\/p>\n<p><img decoding=\"async\" alt=\"Hoe we verschillende tijdreeksdatabases hebben getest\" src=\"\/wp-content\/uploads\/2019\/08\/2e1a6010fcb09de8cd28ec826752d160.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nToch bleef het cruciale systeem van het bedrijf stabiel functioneren, en we wilden niet experimenteren met de overstap naar iets anders.<\/p>\n<p>In 2017, at the Percona Live conference in San Jose, the developers of Clickhouse probably introduced themselves for the first time. At first glance, the system seemed production-ready (after all, Yandex.Metrica is serious production), support was quick and straightforward, and most importantly, operation was simple. Since 2018, we started the transition process. However, by that time, there were many 'mature' and time-tested TSDB systems, and we decided to take a significant amount of time to compare alternatives to ensure that there were no alternatives to Clickhouse that met our requirements.<\/p>\n<p>In addition to the requirements already specified for the storage, new ones have emerged:<\/p>\n<ul>\n<li>the new system must provide at least the same performance as MySQL on the same hardware;<\/li>\n<li>the storage of the new system should take up significantly less space;<\/li>\n<li>the DBMS must still be easy to manage;<\/li>\n<li>we wanted to change the application as little as possible when switching databases.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Which systems did we start considering<\/h4>\n<p>\n<b><u>Apache Hive\/Apache Impala<\/u><\/b><br \/>\nA well-established Hadoop stack. Essentially, this is a SQL interface built on top of data stored in proprietary formats on HDFS. <\/p>\n<p>Advantages.<\/p>\n<ul>\n<li>With stable operation, it is very easy to scale data.<\/li>\n<li>There are columnar data storage solutions (less space).<\/li>\n<li>Very fast execution of parallelized tasks when resources are available.<\/li>\n<\/ul>\n<p>\nCons.<\/p>\n<ul>\n<li>It\u2019s Hadoop, and it\u2019s complex to operate. If we are not ready to take a ready-made solution in the cloud (and we are not ready due to cost), the entire stack will have to be assembled and maintained by admins, which is something we really don\u2019t want.<\/li>\n<li>Data aggregates <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/blog\/2014\/04\/21\/using-apache-hadoop-and-impala-together-with-mysql-for-data-analysis\/\">really fast<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nHowever:<\/p>\n<p><img decoding=\"async\" alt=\"Hoe we verschillende tijdreeksdatabases hebben getest\" src=\"\/wp-content\/uploads\/2019\/08\/6baa1b6024def8c1c7518ef386cfc8d3.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSpeed is achieved by scaling the number of computing servers. Simply put, if we are a large company engaged in analytics and it is critically important for the business to aggregate information as quickly as possible (even at the cost of using a large amount of computational resources), this may be our choice. But we were not ready to drastically increase our hardware capacity for task execution speed.<\/p>\n<p><b><u>Druid\/Pinot<\/u><\/b><\/p>\n<p>Now much more about specifically TSDB, but again \u2014 a Hadoop stack.<\/p>\n<p>Er is <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@leventov\/comparison-of-the-open-source-olap-systems-for-big-data-clickhouse-druid-and-pinot-8e042a5ed1c7\">an excellent article comparing the pros and cons of Druid and Pinot against ClickHouse <\/a><\/noindex>. <\/p>\n<p>In enkele woorden: Druid\/Pinot presteren beter dan ClickHouse in situaties waarbij:<\/p>\n<ul>\n<li>U heeft een heterogene gegevensstructuur (in ons geval registreren we alleen tijdreeksen van servermetriek, en in wezen is dit \u00e9\u00e9n tabel. Maar er kunnen ook andere gevallen zijn: tijdreeksen van apparatuur, economische tijdreeksen, enz. \u2014 elk met zijn eigen structuur die verzameld en verwerkt moet worden).<\/li>\n<li>Er is echter heel veel van deze gegevens.<\/li>\n<li>Tafels en gegevens met tijdreeksen komen en gaan (dat wil zeggen, een bepaalde set gegevens komt binnen, wordt geanalyseerd en verwijderd).<\/li>\n<li>Er is geen duidelijke criteria waarop gegevens gepartitioneerd kunnen worden.<\/li>\n<\/ul>\n<p>\nIn de tegenovergestelde gevallen presteert ClickHouse beter, en dat is ons geval.<\/p>\n<p><b><u>ClickHouse<\/u><\/b><\/p>\n<ul>\n<li>SQL-achtig.<\/li>\n<li>Eenvoudig in het beheer.<\/li>\n<li>Mensen zeggen dat het werkt.<\/li>\n<\/ul>\n<p>\nKomt op de shortlist voor testen.<\/p>\n<p><b><u>InfluxDB<\/u><\/b><\/p>\n<p>Buitenlandse alternatieven voor ClickHouse. Nadelen: High Availability is alleen beschikbaar in de commerci\u00eble versie, maar dat moet nog vergeleken worden.<\/p>\n<p>Komt op de shortlist voor testen.<\/p>\n<p><b><u>Cassandra<\/u><\/b> <\/p>\n<p>Aan de andere kant weten we dat het wordt gebruikt voor het opslaan van metrische tijdreeksen door monitoring systemen zoals bijvoorbeeld, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.signalfx.com\/blog\/making-cassandra-perform-as-a-tsdb\/\">SignalFX<\/a><\/noindex> of OkMeter. Er zijn echter specifieke details.<\/p>\n<p>Cassandra is geen kolomgebaseerde database in de gebruikelijke zin. Het lijkt meer op een rij-gebaseerde, maar in elke rij kan een verschillend aantal kolommen zitten, waardoor een kolomachtige weergave gemakkelijk kan worden georganiseerd. In dit opzicht is het begrijpelijk dat met een limiet van 2 miljard kolommen bepaalde gegevens juist in kolommen kunnen worden opgeslagen (dezelfde tijdreeksen). Bijvoorbeeld, MySQL heeft een limiet van 4096 kolommen en daar kun je gemakkelijk een fout met code 1117 tegenkomen als je probeert hetzelfde te doen.<\/p>\n<p>De Cassandra-engine is gericht op het opslaan van grote hoeveelheden gegevens in een gedistribueerd systeem zonder een master, en volgens de eerder genoemde CAP-theorema is Cassandra meer gericht op AP, dat wil zeggen, op gegevensbeschikbaarheid en weerstand tegen partitionering. Hierdoor kan dit hulpmiddel uitstekend geschikt zijn als je alleen naar deze database wilt schrijven en er voldoende zelden uit leest. Het is logisch om Cassandra te gebruiken als een 'koud' opslagmedium. Dit betekent dat het functioneert als een langdurige betrouwbare opslagplaats voor grote hoeveelheden historische data die zelden nodig zijn, maar indien nodig kunnen worden opgehaald. Niettemin, om een compleet beeld te krijgen, zullen we het ook testen. Maar, zoals ik eerder zei, is er geen verlangen om de code actief aan te passen aan de gekozen database-oplossing, dus we zullen het vrij beperkt testen - zonder de database-structuur aan te passen aan de specificaties van Cassandra.<\/p>\n<p><b><u>Prometheus<\/u><\/b><\/p>\n<p>Uit nieuwsgierigheid hebben we besloten om de prestaties van de Prometheus-opslag te testen - gewoon om te begrijpen of we sneller zijn dan de huidige oplossingen of trager, en in welke mate.<\/p>\n<h4>Testmethodologie en resultaten<\/h4>\n<p>\nWe hebben 5 databases getest in de volgende 6 configuraties: ClickHouse (1 node), ClickHouse (gedistribueerde tabel op 3 nodes), InfluxDB, Mysql 8, Cassandra (3 nodes) en Prometheus. Het testplan is als volgt:<\/p>\n<ol>\n<li>we laden historische gegevens van een week (840 miljoen waarden per dag; 208 duizend metrics);<\/li>\n<li>we genereren schrijfbelasting (we beschouwden 6 belastingmodi, zie hieronder);<\/li>\n<li>tijdens het schrijven doen we af en toe selecties om gebruikersverzoeken na te simuleren, terwijl ze met grafieken werken. Om het niet te gecompliceerd te maken, kozen we gegevens van 10 metrics (precies het aantal dat op de CPU-grafiek staat) voor een week.<\/li>\n<\/ol>\n<p>\nWe maken een belasting na die het gedrag simuleert van onze monitoringagent, die elke 15 seconden waarden naar elke metric verzendt. Hierbij is het voor ons interessant om te vari\u00ebren:<\/p>\n<ul>\n<li>het totale aantal metrics waarin gegevens worden geschreven;<\/li>\n<li>de verzendinterval van waarden naar eenmetric;<\/li>\n<li>de batchgrootte.<\/li>\n<\/ul>\n<p>\nOver de batchgrootte. Aangezien de meeste van onze proefdatabases niet aanbevolen zijn voor belasting met enkele inserts, hebben we een relay nodig dat de binnenkomende metrics verzamelt en ze op enige wijze groepeert en ze als batchinsert in de database schrijft.<\/p>\n<p>Ook om beter te begrijpen hoe we de verkregen gegevens later moeten interpreteren, laten we ons voorstellen dat we niet gewoon een hoop metrics verzenden, maar dat de metrics zijn georganiseerd in servers \u2014 125 metrics per server. Hier is de server gewoon een virtuele entiteit \u2014 alleen om te begrijpen dat bijvoorbeeld 10.000 metrics ongeveer overeenkomen met 80 servers.<\/p>\n<p>En dus, rekening houdend met dit alles, zijn hier onze 6 schrijf laadmodi voor de database:<\/p>\n<p><img decoding=\"async\" alt=\"Hoe we verschillende tijdreeksdatabases hebben getest\" src=\"\/wp-content\/uploads\/2019\/08\/3ba70050dc7e711cb8f3d14ac1a6707b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEr zijn hier twee aspecten. Ten eerste bleken dergelijke batchgroottes voor Cassandra te groot, daar gebruikten we waarden van 50 of 100. Ten tweede, aangezien Prometheus strikt in pull-modus werkt, dat wil zeggen dat het zelf gegevens ophaalt van metrics bronnen (en zelfs pushgateway, ondanks zijn naam, verandert de situatie fundamenteel niet), werden de bijbehorende belastingen gerealiseerd door een combinatie van statische configuraties.<\/p>\n<p>De testresultaten zijn als volgt:<\/p>\n<p><img decoding=\"async\" alt=\"Hoe we verschillende tijdreeksdatabases hebben getest\" src=\"\/wp-content\/uploads\/2019\/08\/9df12bee66ad8c5df720ba08472efead.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Hoe we verschillende tijdreeksdatabases hebben getest\" src=\"\/wp-content\/uploads\/2019\/08\/891090bf0461c7e3c48e38eb36f9e217.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Hoe we verschillende tijdreeksdatabases hebben getest\" src=\"\/wp-content\/uploads\/2019\/08\/137f944b3578ab5bad4ebc5fa6f96b79.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Wat opvalt<\/b>: fant\u00e1stisch snelle queries uit Prometheus, vreselijk trage queries uit Cassandra, onacceptabel trage queries uit InfluxDB; op het gebied van schrijfsnelheid wint ClickHouse, terwijl Prometheus niet deelneemt aan de competitie, omdat het inserts zelf intern uitvoert en wij niets meten.<\/p>\n<p><u><b>Uiteindelijk<\/b><\/u>: ClickHouse en InfluxDB presteerden het beste, maar een cluster van Influx kan alleen worden gebouwd op basis van de Enterprise-versie, die geld kost, terwijl ClickHouse gratis is en in Rusland is ontwikkeld. Logisch dat in de VS de keuze mogelijk in het voordeel van InfluxDB valt, terwijl hier de voorkeur naar ClickHouse uitgaat.<br \/>\n<br \/>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/462111\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0417\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0440\u044f\u0434\u043e\u0432 (Time-series databases) \u043f\u0440\u0435\u0432\u0440\u0430\u0442\u0438\u043b\u0438\u0441\u044c \u0438\u0437 \u0434\u0438\u043a\u043e\u0432\u0438\u043d\u043d\u043e\u0439 \u0448\u0442\u0443\u043a\u0438 (\u0443\u0437\u043a\u043e\u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u044e\u0449\u0435\u0439\u0441\u044f \u043b\u0438\u0431\u043e \u0432 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u0445 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 (\u0438 \u043f\u0440\u0438\u0432\u044f\u0437\u0430\u043d\u043d\u043e\u0439 \u043a \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u044b\u043c \u0440\u0435\u0448\u0435\u043d\u0438\u044f\u043c), \u043b\u0438\u0431\u043e \u0432 Big Data \u043f\u0440\u043e\u0435\u043a\u0442\u0430\u0445) \u0432 \u00ab\u0442\u043e\u0432\u0430\u0440 \u043d\u0430\u0440\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u0435\u043d\u0438\u044f\u00bb. \u041d\u0430 \u0442\u0435\u0440\u0440\u0438\u0442\u043e\u0440\u0438\u0438 \u0420\u0424 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u043e\u0435 \u0441\u043f\u0430\u0441\u0438\u0431\u043e \u0437\u0430 \u044d\u0442\u043e \u043d\u0430\u0434\u043e \u0441\u043a\u0430\u0437\u0430\u0442\u044c \u042f\u043d\u0434\u0435\u043a\u0441\u0443 \u0438 ClickHouse\u2019\u0443. \u0414\u043e \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u043c\u0435\u043d\u0442\u0430, \u0435\u0441\u043b\u0438 \u0432\u0430\u043c \u0431\u044b\u043b\u043e \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u0441\u043e\u0445\u0440\u0430\u043d\u0438\u0442\u044c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27518,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36737","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0417\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u0431\u0430\u0437\u044b.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u043a \u043c\u044b \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043b\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0440\u044f\u0434\u043e\u0432 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0417\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u0431\u0430\u0437\u044b.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:13:29+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:13:29+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Hoe we verschillende tijdreeks databases hebben getest | ProHoster","description":"In de afgelopen jaren hebben databases.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\udd47\u041a\u0430\u043a \u043c\u044b \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043b\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0440\u044f\u0434\u043e\u0432 | ProHoster","og:description":"\u0417\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u0431\u0430\u0437\u044b.","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov","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":"2019-10-31T19:13:29+00:00","article:modified_time":"2019-10-31T19:13:29+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36737","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":"2026-01-22 04:38:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:39:24","updated":"2026-01-22 04:38:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/36737","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=36737"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/36737\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/27518"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=36737"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=36737"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=36737"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}