Bagaimana cara perusahaan seperti Amazon menghindari kemacetan mengakses lapisan basis data?

29

Jika Anda membayangkan perusahaan seperti Amazon (atau aplikasi web e-commerce besar lainnya), yang mengoperasikan toko online dalam skala besar dan hanya memiliki jumlah terbatas barang fisik di gudang, bagaimana mereka dapat mengoptimalkan ini sehingga tidak ada hambatan tunggal? Tentu saja, mereka harus memiliki sejumlah database dengan replikasi, dan banyak server yang menangani beban secara mandiri. Namun, jika banyak pengguna dilayani oleh server yang terpisah dan keduanya mencoba menambahkan item yang sama ke troli mereka, yang hanya ada satu yang tersisa, harus ada "sumber kebenaran" untuk jumlah yang tersisa untuk item itu. Bukankah ini berarti bahwa paling tidak, semua pengguna yang mengakses info produk untuk satu item harus meminta database yang sama secara serial?

Saya ingin memahami bagaimana Anda dapat mengoperasikan toko yang besar menggunakan komputasi terdistribusi dan tidak membuat hambatan besar pada DB tunggal yang berisi informasi inventaris.

web-applications scalability distributed-computing

— mattgmg1990
sumber

Arsitektur Amazon pada pertengahan tahun 2000-an (masih relevan dengan pertanyaan Anda): highscalability.com/amazon-architecture

— Joeri Sebrechts

Ini juga terjadi dengan kursi di pesawat terbang (atau untuk liburan misalnya paket di mana satu item dalam keranjang belanja mewakili penerbangan di sana, mobil sewaan, menginap di hotel dan penerbangan kembali), dengan banyak agen yang berbeda menjual kursi yang sama di situs masing-masing . Solusi banyak sekali tetapi mereka semua memiliki satu database kebenaran akhir dengan status aktual untuk setiap bagian di suatu tempat.

— RemcoGerlich

1

@RemcoGerlich: cara Anda mengatakan "satu database kebenaran akhir" membuat saya berpikir tentang satu mesin dengan database suci besar di atasnya. Pada kenyataannya, apa yang terjadi untuk data penting adalah bahwa semua transaksi mencapai beberapa server sekaligus, memastikan bahwa semua database itu sinkron setiap saat.

— Arseni Mourzenko

27

Namun, jika banyak pengguna dilayani oleh server yang terpisah dan keduanya mencoba menambahkan item yang sama ke troli mereka, yang hanya tersisa satu, pasti ada "sumber kebenaran" untuk jumlah yang tersisa untuk item itu.

Tidak juga. Ini bukan masalah yang membutuhkan solusi teknis 100% sempurna, karena kedua kasus kesalahan memiliki solusi bisnis yang tidak terlalu mahal:

Jika Anda salah memberi tahu pengguna item terjual, Anda kehilangan penjualan. Jika Anda menjual jutaan item setiap hari dan ini terjadi mungkin sekali atau dua kali sehari, itu akan hilang dalam kebisingan.
Jika Anda menerima pesanan dan saat memprosesnya ternyata Anda kehabisan barang, Anda cukup memberi tahu pelanggan dan memberi mereka pilihan menunggu sampai Anda dapat mengisi kembali, atau membatalkan pesanan. Anda memiliki satu pelanggan yang sedikit kesal. Sekali lagi bukan masalah besar ketika 99,99% pesanan bekerja dengan baik.

Bahkan, saya sendiri baru-baru ini mengalami kasus kedua, jadi ini bukan hipotesis: itulah yang terjadi dan bagaimana Amazon menanganinya.

Ini adalah konsep yang sering diterapkan ketika Anda memiliki masalah yang secara teori sangat sulit untuk dipecahkan (baik itu dalam hal kinerja, optimasi, atau apa pun): Anda sering dapat hidup dengan solusi yang bekerja sangat baik untuk sebagian besar kasus dan menerima bahwa kadang-kadang gagal, selama Anda dapat mendeteksi dan menangani kegagalan saat itu terjadi.

— Michael Borgwardt
sumber

2

Kenangan, Tebak, dan Permintaan Maaf Pat Helland yang juga dibahas di Building on Quicksand dan kompensasi transaksi adalah ide yang relevan di sini.

— Derek Elkins

1

Anda mengatakan "tidak benar-benar" tetapi saya merasa Anda setuju dengan apa yang saya sarankan. Kedengarannya seperti apa yang Anda katakan adalah bahwa ketika pengguna hanya menjelajah, kami memberikan perkiraan cache dari persediaan yang tersisa, tetapi hanya ketika mereka benar-benar mencoba untuk menyelesaikan pembelian yang kami lakukan menulis untuk mengurangi persediaan yang tersisa. DB yang berisi nilai itu akan mengeksekusi setiap transaksi secara atomis, dan jika dua pengguna mencoba pada saat yang sama, kami menampilkan pesan kesalahan untuk yang kedua, karena ini tidak mungkin terjadi. Jadi, pada akhirnya ada satu bilangan bulat pada satu mesin yang berisi "kebenaran."

— mattgmg1990

2

@ mattgmg1990: benar, akhirnya Anda tentu saja harus tahu "kebenaran" di suatu tempat, tetapi perbedaan penting adalah bahwa pemrosesan pesanan dapat dilakukan dalam antrian sehingga Anda tidak perlu akses tulis atom bersamaan. Dalam kasus saya, "pesan kesalahan" sebenarnya datang berjam-jam setelah saya menyelesaikan pesanan di situs web Amazon - saya mendapat email yang mengatakan bahwa mereka memiliki masalah dengan persediaan barang itu dan saya bisa memilih untuk membatalkan pesanan atau tidak melakukan apa-apa dan menunggu bagi mereka untuk memenuhinya. Saya melakukan yang terakhir karena saya tidak membutuhkan barang segera, dan mereka benar-benar mengirimkannya beberapa minggu kemudian.

