Clickhouse izmantoÅ”ana kā ELK, Big Query un TimescaleDB aizstājējs

Clickhouse ir atvērtā koda kolonnu datu bāzes pārvaldÄ«bas sistēma tieÅ”saistes analÄ«tisko vaicājumu apstrādei (OLAP), ko izveidojis Yandex. To izmanto Yandex, CloudFlare, VK.com, Badoo un citi servisi visā pasaulē, lai uzglabātu patieŔām lielu datu apjomu (tÅ«kstoÅ”iem rindu sekundē vai diskā saglabāto datu petabaitu ievietoÅ”ana).

Parastā ā€œvirknesā€ DBVS, kuras piemēri ir MySQL, Postgres, MS SQL Server, dati tiek glabāti Ŕādā secÄ«bā:

Clickhouse izmantoÅ”ana kā ELK, Big Query un TimescaleDB aizstājējs

Å ajā gadÄ«jumā ar vienu rindu saistÄ«tās vērtÄ«bas tiek fiziski saglabātas blakus. Kolonnu DBVS vērtÄ«bas no dažādām kolonnām tiek glabātas atseviŔķi, un vienas kolonnas dati tiek glabāti kopā:

Clickhouse izmantoÅ”ana kā ELK, Big Query un TimescaleDB aizstājējs

Kolonnu DBVS piemēri ir Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.

Pasta ekspeditoru uzņēmums Kvintrija 2018. gadā sāka izmantot Clickhouse pārskatu sniegÅ”anai un bija ļoti pārsteigts ar tā vienkārŔību, mērogojamÄ«bu, SQL atbalstu un ātrumu. Å Ä«s DBVS ātrums robežojās ar maÄ£iju.

VienkārŔība

Clickhouse instalē Ubuntu ar vienu komandu. Ja zināt SQL, varat nekavējoties sākt izmantot Clickhouse savām vajadzÄ«bām. Tomēr tas nenozÄ«mē, ka pakalpojumā MySQL varat veikt ā€œparādÄ«t tabulu izveideiā€ un nokopēt un ielÄ«mēt SQL pakalpojumā Clickhouse.

SalÄ«dzinot ar MySQL, tabulu shēmu definÄ«cijās ir bÅ«tiskas datu tipu atŔķirÄ«bas, tāpēc jums joprojām bÅ«s nepiecieÅ”ams zināms laiks, lai mainÄ«tu tabulas shēmas definÄ«cijas un apgÅ«tu tabulu dzinējus, lai justos ērti.

Clickhouse darbojas lieliski bez papildu programmatÅ«ras, taču, ja vēlaties izmantot replikāciju, jums bÅ«s jāinstalē ZooKeeper. Vaicājumu veiktspējas analÄ«ze uzrāda izcilus rezultātus ā€“ sistēmas tabulās ir visa informācija, un visus datus var izgÅ«t, izmantojot veco un garlaicÄ«go SQL.

ŠŸŃ€Š¾ŠøŠ·Š²Š¾Š“ŠøтŠµŠ»ŃŒŠ½Š¾ŃŃ‚ŃŒ

  • Etalons Clickhouse salÄ«dzinājumi ar Vertica un MySQL servera konfigurācijā: divas ligzdas IntelĀ® XeonĀ® CPU E5-2650 v2 @ 2.60 GHz; 128 GiB RAM; md RAID-5 uz 8 6 TB SATA HDD, ext4.
  • Etalons Clickhouse salÄ«dzinājums ar Amazon RedShift mākoņkrātuvi.
  • Emuāra fragmenti Cloudflare par Clickhouse veiktspēju:

Clickhouse izmantoÅ”ana kā ELK, Big Query un TimescaleDB aizstājējs

ClickHouse datubāzei ir ļoti vienkārÅ”s dizains ā€“ visiem klastera mezgliem ir vienāda funkcionalitāte un koordinācijai tiek izmantots tikai ZooKeeper. Mēs izveidojām nelielu vairāku mezglu kopu un veicām testÄ“Å”anu, kuras laikā atklājām, ka sistēmai ir diezgan iespaidÄ«gs sniegums, kas atbilst apgalvotajām priekÅ”rocÄ«bām analÄ«tiskajos DBVS etalonos. Mēs nolēmām tuvāk apskatÄ«t ClickHouse koncepciju. Pirmais Ŕķērslis pētniecÄ«bai bija rÄ«ku trÅ«kums un nelielā ClickHouse kopiena, tāpēc mēs iedziļinājāmies Ŕīs DBVS dizainā, lai saprastu, kā tā darbojas.

