Database Scaling

 Database Scaling
Ketika database sudah 1TB maka aplikasi kita sudah lemot dan reponse lambat bngt, atau ketika insert lama bngt.
1. Vertical scaling
Memperbesar /upgrade hardware harddisk, misal dari RAM 8GB ke 16GB.
hardware punya limit, cpu, ram, hardisk, dan harga nya kenaikan hardware semakin mahal secara exponensial. Skalabitas terbaik dari horizontal scalling
2. Horizontal scaling
Beli baru dan spek yg sama dan dipasang sebgai node atau server baru. contoh misal data kita 1 TB, kita beli 250GB dan di sharding di taruh di 4 server dimana setiap server membaca 250GB
problemnya ketika insert data, tekniknya dengan routing data caranya gmn bisa consisten.
pemotongan data terlalu ribet nambah customer baru.
sharding algorithm
var hash = hashingAlgo(data.id)
var shardNum = hash % totalShard;
database.save(data,shardNum);

Dengan seperti itu akan konsisten dibanding manual routing berdasarkan daerah.

Serching kita harus di semua shard atau di semua partisi. Bagaimana degan paging ? melakukan 20 data tiap data utk 1 page menjadi total data, dan disorting 20 data pertama, Deep paging problem, hasilnya ketika page 1000, tiap partisi maka ada problem. Kita ganti paging dengan kriteria, ganti cara melampilkan data, contoh internet banking, ketika daftar transaksi (tiidak dengan paging) tetapi rata2 melakukan query dengan rentang waktu. Tantangannya aplikasi ecommerce tidak bisa rentang waktu, tetapi bisa kriteria waktu.
Ketika server mati dlm aplikasi sharding kita hanya kehilangan 1 buah part, problemmnya, kita select data di shard mati maka tidak ada. solusinya replication data  dinode beda, tetapi makin bnyak data atau 2 kali lipat. Cara handle sharding, replication, distribusi routing, searching jngan manual mending kita kasihkan ke databasenya. Saat ini diusahakan problem2 database, mongodb, casandra dll. teknik terakhir itu dengan caching. Simpan cache di aplikasi atau menggunakan DB utk caching, biasanya ada di RAM atau database. biasnaya select di memory.