— Michael Borgwardt

@DerekElkins itu adalah artikel yang bagus, terutama poin tentang data digital menjadi representasi dari kenyataan yang tidak dapat dihindari tidak sempurna karena kenyataan selalu dapat memiliki perubahan sistem Anda tidak dapat secara otomatis tahu.

— Michael Borgwardt

6

Kombinasi dari

hashing
pecahan
replikasi
distribusi
fail-over tinggi
toko kunci-nilai

Tidak ada keajaiban, hanya situasi yang semakin kompleks. Sama seperti DNS, itu dibuat untuk skala.

'Versi tunggal kebenaran' adalah bagian dari sistem semacam itu. Menghasilkan kunci baru menjadi operasi yang lebih kompleks daripada hanya menghasilkan nomor berikutnya dalam urutan. Misalnya ada sekuens lain. Ini adalah jenis kompleksitas yang dapat ditangani oleh sistem database terdistribusi dan mereka melakukannya dengan membuat beberapa operasi ke dan dari komponen ketika membuat objek baru, menjadikannya tersedia untuk orang lain, memastikan bahwa urutannya unik ketika diperlukan, kunci komposit, dll. .

— Michael Durrant
sumber

Saya sudah membaca tentang masing-masing konsep ini tetapi bagian saya tetap terjebak adalah skenario spesifik dari inventaris yang tersisa. Jika hanya ada 5 buku yang tersisa, dan pengguna membuat permintaan di beberapa server, apakah mereka selalu menyelesaikan ke tabel database tunggal ketika tiba saatnya untuk menanyakan inventaris yang tersisa untuk memastikan tidak ada dua pengguna yang bisa mendapatkan buku terakhir pada saat yang sama? Apa penggunaan khusus dari hal di atas yang membuatnya sehingga ini tidak memperlambat seluruh sistem dan replikasi masih bisa berguna dengan beberapa contoh DB?

— mattgmg1990

Menambahkan sedikit lagi. saya tidak bisa menjelaskan semua kerumitan dalam format ini, maaf.

— Michael Durrant

1

Hanya beberapa orang yang tertarik pada buku yang diberikan, ini berarti, buku dapat ditangani oleh beling dengan beban yang relatif kecil.

— Basilev

6

Saya pikir dalam skenario Anda menggambarkan sistem hanya harus meminta maaf kepada pengguna bahwa orang lain membeli salinan terakhir. Saya membayangkan ini memang terjadi dari waktu ke waktu.

— Matthew James Briggs

1

Saya bertaruh bahwa hanya ada 5 buku yang tersisa indikator kurang komputasi dan lebih banyak pemasaran.

— mouviciel

5

Saya telah melihat masalah 'Item Terakhir Dalam Stok' diselesaikan dengan cara berikut:

Perbarui semua level stok setiap hari dan beri flag produk sebagai tinggi, rendah, sesuai pesanan atau keluar dari kategori stok sesuai dengan level ambang batas.

Jelas itu item 'stok rendah' yang bermasalah

Item dengan tingkat stok tinggi

Jangan repot-repot mengecek level stok. Tempatkan saja pesanan

Item dengan tingkat stok rendah

Peringatkan pengguna saat menjelajah 'Sisa terakhir!'. ketika mereka pergi untuk membayar, periksa dan kurangi tingkat persediaan. Jika kehabisan stok, Perbarui status item.

Dengan cara ini Anda hanya menekan database untuk item 'stok rendah' dan Anda hanya melakukan itu ketika pelanggan cukup jauh dari proses pembelian. Biayanya adalah beberapa pelanggan tidak akan dapat menyelesaikan pembelian mereka.

Namun, dalam kebanyakan kasus 'kehabisan stok' sebenarnya hanya berarti Anda menunggu pengiriman lain, jadi Anda tetap ingin menerima pesanan dan mungkin hanya memunculkan peringatan atau membatasi opsi pengiriman. Jadi pelanggan tidak hilang.

Selama waktu muat yang tinggi seperti penjualan, Anda bahkan dapat mematikan pengecekan stok dan hanya mengirim email kepada pelanggan nanti, 'maaf kami kehabisan X, apakah Anda mau Y'

Pada dasarnya tujuan dari setiap platform e-commerce tidak pernah dibaca dari database. Selalu sajikan halaman yang di-cache dan lakukan semua sisi klien.

— Ewan
sumber

2

Dalam video ini, Martin Fowler membahas basis data NoSQL:

https://www.youtube.com/watch?v=qI_g07C_Q5I

Salah satu poin (di suatu tempat di sana), adalah bahwa tempat-tempat seperti Amazon lebih suka membuat 99% orang senang dengan menerima pesanan mereka tanpa bisa memeriksa "pasti" apakah itu benar-benar tersedia, dan mungkin mengganggu persentase yang sangat kecil dengan memiliki untuk mengatakan "maaf, sepertinya seseorang mengalahkanmu karenanya."

Artinya, tidak ada penanganan nyata untuk skenario yang Anda gambarkan, hanya saja Amazon mengambil manfaat dari keraguan berdasarkan pembacaan inventaris terakhir yang sukses, dan jika transaksi bersamaan menyelinap di antara - oopsi.

(btw, itu video yang bagus jika Anda penasaran dengan NoSQL)

— Jachach
sumber