ClickHouse neatbalsta datu saņemÅ”anu tieÅ”i no Kafka, jo tā ir tikai datu bāze, tāpēc mēs izveidojām paÅ”i savu adaptera pakalpojumu Go. Tas nolasÄ«ja Cap'n Proto kodētos ziņojumus no Kafka, pārveidoja tos par TSV un ievietoja tos ClickHouse partijās, izmantojot HTTP saskarni. Vēlāk mēs pārrakstÄ«jām Å”o pakalpojumu, lai izmantotu Go bibliotēku kopā ar ClickHouse interfeisu, lai uzlabotu veiktspēju. Izvērtējot pakeÅ”u saņemÅ”anas veiktspēju, atklājām bÅ«tisku lietu - izrādÄ«jās, ka ClickHouse Ŕī veiktspēja stipri ir atkarÄ«ga no paketes izmēra, tas ir, vienlaicÄ«gi ievietoto rindu skaita. Lai saprastu, kāpēc tas notiek, mēs apskatÄ«jām, kā ClickHouse uzglabā datus.

Galvenais dzinējs vai drÄ«zāk tabulu dzinēju saime, ko ClickHouse izmanto datu glabāŔanai, ir MergeTree. Å is dzinējs ir konceptuāli lÄ«dzÄ«gs LSM algoritmam, ko izmanto Google BigTable vai Apache Cassandra, taču izvairās veidot starpposma atmiņas tabulu un ieraksta datus tieÅ”i diskā. Tas nodroÅ”ina izcilu rakstÄ«Å”anas caurlaidspēju, jo katra ievietotā pakete tiek kārtota tikai pēc primārās atslēgas, saspiesta un ierakstÄ«ta diskā, veidojot segmentu.

Atmiņas tabulas vai datu ā€œsvaigumaā€ jēdziena trÅ«kums arÄ« nozÄ«mē, ka tos var tikai pievienot; sistēma neatbalsta mainÄ«Å”anu vai dzÄ“Å”anu. PaÅ”laik vienÄ«gais veids, kā dzēst datus, ir dzēst tos pēc kalendārā mēneÅ”a, jo segmenti nekad nepārsniedz mēneÅ”a robežu. ClickHouse komanda aktÄ«vi strādā, lai padarÄ«tu Å”o funkciju pielāgojamu. No otras puses, tas padara segmentu rakstÄ«Å”anu un sapludināŔanu bez strÄ«diem, tāpēc saņemiet caurlaidspējas skalas lineāri ar vienlaicÄ«gu ievietojumu skaitu, lÄ«dz notiek I/O vai kodola piesātinājums.
Taču Å”is apstāklis ā€‹ā€‹nozÄ«mē arÄ« to, ka sistēma nav piemērota mazām paketēm, tāpēc buferÄ“Å”anai tiek izmantoti Kafka servisi un ievietotāji. Turklāt ClickHouse fonā turpina nepārtraukti apvienot segmentus, lai daudzas mazas informācijas daļas tiktu apvienotas un ierakstÄ«tas vairāk reižu, tādējādi palielinot ierakstÄ«Å”anas intensitāti. Tomēr pārāk daudz nesaistÄ«tu detaļu izraisÄ«s agresÄ«vu ieliktņu droseli, kamēr saplÅ«Å”ana turpināsies. Mēs esam noskaidrojuÅ”i, ka labākais kompromiss starp reāllaika datu ievadi un ievades veiktspēju ir tabulā pieņemt ierobežotu skaitu ievietoÅ”anas gadÄ«jumu sekundē.

Tabulas lasÄ«Å”anas veiktspējas atslēga ir datu indeksÄ“Å”ana un atraÅ”anās vieta diskā. NeatkarÄ«gi no tā, cik ātra ir apstrāde, kad dzinējam ir jāskenē terabaiti datu no diska un jāizmanto tikai daļa no tiem, tas prasÄ«s laiku. ClickHouse ir kolonnu veikals, tāpēc katrā segmentā ir fails katrai kolonnai (kolonnai) ar sakārtotām vērtÄ«bām katrai rindai. Tādējādi visas kolonnas, kas nav vaicājumā, vispirms var izlaist un pēc tam var apstrādāt vairākas Ŕūnas paralēli vektorizētai izpildei. Lai izvairÄ«tos no pilnÄ«gas skenÄ“Å”anas, katram segmentam ir neliels indeksa fails.

