Tips dan Trick membangun Big Data

[horasjey]

Hallo om,

minta sarannya dong

kira kira hal apa ya yang perlu di perhatin agar Sebuah Proses pembacaan database tidak berat atau memakan resouce besar / banyak.

karena sejauh ini yang telah saya rasakan adalah

1. ketika baru buat website dari awal ( katakan tidak ada postingan ), maka website cepat saat di proses penambahan postingan , termasuk mencari postingan dari data.
2. namun ketika website sudah berisi sekitar 1000 data , baru muncul masalah baru , di mana Respource CPU habis di mysql hingga ribuan%

Yang ada dalam pikiran saya, apakah ada tips atau trik membangun database besar / bigData agar bisa maksimal ketika data banyak , apakah itu struktur database ,atau driver database yang recomended, atau emnag harus butuh resouce yang gede untuk melakukan hal itu ketika data sudah banyak..?



mungkin ada yang sepemikiran dengan saya..?


salam hormat

 

[wpanel]

cara paling gampang menurut saya adalah
buat 1 skenario dalam 3 bahasa pemrograman, (nodejs, php dan go)
terus di test dan di analasis.
bisa prometheus, datadog dll.
dari situ keliatan bottlenecknya apa. apa di database atau di bahasanya.
disesuaikan dengan kasusnya, pakai alat yang tepat.

dalam kasus saya, saya lebih menyukai duckdb dan sqlite untuk big data.
tidak menyukai mysql dan postgres.

 

[sa1638]

namun ketika website sudah berisi sekitar 1000 data , baru muncul masalah baru , di mana Respource CPU habis di mysql hingga ribuan%

Apakah sudah terkait query? apakah sudah dioptimasi database, mungkin normalisasi database dan query? Aneh juga kalau 1000 data saja loadnya sampai ribuan%.

 

[horasjey]

cara paling gampang menurut saya adalah
buat 1 skenario dalam 3 bahasa pemrograman, (nodejs, php dan go)
terus di test dan di analasis.
bisa prometheus, datadog dll.
dari situ keliatan bottlenecknya apa. apa di database atau di bahasanya.
disesuaikan dengan kasusnya, pakai alat yang tepat.

dalam kasus saya, saya lebih menyukai duckdb dan sqlite untuk big data.
tidak menyukai mysql dan postgres.

Wordpress bs menggunakan golang ya om untuk backend DB nya..?

Apakah sudah terkait query? apakah sudah dioptimasi database, mungkin normalisasi database dan query? Aneh juga kalau 1000 data saja loadnya sampai ribuan%.

ia , ini yang lagi saya coba pahamin terkait database,
hal hal apa yang harus di perhatikan agar tidak memakan resource besar saat data base sudah banyak,

Aneh juga kalau 1000 data saja loadnya sampai ribuan%.

ini hanya data perumpamaan saja, Db mysql saya ukurannya sekitar 200Mb+ an, tp proses update data atau post data ke DB makan resource besar, apakah emg gt Flowchart nya DB, semakain besar ukuran DB , semakan lambat proses update data atau memakan resource besar.

 

[Milea Adnan]

Kalau mau masih pakai RDBMS / SQL :
1. Pindah ke MariaDB (karena masih support Stored Procedure / PL-SQL), MySQL tidak support.
2. Sederhanakan query (jangan dikit-dikit pakai select * from).
3. Ganti storage engine-nya pakai MyRocks (kl masih setia sama MySQL, ganti pakai InnoDB).
4. Tweak konfigurasi MariaDB nya (my.cnf), bisa pakai tool-tool yg disediakan via online.
5. Optimalkan penggunaan stored-procedure-nya, spy trafik data antara aplikasi dengan DB jauh berkurang.
6. Caching database-nya menggunakan memcached, buat meminimalisir lagi trafik antara aplikasi dan DB.

Atau bisa meninggalkan RDBMS / SQL, dengan menggunakan NoSQL, seperti misalnya MongoDB dan Redis.

 

[XXIKU.COM]

Kalau saya sih mengandalkan Memcached atau Redis, disk server selalu pilih pakai yg SSD NVMe Samsung untuk kecepatan respons dan proses data r/w. Masih betah MariaDB

 

[wpanel]

Wordpress bs menggunakan golang ya om untuk backend DB nya..?

di awal tidak dijelaskan dalam kasus apa, dikira "Big Data" beneran. Go tidak bisa menjalankan wordpress. tapi si om bisa buat kompiler buat php agar berjalan standalone tanpa php engine. Kalau kasusnya adalah wordpress dan lemot dengan 1000 data. ada yang salah itu, bukan dengan php nya tapi ada masalah yang perlu dicari

 

[Habibillah]

jangan-jangan querya gak ada yang pake limit offset.