Bagaimana cara menyimpan 3 juta catatan dalam format nilai kunci?

10

Kami harus menyimpan informasi dasar tentang 3 juta produk. Saat ini infonya adalah CSV 180 mb yang diperbarui setiap triwulan.

Akan ada sekitar 30.000 kueri per hari, tetapi kueri itu hanyalah sebuah toko nilai kunci yang sangat sederhana. Kami hanya perlu mencari ID produk dan menampilkan sisa informasi (yang semuanya akan menjadi satu catatan).

Ini untuk web, jadi kinerja cepat sangat penting.

Haruskah kita menggunakan MySQL, meskipun kita benar-benar tidak memerlukan database relasional? Haruskah kita menghasilkan 3 juta file html statis setiap kuartal? Haruskah kita menyimpan CSV satu baris untuk setiap produk pada sesuatu seperti Amazon S3 atau Rackspace Cloud Files? Apa cara terbaik untuk melakukan ini?

Phil
sumber

Jawaban:

16

Karena MySQL sangat banyak didukung dan ini benar-benar hal yang sepele untuk dilakukan, saya sarankan untuk menggunakannya. Kecuali server memiliki setidaknya beberapa GB memori saya sarankan tetap menggunakan MySQL daripada menggunakan sistem di-memori.

Setelah Anda mulai memasukkan data ke dalam basis data, apakah itu MySQL atau yang lainnya, kemungkinan besar Anda akan menemukan lebih banyak kegunaan untuk itu. Saat ini Anda hanya berbicara tentang pasangan nilai kunci tetapi sisa data terkait produk Anda harus disimpan di suatu tempat. Jika itu tidak ada dalam database saya tidak bisa membayangkan penyimpanan data menjadi sangat efisien.

Apa pun yang Anda lakukan, jangan membuat tiga juta file itu. Kami telah melihat sejumlah pertanyaan di sini yang dihasilkan dari masalah yang dibuat banyak file.

John Gardeniers
sumber
13

Anda dapat menggunakan tipe Key-Value khusus dari database NoSQL yang dioptimalkan untuk jenis tugas ini. Lihatlah:

  • Redis - Redis adalah open source, nilai kunci toko. Ini sering disebut sebagai server struktur data karena kunci dapat berisi string, hash, daftar, set, dan set yang diurutkan.
  • MemcacheDB - MemcacheDB adalah sistem penyimpanan nilai kunci terdistribusi yang dirancang untuk persisten.
  • yang lain (salah satu dari daftar tersebut dapat ditemukan di sini: http://nosql-database.org/ )

Tentu saja Anda dapat menggunakan MySQL atau database relasional lainnya, tetapi solusi yang dirancang khusus untuk tipe data kunci-nilai seharusnya lebih baik (jika tidak, apa gunanya mendesainnya di tempat pertama, kecuali mungkin fakta bahwa itu akan jauh lebih kecil (dalam hal RAM dan HDD) solusi).

LazyOne
sumber
Kita bisa menggunakan Redis, tetapi apakah Anda pikir ini akan bekerja pada P4 dengan 2 gigs RAM?
Phil
@Phil Mengingat file CSV Anda sekitar 180MB - seharusnya baik-baik saja. Meskipun kami menggunakannya dalam sebuah proyek (hanya sekali sejauh ini) dengan sekitar 200 ribu catatan dan server memiliki 8GB RAM sehingga sulit bagi saya untuk membandingkan.
LazyOne
6

Dan sekarang untuk sesuatu yang sama sekali berbeda:

Diberikan:

  • Produk 180MB / 3M = 62 byte / produk rata-rata.
  • 30.000 kueri per hari = 0,34 kueri per detik
  • Diperbarui setiap triwulan = data dasarnya statis

Solusi di luar kotak:

Dump setiap produk sebagai catatan sumber daya TXT dan simpan di DNS, misalnya:

$origin products.example.com.

product_1_name IN TXT "product 1 description"
product_2_name IN TXT "product 2 description"
...
product_3000000_name IN TXT "product 3000000 description"

Manfaat:

  • sangat andal dan tepercaya (Anda sudah bergantung padanya setiap hari)
  • dapat dibangun di hampir semua platform
  • hampir setiap bahasa memiliki dukungan untuk permintaan DNS dalam satu bentuk atau lainnya
  • open source dan server komersial mendukung berbagai jenis database backend
  • dapat direplikasi secara sepele (cukup tentukan beberapa server nama)
  • menangani pembaruan atom, bahkan ketika direplikasi di selusin server
  • dapat ditandatangani secara kriptografis untuk memastikan integritas data
  • dapat menangani pesanan dengan tingkat permintaan lebih tinggi per detik (10.000 kueri per detik mudah ditangani dengan perangkat keras komoditas)

Alasan mengapa ini mungkin ide yang buruk:

  • Anda perlu mencari data (DNS adalah kunci murni / nilai pencarian)
  • Anda perlu menyembunyikan data (DNS tidak memiliki kerahasiaan)
Theobroma Cacao
sumber
1
Jika saya bisa memberikan poin bonus untuk orisinalitas, ini akan mendapatkan suara saya. Saya tidak akan mengatakan DNS sama sekali dapat diandalkan, seperti pada jaringan rumah yang khas sepertinya ajaib jika ia bekerja dan kutukan jika tidak.
Martin Vilcans
1
Saya tertarik. Saya sebenarnya sangat menyukai ide ini, tetapi bagi saya, saya akan pergi dengan sesuatu yang sedikit lebih dicoba / diuji seperti CouchDB
Tom O'Connor
Pernah menonton Monty Python?
Mark Henderson
Agaknya ini berada dalam jaringan perusahaan. Keandalan DNS menjadi masalah ketika paket harus berani di internet. Karena, secara default, DNS menggunakan UDP, Anda harus bergantung pada kebijakan transmisi ulang resolver DNS jika sebuah paket dijatuhkan. Dalam jaringan perusahaan, kemungkinan Anda akan mendapatkan paket loss yang cukup signifikan (mungkin) dapat diabaikan. Dan Anda selalu dapat memaksa DNS untuk menggunakan TCP (meskipun dengan kinerja yang tinggi, dianggap tidak signifikan dalam kasus ini). Dan saya jamin, DNS mendapat lebih banyak pencarian daripada gabungan semua instalasi CouchDB :-).
Theobroma Cacao
Kapten Hindsight di sini. Satu kata: blockchain.
datashaman
4