Ņemot vērā, ka visas kolonnas ir sakārtotas pēc "primārās atslēgas", indeksa failā ir tikai katras N rindas etiķetes (tvertās rindas), lai tās varētu saglabāt atmiņā pat ļoti lielām tabulām. Piemēram, varat iestatīt noklusējuma iestatījumus uz "atzīmēt katru 8192. rindu", pēc tam "niecīgo" tabulas indeksāciju ar 1 triljonu. rindas, kas viegli iekļaujas atmiņā, aizņemtu tikai 122 070 rakstzīmes.

Sistēmas izstrāde

Clickhouse attÄ«stÄ«bai un uzlaboÅ”anai var izsekot Github repo un pārliecinieties, ka ā€œpieaugÅ”anasā€ process notiek iespaidÄ«gā tempā.

Clickhouse izmantoÅ”ana kā ELK, Big Query un TimescaleDB aizstājējs

Popularitāte

Å Ä·iet, ka Clickhouse popularitāte pieaug eksponenciāli, Ä«paÅ”i krievvalodÄ«go kopienā. PagājuŔā gada High load 2018 konference (Maskava, 8. gada 9.ā€“2018. novembris) parādÄ«ja, ka tādi monstri kā vk.com un Badoo izmanto Clickhouse, ar kuru vienlaikus ievieto datus (piemēram, žurnālus) no desmitiem tÅ«kstoÅ”u serveru. 40 minÅ«Å”u video Jurijs Nasretdinovs no VKontakte komandas stāsta par to, kā tas tiek darÄ«ts. DrÄ«zumā mēs publicēsim stenogrammu vietnē Habr, lai atvieglotu darbu ar materiālu.

Pieteikumi

Pēc kāda laika izpētei, manuprāt, ir jomas, kurās ClickHouse varētu bÅ«t noderÄ«ga vai pilnÄ«bā aizstāt citus, tradicionālākus un populārākus risinājumus, piemēram, MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot un DruÄ«ds. Tālāk ir aprakstÄ«ta informācija par ClickHouse izmantoÅ”anu, lai modernizētu vai pilnÄ«bā aizstātu iepriekÅ” minēto DBVS.

MySQL un PostgreSQL paplaŔināŔana

Pavisam nesen mēs biļetenu platformai daļēji aizstājām MySQL ar ClickHouse Mautic biļetens. Problēma bija tā, ka MySQL slikta dizaina dēļ reÄ£istrēja katru nosÅ«tÄ«to e-pastu un katru saiti Å”ajā e-pastā ar base64 jaucējkodu, izveidojot milzÄ«gu MySQL tabulu (email_stats). Pēc tikai 10 miljonu e-pasta ziņojumu nosÅ«tÄ«Å”anas pakalpojumu abonentiem Ŕī tabula aizņēma 150 GB faila vietas, un MySQL sāka bÅ«t ā€œstulbaā€ vienkārÅ”os vaicājumos. Lai novērstu faila vietas problēmu, mēs veiksmÄ«gi izmantojām InnoDB tabulas saspieÅ”anu, kas to samazināja par 4 reizēm. Tomēr joprojām nav jēgas MySQL glabāt vairāk nekā 20ā€“30 miljonus e-pasta ziņojumu tikai lasÄ«Å”anas vēstures labad, jo jebkurÅ” vienkārÅ”s vaicājums, kuram kaut kādu iemeslu dēļ ir jāveic pilna skenÄ“Å”ana, rada mijmaiņas un daudz /O slodze, saskaņā ar kuru regulāri saņēmām Zabbix brÄ«dinājumus.

Clickhouse izmantoÅ”ana kā ELK, Big Query un TimescaleDB aizstājējs

Clickhouse izmanto divus saspieÅ”anas algoritmus, kas aptuveni samazina datu apjomu 3-4 reizes, taču Å”ajā konkrētajā gadÄ«jumā dati bija Ä«paÅ”i "saspiežami".

Clickhouse izmantoÅ”ana kā ELK, Big Query un TimescaleDB aizstājējs

