Dalam dunia pemprosesan data berskala tinggi, sebuah artikel teknikal terbaru yang memperincikan perjalanan sebuah syarikat daripada juta-an kepada bilion-an log permintaan telah mencetuskan perbincangan hangat dalam kalangan pakar pangkalan data. Penulis asal menggambarkan penyelesaian kompleks mereka yang melibatkan Kafka, Vector, dan ClickHouse, namun komuniti pembangun dengan pantas mempersoalkan sama ada alternatif yang lebih mudah mungkin sudah memadai.
Debat Teras Seni Bina
Komuniti teknikal telah membangkitkan persoalan penting mengenai keperluan seni bina tiga komponen tersebut. Beberapa pengulas menunjuk kepada ciri async_insert terbina dalam ClickHouse sebagai penyelesaian berpotensi untuk ralat TOO_MANY_PARTS asal yang melanda pelaksanaan awal. Ciri ini membolehkan pangkalan data secara automatik mengumpulkan penulisan masuk, mengurangkan kiraan bahagian yang menyebabkan masalah kestabilan. Konsensus komuniti mencadangkan bahawa reka bentuk skema yang betul dengan kunci partition dan kunci utama yang sesuai mungkin telah menghalang banyak masalah awal tanpa memerlukan komponen infrastruktur tambahan.
Masalah terasnya ialah kunci utama pokok gabungan anda salah. ClickHouse async_insert sudah boleh menyelesaikan semua isu anda.
Isu Biasa ClickHouse yang Disebut
- Ralat TOO_MANY_PARTS daripada operasi insert yang pantas
- Reka bentuk skema yang lemah (kunci partition dan kunci utama)
- Penggunaan memori yang tinggi semasa import
- Masalah kestabilan dengan integrasi Kafka natif
- Strategi migrasi yang kompleks
Mempertikaikan Rangkaian Komponen
Beberapa pengguna ClickHouse yang berpengalaman menyuarakan kekeliruan tentang peranan setiap komponen dalam seni bina akhir. Komen menekankan bahawa Vector termasuk keupayaan penimbalan terbina dalam, menjadikan Kafka berpotensi berlebihan untuk kes penggunaan ini. Sebaliknya, yang lain menyatakan bahawa ClickHouse boleh menggunakan terus daripada Kafka menggunakan integrasi asli, mempersoalkan mengapa Vector diperlukan langsung. Ini membawa kepada perbincangan tentang sama ada penyelesaiannya telah menjadi terlalu direka untuk masalah yang pada asasnya merupakan masalah penelanan data isipadu tinggi.
Debat tersebut meluas kepada strategi penimbalan alternatif, dengan cadangan merangkumi penyelesaian berasaskan Redis sehingga alat khusus seperti kittenhouse. Sesetengah pengulas berkongsi pelaksanaan berjaya mereka sendiri menggunakan seni bina yang lebih mudah, dengan seorang menyatakan peningkatan prestasi yang mengagumkan: Saya sudah kagum dengan prestasinya (200ms untuk mempersoalkan apa yang Postgres lakukan dalam 500-600ms), tetapi kemudian saya sedar saya belum meletakkan indeks pada jadual Clickhouse. Sekarang pertanyaan itu kembali dalam 50-70ms.
Perbandingan Prestasi ClickHouse
- Pertanyaan PostgreSQL asal: 500-600ms
- ClickHouse tanpa indeks: 200ms
- ClickHouse dengan indeks: 50-70ms (termasuk masa rangkaian)
Strategi Migrasi dan Pemilihan Alat
Ahli komuniti juga mempersoalkan pendekatan migrasi, terutamanya keputusan untuk memperkenalkan Kafka sebagai komponen seni bina kekal untuk apa yang kelihatan seperti keperluan penulisan berganda sementara semasa migrasi. Beberapa mencadangkan bahawa menulis kepada kedua-dua MariaDB dan ClickHouse secara serentak dalam tempoh peralihan sudah memadai tanpa komitmen kepada kerumitan operasi mengekalkan kelompok Kafka untuk jangka panjang.
Perbincangan mendedahkan bahawa walaupun penyelesaian yang dipilih berfungsi, ramai jurutera berpengalaman percaya pendekatan yang lebih mudah boleh mencapai keputusan yang sama dengan kurang beban operasi. Seperti yang dinyatakan oleh seorang pengulas, Kafka + Vector sememangnya penyelesaian yang tidak betul. Masalah teras mereka ialah skema jadual destinasi dan pemilihan kunci utama + partition yang sangat lemah.
Penyelesaian Alternatif yang Dicadangkan oleh Komuniti
- Ciri async_insert ClickHouse
- Jadual buffer dengan konfigurasi yang sesuai
- Penimbalan Redis dengan cron jobs
- Kittenhouse (alat penimbalan khusus)
- Integrasi terus Kafka ke ClickHouse
- Tulis-dwi ke pangkalan data sumber dan ClickHouse semasa migrasi
Pertukaran Pilihan Seni Bina
Perbualan itu menekankan ketegangan penting dalam keputusan kejuruteraan: keseimbangan antara menggunakan penyelesaian kompleks yang terbukti berbanding mengoptimumkan untuk kesederhanaan. Sesetengah mempertahankan pendekatan asal, menyatakan bahawa memilih penyelesaian yang agak lebih kompleks yang melibatkan seni bina tambahan tetapi telah dicuba dan diuji oleh pihak ketiga yang anda percayai kadangkala boleh menjadi hasil akhir yang lebih sesuai. Jaminan selalunya lebih berat daripada kesederhanaan.
Ini mencerminkan corak biasa dalam cabaran penskalaan - apa yang bermula sebagai penggantian pangkalan data yang mudah selalunya berkembang menjadi pertimbangan semula seni bina yang lebih luas. Perbincangan komuniti berfungsi sebagai kajian kes berharga tentang bagaimana pasukan kejuruteraan yang berbeza mungkin mendekati masalah yang sama dengan falsafah berbeza tentang kerumitan, kebolehkekalan, dan beban operasi.
Dialog yang berterusan menunjukkan bahawa walaupun dengan teknologi matang seperti ClickHouse, tiada penyelesaian satu-saiz-untuk-semua untuk menskala sistem data. Seni bina yang paling sesuai bergantung heavily pada kes penggunaan khusus, kepakaran pasukan, dan pertimbangan penyelenggaraan jangka panjang dan bukannya semata-mata keupayaan teknikal.