Database
 sql >> Teknologi Basis Data >  >> RDS >> Database

Kueri Basis Data:Bagaimana Cara Menemukan Jarum di Tumpukan Jerami?

Skenario anak poster untuk data besar – Anda perlu menyaring sejumlah besar data untuk mengekstrak yang kecil “ nugget” informasi. Selain itu, perlu dilakukan dalam waktu sesingkat mungkin, bisnis Anda bergantung padanya. Secara historis, menggunakan teknologi sistem manajemen basis data relasional (RDBMS) tradisional, skenario semacam ini membutuhkan tim yang besar dan investasi waktu dan uang. Sebagian besar RDBMS tradisional hanya menskalakan secara vertikal, jadi Anda harus terus membeli mesin yang lebih besar dan lebih besar untuk mengurangi waktu penyelesaian Anda. Munculnya cloud publik dan database NoSQL seperti MongoDB benar-benar mengganggu cara tim memikirkan skenario ini.

Salah satu pelanggan kami baru-baru ini datang kepada kami dengan masalah yang menarik. Mereka secara berkala perlu menjalankan kueri yang sangat kompleks yang memindai seluruh kumpulan data mereka. Kueri ini hampir merupakan pemindaian koleksi yang menyentuh setiap dokumen dalam koleksi, dan menyertakan detail berikut:

  • Total data sekitar 100 GB.
  • Keamanan data tidak menjadi masalah karena salinan utama data berada di tempat lain.
  • Kecepatan kueri sangat penting. Tujuannya adalah untuk dapat menjalankan seluruh kueri dalam waktu 10-15 menit.
  • Sistem hanya perlu aktif saat kueri sedang berjalan (minimalkan biaya).

Karena persyaratan terakhir, masuk akal untuk menjalankan seluruh sistem di cloud publik. Mesin dihidupkan hanya beberapa jam setiap minggu agar data diperbarui dan kueri dijalankan. Pelanggan sudah merasa nyaman dengan Amazon EC2, sehingga keputusan dibuat untuk membuat prototipe sistem di AWS.

Konfigurasi terbaik untuk mencapai tujuan ini adalah penerapan MongoDB yang di-sharding. Inilah konfigurasi yang kami tentukan:

  • 3 pecahan – setiap pecahan memiliki instans mandiri (r3.xlarge) dengan RAM 30 GB
  • 1 server konfigurasi
  • 1 router pecahan (m3.xlarge) dengan RAM 15 GB

Beberapa hal yang perlu diperhatikan tentang pilihan kita:

  • Set Standalone vs. Replika

    Keamanan data bukanlah persyaratan penting di sini karena data master disimpan dalam sistem yang terpisah. Oleh karena itu, kami menggunakan server mandiri alih-alih set replika untuk menghemat biaya.

  • 3 Server Konfigurasi vs 1 Server Konfigurasi

    ama alasan seperti di atas. Keamanan data bukanlah masalah penting. Dalam lingkungan produksi yang khas, kami akan menggunakan tiga server konfigurasi.

Keindahan sebenarnya dari konfigurasi ini adalah karena konfigurasi sharded, hampir seluruh 100GB data disimpan sepenuhnya di dalam memori. Jadi, pada dasarnya apa yang Anda jalankan adalah pemindaian "dalam memori". Ini secara dramatis mengurangi waktu menjalankan kueri dari beberapa jam menjadi kurang dari 10 menit. Penggunaan cloud publik juga secara dramatis mengurangi investasi modal karena Anda hanya membayar mesin saat sedang berjalan.

Ini adalah perubahan yang cukup dramatis dalam cara tim menangani skenario ini selama dekade terakhir. Jadi, jika Anda berada dalam bisnis "menemukan jarum di tumpukan jerami", pikirkan Cloud + NoSQL!

Seperti biasa, jika Anda memiliki pertanyaan, Anda dapat menghubungi kami di [email protected].


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Kejutan dan Asumsi Kinerja :DATEADD

  2. ETL vs ELT:Kami Memposisikan, Anda Menilai

  3. FrankenQueries:ketika SQL dan NoSQL bertabrakan

  4. 12 Operator SQL yang Umum Digunakan

  5. Cara Menambahkan Posisi Peringkat ke Baris dengan DENSE_RANK() di SQL