Jangan biarkan skala spasial (1000+ perangkat) menyesatkan Anda tentang skala komputasi dan/atau penyimpanan. Beberapa lusin sisipan 35-byte per detik adalah beban kerja sepele untuk DBMS arus utama apa pun, bahkan berjalan pada perangkat keras kelas bawah. Demikian pula, 142 juta catatan per bulan hanya dalam urutan penyimpanan 1~10 gigabyte per bulan, tanpa kompresi apa pun, termasuk indeks.
Dalam komentar pertanyaan Anda, Anda mengatakan:
"Ini semua tentang keandalan, skalabilitas, dan kecepatan. Sangat penting bahwa solusi skala dengan mudah (MongoDB autosharding?) hanya memasukkan lebih banyak node, dan kecepatan juga sangat penting
Keandalan? DBMS arus utama mana pun dapat menjamin ini (dengan asumsi maksud Anda itu tidak akan merusak data Anda, dan itu tidak akan macet - lihat diskusi saya tentang teorema CAP di bagian bawah jawaban ini). Kecepatan? Bahkan dengan satu mesin, 10~100 kali beban kerja ini seharusnya tidak menjadi masalah. Skalabilitas? Pada tingkat saat ini, data satu tahun penuh, tidak terkompresi, bahkan diindeks sepenuhnya, akan dengan mudah masuk ke dalam 100 gigabyte ruang disk (juga, kami telah menetapkan bahwa tingkat penyisipan tidak menjadi masalah).
Karena itu, saya tidak melihat kebutuhan yang jelas untuk solusi eksotis seperti NoSQL, atau bahkan database terdistribusi -- database relasional lama seperti MySQL akan baik-baik saja. Jika Anda khawatir tentang failover, cukup siapkan server cadangan dalam konfigurasi master-slave. Jika kita berbicara 100 atau 1000 kali skala saat ini, cukup partisi secara horizontal beberapa instance berdasarkan ID perangkat pengumpulan data (yaitu {indeks partisi} ={device id} modulo {jumlah partisi}).
Ingatlah bahwa meninggalkan batas-batas yang aman dan nyaman dari dunia database relasional berarti mengabaikan kedua model representasionalnya dan perangkatnya yang kaya . Ini akan membuat "penambangan data kompleks" Anda jauh lebih sulit--Anda tidak hanya perlu memasukkan data ke dalam database, Anda juga perlu mengeluarkannya.
Semua itu dikatakan, MongoDB dan CouchDB sangat sederhana untuk digunakan dan digunakan. Mereka juga sangat menyenangkan, dan akan membuat Anda lebih menarik bagi banyak orang (bukan hanya programmer--eksekutif juga!).
Kebijaksanaan umum adalah bahwa, dari tiga solusi NoSQL yang Anda sarankan, Cassandra adalah yang terbaik untuk volume penyisipan tinggi (tentu saja, secara relatif, saya tidak berpikir Anda memiliki volume sisipan tinggi--ini dirancang untuk digunakan oleh Facebook ); ini dilawan dengan menjadi lebih sulit untuk diajak bekerja sama. Jadi, kecuali Anda memiliki beberapa persyaratan aneh yang tidak Anda sebutkan, saya sarankan untuk tidak melakukannya, untuk kasus penggunaan Anda.
Jika Anda yakin dengan penerapan NoSQL, Anda mungkin ingin mempertimbangkan teorema CAP. Ini akan membantu Anda memutuskan antara MongoDB dan CouchDB. Ini tautan yang bagus:http://blog.nahurst.com/visual-guide-to-nosql-systems. Semuanya bermuara pada apa yang Anda maksud dengan "keandalan":MongoDB memperdagangkan ketersediaan untuk konsistensi, sedangkan CouchDB memperdagangkan konsistensi untuk ketersediaan . (Cassandra memungkinkan Anda untuk menyempurnakan tradeoff ini, per kueri, dengan menentukan berapa banyak server yang harus ditulis/dibaca agar penulisan/pembacaan berhasil; UPDATE:Sekarang, begitu juga CouchDB, dengan BigCouch! Sangat menarik...)
Semoga sukses dalam proyek Anda.