MySQL dengan MyISAM dan beberapa indeks bagus kedengarannya cocok untuk ini. Ada banyak pilihan lain tentu saja, tetapi MySQL sangat luas (jika tidak secara universal) didukung pada web host komersial. Tergantung pada kecepatan yang Anda butuhkan, memcached mungkin juga layak untuk dilihat , tetapi tanpa mengetahui ukuran setiap pasangan kunci / nilai, menyimpan 3 juta dari mereka dalam memori mungkin merupakan ide yang bahkan lebih buruk daripada file CSV 180Mb (oh tunggu, itu file CSV 180Mb, jadi kita tahu seberapa besar mereka. Mereka pasti pasangan yang cukup kecil, jadi memcached bisa lebih baik).

Anda tidak ingin 3 juta file HTML statis, itu akan merusak sistem file Anda. CSV satu baris, bahkan pada S3, akan memiliki masalah yang sama. Tidak ada yang mau 3 juta file di folder.

Mark Henderson
sumber
Mereka adalah pasangan yang sangat kecil ... ini adalah data yang sangat mendasar seperti harga, tanggal pembuatan, jumlah gudang, dll. Kurang dari 10 kolom. Jadi Anda pikir MySQL adalah cara untuk pergi, benarkah? Server itu akan berjalan adalah P4 dengan 2 gigs RAM - saya pikir itu harus baik-baik saja?
Phil
@ Phil - So you think MySQL is the way to go, really?- tidak, tidak juga, tetapi sangat fleksibel dan seperti yang saya sebutkan, didukung hampir secara universal. Namun LazyOne telah memposting beberapa alternatif bagus di atas. Saya tidak ingat istilah NoSQL, tapi itu melayang-layang di otak saya di suatu tempat
Mark Henderson
4

Anda bisa menggunakan Berkeley Database yang melakukan hal semacam ini, bahkan jika itu belum pinggul sejak awal Perl5. Berkeley hanya mendukung pasangan nilai kunci, dan Anda mengikat seluruh db ke hash dan mengaksesnya.

Menggunakan Berkeley sangat terperinci dalam banyak referensi Perl lama yang ada di rak Anda atau coba Perldoc untuk Modul CPAN BerkeleyDB . Saya biasanya menghindari menggunakan Berkeley DB (meskipun majikan saya memiliki banyak kode kuno yang memainkannya dengan jelas, dan beberapa DB sama besarnya dengan milik Anda), karena tidak menyenangkan ketika data Anda menjadi lebih kompleks.

brainbuz
sumber
2
BDB adalah skool lama tetapi sangat efektif dan sesuai untuk situasi ini.
womble
Waspadalah terhadap lisensi untuk Berkely DB en.wikipedia.org/wiki/Sleepycat_license itu membutuhkan SEMUA kode sumber tersedia tidak hanya bagian DB.
WolfmanJM
4

Anda telah menandai pertanyaan Anda sebagai amazon S3.

Saya ingin menarik perhatian Anda ke salah satu produk terkait lainnya yang disebut Amazon SimpleDB.
Kedengarannya seperti model data SimpleDB akan cocok dengan jenis aplikasi Anda.

