Pengoptimalan Odoo data besar adalah masalah yang sangat serius karena ketika Odoo digunakan oleh perusahaan besar, menyiratkan bahwa mereka akan menggunakan sistem secara ekstensif dan itu sejalan dengan pertumbuhan data yang sangat cepat dan berkelanjutan. Jelas, tabel standar yang paling terpengaruh adalah yang kita sebut tabel "_lines" seperti:
sales_order_line
account_move_line
stock_move_line
Masalah
Untuk mengevaluasi dampak pertumbuhan data generik pada tabel ini, bayangkan sebuah perusahaan standar dengan 10 cabang dan 2 orang akuntansi yang memvalidasi 100 faktur setiap hari buka. Berbicara realistis dan tetapkan jumlah rata-rata sales_invoice_line per faktur pada 10 item per faktur. Hasilnya adalah sebagai berikut:
100 faktur X 10 item per faktur = 1000 baris faktur.
1000 baris faktur akan menghasilkan 1000 lini produk + 100 baris pajak + 100 baris jumlah faktur total di dalam Jurnal Penjualan jika kita mengkonfigurasi baris terakhir untuk menulis account_moves PER PRODUCT, yang merupakan satu-satunya cara yang baik untuk menarik nilai Dashboarding yang baik di kemudian hari per akun atau per produk kategori dll… Ini berarti 1200 akun_move_lines per pengguna per hari.
Dikalikan dengan 2 pengguna, ini memberi kami 2.400 entri akun_move_line per cabang per hari.
Dikalikan dengan 10 cabang, ini memberi kita 24.000 entri account_move_line per perusahaan per hari.
Dikalikan 25 hari, kita mendapat 24.000 X 25 = 600.000 akun_move_lines per bulan.
Setiap tahun, kami mendapatkan 600.000 x 12 = 7.200.000
Di atas 3 juta baris, Anda akan mulai merasakan dampak penting pada penurunan performa.
Lebih dari 5 hingga 6 juta baris, Anda akan merasakan penurunan secara berat. Tentu saja, ini tergantung pada perangkat keras Anda, teknologi disk, ketersediaan CPU, strategi antrian, dll. Tetapi secara keseluruhan, dalam kasus kami saat ini, ada lebih banyak masalah yang datang:
7.200.000 entri account_move_line adalah faktur murni yang divalidasi… .. tetapi ini berarti tabel sales_order_lines dapat 2 hingga 10 kali lebih besar dalam periode yang sama karena juga berisi penawaran. Berbicara realistis dan menilai bahwa Anda mengkonversi 30% dari penawaran Anda menjadi penjualan: tabel sales_order_line Anda akan menjadi sekitar 3 kali lebih besar: itu adalah kasar 21.000.000 entri per tahun yang sedang kita bicarakan.
Anda memiliki sebanyak itu di tabel stock_move_lines.
Saya bahkan tidak berbicara tentang MRP yang dapat membuat tabel yang lebih besar bersama dengan nomor lot dll… jika klien melakukan produksi juga.
Saya berasumsi bahwa ini adalah sistem untuk 1 Perusahaan. Jika tidak, Anda akan mendapatkan data dari perusahaan yang berbeda di dalam tabel yang sama. Bayangkan ini dikalikan dengan 3 perusahaan di dalam tabel yang sama!
Saya berasumsi Anda memiliki server khusus dan sumber daya khusus per perusahaan, tetapi tidak selalu demikian karena banyak orang yang masih menggunakan shared hosting.
Sekarang, jika kami menganggap Anda memiliki sekitar 30 pengguna yang mengakses tabel dasar dan paling penting ini secara bersamaan dan beberapa pengguna mencoba melakukan Dashboarding sementara yang lainnya mencoba bekerja…. Baik…. Lupakan! Belilah kopi untuk diri Anda sendiri atau berlangganan kelas Zen.
Mengukur Kesesuaian Kinerja
Banyak klien kami termasuk departemen IT, Mitra Odoo lainnya, dan pengembang Independen telah meminta kami untuk mengoptimalkan penerapan mereka karena sistem melambat. Saya menghabiskan waktu bermain-main dengan yang berikut ini untuk memberi Anda wawasan yang sebenarnya tentang pengoptimalan data besar di Odoo. Kit tes saya terdiri dari:
1 XEON E5 – 6 cores CPU 2Ghz
8 Gb RAM
SSD Hard Drive 256 Gb
Ubuntu 16.04
PostgreSQL 9.5
Pengujian dilakukan dengan dan tanpa PgBouncer
Data palsu dibuat untuk acara tersebut di dalam tabel account_move / account_move_line
Berikut hasil pengukuran saya berikut ini:
Memilih semua Item Jurnal dari Semua jurnal
Dikelompokkan berdasarkan periode
Tanggal efektif lebih dari...
Tanggal efektif kurang dari…
Dengan jumlah SUM yang dihitung untuk kolom Kredit/Debit di bagian bawah
Dari penjelasan di atas, orang dapat dengan jelas memahami bahwa:
Pengindeksan membantu tetapi tidak cukup dalam jangka panjang
Partisi bekerja jauh lebih baik
Menngabungkan Partisi dan Pengindeksan bekerja lebih baik
Penggabungan Partisi dan Pengindeksan dan mengasosiasikannya dengan PGBouncer memberikan hasil terbaik.
Untuk 1.000.000.000 baris, perbedaan antara struktur standar PostgreSQL Odoo dan Dioptimalkan dengan Partisi, Pengindeksan, dan PgBounce turun dari 30,000 md (30 detik) menjadi kurang dari 3,000 md (3 detik). Namun, perlu diingat bahwa ini hanya satu permintaan dari satu pengguna. Letakkan ini dalam perspektif dengan 30 atau lebih pengguna bersamaan dan Anda memahami ini adalah perbedaan antara sistem yang berjalan dan sistem yang hanya secara sistematis kehabisan waktu dan menyebabkan kesalahan hingga akhirnya macet.
Jika Anda skeptis tentang analisis di atas untuk pengoptimalan Big Data Odoo, lihat posting ini: PostgreSQL: Tabel Partisi vs Tabel Non Partisi. Ini tidak didedikasikan untuk Odoo dan berurusan dengan tabel yang lebih sederhana di dalam PostgreSQL tetapi pendekatannya sangat mudah dan akurat, dan kesimpulannya cukup identik.
Apakah Anda ingin mengoptimalkan data dalam jumlah besar di sistem Anda?
Melaksanakan Strategi Optimasi Odoo Data Besar
Jika Anda membaca posting ini, itu berarti Anda mempertimbangkan untuk memberikan solusi data besar dengan Odoo atau PostgreSQL sebagai basis atau Anda sudah mengalami kelambatan. Namun, ketahuilah bahwa kelambatan dapat berasal dari berbagai alasan:
Anda membiarkan PostgreSQL Anda dikonfigurasi dengan pengaturan default. Ada banyak hal yang harus dilakukan di sisi itu untuk memanfaatkan potensi sebenarnya dari server / cluster PostgreSQL Anda dan pengaturan default pasti harus diganti dengan sumber daya dan strategi penggunaan yang tepat.
Anda memiliki sesi antrian dan masalah autentikasi HBA atau keduanya: belajar menggunakan PgBouncer
Jika kasus Anda tidak sesuai dengan alasan di atas, maka Anda mungkin perlu masuk ke Indexing dan Partitioning dan rekomendasi saya adalah sebagai berikut:
Berhati-hatilah karena pengindeksan dapat menjadi mahal dalam sumber daya, terutama jika Anda bermain-main dengan nilai string.
Menempatkan Pengindeksan di mana-mana adalah pendekatan yang SALAH. Letakkan hanya di tempat yang Anda ketahui ORM dan modul Anda cenderung untuk mendorong dan menarik nilai.
Tentukan strategi partisi dari awal dan jangan menunggu sampai tabel Anda menjadi besar. Anda TAHU profil klien Anda, omset, pengguna dan ini HARUS diantisipasi.
Strategi partisi Anda harus mengikuti orientasi pertumbuhan data. Setiap klien berbeda. Ini selalu merupakan proses "per kasus".
Menerapkan logika struktur tabel partisi yang mengikuti logika pemicu.
Waspadai aturan pemicu yang salah didefinisikan yang dapat menyebabkan tumpang tindih data atau loop tak terbatas.
Aturan Pemartisian berfungsi ... tetapi dari pengalaman, Pemicu (trigger) berfungsi LEBIH BAIK dengan Odoo. Jadi, tetap berpegang pada pemicu (trigger).
Jika versi PostgreSQL Anda adalah 11 atau lebih tinggi, maka saya sangat menyarankan Anda menggunakan warisan partisi.
Bersikaplah lembut dengan Pemicu (Trigger). Jika Anda membutuhkan kerumitan, masukkan ke dalam fungsi sebagai gantinya.
Regangkan partisi anak Anda sesuai dengan pola Odoo atau Data.
Gunakan Pengecualian Batasan untuk mengoptimalkan kecepatan kueri Anda. Untuk dapat melakukannya, ingatlah untuk menyusun partisi Anda sesuai dengan ini juga.
Jika Anda sudah memiliki sistem yang lambat dan perlu mengatur ulang data Anda melalui proses partisi pengoptimalan Big data Odoo, Anda harus mengikuti panduan di bawah ini:
Terapkan juga rekomendasi di atas.
Ingat Odoo tidak tahu Anda mengubah struktur data di dalam PostgreSQL. Melakukannya dengan cara yang benar menyiratkan bahwa Anda mempertahankan semua nama tabel induk, kolom, format data dan batasan antar tabel.
Periksa jumlah data Anda sebelum dan sesudah resegmentasi / partisi. YA, ini dasar… tetapi Anda harus memastikan semuanya ada di sana.
Ingatlah untuk mempersiapkan masa depan juga. Memisahkan data per tahun untuk data masa lalu misalnya tetapi tidak memisahkannya untuk tahun-tahun mendatang adalah kesalahan BESAR. Ingat PostgreSQL akan berjalan selambat permintaan paling lambat dari semuanya. Jadi, jika Anda mempertimbangkan untuk memisahkan dengan baik 5 tahun terakhir yang berat dan kemudian membiarkan kekacauan besar sebagai meja aktif untuk semua yang lainnya yang terus berkembang, Anda tidak menyelesaikan apa pun… dan hanya membuat segalanya menjadi berantakan. Performa juga akan menurun.
Port Cities - Tim global dengan keahlian Optimalisasi Data Besar
IJika Anda merasa pengoptimalan Big Data Odoo ini terlalu rumit dan terlalu terspesialisasi, maka Anda harus mempertimbangkan untuk melakukannya dan diintegrasikan oleh tim yang memiliki pengalaman di Odoo dan PostgreSQL. Port Cities memiliki tim yang terdiri dari 80 pengembang internal yang siap membantu Anda dengan pengoptimalan Big Data.
Hubungi kami untuk informasi lebih lanjut tentang cara mengoptimalkan data Anda dan meningkatkan kinerja sistem Anda seiring dengan pertumbuhan perusahaan Anda.