ELK nomaiņa

Pamatojoties uz manu pieredzi, ELK kaudze (ElasticSearch, Logstash un Kibana, Å”ajā konkrētajā gadÄ«jumā ElasticSearch) prasa daudz vairāk resursu, nekā nepiecieÅ”ams žurnālu glabāŔanai. ElasticSearch ir lieliska programma, ja vēlaties labu pilna teksta žurnālu meklÄ“Å”anu (kas, manuprāt, jums nav Ä«sti vajadzÄ«ga), taču man rodas jautājums, kāpēc tā ir kļuvusi par de facto standarta reÄ£istrÄ“Å”anas dzinēju. Tās pārsÅ«tÄ«Å”anas veiktspēja kopā ar Logstash radÄ«ja problēmas pat pie diezgan nelielas darba slodzes, un bija nepiecieÅ”ams pievienot arvien vairāk RAM un diska vietas. Kā datu bāze Clickhouse ir labāka par ElasticSearch Ŕādu iemeslu dēļ:

  • SQL dialektu atbalsts;
  • Labākā saglabāto datu saspieÅ”anas pakāpe;
  • Atbalsts Regex regulāro izteiksmju meklÄ“Å”anai pilna teksta meklÄ“Å”anas vietā;
  • Uzlabota vaicājumu plānoÅ”ana un augstāka vispārējā veiktspēja.

Å obrÄ«d lielākā problēma, kas rodas, salÄ«dzinot ClickHouse ar ELK, ir risinājumu trÅ«kums žurnālu augÅ”upielādei, kā arÄ« dokumentācijas un pamācÄ«bu trÅ«kums par Å”o tēmu. Turklāt katrs lietotājs var konfigurēt ELK, izmantojot Digital Ocean rokasgrāmatu, kas ir ļoti svarÄ«gi Ŕādu tehnoloÄ£iju ātrai ievieÅ”anai. Ir datu bāzes dzinējs, bet vēl nav Filebeat for ClickHouse. Jā, tas ir tur tekoÅ”i un sistēma darbam ar baļķiem guļbÅ«ve, ir rÄ«ks klikŔķaste lai ievadÄ«tu žurnālfaila datus ClickHouse, taču tas viss aizņem vairāk laika. Tomēr ClickHouse joprojām ir lÄ«deris savas vienkārŔības dēļ, tāpēc pat iesācēji to var viegli uzstādÄ«t un sākt lietot pilnÄ«bā funkcionāli tikai 10 minÅ«Å”u laikā.

Dodot priekÅ”roku minimālisma risinājumiem, es mēģināju izmantot FluentBit, ļoti maz atmiņas žurnālu augÅ”upielādes rÄ«ku, ar ClickHouse, vienlaikus cenÅ”oties izvairÄ«ties no Kafka lietoÅ”anas. Tomēr ir jānovērÅ” nelielas nesaderÄ«bas, piemēram, datuma formāta problēmasPirms to var izdarÄ«t bez starpniekservera slāņa, kas pārvērÅ” datus no FluentBit uz ClickHouse.

Kā alternatÄ«vu Kibana var izmantot kā ClickHouse aizmugursistēmu grafana. Cik es saprotu, tas var izraisÄ«t veiktspējas problēmas, renderējot milzÄ«gu skaitu datu punktu, Ä«paÅ”i ar vecākām Grafana versijām. Mēs to vēl neesam izmēģinājuÅ”i vietnē Qwintry, bet sÅ«dzÄ«bas par to laiku pa laikam parādās Telegram ClickHouse atbalsta kanālā.

Google Big Query un Amazon RedShift nomaiņa (risinājums lieliem uzņēmumiem)

Ideāls BigQuery izmantoÅ”anas gadÄ«jums ir ielādēt 1 TB JSON datu un tajā izpildÄ«t analÄ«tiskos vaicājumus. Big Query ir lielisks produkts, kura mērogojamÄ«bu ir grÅ«ti pārvērtēt. Å Ä« ir daudz sarežģītāka programmatÅ«ra nekā ClickHouse, kas darbojas iekŔējā klasterÄ«, taču no klienta viedokļa tai ir daudz kopÄ«ga ar ClickHouse. BigQuery var ātri paaugstināt cenu, tiklÄ«dz sākat maksāt par katru SELECT, tāpēc tas ir Ä«sts SaaS risinājums ar visiem tā plusiem un mÄ«nusiem.

