Kami adalah departemen pengembangan teknologi jaringan ritel. Suatu hari, manajemen menetapkan tugas untuk mempercepat penghitungan skala besar dengan menggunakan Apache Ignite bersama dengan MSSQL, dan menunjukkan situs web dengan ilustrasi indah dan contoh kode Java. Saya langsung menyukai situs itu , deskripsi yang menjanjikan keajaiban: Anda tidak perlu menerapkan kode Java atau Scala secara manual pada setiap node di grid dan menerapkannya kembali setiap kali ada perubahan. Seiring berjalannya pekerjaan, ternyata Zero Deployment memiliki kegunaan tertentu, fitur-fiturnya ingin saya bagikan. Di bawah potongan terdapat pemikiran dan detail implementasi.
1. Pernyataan masalah
Inti masalahnya adalah sebagai berikut. Terdapat direktori titik penjualan SalesPoint dan direktori produk Sku (Stock Keeping Unit). Tempat penjualan memiliki atribut “Jenis toko” dengan nilai “kecil” dan “besar”. Beraneka ragam (daftar produk tempat penjualan) terhubung ke setiap tempat penjualan (dimuat dari DBMS) dan informasi diberikan bahwa sejak tanggal yang ditentukan produk yang ditentukan
dikecualikan dari bermacam-macam atau ditambahkan ke bermacam-macam.
Diperlukan untuk mengatur cache tempat penjualan yang dipartisi dan menyimpan di dalamnya informasi tentang produk yang terhubung selama sebulan sebelumnya. Kompatibilitas dengan sistem pertarungan memerlukan node klien Ignite untuk memuat data, menghitung agregat formulir (Jenis toko, Kode produk, hari, jumlah_penjualan_poin) dan mengunggahnya kembali ke DBMS.
2. Studi sastra
Saya belum punya pengalaman, jadi saya mulai menari dari kompor. Artinya, dari review publikasi.
Pasal 2016 berisi link ke dokumentasi proyek Apache Ignite dan sekaligus celaan atas ketidakjelasan dokumentasi ini. Saya membacanya kembali beberapa kali, kejelasan tidak muncul. Saya mengacu pada tutorial resmi Yang
dengan optimis berjanji, “Anda akan siap bekerja dalam sekejap!” Saya sedang mencari tahu pengaturan variabel lingkungan, menonton dua video Apache Ignite Essentials, tetapi itu tidak terlalu berguna untuk tugas khusus saya. Saya berhasil meluncurkan Ignite dari baris perintah dengan file standar "example-ignite.xml", membangun aplikasi pertama menggunakan Maven. Aplikasi ini berfungsi dan menggunakan Zero Deployment, sungguh indah!
Saya membaca lebih lanjut, dan di sana contohnya langsung menggunakan affinityKey (dibuat sebelumnya melalui kueri SQL), dan bahkan menggunakan BinaryObject yang misterius:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); Baca : format biner - sesuatu seperti refleksi, mengakses bidang suatu objek berdasarkan nama. Dapat membaca nilai suatu bidang tanpa melakukan deserialisasi objek sepenuhnya (menghemat memori). Tapi kenapa BinaryObject digunakan bukan Person, karena ada Zero Deployment? Mengapa IgniteCache ditransfer ke IgniteCache ? Masih belum jelas.
Saya sedang membuat ulang Aplikasi Komputasi agar sesuai dengan kasus saya. Kunci utama direktori tempat penjualan di MSSQL didefinisikan sebagai [id] [int] BUKAN NULL, saya membuat cache dengan analogi
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")Dalam konfigurasi xml saya menunjukkan bahwa cache dipartisi
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Partisi berdasarkan tempat penjualan mengasumsikan bahwa agregat yang diperlukan akan dibangun pada setiap node cluster untuk catatan salesPointCache yang tersedia di sana, setelah itu node klien akan melakukan penjumlahan akhir.
Saya sedang membaca tutorialnya , saya melakukannya dengan analogi. Pada setiap node cluster saya menjalankan IgniteRunnable(), seperti ini:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Saya menambahkan logika agregasi dan pengunggahan dan menjalankannya pada kumpulan data pengujian. Semuanya berfungsi secara lokal di server pengembangan.
Saya meluncurkan dua server pengujian CentOs, menentukan alamat IP di default-config.xml, menjalankan masing-masing server
./bin/ignite.sh config/default-config.xmlKedua node Ignite sedang berjalan dan dapat melihat satu sama lain. Saya menentukan alamat yang diperlukan dalam konfigurasi xml aplikasi klien, itu dimulai, menambahkan node ketiga ke topologi dan segera ada dua node lagi. Log menunjukkan “ClassNotFoundException: model.SalesPoint” di baris
SalesPoint sp=salesPointCache.get(spId);StackOverflow mengatakan bahwa alasan kesalahan tersebut adalah karena tidak ada kelas SalesPoint khusus di server CentOs. Kami telah tiba. Bagaimana dengan “Anda tidak perlu menerapkan kode Java secara manual di setiap node” dan seterusnya? Atau apakah “kode Java Anda” bukan tentang SalesPoint?
Saya mungkin melewatkan sesuatu - saya mulai mencari lagi, membaca dan mencari lagi. Setelah beberapa saat, saya merasa sudah membaca semua topik tersebut, tidak ada lagi yang baru. Saat saya mencari, saya menemukan beberapa komentar menarik.
, Arsitek Utama di GridGain Systems, di StackOverflow, April 2016:
Model classes are not peer deployed, but you can use withKeepBinary() flag
on the cache and query BinaryObjects. This way you will avoid deserialization
on the server side and will not get ClassNotFoundException.Pendapat otoritatif lainnya: , Direktur manajemen produk, GridGain Systems.
Artikel tentang Habré referensi tiga artikel oleh Denis Magda: , , 2016-2017. Di artikel kedua, Denis menyarankan untuk memulai node cluster melalui MaintenanceServiceNodeStartup.jar. Anda juga dapat menggunakan peluncuran dengan konfigurasi xml dan baris perintah, namun kemudian Anda perlu menempatkan kelas khusus secara manual pada setiap node cluster yang disebarkan:
That's it. Start (..) node using MaintenanceServiceNodeStartup file or pass
maintenance-service-node-config.xml to Apache Ignite's ignite.sh/bat scripts.
If you prefer the latter then make sure to build a jar file that will contain
all the classes from java/app/common and java/services/maintenance directories.
The jar has to be added to the classpath of every node where the service
might be deployed.Memang benar, itu saja. Ternyata, format biner misterius ini!
3. Toples Tunggal
Denis menempati posisi pertama dalam peringkat pribadi saya, IMHO tutorial paling berguna dari semua yang tersedia. Di miliknya Github berisi contoh pengaturan node cluster yang sudah siap pakai, yang dikompilasi tanpa jongkok tambahan apa pun.
Saya melakukannya dengan cara yang sama dan mendapatkan satu file jar yang meluncurkan "data node" atau "client node" tergantung pada argumen baris perintah. Perakitan dimulai dan berfungsi. Zero Deployment telah dikalahkan.
Transisi dari megabyte data uji ke puluhan gigabyte data pertempuran menunjukkan bahwa format biner ada karena suatu alasan. Hal ini diperlukan untuk mengoptimalkan konsumsi memori pada node, dan di sinilah BinaryObject menjadi sangat berguna.
4. Kesimpulan
Kecaman pertama yang muncul mengenai ketidakjelasan dokumentasi proyek Apache Ignite ternyata wajar; hanya sedikit yang berubah sejak tahun 2016. Tidak mudah bagi pemula untuk merakit prototipe yang berfungsi berdasarkan situs web dan/atau repositori.
Berdasarkan hasil pekerjaan yang dilakukan, kesannya Zero Deployment berfungsi, namun hanya pada level sistem. Sesuatu seperti ini: BinaryObject digunakan untuk mengajarkan node cluster jarak jauh untuk bekerja dengan kelas khusus; Zero Deployment - mekanisme internal
Apache Ignite sendiri dan mendistribusikan objek sistem ke seluruh cluster.
Semoga pengalaman saya bermanfaat bagi pengguna baru Apache Ignite.
Sumber: www.habr.com