нь Yandex-ийн бүтээсэн, онлайн аналитик асуулга боловсруулах (OLAP) нээлттэй эхийн багана мэдээллийн сангийн удирдлагын систем юм. Үүнийг Yandex, CloudFlare, VK.com, Badoo болон дэлхийн бусад үйлчилгээнүүд үнэхээр их хэмжээний өгөгдөл (секундэд хэдэн мянган мөр оруулах эсвэл дискэн дээр хадгалагдсан петабайт) хадгалахад ашигладаг.
Жишээ нь MySQL, Postgres, MS SQL Server зэрэг ердийн "мөр" DBMS-д өгөгдлийг дараах дарааллаар хадгалдаг.
Энэ тохиолдолд нэг мөртэй холбоотой утгуудыг физикийн хувьд ойролцоо хадгална. Багана хэлбэрийн DBMS-д янз бүрийн баганын утгыг тусад нь, нэг баганын өгөгдлийг хамтад нь хадгалдаг.
Багана хэлбэрийн DBMS-ийн жишээ бол Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Шуудан дамжуулагч компани 2018 онд Clickhouse-г тайлан гаргахдаа ашиглаж эхэлсэн бөгөөд энгийн байдал, өргөтгөх боломжтой байдал, SQL дэмжлэг, хурдаараа маш их сэтгэгдэл төрүүлсэн. Энэхүү DBMS-ийн хурд нь ид шидтэй хиллэдэг.
хялбар
Clickhouse-г Ubuntu дээр ганцхан тушаалаар суулгасан. Хэрэв та SQL-г мэддэг бол Clickhouse-г хэрэгцээндээ зориулан шууд ашиглаж эхлэх боломжтой. Гэсэн хэдий ч энэ нь та MySQL дээр "хүснэгт үүсгэх" үйлдлийг хийж, Clickhouse дээр SQL-г хуулж буулгаж болно гэсэн үг биш юм.
MySQL-тэй харьцуулахад хүснэгтийн схемийн тодорхойлолтод өгөгдлийн төрлийн чухал ялгаа байдаг тул та хүснэгтийн схемийн тодорхойлолтыг өөрчлөх, хүснэгтийн хөдөлгүүрийг сурахад бага зэрэг хугацаа шаардагдах болно.
Clickhouse ямар ч нэмэлт програм хангамжгүйгээр маш сайн ажилладаг, гэхдээ хэрэв та хуулбарлахыг ашиглахыг хүсвэл ZooKeeper-г суулгах хэрэгтэй болно. Асуулгын гүйцэтгэлийн шинжилгээ нь маш сайн үр дүнг харуулж байна - системийн хүснэгтүүд нь бүх мэдээллийг агуулдаг бөгөөд хуучин, уйтгартай SQL ашиглан бүх өгөгдлийг олж авах боломжтой.
Бүтээмж
- Серверийн тохиргоонд Clickhouse-ийг Vertica болон MySQL-тэй харьцуулсан: Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz хоёр залгуур; 128 гиб RAM; md RAID-5 дээр 8 6TB SATA HDD, ext4.
- Clickhouse-ийг Amazon RedShift үүл хадгалах сантай харьцуулах.
- Блогын хэсгээс :
ClickHouse мэдээллийн сан нь маш энгийн загвартай - кластерын бүх зангилаа нь ижил функцтэй бөгөөд зохицуулалтын хувьд зөвхөн ZooKeeper ашигладаг. Бид хэд хэдэн зангилааны жижиг кластер байгуулж, туршилт хийсэн бөгөөд энэ явцад систем нь DBMS-ийн аналитик жишиг үзүүлэлтүүдэд заасан давуу талуудтай нийцэж байгаа нь гайхалтай гүйцэтгэлтэй болохыг олж мэдсэн. Бид ClickHouse-ийн цаад ойлголтыг нарийвчлан авч үзэхээр шийдсэн. Судалгаанд тулгарч буй хамгийн эхний бэрхшээл нь багаж хэрэгсэл дутагдалтай, ClickHouse-ын жижиг нийгэмлэг байсан тул бид энэ DBMS-ийн дизайныг судалж, энэ нь хэрхэн ажилладагийг ойлгох болно.
ClickHouse нь Кафкагаас шууд мэдээлэл хүлээн авахыг дэмждэггүй, учир нь энэ нь зүгээр л мэдээллийн сан учраас бид Go-д өөрийн адаптер үйлчилгээг бичсэн. Энэ нь Кафкагийн Cap'n Proto кодчилсон мессежүүдийг уншиж, TSV болгон хөрвүүлж, HTTP интерфэйсээр дамжуулан ClickHouse-д багцалсан. Бид дараа нь гүйцэтгэлийг сайжруулахын тулд Go номын санг ClickHouse-ийн өөрийн интерфейстэй хамт ашиглахын тулд энэ үйлчилгээг дахин бичсэн. Пакет хүлээн авах гүйцэтгэлийг үнэлэхдээ бид нэг чухал зүйлийг олж мэдсэн - ClickHouse-ийн хувьд энэ үзүүлэлт нь багцын хэмжээ, өөрөөр хэлбэл нэгэн зэрэг оруулсан мөрүүдийн тооноос ихээхэн хамаардаг болохыг олж мэдсэн. Яагаад ийм зүйл болдгийг ойлгохын тулд бид ClickHouse нь өгөгдлийг хэрхэн хадгалдаг талаар харлаа.
ClickHouse-ын өгөгдөл хадгалахад ашигладаг үндсэн хөдөлгүүр, эс тэгвээс хүснэгтийн хөдөлгүүрүүдийн гэр бүл бол MergeTree юм. Энэ хөдөлгүүр нь Google BigTable эсвэл Apache Cassandra-д хэрэглэгддэг LSM алгоритмтай үзэл баримтлалын хувьд төстэй боловч дундын санах ойн хүснэгт үүсгэхээс зайлсхийж, өгөгдлийг диск рүү шууд бичдэг. Оруулсан пакет бүрийг зөвхөн үндсэн түлхүүрээр эрэмбэлж, шахаж, дискэнд бичдэг тул сегмент үүсгэхийн тулд энэ нь маш сайн бичих чадварыг өгдөг.
Санах ойн хүснэгт эсвэл мэдээллийн "шинэхэн" гэсэн ойлголт байхгүй байгаа нь тэдгээрийг зөвхөн нэмэх боломжтой гэсэн үг бөгөөд систем нь өөрчлөх, устгахыг дэмждэггүй. Сегментүүд сарын заагийг огтолдоггүй тул одоогоор өгөгдлийг устгах цорын ганц арга бол хуанлийн сараар устгах явдал юм. ClickHouse-ын баг энэ функцийг өөрчлөхийн тулд идэвхтэй ажиллаж байна. Нөгөөтэйгүүр, энэ нь бичих, нэгтгэх сегментүүдийг маргаангүй болгодог тул I/O эсвэл үндсэн ханалт үүсэх хүртэл дамжуулах чадварын хуваарийг зэрэгцээ оруулгын тоогоор шугаман байдлаар хүлээн авна.
Гэсэн хэдий ч энэ нь мөн систем нь жижиг пакетуудад тохиромжгүй гэсэн үг юм, тиймээс буфер хийхдээ Кафка үйлчилгээ болон оруулагчийг ашигладаг. Дараа нь, цаана байгаа ClickHouse нь сегментүүдийг нэгтгэх ажлыг үргэлжлүүлэн хийдэг бөгөөд ингэснээр олон жижиг мэдээллийг нэгтгэж, илүү олон удаа бүртгэх бөгөөд ингэснээр бичлэгийн эрчмийг нэмэгдүүлнэ. Гэсэн хэдий ч, хэт олон холболтгүй хэсгүүд нь нийлүүлэлт үргэлжилсээр байвал оруулгыг түрэмгийлэхэд хүргэдэг. Хүснэгтэнд секундэд хязгаарлагдмал тооны оруулга оруулах нь бодит цагийн залгих ба залгих гүйцэтгэлийн хоорондох хамгийн сайн тохирол гэдгийг бид олж мэдсэн.
Хүснэгтийг унших гүйцэтгэлийн гол түлхүүр нь индексжүүлэлт болон диск дээрх өгөгдлийн байршил юм. Хичнээн хурдан боловсруулалт хийснээс үл хамааран хөдөлгүүр нь дискнээс терабайт өгөгдлийг сканнердаж, зөвхөн нэг хэсгийг нь ашиглах шаардлагатай үед цаг хугацаа шаардагдана. ClickHouse нь багана хэлбэртэй дэлгүүр тул сегмент бүр нь мөр бүрийн эрэмбэлэгдсэн утгууд бүхий багана (багана) бүрийн файлыг агуулна. Ингэснээр асуулгад алга болсон баганыг бүхэлд нь алгасаж, дараа нь олон нүдийг векторжуулсан гүйцэтгэлтэй зэрэгцүүлэн боловсруулж болно. Бүрэн скан хийхээс зайлсхийхийн тулд сегмент бүр жижиг индекс файлтай байна.
Бүх баганыг "анхдагч түлхүүр"-ээр эрэмбэлдэг тул индекс файл нь зөвхөн N-р мөр бүрийн тэмдэглэгээг (барьсан мөр) агуулж байдаг бөгөөд ингэснээр тэдгээрийг маш том хүснэгтүүдэд ч санах ойд хадгалах боломжтой. Жишээлбэл, та анхдагч тохиргоог "8192-р мөр бүрийг тэмдэглэж", дараа нь 1 их наядаар хүснэгтийн "бага" индексжүүлж болно. санах ойд амархан багтах мөрүүд нь ердөө 122 тэмдэгт авна.
Системийн хөгжил
Clickhouse-ийн хөгжил, сайжруулалтыг эндээс харж болно "Өсөх" үйл явц гайхалтай хурдацтай явагдаж байгаа эсэхийг шалгаарай.
Түгээмэл байдал
Clickhouse-ийн нэр хүнд, ялангуяа орос хэлээр ярьдаг хүмүүсийн дунд асар хурдацтай өсч байгаа бололтой. Өнгөрсөн жилийн "High load 2018" бага хурал (Москва, 8 оны 9-р сарын 2018-40-ний хооронд) vk.com болон Badoo зэрэг мангасууд Clickhouse ашигладаг бөгөөд үүгээрээ хэдэн арван мянган серверээс өгөгдөл (жишээ нь лог) оруулдаг болохыг харуулсан. XNUMX минутын видеон дээр . Удахгүй бид материалтай ажиллахад хялбар болгох үүднээс бичлэгийг Хабр дээр нийтлэх болно.
Програмууд
Судалгаанд хэсэг хугацаа зарцуулсны дараа ClickHouse нь ашигтай эсвэл MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot гэх мэт илүү уламжлалт, түгээмэл шийдлүүдийг бүрэн орлож чадах газрууд байгаа гэж би бодож байна. Друид. Дараах нь дээрх DBMS-ийг шинэчлэх эсвэл бүрэн солихын тулд ClickHouse-г ашиглах талаар дэлгэрэнгүй тайлбарласан болно.
MySQL болон PostgreSQL-ийн чадавхийг өргөтгөх
Саяхан бид мэдээллийн платформдоо MySQL-г ClickHouse-ээр хэсэгчлэн сольсон . Асуудал нь MySQL нь муу дизайнтай байсан тул илгээсэн имэйл бүр болон тэр имэйл дэх холбоос бүрийг base64 хэшээр бүртгэж, асар том MySQL хүснэгтийг (email_stats) үүсгэж байсан явдал байв. Үйлчилгээний захиалагчдад ердөө 10 сая имэйл илгээсний дараа энэ хүснэгт нь 150 ГБ файлын зай эзэлсэн бөгөөд MySQL энгийн асуулгад "тэнэг" болж эхлэв. Файлын зайны асуудлыг засахын тулд бид InnoDB хүснэгтийн шахалтыг амжилттай ашигласан бөгөөд үүнийг 4 дахин багасгасан. Гэсэн хэдий ч ямар нэг шалтгааны улмаас бүрэн скан хийх шаардлагатай энгийн асуулга нь свопын үр дүнд хүргэдэг тул зөвхөн түүх уншихын тулд MySQL-д 20-30 сая гаруй имэйл хадгалах нь утгагүй хэвээр байна. /O ачаалал, үүний дагуу бид байнга Zabbix-аас анхааруулга авч байсан.
Clickhouse нь өгөгдлийн хэмжээг ойролцоогоор бууруулдаг хоёр шахалтын алгоритмыг ашигладаг , гэхдээ энэ тохиолдолд өгөгдөл нь ялангуяа "шахах" байсан.
ELK-г сольж байна
Миний туршлага дээр үндэслэн ELK стек (ElasticSearch, Logstash болон Kibana, энэ тохиолдолд ElasticSearch) нь бүртгэлийг хадгалахад шаардагдахаас хамаагүй их нөөц шаарддаг. ElasticSearch нь танд бүрэн текстийн бүртгэлийн сайн хайлт хэрэгтэй бол (энэ нь танд үнэхээр хэрэггүй гэж бодож байна) маш сайн хөдөлгүүр юм, гэхдээ энэ нь яагаад де факто стандарт бүртгэлийн систем болсон юм бол гэж би гайхаж байна. Logstash-тай хослуулсан түүний гүйцэтгэл нь бага ачаалалтай байсан ч бидэнд асуудал үүсгэж, илүү их RAM болон дискний зай нэмэхийг шаарддаг. Мэдээллийн сангийн хувьд Clickhouse нь дараах шалтгааны улмаас ElasticSearch-ээс илүү дээр юм.
- SQL аялгууны дэмжлэг;
- Хадгалагдсан өгөгдлийг шахах хамгийн сайн түвшин;
- Бүрэн текст хайлтын оронд Regex тогтмол илэрхийллийн хайлтыг дэмжих;
- Сайжруулсан асуулгын хуваарь, илүү өндөр гүйцэтгэл.
Одоогийн байдлаар ClickHouse-ийг ELK-тэй харьцуулах үед гарч буй хамгийн том асуудал бол лог байршуулах шийдэл дутмаг, мөн сэдвийн талаархи баримт бичиг, зааваргүй байгаа явдал юм. Түүнээс гадна хэрэглэгч бүр Дижитал далайн гарын авлагыг ашиглан ELK-ийг тохируулах боломжтой бөгөөд энэ нь ийм технологийг хурдан хэрэгжүүлэхэд маш чухал юм. Өгөгдлийн сангийн хөдөлгүүр байгаа боловч ClickHouse-д зориулсан Filebeat хараахан байхгүй байна. Тийм ээ, тэнд байгаа болон бүртгэлтэй ажиллах систем , хэрэгсэл байна лог файлын өгөгдлийг ClickHouse руу оруулах боловч энэ бүхэн илүү их цаг зарцуулдаг. Гэсэн хэдий ч ClickHouse нь энгийн байдгаараа тэргүүлэгч хэвээр байгаа тул анхлан суралцагчид ч үүнийг хялбархан суулгаж, ердөө 10 минутын дотор бүрэн ажиллагаатай ашиглаж эхлэх боломжтой.
Минималист шийдлүүдийг илүүд үзэж, би Кафкаг ашиглахаас зайлсхийхийг хичээхийн зэрэгцээ маш бага санах ойтой лог тээвэрлэх хэрэгсэл болох FluentBit-ийг ClickHouse-тай хамт ашиглахыг оролдсон. Гэсэн хэдий ч, гэх мэт бага зэргийн үл нийцэх байдлыг арилгах шаардлагатай Өмнө нь үүнийг FluentBit-ээс ClickHouse руу өгөгдлийг хөрвүүлдэг прокси давхаргагүйгээр хийж болно.
Альтернатив хувилбар болгон Кибана-г ClickHouse backend болгон ашиглаж болно . Миний ойлгож байгаагаар энэ нь маш олон тооны өгөгдлийн цэгүүдийг, ялангуяа Grafana-ийн хуучин хувилбаруудыг үзүүлэх үед гүйцэтгэлийн асуудал үүсгэж болзошгүй юм. Бид үүнийг Qwintry дээр хараахан туршиж үзээгүй байгаа ч энэ тухай гомдол Telegram дахь ClickHouse тусламжийн суваг дээр үе үе гарч ирдэг.
Google Big Query болон Amazon RedShift-ийг солих (том компаниудад зориулсан шийдэл)
BigQuery-г ашиглах хамгийн тохиромжтой тохиолдол бол 1 TB JSON өгөгдлийг ачаалж, түүн дээр аналитик асуулга ажиллуулах явдал юм. Big Query бол өргөтгөх чадварыг хэт үнэлж баршгүй маш сайн бүтээгдэхүүн юм. Энэ нь дотоод кластер дээр ажилладаг ClickHouse-аас хамаагүй илүү төвөгтэй программ хангамж боловч үйлчлүүлэгчийн үүднээс ClickHouse-тай ижил төстэй зүйл ихтэй байдаг. BigQuery нь СОНГОЛТ бүрт төлбөр төлж эхэлмэгц хурдан үнэтэй болох тул энэ нь бүх давуу болон сул талуудтай жинхэнэ SaaS шийдэл юм.
Тооцооллын хувьд үнэтэй асуулга явуулж байгаа үед ClickHouse нь хамгийн сайн сонголт юм. Та өдөр бүр олон SELECT асуулга ажиллуулдаг бол Big Query-г ClickHouse-ээр солих нь илүү утга учиртай, учир нь ийм орлуулалт нь олон терабайт өгөгдөл боловсруулагдаж байгаа үед танд хэдэн мянган доллар хэмнэнэ. Энэ нь хадгалагдсан өгөгдөлд хамаарахгүй бөгөөд үүнийг Big Query дээр боловсруулахад маш хямд байдаг.
Altinity-ийн үүсгэн байгуулагч Александр Зайцевын нийтлэлд Ийм DBMS шилжилтийн ашиг тусын талаар ярьдаг.
TimescaleDB солих
TimescaleDB нь PostgreSQL өргөтгөл бөгөөд ердийн мэдээллийн сан дахь цагийн цуваатай ажиллахад тохиромжтой., ).
ClickHouse нь цаг хугацааны цувралын хувьд ноцтой өрсөлдөгч биш боловч багана бүтэц, вектор асуулгын гүйцэтгэлтэй боловч аналитик асуулга боловсруулах ихэнх тохиолдолд TimescaleDB-ээс хамаагүй хурдан байдаг. Үүний зэрэгцээ ClickHouse-аас багц өгөгдлийг хүлээн авах гүйцэтгэл нь ойролцоогоор 3 дахин их бөгөөд энэ нь 20 дахин бага дискний зай ашигладаг бөгөөд энэ нь их хэмжээний түүхэн өгөгдлийг боловсруулахад үнэхээр чухал юм. .
ClickHouse-аас ялгаатай нь TimescaleDB дээр дискний зай хэмнэх цорын ганц арга бол ZFS эсвэл ижил төстэй файлын системийг ашиглах явдал юм.
ClickHouse-д удахгүй гарах шинэчлэлтүүд нь дельта шахалтыг нэвтрүүлэх бөгөөд энэ нь цагийн цувааны өгөгдлийг боловсруулах, хадгалахад илүү тохиромжтой байх болно. TimescaleDB нь дараах тохиолдолд нүцгэн ClickHouse-аас илүү сайн сонголт байж болно.
- маш бага RAM (<3 GB) бүхий жижиг суулгацууд;
- том хэсгүүдэд буфер хийхийг хүсэхгүй байгаа олон тооны жижиг INSERT;
- илүү сайн тууштай байдал, жигд байдал, ACID-ийн шаардлага;
- PostGIS дэмжлэг;
- Timescale DB нь үндсэндээ PostgreSQL учраас одоо байгаа PostgreSQL хүснэгтүүдтэй нэгдэх.
Hadoop болон MapReduce системүүдтэй өрсөлдөх
Hadoop болон MapReduce-ийн бусад бүтээгдэхүүнүүд нь маш олон нарийн төвөгтэй тооцоолол хийх боломжтой боловч асар их хоцрогдолтой ажиллах хандлагатай байдаг. ClickHouse нь терабайт өгөгдлийг боловсруулж, үр дүнг бараг агшин зуур гаргах замаар энэ асуудлыг засдаг. Тиймээс ClickHouse нь өгөгдөл судлаачдын сонирхлыг татахуйц хурдан, интерактив аналитик судалгаа хийхэд илүү үр дүнтэй байдаг.
Пинот, Друид нартай хийсэн тэмцээн
ClickHouse-ийн хамгийн ойрын өрсөлдөгчид нь багана хэлбэртэй, шугаман масштабтай нээлттэй эхийн бүтээгдэхүүн болох Pinot болон Druid юм. Эдгээр системийг харьцуулсан гайхалтай бүтээлийг нийтлэлд нийтлэв 1 оны 2018-р сарын XNUMX-ний өдөр
Энэ нийтлэлийг шинэчлэх шаардлагатай байна - ClickHouse нь UPDATE болон DELETE үйлдлүүдийг дэмждэггүй гэж хэлдэг бөгөөд энэ нь хамгийн сүүлийн үеийн хувилбаруудын хувьд тийм ч үнэн биш юм.
Бид эдгээр мэдээллийн сангуудын талаар тийм ч их туршлагагүй ч Druid болон Pinot-ийг ажиллуулахад шаардлагатай дэд бүтцийн нарийн төвөгтэй байдалд үнэхээр дургүй - энэ нь бүх талаараа Java-оор хүрээлэгдсэн хөдөлгөөнт хэсгүүд юм.
Druid болон Pinot нь Apache-ийн инкубаторын төслүүд бөгөөд тэдгээрийн явцыг Apache GitHub төслийн хуудсан дээр нарийвчлан тусгасан болно. Пино 2018 оны 8-р сард инкубаторт гарч ирсэн бөгөөд Друид XNUMX сарын өмнө буюу XNUMX-р сард төрсөн.
AFS хэрхэн ажилладаг талаар мэдээлэл дутмаг байгаа нь надад зарим, магадгүй тэнэг асуултуудыг төрүүлдэг. Пинотын зохиогчид Апачи сан нь Друид руу илүү таатай ханддагийг анзаарсан уу, өрсөлдөгчид хандах энэ хандлага нь атаархлыг төрүүлсэн үү? Друидын хөгжил удааширч, Пиногийн хөгжил түргэсэх болов уу?
ClickHouse-ийн сул талууд
Төлөвшөөгүй байдал: Мэдээжийн хэрэг, энэ нь уйтгартай технологи биш хэвээр байгаа ч ямар ч тохиолдолд бусад багана хэлбэрийн DBMS-д үүнтэй төстэй зүйл ажиглагддаггүй.
Жижиг оруулга нь өндөр хурдтай ажиллахад тийм ч сайн ажилладаггүй: жижиг оруулгын гүйцэтгэл нь мөр тус бүрийн баганын тоотой пропорциональ мууддаг тул оруулгыг том хэсгүүдэд хуваах ёстой. ClickHouse нь дискэн дээрх өгөгдлийг ингэж хадгалдаг - багана бүр 1 ба түүнээс дээш файлыг төлөөлдөг тул 1 багана агуулсан 100 мөр оруулахын тулд та дор хаяж 100 файл нээж бичих хэрэгтэй. Ийм учраас буферийн оруулга нь зуучлагчийг шаарддаг (үйлчлүүлэгч өөрөө буфер хийхгүй бол) - ихэвчлэн Кафка эсвэл дарааллын удирдлагын зарим төрлийн систем. Та мөн дараа нь MergeTree хүснэгтэд их хэмжээний өгөгдлийг хуулахын тулд Buffer table хөдөлгүүрийг ашиглаж болно.
Хүснэгтийн холболтууд нь серверийн RAM-аар хязгаарлагддаг, гэхдээ наад зах нь тэнд байна! Жишээлбэл, Druid болон Pinot-д ийм холболтууд огт байдаггүй, учир нь тэдгээрийг зангилааны хооронд их хэмжээний өгөгдлийг шилжүүлэхийг дэмждэггүй тархсан системд шууд хэрэгжүүлэхэд хэцүү байдаг.
үр дүн нь
Энэхүү DBMS нь гүйцэтгэлийн маш сайн тэнцвэр, зардал бага, өргөтгөх боломжтой, энгийн байдлыг хангадаг тул бид ойрын жилүүдэд Qwintry-д ClickHouse-ийг өргөнөөр ашиглахаар төлөвлөж байна. ClickHouse нийгэмлэг үүнийг жижиг болон дунд хэмжээний суулгацуудад ашиглах олон арга замыг гаргаж ирсний дараа энэ нь хурдан тархаж эхэлнэ гэдэгт би итгэлтэй байна.
Зарим зар 🙂
Бидэнтэй хамт байсанд баярлалаа. Манай нийтлэл танд таалагдаж байна уу? Илүү сонирхолтой контент үзэхийг хүсч байна уу? Захиалга өгөх эсвэл найзууддаа санал болгох замаар биднийг дэмжээрэй, , Бидний танд зориулж бүтээсэн анхны түвшний серверүүдийн өвөрмөц аналоги: (RAID1 болон RAID10, 24 хүртэлх цөм, 40 ГБ хүртэл DDR4-тэй байх боломжтой).
Амстердам дахь Equinix Tier IV дата төвд Dell R730xd 2 дахин хямд байна уу? Зөвхөн энд Нидерландад! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллараас! тухай уншина уу
Эх сурвалж: www.habr.com