ClickHouse ir labākā izvēle, ja veicat daudz skaitļoÅ”anas ziņā dārgu vaicājumu. Jo vairāk SELECT vaicājumu izpildāt katru dienu, jo lietderÄ«gāk ir aizstāt Big Query ar ClickHouse, jo Ŕāda aizstāŔana var ietaupÄ«t tÅ«kstoÅ”iem dolāru, ja runa ir par daudzu terabaitu datu apstrādi. Tas neattiecas uz saglabātajiem datiem, kuru apstrāde programmā Big Query ir diezgan lēta.

Altinity līdzdibinātāja Aleksandra Zaiceva rakstā "PārcelŔanās uz ClickHouse" apraksta Ŕādas DBVS migrācijas priekŔrocības.

TimescaleDB nomaiņa

TimescaleDB ir PostgreSQL paplaÅ”inājums, kas optimizē darbu ar laikrindu laikrindām parastā datu bāzē (https://docs.timescale.com/v1.0/introduction, https://habr.com/ru/company/zabbix/blog/458530/).

Lai gan ClickHouse nav nopietns konkurents laikrindu niŔā, taču kolonnu struktÅ«ras un vektora vaicājumu izpilde, vairumā analÄ«tisko vaicājumu apstrādes gadÄ«jumu ir daudz ātrāka par TimescaleDB. Tajā paŔā laikā pakeÅ”u datu saņemÅ”anas veiktspēja no ClickHouse ir aptuveni 3 reizes lielāka, un tā arÄ« izmanto 20 reizes mazāk vietas diskā, kas ir patieŔām svarÄ«gi liela apjoma vēsturisko datu apstrādei: ā€Øhttps://www.altinity.com/blog/ClickHouse-for-time-series.

AtŔķirÄ«bā no ClickHouse, vienÄ«gais veids, kā ietaupÄ«t vietu diskā TimescaleDB, ir izmantot ZFS vai lÄ«dzÄ«gas failu sistēmas.

Gaidāmie ClickHouse atjauninājumi, iespējams, ieviesÄ«s delta saspieÅ”anu, kas padarÄ«s to vēl piemērotāku laikrindu datu apstrādei un glabāŔanai. TimescaleDB var bÅ«t labāka izvēle nekā tukÅ”a ClickHouse Ŕādos gadÄ«jumos:

  • mazas instalācijas ar ļoti mazu operatÄ«vo atmiņu (<3 GB);
  • liels skaits mazu INSERT, kurus nevēlaties buferizēt lielos fragmentos;
  • labāka konsistence, viendabÄ«gums un SKĀBES prasÄ«bas;
  • PostGIS atbalsts;
  • savienoÅ”ana ar esoÅ”ajām PostgreSQL tabulām, jo ā€‹ā€‹Timescale DB bÅ«tÄ«bā ir PostgreSQL.

Konkurence ar Hadoop un MapReduce sistēmām

Hadoop un citi MapReduce produkti var veikt daudz sarežģītu aprēķinu, taču tie mēdz darboties ar milzÄ«gu latentumu. ClickHouse novērÅ” Å”o problēmu, apstrādājot terabaitus datu un gandrÄ«z uzreiz iegÅ«stot rezultātus. Tādējādi ClickHouse ir daudz efektÄ«vāks, veicot ātrus, interaktÄ«vus analÄ«tiskos pētÄ«jumus, kam vajadzētu interesēt datu zinātniekus.

Sacensības ar Pinot un Druid

ClickHouse tuvākie konkurenti ir kolonnveida, lineāri mērogojami atvērtā pirmkoda produkti Pinot un Druid. Rakstā ir publicēts lielisks Å”o sistēmu salÄ«dzināŔanas darbs Romāna Leventova 1. gada 2018. februāris

Clickhouse izmantoÅ”ana kā ELK, Big Query un TimescaleDB aizstājējs

Šis raksts ir jāatjaunina - tajā teikts, ka ClickHouse neatbalsta UPDATE un DELETE darbības, kas nav pilnībā taisnība jaunākajām versijām.

Mums nav lielas pieredzes ar Ŕīm DBVS, taču man nepatÄ«k pamatā esoŔās infrastruktÅ«ras sarežģītÄ«ba, kas nepiecieÅ”ama Druid un Pinot darbināŔanai - tā ir vesela virkne "kustÄ«gu daļu", ko no visām pusēm ieskauj Java.

Druid un Pinot ir Apache inkubatoru projekti, par kuru gaitu Apache ir detalizēti atspoguļots savās GitHub projektu lapās. Pinots inkubatorā parādÄ«jās 2018. gada oktobrÄ«, un DruÄ«ds piedzima 8 mēneÅ”us agrāk - februārÄ«.

Informācijas trÅ«kums par to, kā darbojas AFS, man rada dažus un, iespējams, muļķīgus jautājumus. Interesanti, vai Pinot autori pamanÄ«ja, ka Apache fonds ir labvēlÄ«gāks pret DruÄ«du, un vai Ŕāda attieksme pret konkurentu radÄ«ja skaudÄ«bas sajÅ«tu? Vai DruÄ«da attÄ«stÄ«ba palēnināsies un Pinot attÄ«stÄ«ba paātrināsies, ja pirmā atbalstÄ«tāji pēkŔņi sāks interesēties par otro?

ClickHouse trūkumi

Nenobriedums: AcÄ«mredzot Ŕī joprojām nav garlaicÄ«ga tehnoloÄ£ija, taču jebkurā gadÄ«jumā nekas tāds nav novērots citās kolonnu DBVS.

Mazie ieliktņi nedarbojas labi lielā ātrumā: ieliktņi ir jāsadala lielākos gabalos, jo mazo ieliktņu veiktspēja pasliktinās proporcionāli kolonnu skaitam katrā rindā. Tādā veidā ClickHouse saglabā datus diskā ā€“ katra kolonna apzÄ«mē 1 vai vairāk failu, tāpēc, lai ievietotu 1 rindu, kurā ir 100 kolonnas, ir jāatver un jāieraksta vismaz 100 faili. Tāpēc buferizācijas ieliktņiem ir nepiecieÅ”ams starpnieks (ja vien klients pats nenodroÅ”ina buferizāciju) - parasti Kafka vai kāda veida rindu pārvaldÄ«bas sistēma. Varat arÄ« izmantot bufera tabulas programmu, lai vēlāk kopētu lielus datu gabalus MergeTree tabulās.

Tabulu savienojumus ierobežo servera RAM, bet vismaz tie ir tur! Piemēram, Druid un Pinot Ŕādu savienojumu vispār nav, jo tos ir grÅ«ti ieviest tieÅ”i sadalÄ«tās sistēmās, kas neatbalsta lielu datu gabalu pārvietoÅ”anu starp mezgliem.

Atzinumi

Nākamajos gados mēs plānojam plaÅ”i izmantot ClickHouse programmā Qwintry, jo Ŕī DBVS nodroÅ”ina izcilu veiktspējas lÄ«dzsvaru, zemas pieskaitāmās izmaksas, mērogojamÄ«bu un vienkārŔību. Esmu diezgan pārliecināts, ka tas sāks ātri izplatÄ«ties, tiklÄ«dz ClickHouse kopiena nāks klajā ar vairākiem veidiem, kā to izmantot mazās un vidēja izmēra instalācijās.

Dažas reklāmas šŸ™‚

Paldies, ka palikāt kopā ar mums. Vai jums patīk mūsu raksti? Vai vēlaties redzēt interesantāku saturu? Atbalsti mūs, pasūtot vai iesakot draugiem, mākoņa VPS izstrādātājiem no 4.99 USD, unikāls sākuma līmeņa serveru analogs, ko mēs jums izgudrojām: Visa patiesība par VPS (KVM) E5-2697 v3 (6 kodoli) 10GB DDR4 480GB SSD 1Gbps no 19$ vai kā koplietot serveri? (pieejams ar RAID1 un RAID10, līdz 24 kodoliem un līdz 40 GB DDR4).

Dell R730xd 2x lētāk Equinix Tier IV datu centrā Amsterdamā? Tikai Å”eit 2x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV no 199$ NÄ«derlandē! Dell R420 ā€” 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB ā€” no 99 USD! LasÄ«t par Kā izveidot infrastruktÅ«ras uzņēmumu klase ar Dell R730xd E5-2650 v4 serveru izmantoÅ”anu 9000 eiro par santÄ«mu?

Avots: www.habr.com

Pievieno komentāru