Bagaimana cara menyimpan 3 juta catatan dalam format nilai kunci?

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?

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.

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).

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)

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.

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.

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/

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.

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.

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.