{"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\/it\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov","title":{"rendered":"Come abbiamo testato diversi database di serie temporali","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Come abbiamo testato diversi database di serie temporali\" src=\"\/wp-content\/uploads\/2019\/08\/14e07eac02df8d1276c46c33276d8a26.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNegli ultimi anni, le banche dati per serie temporali (Time-series databases) sono passate da una soluzione di nicchia, utilizzata principalmente in sistemi di monitoraggio aperti (e vincolata a soluzioni specifiche) o in progetti Big Data, a un \"prodotto di consumo pubblico\". In Russia, un grande ringraziamento va a Yandex e ClickHouse per questo. Fino a quel momento, se avevate bisogno di conservare un grande volume di dati time-series, dovevate accontentarvi di un mostruoso stack Hadoop e gestirlo, oppure interagire con protocolli specifici per ogni sistema. <\/p>\n<p>Potrebbe sembrare che nel 2019 un articolo su quale TSDB utilizzare si possa riassumere in una sola frase: \"utilizzate semplicemente ClickHouse\". Ma\u2026 ci sono delle sfumature. <\/p>\n<p>In effetti, ClickHouse si sta sviluppando attivamente, la base utenti cresce e il supporto \u00e8 molto attivo, ma non siamo diventati prigionieri del successo pubblico di ClickHouse, che ha oscurato altre soluzioni che potrebbero essere pi\u00f9 efficaci\/affidabili? <\/p>\n<p>All'inizio dello scorso anno abbiamo iniziato a rielaborare il nostro sistema di monitoraggio, nel corso del quale \u00e8 sorto il problema della scelta della banca dati adatta per la conservazione dei dati. \u00c8 di questa scelta che voglio parlare qui.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h4>Definizione del compito<\/h4>\n<p>\nPrima di tutto, \u00e8 necessaria una premessa. Perch\u00e9 abbiamo bisogno di un nostro sistema di monitoraggio e come era strutturato?<\/p>\n<p>Abbiamo iniziato a offrire servizi di supporto nel 2008 e nel 2010 \u00e8 diventato chiaro che aggregare i dati sui processi che avvenivano nell'infrastruttura dei clienti con le soluzioni disponibili all'epoca era diventato complesso (stiamo parlando, per sfortuna, di Cacti, Zabbix e del nascente Graphite).<\/p>\n<p>I nostri principali requisiti erano:<\/p>\n<ul>\n<li>supporto (all'epoca - decine, e in prospettiva - centinaia) di clienti all'interno di un unico sistema e, nel contempo, la presenza di un sistema centrale di gestione delle notifiche;<\/li>\n<li>flessibilit\u00e0 nella gestione del sistema di notifiche (escalation delle notifiche tra i turnisti, gestione dei turni, knowledge base);<\/li>\n<li>possibilit\u00e0 di una profonda dettagliabilit\u00e0 nei grafici (Zabbix all'epoca generava grafici in formato immagine);<\/li>\n<li>memorizzazione a lungo termine di un grande volume di dati (un anno o pi\u00f9) e possibilit\u00e0 di accesso rapido ad essi.<\/li>\n<\/ul>\n<p>\nIn questo articolo ci interessa l'ultimo punto.<\/p>\n<p>Parlando di archiviazione, i requisiti erano i seguenti:<\/p>\n<ul>\n<li>il sistema deve funzionare rapidamente;<\/li>\n<li>\u00e8 preferibile che il sistema abbia un'interfaccia SQL;<\/li>\n<li>il sistema deve essere stabile e avere una base utenti attiva e supporto (una volta ci siamo trovati di fronte alla necessit\u00e0 di supportare sistemi come MemcacheDB, che ha smesso di essere sviluppato, o l'archivio distribuito MooseFS, il cui bug tracker era in cinese: non volevamo ripetere questa storia per il nostro progetto);<\/li>\n<li>conformit\u00e0 al teorema CAP: Consistenza (necessaria) \u2014 i dati devono essere aggiornati, non vogliamo che il sistema di gestione degli avvisi non riceva nuovi dati e lanci allarmi su tutti i progetti in merito alla mancata ricezione di dati; Tolleranza alle ripartizioni (necessaria) \u2014 non vogliamo avere un sistema in Split Brain; Disponibilit\u00e0 (non critica, nel caso esista una replica attiva) \u2014 possiamo passare manualmente a un sistema di riserva in caso di emergenza, tramite codice.<\/li>\n<\/ul>\n<p>\nStranamente, a quel tempo la soluzione ideale per noi si \u00e8 rivelata MySQL. La nostra struttura dati era estremamente semplice: id del server, id del contatore, timestamp e valore; l'estrazione rapida dei dati recenti era garantita da una grande dimensione del buffer pool, mentre l'estrazione dei dati storici avveniva tramite SSD.<\/p>\n<p><img decoding=\"async\" alt=\"Come abbiamo testato diversi database di serie temporali\" src=\"\/wp-content\/uploads\/2019\/08\/555bff26c74badf85131c4d9198871af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn questo modo, siamo riusciti ad estrarre dati freschi di due settimane, con una risoluzione fino al secondo, in 200 ms prima del momento di rendering completo dei dati, e abbiamo vissuto in questo sistema per parecchio tempo.<\/p>\n<p>Nel frattempo, il tempo passava e la quantit\u00e0 di dati cresceva. Nel 2016, i volumi di dati raggiungevano decine di terabyte, il che rappresentava un notevole costo per gli SSD in affitto.<\/p>\n<p>A questo punto, i database column-oriented stavano guadagnando popolarit\u00e0, e abbiamo iniziato a considerarli attivamente: nei database column-oriented i dati vengono archiviati, come suggerisce il termine, in colonne, e se si guarda ai nostri dati, \u00e8 facile vedere una grande quantit\u00e0 di duplicati che potrebbero essere compressi utilizzando un database column-oriented.<\/p>\n<p><img decoding=\"async\" alt=\"Come abbiamo testato diversi database di serie temporali\" src=\"\/wp-content\/uploads\/2019\/08\/2e1a6010fcb09de8cd28ec826752d160.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTuttavia, il sistema chiave per il funzionamento dell'azienda continuava a funzionare in modo stabile, e non volevamo sperimentare una transizione verso qualcos'altro.<\/p>\n<p>Nel 2017 alla conferenza Percona Live di San Jose, gli sviluppatori di Clickhouse si sono presentati probabilmente per la prima volta. A prima vista, il sistema era pronto per la produzione (dopotutto, Yandex.Metrica \u00e8 un ambiente di produzione rigoroso), il supporto era rapido e semplice e, soprattutto, l'operativit\u00e0 era facile. Dal 2018 abbiamo avviato il processo di transizione. Ma a quel punto, c'erano gi\u00e0 molte soluzioni TSDB 'mature' e collaudate, e abbiamo deciso di dedicare un tempo significativo per confrontare le alternative, per assicurarci che non esistessero soluzioni alternative a Clickhouse che soddisfacessero i nostri requisiti.<\/p>\n<p>In aggiunta ai requisiti gi\u00e0 elencati per il database, sono emerse nuove esigenze:<\/p>\n<ul>\n<li>il nuovo sistema deve garantire almeno le stesse prestazioni di MySQL, sulla stessa quantit\u00e0 di hardware;<\/li>\n<li>l'archiviazione del nuovo sistema deve occupare significativamente meno spazio;<\/li>\n<li>Il DBMS deve comunque essere facile da gestire;<\/li>\n<li>si desiderava modificare il meno possibile l'applicazione durante il cambio del DBMS.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Quali sistemi abbiamo iniziato a considerare<\/h4>\n<p>\n<b><u>Apache Hive\/Apache Impala<\/u><\/b><br \/>\nUn vecchio stack Hadoop collaudato. Fondamentalmente \u00e8 un'interfaccia SQL costruita sopra la memorizzazione dei dati in formati proprietari su HDFS. <\/p>\n<p>Vantaggi.<\/p>\n<ul>\n<li>Con un funzionamento stabile, \u00e8 molto semplice scalare i dati.<\/li>\n<li>Ci sono soluzioni colonnari per l'archiviazione dei dati (meno spazio).<\/li>\n<li>Esecuzione molto rapida di compiti paralleli quando ci sono risorse disponibili.<\/li>\n<\/ul>\n<p>\nContro.<\/p>\n<ul>\n<li>\u00c8 Hadoop ed \u00e8 complesso da gestire. Se non siamo pronti a prendere una soluzione pronta nel cloud (e non lo siamo per quanto riguarda i costi), l'intero stack dovr\u00e0 essere assemblato e mantenuto a mano dagli amministratori, e questo non \u00e8 desiderabile.<\/li>\n<li>I dati vengono aggregati <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/blog\/2014\/04\/21\/using-apache-hadoop-and-impala-together-with-mysql-for-data-analysis\/\">davvero rapidamente<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nTuttavia:<\/p>\n<p><img decoding=\"async\" alt=\"Come abbiamo testato diversi database di serie temporali\" src=\"\/wp-content\/uploads\/2019\/08\/6baa1b6024def8c1c7518ef386cfc8d3.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa velocit\u00e0 viene raggiunta aumentando il numero di server di calcolo. In altre parole, se siamo una grande azienda, ci occupiamo di analisi e per il business \u00e8 cruciale aggregare informazioni il pi\u00f9 rapidamente possibile (anche a costo di utilizzare molte risorse computazionali), - questo potrebbe essere la nostra scelta. Ma non eravamo pronti a raddoppiare il parco macchine per aumentare la velocit\u00e0 delle operazioni.<\/p>\n<p><b><u>Druid\/Pinot<\/u><\/b><\/p>\n<p>Gi\u00e0 molto pi\u00f9 specifico per i TSDB, ma ancora una volta - stack Hadoop.<\/p>\n<p>C'\u00e8 <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@leventov\/comparison-of-the-open-source-olap-systems-for-big-data-clickhouse-druid-and-pinot-8e042a5ed1c7\">ottimo articolo che confronta i vantaggi e gli svantaggi di Druid e Pinot rispetto a ClickHouse <\/a><\/noindex>. <\/p>\n<p>In poche parole: Druid\/Pinot sembrano migliori di Clickhouse nei casi in cui:<\/p>\n<ul>\n<li>Hai un carattere eterogeneo dei dati (nel nostro caso registriamo solo le serie temporali delle metriche dei server, e, in sostanza, questa \u00e8 una sola tabella. Ma possono esserci anche altri casi: serie temporali di attrezzature, serie temporali economiche, ecc. \u2014 ciascuna con la propria struttura, che devono essere aggregate e elaborate).<\/li>\n<li>Tuttavia, ci sono molte di queste informazioni.<\/li>\n<li>Le tabelle e i dati con le serie temporali appaiono e scompaiono (cio\u00e8, un certo insieme di dati arriva, viene analizzato e poi rimosso).<\/li>\n<li>Non c'\u00e8 un criterio chiaro secondo cui i dati possono essere partizionati.<\/li>\n<\/ul>\n<p>\nNei casi opposti, ClickHouse si comporta meglio, ed \u00e8 questo il nostro caso.<\/p>\n<p><b><u>ClickHouse<\/u><\/b><\/p>\n<ul>\n<li>Simile a SQL.<\/li>\n<li>Facile da gestire.<\/li>\n<li>La gente dice che funziona.<\/li>\n<\/ul>\n<p>\nEntrano nella short list per i test.<\/p>\n<p><b><u>InfluxDB<\/u><\/b><\/p>\n<p>Un'alternativa estera a ClickHouse. Tra gli svantaggi: l'High Availability \u00e8 presente solo nella versione commerciale, ma va fatta un confronto.<\/p>\n<p>Entrano nella short list per i test.<\/p>\n<p><b><u>Cassandra<\/u><\/b> <\/p>\n<p>Da un lato, sappiamo che \u00e8 utilizzato per memorizzare serie temporali metriche in sistemi di monitoraggio come, ad esempio, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.signalfx.com\/blog\/making-cassandra-perform-as-a-tsdb\/\">SignalFX<\/a><\/noindex> o OkMeter. Tuttavia, ci sono delle specificit\u00e0.<\/p>\n<p>Cassandra non \u00e8 un database a colonne nella sua accezione tradizionale. Si presenta pi\u00f9 come un database a righe, ma in ogni riga pu\u00f2 esserci un numero diverso di colonne, il che consente di organizzare facilmente una visualizzazione a colonne. In questo senso, \u00e8 chiaro che con un limite di 2 miliardi di colonne \u00e8 possibile memorizzare alcuni dati proprio nelle colonne (come le serie temporali). Ad esempio, in MySQL c'\u00e8 un limite di 4096 colonne e l\u00ec \u00e8 facile imbattersi nell'errore con codice 1117 se si prova a fare la stessa cosa.<\/p>\n<p>Il motore Cassandra \u00e8 orientato alla memorizzazione di grandi volumi di dati in un sistema distribuito senza master, e nella menzionata teoria CAP, Cassandra \u00e8 pi\u00f9 orientata all'AP, ovvero all'affidabilit\u00e0 dei dati e alla resilienza alla partizione. Pertanto, questo strumento pu\u00f2 essere particolarmente utile se \u00e8 necessario solo scrivere su questo database e leggerlo raramente. \u00c8 quindi logico utilizzare Cassandra come deposito \"freddo\", ovvero come un luogo di archiviazione affidabile a lungo termine per grandi volumi di dati storici che sono raramente richiesti, ma che possono essere estratti se necessario. Tuttavia, per completezza, testeremo anche essa. Ma, come ho gi\u00e0 detto in precedenza, non ho voglia di riscrivere attivamente il codice per l'opzione di database scelta, quindi lo testeremo in modo piuttosto limitato, senza adattare la struttura del database alle specifiche di Cassandra.<\/p>\n<p><b><u>Prometheus<\/u><\/b><\/p>\n<p>E, per curiosit\u00e0, abbiamo deciso di testare le prestazioni dello storage Prometheus, giusto per capire se siamo pi\u00f9 veloci delle soluzioni attuali o pi\u00f9 lenti e di quanto.<\/p>\n<h4>Metodologia e risultati dei test<\/h4>\n<p>\nQuindi, abbiamo testato 5 database nelle seguenti 6 configurazioni: ClickHouse (1 nodo), ClickHouse (tabella distribuita su 3 nodi), InfluxDB, Mysql 8, Cassandra (3 nodi) e Prometheus. Il piano di test \u00e8 il seguente:<\/p>\n<ol>\n<li>carichiamo i dati storici di una settimana (840 milioni di valori al giorno; 208 mila metriche);<\/li>\n<li>generiamo carico di scrittura (abbiamo considerato 6 modalit\u00e0 di carico, vedere sotto);<\/li>\n<li>parallelamente alla scrittura, facciamo periodicamente delle estrazioni, emulando le richieste di un utente che lavora con grafici. Per non complicare troppo, abbiamo scelto i dati di 10 metriche (esattamente quante ce ne sono nel grafico CPU) per una settimana.<\/li>\n<\/ol>\n<p>\nCarichiamo, emulando il comportamento del nostro agente di monitoraggio, che invia a ogni metrica valori ogni 15 secondi. Siamo interessati a variare:<\/p>\n<ul>\n<li>il numero totale di metriche in cui vengono scritti i dati;<\/li>\n<li>l'intervallo di invio valori in una metrica;<\/li>\n<li>la dimensione del batch.<\/li>\n<\/ul>\n<p>\nSulla dimensione del batch. Poich\u00e9 quasi tutti i nostri database sperimentali non raccomandano di essere caricati con singole inserzioni, avremo bisogno di un relay che raccoglie le metriche in arrivo e le raggruppa per un certo numero e le scrive nel database in inserimento di batch.<\/p>\n<p>Inoltre, per capire meglio come interpretare i dati ricevuti, immaginiamo che non inviamo semplicemente una serie di metriche, ma che le metriche siano organizzate in server - con 125 metriche per server. Qui il server \u00e8 solo un'entit\u00e0 virtuale - giusto per capire che, ad esempio, 10000 metriche corrispondono a circa 80 server.<\/p>\n<p>Ecco, tenendo conto di tutto questo, i nostri 6 regimi di carico del database per la scrittura:<\/p>\n<p><img decoding=\"async\" alt=\"Come abbiamo testato diversi database di serie temporali\" src=\"\/wp-content\/uploads\/2019\/08\/3ba70050dc7e711cb8f3d14ac1a6707b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCi sono due aspetti. In primo luogo, per Cassandra, queste dimensioni dei batch si sono rivelate troppo grandi; l\u00ec abbiamo utilizzato valori di 50 o 100. In secondo luogo, poich\u00e9 Prometheus funziona rigorosamente in modalit\u00e0 pull, cio\u00e8 raccoglie da solo i dati dalle fonti delle metriche (e persino pushgateway, nonostante il nome, non cambia radicalmente la situazione), i carichi corrispondenti sono stati realizzati tramite una combinazione di configurazioni statiche.<\/p>\n<p>I risultati del test sono i seguenti:<\/p>\n<p><img decoding=\"async\" alt=\"Come abbiamo testato diversi database di serie temporali\" src=\"\/wp-content\/uploads\/2019\/08\/9df12bee66ad8c5df720ba08472efead.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Come abbiamo testato diversi database di serie temporali\" src=\"\/wp-content\/uploads\/2019\/08\/891090bf0461c7e3c48e38eb36f9e217.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Come abbiamo testato diversi database di serie temporali\" src=\"\/wp-content\/uploads\/2019\/08\/137f944b3578ab5bad4ebc5fa6f96b79.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Cosa vale la pena notare<\/b>: estrazioni incredibilmente veloci da Prometheus, estrazioni estremamente lente da Cassandra, estrazioni inaccettabilmente lente da InfluxDB; nella velocit\u00e0 di scrittura ClickHouse ha vinto, mentre Prometheus non partecipa alla competizione perch\u00e9 effettua gli inserti internamente e noi non misuriamo nulla.<\/p>\n<p><u><b>In definitiva<\/b><\/u>: ClickHouse e InfluxDB hanno ottenuto le migliori prestazioni, ma un cluster di Influx pu\u00f2 essere costruito solo sulla base della versione Enterprise, che ha un costo, mentre ClickHouse \u00e8 gratuito e sviluppato in Russia. \u00c8 logico che negli Stati Uniti la scelta sia a favore di InfluxDB, mentre da noi si opta per ClickHouse.<br \/>\n<br \/>Fonte: <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.1.1 - 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\/it\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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\/it\/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\udd47Come abbiamo testato diversi database di serie temporali | ProHoster","description":"Negli ultimi anni, i database.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-testirovali-neskolko-baz-dannyh-vremennyh-ryadov","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/36737","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=36737"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/36737\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/27518"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=36737"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=36737"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=36737"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}