Halo, Habr!
Catatan kecil ini lahir selama diskusi artikel
"Monolith Terdistribusi ..." , dan karena topik ini membutuhkan pemikiran lebih lanjut, saya memutuskan untuk mempostingnya di blog saya. Penulis artikel tersebut benar-benar menggambarkan database terdistribusi, membuktikan bahwa Event Log adalah satu-satunya struktur penyimpanan yang benar di dalamnya. Argumennya kira-kira sebagai berikut:
- Karena acara selalu dilokalkan dalam ruang / waktu, ia dapat menyimpan semua data itu sendiri (kadang-kadang dalam bentuk tautan ke acara sebelumnya), yang menjadikan acara tersebut serial, meningkatkan lokalitas, mengurangi konektivitas, dll.
- Setelah suatu peristiwa terjadi, itu tidak lagi berubah (perbaikan apa pun didokumentasikan oleh peristiwa lain), yang mengurangi lalu lintas replikasi.
- Format penyimpanan acara dapat lebih atau kurang disatukan, dan dilepaskan dari area subjek tertentu.
- Log peristiwa dapat secara relatif mudah dipisah / digabungkan, Anda dapat menyimpan berbagai jenis peristiwa pada node yang berbeda, yaitu, pada dasarnya, kita berbicara tentang database terdistribusi.
- Acara dipesan berdasarkan waktu, dan urutan ini juga mencerminkan hubungan sebab akibat (peristiwa saat ini tidak dapat dirujuk kemudian).
- Saat merekam suatu peristiwa, tidak perlu memperbarui data lain secara transaksi (pada kenyataannya, diperlukan, tetapi dalam sejumlah kasus tertentu, misalnya, saldo pelanggan dalam sistem penagihan harus relevan secara instan, perlu memperbarui konter tautan, dll.).
- Pelaporan dapat dibangun langsung dari log peristiwa, tanpa perlu mengubah data menjadi bentuk normal.
Mengenai poin terakhir, banyak tes kinerja (termasuk di blog saya) menunjukkan bahwa pada perangkat keras modern, memproses satu miliar peristiwa (fakta) dengan algoritma single-pass dengan memori jangka pendek membutuhkan waktu beberapa menit, yang cukup dapat diterima untuk pelaporan. Dan karena pemrosesan peristiwa dari berbagai jenis yang tidak terhubung oleh tautan mudah diparalelkan - waktu pelaporan dapat dikurangi hingga puluhan detik, sementara tidak memiliki overhead untuk normalisasi data / pengindeksan / pengumpulan statistik / debugging dan mengisyaratkan permintaan - seperti halnya dalam RDBMSs biasa. Karena itu, membuat laporan berdasarkan data seperti itu tidak membuat saya takut. Namun, pertimbangkan masalahnya secara lebih luas.
Aplikasi bisnis yang khas dapat direpresentasikan sebagai rantai transformasi data:
"Input => model => output". Skema penyimpanan apa pun adalah kompromi antara tiga ekstrem:
- Kami menyimpan data dalam format output. Ini adalah cara kerja berbagai etalase dan OLAP, di mana waktu respons penting. Kontra diketahui - permintaan memori berlebihan dan laju pembaruan rendah (biasanya batch).
- Kami menyimpan data dalam format model domain, sehingga menyederhanakan algoritma perhitungan. Ada banyak kelemahan - diperlukan transformasi data ganda (dari input ke model, dan dari model ke output), biaya transaksi meningkat, sulit untuk menyediakan penyimpanan terdistribusi, mengubah skema mahal, dll. Namun, ini adalah opsi paling populer.
- Kami menyimpan data dalam format input (pada kenyataannya, apa yang penulis artikel tawarkan adalah log peristiwa). Dalam hal ini, biaya transaksi minimal, data mudah dibagi dan digabungkan, skema penyimpanan yang sederhana, jelas, dan stabil. Untung! Benar, Anda harus belajar memprogram lagi.
Sehubungan dengan bidang yang saya minati (sistem informasi perusahaan), suatu peristiwa adalah dokumen utama, dan buku rujukan dapat dianggap sebagai peristiwa sebelumnya. Saya sudah menggambarkan struktur tabel khas ERP barat dalam artikel
"NoERP atau tampilan baru ..." , di mana saya mengusulkan untuk menghapuskan normalisasi data yang berlebihan (dengan pengecualian register saldo instan), dan menulis ulang sebagian besar perhitungan / laporan dalam siklus sekali pakai, di mana yang primer akan diproses secara langsung dokumen. Saya tidak akan mengulangi argumen, semuanya dinyatakan dalam artikel, tetapi skema yang saya usulkan praktis bertepatan dengan tesis penulis artikel pertama, yaitu, bahwa event log adalah data. Sangat menyenangkan ketika orang lain berpikir ke arah ini.
Jelas bahwa pendekatan ini tampaknya merupakan langkah mundur dibandingkan dengan DBMS cerdas modern, tetapi di dunia highloid kadang-kadang Anda harus meninggalkan alat populer / abstrak / universal - demi pemrograman imperatif brutal dan efektif, yang, apalagi, tidak memerlukan lisensi mahal untuk node. / kernel / pengguna.
Saya ingin mengatakan secara terpisah tentang metode pengorganisasian hubungan dalam log peristiwa - itu harus dua arah, yaitu, setiap peristiwa harus menyimpan penghitung referensi untuk dirinya sendiri. Ini diperlukan untuk penerapan algoritma lintas-tunggal - kita beralih dari peristiwa lama ke yang baru, pada saat yang sama melakukan cache setiap peristiwa dengan jumlah tautan masuk dalam memori yang tidak nol, dan menghapusnya dari cache hanya setelah memproses semua yang merujuk. Kehadiran penghitung referensi secara tidak menyenangkan mengurangi kinerja transaksional - misalnya, jika direktori rekanan digunakan di setiap dokumen, penghitung referensi di rekanan harus diperbarui setiap kali dokumen ditambahkan, kadang-kadang pada node yang berbeda. Namun, tempat ini dapat dioptimalkan secara universal, menghindari transaksi terdistribusi dalam semua kasus lainnya.
Sebenarnya, pada level ide ini semua untuk saat ini, saya masih berharap untuk proyek tertentu (misalnya, berdasarkan penerimaan kas atau faktur), dan, jika kesempatan ini muncul dengan sendirinya, saya akan melaporkan hasilnya.