Ini bukan plug untuk itu, tetapi layak untuk dilihat terutama jika Anda berencana menggunakan layanan cloud Amazon.

Model data SDB menyerupai spreadsheet.

Lihat di sini untuk info lebih lanjut: http://aws.amazon.com/simpledb/ Dan model data: http://docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/

Mat
sumber
SimpleDB mahal. Sangat menyakitkan, dalam banyak kasus.
Tom O'Connor
1

Meskipun data 180MB dapat dengan mudah ditangani oleh basis data relasional, saya sangat merekomendasikan MongoDB ( http://www.mongodb.org/) di atas MySQL, Redis, MemcacheDB, dan toko nilai kunci lainnya atau basis data relasional. Alasannya adalah untuk masalah seperti ini, MongoDB adalah sistem tercepat, paling ekspresif untuk digunakan, memungkinkan pembaruan dinamis super cepat tanpa batasan skema, sehingga dokumen Anda dapat memiliki format yang berbeda jika Anda suka. Saya berada di sebuah presentasi dari guardian.co.uk tempo hari dan mereka telah membuat keputusan kebijakan untuk melarang semua database relasional dan menggunakan MongoDB secara eksklusif untuk menyajikan berita mereka. Anda dapat merasakan seberapa cepat situs web mereka dan yang telah online sejak 1995 (surat kabar online tertua di Inggris). Mereka juga telah melalui semua jenis kemacetan di masa lalu karena database relasional. Untuk 180mb, MongoDB akan melayani semuanya dari dalam memori, jadi waktu pemuatan sub-ms kemungkinan besar akan terjadi.

snez
sumber
0

Akan ada sekitar 30.000 kueri per hari, tetapi kueri itu hanyalah sebuah toko nilai kunci yang sangat sederhana. Kami hanya perlu mencari ID produk dan menampilkan sisa informasi (yang semuanya akan menjadi satu catatan).

Anda mengatakan bahwa pertanyaan Anda hanya pencarian kunci sederhana, dengan pencarian biner Anda memerlukan 21 iterasi pada kasus terburuk, dengan kunci hash pertanyaan Anda bahkan lebih cepat. Tiga juta catatan kecil selama Anda menghindari penggabungan (atau operasi jenis produk kartesius lainnya) dan pencarian linier.

Saya berani mengatakan apa pun akan baik-baik saja. Beban Anda adalah 30000 kueri / hari berarti bahwa (dengan asumsi beban Anda konstan sepanjang hari) Anda memiliki permintaan tunggal setiap 20 detik; itu tidak terlalu buruk.

Saya akan merekomendasikan menerapkan dalam teknologi yang paling Anda kenal pertama dan kemudian mengukur apakah ini benar-benar hambatan sistem.

Lie Ryan
sumber
0

Cara terbaik untuk melakukan ini sangat tergantung pada kualitas dan sifat data dan pertanyaan Anda. Sebagai permulaan, 180MB data dalam satu tabel untuk produk bukanlah masalah, bagaimanapun cara Anda melihatnya. Dan 30 ribu pertanyaan per hari bahkan lebih sedikit masalah. Dengan database yang dikonfigurasi dengan benar, desktop lama apa pun dapat menangani pemuatan ini.

Orang lain telah menunjukkan dua opsi utama Anda, MySQL atau database noSQL.

Jika Anda memiliki sejumlah atribut yang ada untuk setiap produk tunggal (seperti pabrikan, harga, nomor gudang, dll. Maka pilihan terbaik Anda adalah memiliki kolom untuk atribut ini dan mengonversi pasangan kunci / nilai Anda ke dalam format tabel datar, dengan ID produk sebagai kunci utama untuk tabel itu. Ini akan bekerja dengan sangat baik bahkan jika beberapa kolom hanya digunakan oleh setengah dari baris, karena untuk sebagian besar produk Anda hanya perlu menjalankan 1 kueri untuk mengambil semua atributnya. ini adalah data tentang produk, saya rasa kemungkinan besar ini adalah struktur data Anda.

Jika atribut sangat bervariasi dalam keberadaan dan tipe data, maka Anda mungkin lebih baik menggunakan database noSQL, yang menangani skenario ini lebih efisien daripada database SQL tradisional.

Mengenai kinerja: Saya sebelumnya pernah bekerja untuk perusahaan e-commerce, di mana untuk waktu yang lama situs web diberikan dengan data dari server MySQL. Server ini memiliki 2GB RAM, database secara keseluruhan sekitar. Berukuran 5GB dan di bawah beban teratas server menangani beberapa ribu permintaan per detik. Ya, kami telah melakukan banyak optimasi kueri, tapi ini pasti bisa dilakukan.

wolfgangsz
sumber