HighLoad++ Москва 2018, Конгресс Холл. 9 сарын 15 00:XNUMX
Хураангуй болон танилцуулга:
Юрий Насретдинов (ВКонтакте): тайланд ClickHouse-ийг манай компанид нэвтрүүлсэн туршлагын талаар ярих болно - энэ нь бидэнд яагаад хэрэгтэй вэ, бидэнд хэр их мэдээлэл хадгалдаг, үүнийг хэрхэн бичих гэх мэт.
Дополнительные материалууд:
Юрий Насретдинов: - Бүгдээрээ сайн уу! Намайг аль хэдийн танилцуулсан тул намайг Юрий Насретдинов гэдэг. Би ВКонтакте дээр ажилладаг. Би манай серверийн флотоос (хэдэн арван мянган) ClickHouse руу өгөгдөл оруулах талаар ярих болно.
Лог гэж юу вэ, яагаад тэдгээрийг цуглуулдаг вэ?
Бид танд юу гэж хэлэх болно: бид юу хийсэн, яагаад "ClickHouse" хэрэгтэй байсан, яагаад бид үүнийг сонгосон, тусгайлан тохируулахгүйгээр та ямар төрлийн гүйцэтгэлийг авах боломжтой. Би танд буфер хүснэгтүүд, тэдгээртэй холбоотой асуудлууд, нээлттэй эх сурвалж болох KittenHouse болон Lighthouse-аас боловсруулсан бидний шийдлүүдийн талаар ярих болно.
Бид яагаад юу ч хийх хэрэгтэй болсон бэ (ВКонтакте дээр бүх зүйл үргэлж сайн байдаг, тийм ээ?). Бид дибаг хийх бүртгэлийг цуглуулахыг хүссэн (мөн тэнд хэдэн зуун терабайт өгөгдөл байсан), магадгүй статистикийг тооцоолоход илүү тохиромжтой байх болно; мөн бид энэ бүхнийг хийх шаардлагатай хэдэн арван мянган серверийн флоттой.
Бид яагаад шийдсэн бэ? Бидэнд лог хадгалах шийдлүүд байсан байх. Энд ийм олон нийтийн "Backend VK" байдаг. Би үүнийг бүртгүүлэхийг зөвлөж байна.
Лог гэж юу вэ? Энэ бол хоосон массивуудыг буцаадаг хөдөлгүүр юм. VK дахь хөдөлгүүрүүд нь бусад хүмүүс микро үйлчилгээ гэж нэрлэдэг. Мөн энд инээмсэглэсэн наалт байна (маш их таалагдсан). Яаж тэгэх вэ? За цааш сонсоорой!
Лог хадгалахад юу ашиглаж болох вэ? Хадупыг дурдахгүй байхын аргагүй. Дараа нь, жишээлбэл, Rsyslog (эдгээр бүртгэлийг файлд хадгалах). LSD. LSD гэж юу болохыг хэн мэдэх вэ? Үгүй ээ, энэ LSD биш. Файлуудыг мөн тус тусад нь хадгал. За, ClickHouse бол хачирхалтай сонголт юм.
Clickhouse ба өрсөлдөгчид: шаардлага ба боломжууд
Бид юу хүсч байна вэ? Бид үйл ажиллагааны талаар хэт их санаа зовохгүй байхыг хүсч байгаа бөгөөд ингэснээр энэ нь хайрцагнаас гарч, хамгийн бага тохиргоотой ажиллах болно. Бид маш их юм бичиж, хурдан бичмээр байна. Мөн бид үүнийг бүх төрлийн сар, жил, өөрөөр хэлбэл удаан хугацаагаар хадгалахыг хүсч байна. Бид тэдний бидэн дээр ирж, "Энд ямар нэг зүйл ажиллахгүй байна" гэж хэлснээс хойш 3 сарын өмнө байсан асуудлыг ойлгож, 3 сарын өмнө юу болсныг харахыг хүсч магадгүй юм. Мэдээллийг шахах нь яагаад давуу тал болох нь ойлгомжтой, учир нь энэ нь эзэлдэг зайны хэмжээг бууруулдаг.
Мөн бидэнд ийм сонирхолтой шаардлага бий: бид заримдаа зарим командын гаралтыг бичдэг (жишээлбэл, бүртгэлүүд), энэ нь 4 килобайтаас илүү байж болно. Хэрэв энэ зүйл UDP дээр ажилладаг бол үүнд зарцуулах шаардлагагүй ... холболтод "нэмэлт зардал" гарахгүй бөгөөд олон тооны серверүүдийн хувьд энэ нь нэмэлт зүйл болно.
Нээлттэй эх сурвалж бидэнд юу санал болгож байгааг харцгаая. Нэгдүгээрт, бид Лог хөдөлгүүртэй - энэ бол бидний хөдөлгүүр; Зарчмын хувьд тэр бүх зүйлийг хийж чадна, тэр ч байтугай урт мөр бичиж чаддаг. За, энэ нь өгөгдлийг ил тод шахдаггүй - хэрэв хүсвэл бид өөрсдөө том багануудыг шахаж чадна ... бид мэдээж хүсэхгүй байна (боломжтой бол). Ганц асуудал бол тэр зөвхөн санах ойд тохирох зүйлээ хэрхэн өгөхийг мэддэг; Үлдсэн хэсгийг уншихын тулд та энэ хөдөлгүүрийн бинлогийг авах хэрэгтэй бөгөөд үүний дагуу нэлээд удаан хугацаа шаардагдана.
Өөр ямар сонголтууд байна вэ? Жишээлбэл, "Хадуп". Ашиглалтын хялбар байдал ... Хадупыг суулгахад хялбар гэж хэн боддог вэ? Мэдээж бичлэг хийхэд ямар ч асуудал байхгүй. Унших үед заримдаа асуулт гарч ирдэг. Зарчмын хувьд, ялангуяа гуалингийн хувьд би тийм биш гэж хэлэх болно. Урт хугацааны хадгалалт - мэдээжийн хэрэг, тийм ээ, өгөгдлийг шахах - тийм ээ, урт мөрүүд - та бичлэг хийх боломжтой нь ойлгомжтой. Гэхдээ олон тооны серверээс бичлэг хийж байна ... Та өөрөө ямар нэг зүйл хийх хэрэгтэй хэвээр байна!
Rsyslog. Үнэн хэрэгтээ бид үүнийг бинлогыг задлахгүйгээр уншихын тулд нөөц сонголт болгон ашигласан боловч урт мөр бичих боломжгүй, зарчмын хувьд 4 килобайтаас илүү бичих боломжгүй. Мэдээллийн шахалтыг өөрөө хийх ёстой. Унших нь файлуудаас гарах болно.
Дараа нь LSD-ийн "бадушка" хөгжил бий. Үндсэндээ "Rsyslog"-тэй адилхан: энэ нь урт мөрүүдийг дэмждэг боловч UDP дээр ажиллах боломжгүй бөгөөд үүнээс болж харамсалтай нь дахин бичих шаардлагатай маш олон зүйл бий. LSD-г хэдэн арван мянган серверээс бичлэг хийх боломжтой болгохын тулд дахин дизайн хийх шаардлагатай.
Бас энд! Хөгжилтэй сонголт бол ElasticSearch юм. Хэрхэн хэлэх? Тэр уншихдаа сайн, өөрөөр хэлбэл хурдан уншдаг, гэхдээ бичихдээ тийм ч сайн биш. Нэгдүгээрт, хэрэв энэ нь өгөгдлийг шахдаг бол энэ нь маш сул байна. Бүрэн хайлт нь анхны хэмжээнээс илүү том өгөгдлийн бүтцийг шаарддаг. Энэ нь ажиллахад хэцүү бөгөөд үүнтэй холбоотой асуудал байнга гардаг. Дахин хэлэхэд, Elastic дээр бичлэг хийх - бид бүгдийг өөрсдөө хийх ёстой.
Энд ClickHouse бол хамгийн тохиромжтой сонголт юм. Цорын ганц зүйл бол хэдэн арван мянган серверээс бичлэг хийх нь асуудал юм. Гэхдээ ядаж нэг асуудал байна, бид үүнийг ямар нэгэн байдлаар шийдэхийг оролдож болно. Мөн тайлангийн үлдсэн хэсэг нь энэ асуудлын тухай юм. ClickHouse-аас ямар төрлийн гүйцэтгэлийг хүлээж чадах вэ?
Бид үүнийг яаж оруулах вэ? MergeTree
Та нарын дунд "ClickHouse"-ын талаар сонсоогүй, мэдэхгүй хүн байна уу? Би чамд хэлэх хэрэгтэй байна, тийм үү? Маш хурдан. Тэнд оруулах - секундэд 1-2 гигабит, секундэд 10 гигабит хүртэл тэсрэлт нь энэ тохиргоог тэсвэрлэх чадвартай - хоёр 6 цөмт Xeon (өөрөөр хэлбэл хамгийн хүчирхэг биш), 256 гигабайт RAM, 20 терабайт байдаг. RAID-д (хэн ч тохируулаагүй, анхдагч тохиргоо). ClickHouse-ийн хөгжүүлэгч Алексей Миловидов бид юу ч тохируулаагүй тул уйлж суугаа байх (бидний хувьд бүх зүйл тийм байсан). Үүний дагуу өгөгдлийг сайн шахаж чадвал секундэд 6 тэрбум мөрийг сканнердах хурдыг авах боломжтой. Хэрэв та текстийн мөрөнд % дуртай бол - секундэд 100 сая мөр, өөрөөр хэлбэл энэ нь маш хурдан юм шиг санагддаг.
Бид үүнийг яаж оруулах вэ? VK нь PHP ашигладаг гэдгийг та мэднэ. Бид PHP-ийн ажилтан бүрээс HTTP-ээр дамжуулан "ClickHouse" руу, MergeTree хүснэгтэд бичлэг бүрийн оруулах болно. Энэ схемийн асуудал хэнд харагдаж байна вэ? Яагаад ч юм хүн болгон гараа өргөсөнгүй. Би та нарт хэлье.
Нэгдүгээрт, маш олон серверүүд байдаг - үүний дагуу маш олон холболтууд байх болно (муу). Дараа нь MergeTree-д секундэд нэгээс илүүгүй удаа өгөгдөл оруулах нь дээр. Тэгээд хэн яагаад мэдэх вэ? За яахав. Би та нарт энэ талаар бага зэрэг хэлье. Өөр нэг сонирхолтой асуулт бол бид аналитик хийхгүй байна, бидэнд өгөгдлийг баяжуулах шаардлагагүй, завсрын сервер хэрэггүй, бид "ClickHouse" руу шууд оруулахыг хүсч байна (илүү шууд байх тусмаа сайн).
Үүний дагуу MergeTree дээр хэрхэн оруулах вэ? Яагаад үүнийг секундэд нэгээс илүү олон удаа оруулахгүй эсвэл бага зэрэг оруулах нь дээр вэ? Баримт нь "ClickHouse" нь багана хэлбэрийн өгөгдлийн сан бөгөөд өгөгдлийг үндсэн түлхүүрийн өсөх дарааллаар эрэмбэлдэг бөгөөд та оруулах үед өгөгдлийг эрэмбэлсэн баганын тоотой тэнцүү тооны файлууд үүсдэг. үндсэн түлхүүрийн өсөх дарааллаар (тусдаа сан үүсгэсэн, оруулга бүрийн диск дээрх файлуудын багц). Дараа нь дараагийн оруулга гарч ирэх бөгөөд цаана нь тэдгээрийг илүү том "хуваалтууд" болгон нэгтгэдэг. Өгөгдөл эрэмбэлэгдсэн тул санах ой их зарцуулахгүйгээр эрэмбэлэгдсэн хоёр файлыг "нэгтгэх" боломжтой.
Гэхдээ таны таамаглаж байгаачлан хэрэв та оруулга бүрт 10 файл бичвэл ClickHouse (эсвэл таны сервер) хурдан дуусдаг тул том багцаар оруулахыг зөвлөж байна. Үүний дагуу бид анхны схемийг хэзээ ч үйлдвэрлэлд нэвтрүүлээгүй. Бид нэн даруй нэгийг нь эхлүүлсэн бөгөөд №2 нь:
Бидний эхлүүлсэн мянга орчим сервер байгаа гэж төсөөлөөд үз дээ, ердөө л PHP байна. Сервер бүр дээр "Kittenhouse" гэж нэрлэдэг манай орон нутгийн агент байдаг бөгөөд энэ нь "ClickHouse"-тэй нэг холболтыг хадгалж, хэдэн секунд тутамд өгөгдөл оруулдаг. Мэдээллийг MergeTree-д биш харин буфер хүснэгтэд оруулдаг бөгөөд энэ нь MergeTree-д шууд оруулахаас зайлсхийхийн тулд яг таг үйлчилдэг.
Буфер хүснэгтүүдтэй ажиллах
Энэ юу вэ? Буфер хүснэгтүүд нь хэсэгчилсэн санах ойн хэсэг юм (өөрөөр хэлбэл үүнийг байнга оруулах боломжтой). Тэдгээр нь хэд хэдэн хэсгээс бүрдэх ба хэсэг бүр нь бие даасан буфер болж ажилладаг бөгөөд тэдгээр нь бие даасан байдлаар цэвэрлэгддэг (хэрэв та буферт олон хэсэг байгаа бол секундэд олон оруулгатай байх болно). Эдгээр хүснэгтээс унших боломжтой - дараа нь та буфер болон эх хүснэгтийн агуулгын нэгдлийг уншсан боловч энэ мөчид бичих нь хаагдсан тул тэндээс уншихгүй байх нь дээр. Буфер хүснэгтүүд нь маш сайн QPS-ийг харуулж байна, өөрөөр хэлбэл 3 мянган QPS хүртэл оруулахад танд ямар ч асуудал гарахгүй. Хэрэв сервер эрчим хүчээ алдвал өгөгдөл алдагдах нь ойлгомжтой, учир нь энэ нь зөвхөн санах ойд хадгалагддаг.
Үүний зэрэгцээ буфер бүхий схем нь ALTER-ийг улам хүндрүүлдэг, учир нь та эхлээд хуучин буферийн хүснэгтийг хуучин схемээр буулгах хэрэгтэй (өгөгдлүүд хаана ч алга болохгүй, учир нь хүснэгтийг устгахаас өмнө устгагдах болно). Дараа нь та хэрэгтэй хүснэгтээ "өөрчилж" дахин буфер хүснэгт үүсгэнэ үү. Үүний дагуу, буфер хүснэгт байхгүй ч таны өгөгдөл хаашаа ч урсахгүй, гэхдээ та үүнийг дискэн дээр ядаж дотооддоо байрлуулж болно.
Kittenhouse гэж юу вэ, энэ нь хэрхэн ажилладаг вэ?
KittenHouse гэж юу вэ? Энэ бол прокси юм. Ямар хэлээр таагаарай? Би тайландаа хамгийн их шуугиан тарьсан сэдвүүдийг цуглуулсан - "Clickhouse", Go, магадгүй би өөр зүйлийг санаж байх болно. Тиймээ, энэ нь Go дээр бичигдсэн, учир нь би C хэл дээр хэрхэн бичихээ мэдэхгүй байна, би хүсэхгүй байна.
Үүний дагуу сервер бүртэй холболтыг хадгалж, санах ойд бичиж чаддаг. Жишээлбэл, хэрэв бид Clickhouse-д алдааны бүртгэл бичих юм бол Clickhouse-д өгөгдөл оруулах цаг байхгүй бол (хэтэрхий их бичигдсэн бол) бид санах ойг томруулдаггүй - үлдсэнийг нь хаядаг. Учир нь бид секундэд хэд хэдэн гигабит алдаа бичвэл заримыг нь хаях магадлалтай. Kittenhouse үүнийг хийж чадна. Нэмж дурдахад, энэ нь найдвартай дамжуулалтыг хийж чадна, өөрөөр хэлбэл дотоод машин дээр диск рүү бичиж, нэг удаа (хэдэн секунд тутамд нэг удаа) энэ файлаас өгөгдөл дамжуулахыг оролддог. Эхлээд бид ердийн Values форматыг ашигладаг байсан - хоёртын формат биш, текст формат (энгийн SQL шиг).
Гэвч дараа нь ийм зүйл болсон. Бид найдвартай хүргэлтийг ашиглаж, бүртгэл бичиж, дараа нь шийдсэн (энэ бол нөхцөлт туршилтын кластер байсан) ... Үүнийг хэдэн цагийн турш зогсоож, буцааж авчирсан бөгөөд мянга мянган серверээс оруулга эхлүүлсэн - Clickhouse-д одоо ч гэсэн "Холболт дээрх утас" - үүний дагуу мянган холболтод идэвхтэй оруулга нь сервер дээр дунджаар нэг хагас мянга орчим ачаалал үүсгэдэг. Хачирхалтай нь сервер хүсэлтийг хүлээн авсан боловч хэсэг хугацааны дараа өгөгдөл оруулсан хэвээр байв; гэхдээ серверт үйлчлэхэд маш хэцүү байсан ...
nginx нэмнэ үү
Thread бүрийн холболтын загварт зориулсан ийм шийдэл нь nginx юм. Бид Clickhouse-ийн өмнө nginx суулгаж, нэгэн зэрэг хоёр хуулбарын тэнцвэрийг тохируулсан (бидний оруулах хурд 2 дахин нэмэгдсэн, гэхдээ ийм байх ёстой гэсэн баримт биш) мөн Clickhouse-тай холболтын тоог хязгаарласан. 50 холболтоос дээш, үүний дагуу илүү , оруулах нь утгагүй юм шиг санагддаг.
Дараа нь бид энэ схем нь ерөнхийдөө сул талуудтай гэдгийг ойлгосон, учир нь энд зөвхөн нэг nginx байна. Үүний дагуу, хэрэв хуулбар байгаа хэдий ч энэ nginx эвдэрсэн бол бид өгөгдлийг алддаг эсвэл ядаж хаана ч бичихгүй. Тиймээс бид өөрсдөө ачааллын тэнцвэржүүлэлтийг хийсэн. "Clickhouse" нь гуалин хийхэд тохиромжтой хэвээр байгааг бид ойлгосон бөгөөд "чөтгөр" нь "Clickhouse" дээр бүртгэлээ бичиж эхэлсэн - үнэнийг хэлэхэд маш тохиромжтой. Бид үүнийг бусад "чөтгөрүүдэд" ашигладаг хэвээр байна.
Дараа нь бид энэ сонирхолтой асуудлыг олж мэдсэн: хэрэв та SQL горимд оруулах стандарт бус аргыг ашигладаг бол энэ нь бүрэн хэмжээний AST-д суурилсан SQL задлан шинжлэгчийг хүчээр шахдаг бөгөөд энэ нь нэлээд удаан байдаг. Үүний дагуу бид ийм зүйл хэзээ ч болохгүй байхын тулд тохиргоог нэмсэн. Бид ачааллыг тэнцвэржүүлж, эрүүл мэндийн үзлэг хийсэн тул хэрэв хүн нас барвал бид өгөгдлийг үлдээсэн хэвээр байна. Одоо бидэнд өөр өөр Clickhouse кластертай байх шаардлагатай маш олон хүснэгт бий. Мөн бид бусад хэрэглээний талаар бодож эхэлсэн - жишээлбэл, бид nginx модулиудаас лог бичихийг хүссэн боловч тэд манай RPC ашиглан хэрхэн харилцахаа мэдэхгүй байна. Би тэдэнд ядаж ямар нэгэн байдлаар хэрхэн илгээхийг зааж өгөхийг хүсч байна - жишээлбэл, UDP-ээр localhost дээр үйл явдлуудыг хүлээн авч, дараа нь Clickhouse руу дамжуулах.
Шийдэлээс нэг алхам дутуу байна
Эцсийн схем нь иймэрхүү харагдаж эхлэв (энэ схемийн дөрөв дэх хувилбар): Clickhouse-ийн урд талын сервер бүр дээр nginx (ижил сервер дээр) байдаг бөгөөд энэ нь ердөө л 50 холболтын тоогоор localhost руу прокси илгээдэг. ширхэг. Мөн энэ схем аль хэдийн ажиллаж байсан, бүх зүйл маш сайн байсан.
Бид нэг сар орчим ингэж амьдарсан. Бүгд баяртай байсан, тэд хүснэгт нэмсэн, нэмсэн, нэмсэн ... Ерөнхийдөө бид буфер хүснэгтүүдийг нэмэх арга нь тийм ч оновчтой биш байсан (ингэж хэлье). Бид хүснэгт бүрт 16 ширхэг хийж, хэдэн секундын зайтай; Бид 20 ширээтэй байсан бөгөөд хүснэгт бүр секундэд 8 оруулга хүлээн авдаг байсан бөгөөд энэ үед "Clickhouse" эхэлсэн ... бичлэгүүд удааширч эхлэв. Тэд дамжуулаагүй төдийгүй... Анхдагч байдлаар, nginx-д ийм сонирхолтой зүйл байсан бөгөөд хэрэв холболтууд дээд талдаа дуусвал бүх шинэ хүсэлтүүдэд "502"-г буцаадаг.
Энд бид (би зүгээр л Clickhouse дахь бүртгэлийг харлаа) хүсэлтийн хагас хувь нь амжилтгүй болсон. Үүний дагуу дискний хэрэглээ өндөр байсан, нэгдэл их байсан. За, би юу хийсэн бэ? Мэдээжийн хэрэг, би холболт болон дээд урсгал яагаад дууссаныг ойлгох гэж санаа зовсонгүй.
Nginx-г урвуу проксигоор сольж байна
Үүнийг бид өөрсдөө зохицуулах хэрэгтэй гэж би шийдсэн, бид үүнийг nginx-д үлдээх шаардлагагүй - nginx Clickhouse-д ямар хүснэгтүүд байдгийг мэдэхгүй, би nginx-ийг урвуу проксигоор сольсон бөгөөд үүнийг би өөрөө бичсэн.
Тэр юу хийж байна вэ? Энэ нь "goshnoy" хэмээх fasthttp номын сан дээр суурилсан, өөрөөр хэлбэл хурдан, бараг nginx шиг хурдан ажилладаг. Уучлаарай, Игорь, хэрэв та энд байгаа бол (жич: Игорь Сысоев бол nginx вэб серверийг бүтээсэн Оросын програмист юм). Энэ нь INSERT эсвэл SELECT гэсэн ямар төрлийн асуулга байдгийг ойлгох боломжтой бөгөөд үүний дагуу янз бүрийн төрлийн асуулгад зориулж өөр өөр холболтын сан агуулна.
Үүний дагуу, бид оруулах хүсэлтийг бөглөх цаг байхгүй байсан ч "сонгосон" нь дамжих болно, мөн эсрэгээр. Мөн энэ нь өгөгдлийг буфер хүснэгтүүдэд бүлэглэдэг - жижиг буфертэй: хэрэв ямар нэгэн алдаа, синтакс алдаа гэх мэт - эдгээр нь бусад өгөгдөлд төдийлөн нөлөөлөхгүй байх болно, учир нь бид зүгээр л буфер хүснэгтэд оруулахад бид жижиг "бачи" байсан бөгөөд бүх синтакс алдаа нь зөвхөн энэ жижиг хэсэгт нөлөөлсөн; энд тэд аль хэдийн том буферт нөлөөлөх болно. Жижиг нь 1 мегабайт, өөрөөр хэлбэл тийм ч жижиг биш юм.
Синхрончлолыг оруулж, үндсэндээ nginx-ийг орлуулах нь nginx-ийн өмнө нь хийж байсан зүйлтэй ижил зүйлийг хийх болно - үүний тулд та орон нутгийн "Kittenhouse"-г өөрчлөх шаардлагагүй. Мөн fasthttp ашигладаг тул маш хурдан ажилладаг - урвуу прокси ашиглан нэг секундэд 100 мянга гаруй хүсэлт гаргах боломжтой. Онолын хувьд та зулзага руу урвуу прокси руу нэг мөр оруулж болно, гэхдээ бид үүнийг хийхгүй.
Схем нь иймэрхүү харагдаж эхлэв: "Kittenhouse", урвуу прокси нь олон хүсэлтийг хүснэгтэд бүлэглэж, эргээд буфер хүснэгтүүд нь тэдгээрийг үндсэн хүсэлтүүдэд оруулдаг.
Алуурчин бол түр зуурын шийдэл, зулзага бол байнгын шийдэл юм
Энэ бол сонирхолтой асуудал... Та нарын хэн нэгэн fasthttp ашигласан уу? Хэн fasthttp-г POST хүсэлтээр ашигласан бэ? Магадгүй үүнийг хийх ёсгүй байсан, учир нь энэ нь хүсэлтийн биетийг анхдагчаар буфер болгодог бөгөөд бидний буферийн хэмжээг 16 мегабайт болгож тохируулсан. Оруулга нь хэзээ нэгэн цагт зогсохоо больсон бөгөөд 16 мегабайтын хэсгүүд олон арван мянган серверээс ирж эхэлсэн бөгөөд бүгдийг нь Clickhouse руу илгээхээс өмнө санах ойд буфер болгосон. Үүний дагуу санах ой дуусч, санах ойгүй алуурчин ирж урвуу проксиг (эсвэл урвуу проксигээс илүү "идэх" боломжтой "Clickhouse") алсан. Цикл дахин давтагдсан. Тийм ч таатай асуудал биш. Хэдийгээр бид үүнийг хэдэн сарын турш ажилласны дараа л олж мэдсэн.
Би юу хийчихэв ээ? Дахин хэлэхэд би яг юу болсныг ойлгох дургүй байна. Миний бодлоор та санах ойд буфер хийх ёсгүй нь ойлгомжтой. Би оролдсон ч fasthttp-г нөхөж чадсангүй. Гэхдээ би үүнийг хийх арга олсон бөгөөд ингэснээр юу ч нөхөх шаардлагагүй болж, би HTTP дээр өөрийн аргыг олсон - би үүнийг KITTEN гэж нэрлэсэн. За, энэ нь логик юм - "VK", "Kitten" ... Өөр юу вэ?..
Хэрэв серверт Kitten аргаар хүсэлт ирвэл сервер логикийн хувьд "мяав" гэж хариулах ёстой. Хэрэв тэр үүнд хариу өгвөл тэр энэ протоколыг ойлгосон гэж үзэж байгаа бөгөөд дараа нь би холболтыг тасалдуулж (fasthttp ийм аргатай) холболт "түүхий" горимд шилждэг. Яагаад надад хэрэгтэй байна вэ? Би TCP холболтоос уншлага хэрхэн явагдаж байгааг хянахыг хүсч байна. TCP нь гайхалтай шинж чанартай: хэрэв хэн ч нөгөө талаас уншихгүй бол бичих нь хүлээж эхэлдэг бөгөөд санах ой үүнд онцгой зарцуулдаггүй.
Тиймээс би нэг дор 50 орчим үйлчлүүлэгчээс уншсан (тавин нь өөр DC-ээс ирсэн ч гэсэн тавин нь хангалттай байх ёстой тул тавиас) ... Энэ хандлагаар хэрэглээ дор хаяж 20 дахин буурсан, гэхдээ би үнэнийг хэлэхэд , Би яг хэдэн цагийг хэмжиж чадаагүй, учир нь энэ нь аль хэдийн утгагүй болсон (алдааны түвшинд аль хэдийн хүрсэн). Протокол нь хоёртын систем бөгөөд энэ нь хүснэгтийн нэр, өгөгдлийг агуулдаг; http толгой байхгүй тул би вэб залгуур ашиглаагүй (би хөтчүүдтэй холбогдох шаардлагагүй - би бидний хэрэгцээнд нийцсэн протокол хийсэн). Тэгээд түүнтэй бүх зүйл сайхан болсон.
Буферийн хүснэгт гунигтай байна
Саяхан бид буфер хүснэгтийн өөр нэг сонирхолтой шинж чанарыг олж мэдэв. Мөн энэ асуудал аль хэдийн бусадтай харьцуулахад илүү их өвдөж байна. Ийм нөхцөл байдлыг төсөөлөөд үз дээ: та аль хэдийн Clickhouse-г идэвхтэй ашиглаж байгаа, танд олон арван Clickhouse сервер байгаа бөгөөд уншихад маш удаан хугацаа шаардагддаг (60 секундээс илүү гэж бодъё); мөн та энэ мөчид ирж, Alter хийнэ үү... Энэ хооронд "Alter"-ээс өмнө эхэлсэн "сонгосон" нь энэ хүснэгтэд орохгүй, "Alter" эхлэхгүй - магадгүй "Clickhouse"-ын ажлын зарим онцлог энэ газар. Магадгүй үүнийг засах боломжтой юу? Эсвэл боломжгүй юм болов уу?
Ерөнхийдөө энэ нь бодит байдал дээр тийм ч том асуудал биш, харин буфер хүснэгтийн хувьд энэ нь илүү өвдөлттэй болох нь тодорхой байна. Учир нь хэрэв таны "Өөрчлөх" хугацаа дууссан гэж үзье (мөн энэ нь өөр хост дээр хугацаа хэтэрсэн байж магадгүй - таных биш, харин хуулбар дээр, жишээ нь) ... Та буфер хүснэгтийг устгасан, таны "Өөрчлөх" ( эсвэл бусад хост) хугацаа дууссан. дараа нь "Өөрчлөх" алдаа гарлаа) - та өгөгдлийг үргэлжлүүлэн бичиж байгаа эсэхийг шалгах хэрэгтэй: та буфер хүснэгтүүдийг буцааж үүсгэнэ (эцэг эх хүснэгттэй ижил схемийн дагуу), дараа нь "Өөрчлөх" нь дамжиж, эцэст нь дуусч, хүснэгтийн буфер нь схемийн хувьд эцэг эхээс ялгаатай болж эхэлдэг. "Өөрчлөлт" гэж юу байснаас хамааран оруулга нь энэ буфер хүснэгтэд очихоо больсон - энэ нь маш гунигтай юм.
Ийм тэмдэг бас байдаг (магадгүй хэн нэгэн үүнийг анзаарсан байх) - үүнийг Clickhouse-ийн шинэ хувилбаруудад query_thread_log гэж нэрлэдэг. Анхдагч байдлаар, зарим хувилбарт нэг хувилбар байсан. Энд бид хоёр сарын дотор 840 сая бичлэг (100 гигабайт) цуглуулсан. Энэ нь тэнд "оруулга" бичсэнтэй холбоотой юм (магадгүй одоо, дашрамд хэлэхэд тэд бичээгүй байж магадгүй). Миний хэлсэнчлэн бидний "оруулга" нь жижиг - бид буфер хүснэгтэд маш олон "оруулга" байсан. Үүнийг идэвхгүй болгосон нь тодорхой байна - би зүгээр л манай сервер дээр харсан зүйлээ хэлж байна. Яагаад? Энэ бол буфер хүснэгт ашиглахын эсрэг өөр нэг аргумент юм! Толбо их гунигтай байна.
Энэ залуугийн нэрийг Спотти гэдгийг хэн мэдсэн юм бэ? VK-ийн ажилтнууд гараа өргөв. БОЛЖ БАЙНА УУ.
"KitttenHouse"-ын төлөвлөгөөний талаар
Төлөвлөгөөгөө ихэвчлэн хуваалцдаггүй, тийм үү? Гэнэт та тэдгээрийг биелүүлж, бусдын нүдэнд тийм ч сайн харагдахгүй болно. Гэхдээ би эрсдэлд орно! Бид дараахь зүйлийг хийхийг хүсч байна: буфер хүснэгтүүд нь таяг хэвээр байгаа бөгөөд бид өөрсдөө оруулгыг буфер болгох хэрэгтэй гэж бодож байна. Гэхдээ бид үүнийг дискэн дээр буферлэхийг хүсэхгүй байгаа тул санах ойд оруулахыг буферлэх болно.
Үүний дагуу, "оруулга" хийгдсэн үед энэ нь синхрон байхаа больсон - энэ нь аль хэдийн буфер хүснэгт болж ажиллах болно, эх хүснэгтэд оруулах (за, хэзээ нэгэн цагт) болон тус тусад нь сувгаар дамжуулан мэдээлэх болно, ямар оруулгууд дамжуулагдсан, аль байхгүй.
Би яагаад синхрон оруулгыг орхиж болохгүй гэж? Энэ нь хамаагүй илүү тохиромжтой. Баримт нь хэрэв та 10 мянган хостоос оруулбал бүх зүйл зүгээр - та хост бүрээс бага зэрэг авах болно, тэнд секундэд нэг удаа оруулдаг, бүх зүйл зүгээр. Гэхдээ би энэ схемийг жишээлбэл, хоёр машинаас ажиллуулахыг хүсч байна, ингэснээр та өндөр хурдтайгаар татаж авах боломжтой - магадгүй Clickhouse-аас хамгийн их ашиг авч чадахгүй, харин урвуу прокси ашиглан нэг машинаас секундэд дор хаяж 100 мегабайт бичээрэй - Энэ схем нь том, жижиг аль алинд нь масштабтай байх ёстой, тиймээс бид оруулах бүрт секунд хүлээх боломжгүй тул асинхрон байх ёстой. Үүний нэгэн адил асинхрон баталгаажуулалт нь оруулга дууссаны дараа ирэх ёстой. Энэ нь өнгөрсөн эсэхийг бид мэдэх болно.
Хамгийн гол нь энэ схемд оруулга хийгдсэн эсэхийг бид тодорхой мэдэж байгаа явдал юм. Ийм нөхцөл байдлыг төсөөлөөд үз дээ: танд буфер хүснэгт байгаа, түүнд ямар нэгэн зүйл бичсэн, дараа нь хүснэгт зөвхөн унших горимд шилжиж, буферийг цэвэрлэх гэж оролдсон гэж үзье. Өгөгдөл хаашаа явах вэ? Тэд буферт үлдэх болно. Гэхдээ бид үүнд итгэлтэй байж чадахгүй - өөр алдаа гарвал яах вэ, үүний улмаас өгөгдөл буферт үлдэхгүй ... (Хаяг Алексей Миловидов, Yandex, ClickHouse хөгжүүлэгч) Эсвэл энэ хэвээр үлдэх үү? Үргэлж? Бүх зүйл сайхан болно гэж Алексей бидэнд итгүүлж байна. Бидэнд түүнд итгэхгүй байх шалтгаан байхгүй. Гэхдээ бүгд адилхан: хэрэв бид буфер хүснэгтүүдийг ашиглахгүй бол тэдэнтэй холбоотой ямар ч асуудал гарахгүй. Зарчмын хувьд том асуудал байхгүй ч гэсэн хоёр дахин олон хүснэгт үүсгэх нь бас тохиромжгүй юм. Энэ бол төлөвлөгөө.
Унших талаар ярилцъя
Одоо унших талаар ярилцъя. Бид энд бас өөрсдийн хэрэглүүрийг бичсэн. Яагаад энд өөрийнхөө хөгжмийн зэмсгийг бичээд байгаа юм шиг санагдаж байна?.. Тэгээд Табиксыг хэн ашигласан бэ? Ямар нэгэн байдлаар гараа өргөсөн хүн цөөхөн... Тэгээд Табиксийн тоглолтод хэн сэтгэл хангалуун байна вэ? За, бид үүнд сэтгэл хангалуун бус байгаа бөгөөд энэ нь өгөгдлийг үзэхэд тийм ч тохиромжтой биш юм. Энэ нь аналитик хийхэд тохиромжтой, гэхдээ зөвхөн үзэхийн тулд үүнийг оновчтой болгоогүй нь тодорхой. Тиймээс би өөрийн гэсэн, өөрийн гэсэн интерфейсийг бичсэн.
Энэ нь маш энгийн - энэ нь зөвхөн өгөгдлийг унших боломжтой. Тэр график үзүүлэхээ мэдэхгүй, юу ч хийхээ мэдэхгүй байна. Гэхдээ энэ нь бидэнд хэрэгтэй зүйлийг харуулж чадна: жишээлбэл, хүснэгтэд хэдэн мөр байгаа, хэр их зай эзэлдэг (багананд хуваахгүйгээр), өөрөөр хэлбэл маш энгийн интерфейс нь бидэнд хэрэгтэй зүйл юм.
Энэ нь Sequel Pro-тэй маш төстэй боловч зөвхөн Twitter-ийн Bootstrap болон хоёр дахь хувилбар дээр хийгдсэн. Та: "Юри, яагаад хоёр дахь хувилбар дээр байгаа юм бэ?" Ямар жил? 2018? Ерөнхийдөө би үүнийг "Булчин" (MySQL) -д зориулж нэлээд удаан хугацаанд хийж байсан бөгөөд тэнд байгаа асуултуудын хэд хэдэн мөрийг өөрчилсөн бөгөөд энэ нь "Clickhouse" дээр ажиллаж эхэлсэн бөгөөд үүнд маш их баярлалаа! Учир нь задлан шинжлэгч нь "булчин"-тай маш төстэй бөгөөд асуулга нь маш төстэй байдаг - ялангуяа эхэндээ маш тохиромжтой.
Энэ нь хүснэгтүүдийг шүүж, хүснэгтийн бүтэц, агуулгыг харуулах, эрэмбэлэх, баганаар шүүж, үр дүнд хүргэсэн асуулга, нөлөөлөлд өртсөн мөрүүдийг (үр дүнд нь хэдэн), өөрөөр хэлбэл, өгөгдөл үзэх үндсэн зүйлс. Маш хурдан.
Мөн редактор байдаг. Би Tabix-ээс редакторыг бүхэлд нь хулгайлах гэж оролдсон ч чадаагүй. Гэхдээ энэ нь ямар нэгэн байдлаар ажилладаг. Зарчмын хувьд энэ бол бүх зүйл.
"Clickhouse" нь үүрэнд тохиромжтой
Clickhouse нь тайлбарласан бүх бэрхшээлийг үл харгалзан лог хийхэд маш сайн тохирдог гэдгийг хэлмээр байна. Хамгийн чухал нь энэ нь бидний асуудлыг шийддэг - энэ нь маш хурдан бөгөөд логуудыг баганагаар шүүх боломжийг олгодог. Зарчмын хувьд буфер хүснэгтүүд сайн ажиллаагүй ч ихэнхдээ яагаад гэдгийг хэн ч мэдэхгүй ... Магадгүй одоо та хаана асуудалтай тулгарахаа илүү сайн мэдэж болно.
TCP? Ерөнхийдөө VK-д UDP ашиглах нь заншилтай байдаг. Тэгээд би TCP ашиглах үед ... Мэдээжийн хэрэг хэн ч надад хэлээгүй: "Юри, чи юу яриад байгаа юм бэ! Та чадахгүй, танд UDP хэрэгтэй." TCP нь тийм ч аймшигтай биш болох нь тогтоогдсон. Цорын ганц зүйл бол, хэрэв таны бичсэн хэдэн арван мянган идэвхтэй нэгдлүүд байгаа бол та үүнийг бага зэрэг анхааралтай бэлтгэх хэрэгтэй; гэхдээ энэ нь боломжтой бөгөөд маш хялбар юм.
Хүн бүр манай нийтийн "VK backend"-ийг захиалсан бол "Kittenhouse", "Lighthouse"-ыг HighLoad Siberia-д байршуулна гэж амласан... Тэгээд та бүхэн мэдэж байгаа, хүн бүр бүртгүүлээгүй... Мэдээжийн хэрэг, би чамайг манай сайтад бүртгүүлэхийг шаардахгүй. олон нийтийн. Та нар хэтэрхий олон байна, хэн нэгэн гомдоох ч байж магадгүй, гэхдээ бүртгүүлээрэй (мөн би энд муур шиг нүдтэй болгох хэрэгтэй). Тийм шүү . Маш их баярлалаа! Github бол биднийх . Clickhouse-ийн тусламжтайгаар таны үс зөөлөн, торгомсог болно.
Удирдах ажил: - Найзууд аа, одоо асуулт асууя. Бид талархлын гэрчилгээ болон VHS-ийн талаархи тайлангаа танилцуулсны дараа шууд.
Юрий Насретдинов (цаашид Ю.Н. гэх): – Хэрэв саяхан дууссан бол миний VHS-ийн тайланг яаж бичиж чадсан бэ?
Удирдах ажил: – Та мөн “Clickhouse” хэрхэн ажиллахыг бүрэн тодорхойлж чадахгүй! Найзууд аа, асуулт асуухад 5 минут!
Асуултууд
Үзэгчдийн асуулт (цаашид Q гэх): - Өдрийн мэнд. Мэдээлэл өгсөнд маш их баярлалаа. Надад хоёр асуулт байна. Би хөнгөмсөг зүйлээр эхэлье: диаграммд (3, 4, 7...) "Kittenhouse" нэрний t үсэгний тоо муурны сэтгэл ханамжид нөлөөлж байна уу?
Ин: - Юуны тоо вэ?
З: - t үсэг. Гурван т, хаа нэгтээ гурван т байна.
Ин: - Би засаагүй гэж үү? За, мэдээж хэрэг болно! Эдгээр нь өөр өөр бүтээгдэхүүн юм - энэ бүх хугацаанд би чамайг хуурч байсан. За, би тоглож байна - энэ хамаагүй. Аа, яг энд! Үгүй ээ, ижил зүйл, би үсгийн алдаа хийсэн.
З: - Баярлалаа. Хоёр дахь асуулт бол ноцтой юм. Миний ойлгож байгаагаар Clickhouse-д буфер хүснэгтүүд нь зөвхөн санах ойд амьдардаг, дискэнд буферд ордоггүй бөгөөд үүний дагуу тогтвортой биш байдаг.
Ин: - Тийм ээ.
З: - Үүний зэрэгцээ таны үйлчлүүлэгч диск рүү буферлэгддэг бөгөөд энэ нь ижил бүртгэлүүдийг хүргэх баталгааг илтгэнэ. Гэхдээ Clickhouse дээр энэ нь ямар ч баталгаатай биш юм. Баталгаажуулалтыг хэрхэн, юунаас болж хийгдэж байгааг тайлбарлана уу?.. Энэ механизмыг илүү дэлгэрэнгүй танилцуулъя
Ин: – Тийм ээ, онолын хувьд энд ямар ч зөрчил байхгүй, учир нь Clickhouse унах үед та үүнийг сая өөр аргаар илрүүлж чадна. Хэрэв Clickhouse гацсан бол (хэрэв энэ нь буруу төгссөн бол) та бичсэн тэмдэглэлээ бага зэрэг ухрааж, бүх зүйл зүгээр байсан тэр мөчөөс эхэлж болно. Нэг минут буцаалаа гэж бодъё, өөрөөр хэлбэл нэг минутын дотор бүх зүйлийг улайсан гэж үздэг.
З: – “Kittenhouse” цонхоо илүү удаан барьдаг, унасан тохиолдолд түүнийг таньж, эргүүлж чаддаг гэсэн үг үү?
Ин: -Гэхдээ энэ бол онолын хувьд. Практикт бид үүнийг хийдэггүй бөгөөд найдвартай хүргэлт нь тэгээс хязгааргүй хүртэл байдаг. Гэхдээ дунджаар нэг. Хэрэв Clickhouse ямар нэг шалтгааны улмаас эвдэрч, серверүүд "дахин ачаалагдах" тохиолдолд бид бага зэрэг алддаг гэдэгт бид сэтгэл хангалуун байна. Бусад бүх тохиолдолд юу ч болохгүй.
З: - Сайн уу. Анхнаасаа л та тайлангийн эхнээс л UDP-г ашиглах юм шиг санагдсан. Танд http, энэ бүхэн байгаа... Мөн таны тайлбарласан ихэнх асуудлууд, миний ойлгож байгаагаар энэ тодорхой шийдлээс үүдэлтэй ...
Ин: - Бид TCP юу ашигладаг вэ?
З: -Үндсэндээ тийм.
Ин: - Үгүй.
З: – Fasthttp-д асуудал гарсан, холболттой холбоотой асуудал гарсан. Хэрэв та дөнгөж UDP-г ашигласан бол өөрийгөө хэсэг хугацаанд хэмнэх байсан. За, урт мессеж эсвэл өөр зүйлтэй холбоотой асуудал гарах болно ...
Ин: - Юутай?
З: – Урт мессежээр, энэ нь MTU-д тохирохгүй байж магадгүй, өөр зүйл ... За, өөр өөрсдийнхөө асуудал байж магадгүй юм. Асуулт нь: яагаад UDP болохгүй гэж?
Ин: – TCP/IP-г боловсруулсан зохиогчид надаас хамаагүй ухаалаг бөгөөд пакетуудыг хэрхэн цуваа болгох (тэдгээр нь явах) зэрэг илгээх цонхыг тохируулах, сүлжээг хэт ачаалахгүй байх, юуны талаар санал хүсэлт өгөх талаар надаас илүү мэддэг гэдэгт би итгэдэг. уншаагүй, нөгөө талаас нь тооцдоггүй ... Энэ бүх асуудал, миний бодлоор, UDP-д байх болно, зөвхөн би өөрөө ижил зүйлийг хэрэгжүүлэхийн тулд аль хэдийн бичсэнээс илүү код бичих шаардлагатай болно. муу. Би С хэлээр бичих нь битгий хэл тэнд ч бичих дургүй...
З: - Зүгээр л тохиромжтой! Илгээсэн, юу ч хүлээх хэрэггүй - энэ нь бүрэн асинхрон юм. Бүх зүйл хэвийн байна гэсэн мэдэгдэл буцаж ирэв - энэ нь ирсэн гэсэн үг; Хэрэв ирэхгүй бол энэ нь муу байна гэсэн үг.
Ин: – Надад аль аль нь хэрэгтэй – Би хүргэлтийн баталгаатай, хүргэлтийн баталгаагүй хоёуланг нь явуулах боломжтой байх хэрэгтэй. Эдгээр нь хоёр өөр хувилбар юм. Би зарим бүртгэлээ алдах эсвэл шалтгааны улмаас алдахгүй байх хэрэгтэй.
З: - Би цаг үрэхгүй. Үүнийг илүү их ярих хэрэгтэй. Баярлалаа.
Удирдах ажил: - Хэн асуулт байна - гараа тэнгэр рүү!
З: - Сайн уу, намайг Саша гэдэг. Тайлангийн дундуур хаа нэгтээ TCP-ээс гадна бэлэн шийдэл болох Кафкагийн нэг хэлбэрийг ашиглах боломжтой гэсэн мэдрэмж гарч ирэв.
Ин: – За... Би танд завсрын сервер ашиглахыг хүсэхгүй байна гэж хэлсэн, учир нь... Кафкагийн хувьд бид арван мянган хосттой болсон; Үнэндээ бидэнд олон арван мянган хостууд бий. Мөн Кафкатай ямар ч итгэмжлэлгүйгээр хийх нь маш их өвдөж магадгүй юм. Нэмж дурдахад хамгийн чухал нь энэ нь "хоцролт" өгдөг хэвээр байгаа бөгөөд энэ нь танд хэрэгтэй нэмэлт хостуудыг өгдөг. Гэхдээ би тэднийг авахыг хүсэхгүй байна - би хүсч байна ...
З: "Гэхдээ эцэст нь ямар ч байсан ийм болсон."
Ин: - Үгүй ээ, хостууд байхгүй! Энэ бүхэн Clickhouse хостууд дээр ажилладаг.
З: - За, мөн эсрэгээр нь "Kittenhouse" - тэр хаана амьдардаг вэ?
Ин: – Clickhouse хост дээр диск рүү юу ч бичихгүй.
З: - Бид бодъё.
Удирдах ажил: -Та сэтгэл хангалуун байна уу? Бид танд цалин өгч чадах уу?
З: - Тиймээ чи чадна. Үнэн хэрэгтээ, ижил зүйлийг олж авахын тулд маш олон суга таяг байдаг бөгөөд одоо - TCP-ийн сэдвээр өмнөх хариулт нь миний бодлоор энэ нөхцөл байдалтай зөрчилдөж байна. Бүх зүйлийг миний өвдөг сөгдөн богино хугацаанд хийж болох байсан юм шиг санагдаж байна.
Ин: – Мөн би яагаад Кафкаг ашиглахыг хүсээгүй юм бэ, яагаад гэвэл Clickhouse Telegram чат дээр Кафкагаас ирсэн мессежүүд алга болсон гэсэн гомдол маш их байсан. Кафкагаас биш, харин Кафка, Кликхаус хоёрын нэгдмэл байдалд; эсвэл тэнд ямар нэг зүйл холбогдоогүй байна. Ойролцоогоор бол Кафкад үйлчлүүлэгч бичих шаардлагатай болно. Илүү энгийн эсвэл найдвартай шийдэл байж чадахгүй гэж би бодож байна.
З: – Надад хэлээч, та яагаад ямар ч дараалал эсвэл ямар нэгэн энгийн автобус хэрэглэж үзээгүй юм бэ? Нэгэнт асинхроноор логуудыг дарааллаар нь илгээж, дарааллаар асинхрон байдлаар хариу хүлээн авах боломжтой гэж та хэлж байна уу?
Ин: – Ямар дарааллыг ашиглаж болох талаар саналаа өгнө үү?
З: – Ямар ч, тэр ч байтугай тэд эмх цэгцтэй байгаа гэсэн баталгаагүй. Зарим төрлийн Redis, RMQ...
Ин: – Редис нь 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