SQL vs NoSQL untuk sistem manajemen inventaris

1. Antrian untuk mengelola pembaruan inventaris untuk setiap saluran.

Ini belum tentu masalah database. Anda mungkin lebih baik melihat sistem perpesanan (mis. RabbitMQ)

1. Tabel inventaris yang memiliki cuplikan alokasi yang benar di setiap saluran.
2. Menyimpan ID Sesi dan data akses cepat lainnya dalam cache.

data sesi mungkin harus dimasukkan ke dalam database terpisah yang lebih cocok untuk tugas tersebut (mis. memcached, redis, dll.) Tidak ada DB satu ukuran untuk semua

1. Menyediakan facebook like dashboard(XMPP) agar penjual selalu update secepatnya.

Kendala saya adalah:1. Pembaruan inventaris tidak dapat hilang.

Ada 3 cara untuk menjawab pertanyaan ini:

1. Fitur ini harus disediakan oleh aplikasi Anda. Basis data dapat menjamin bahwa catatan yang buruk ditolak dan dikembalikan, tetapi tidak menjamin bahwa setiap kueri akan dimasukkan. Aplikasi harus cukup pintar untuk mengenali saat terjadi kesalahan dan mencoba lagi.

2. beberapa DB menyimpan catatan dalam memori dan kemudian menyiram memori ke disk secara berkala, ini dapat menyebabkan hilangnya data jika terjadi kegagalan daya. (mis. Mongo bekerja dengan cara ini secara default kecuali Anda mengaktifkan penjurnalan. CouchDB selalu menambahkan catatan (bahkan menghapus adalah tanda yang ditambahkan ke catatan sehingga kehilangan data sangat sulit))

3. Beberapa DB dirancang untuk sangat andal, bahkan jika gempa bumi, angin topan, atau bencana alam lainnya menyerang, mereka tetap tahan lama. ini termasuk Cassandra, Hbase, Riak, Hadoop, dll

Jenis daya tahan apa yang Anda maksud?

1. Antrian Pekerjaan harus dijalankan secara berurutan dan sebaiknya tidak pernah hilang.

Sebagian besar solusi noSQL lebih suka dijalankan secara paralel. jadi Anda memiliki dua opsi di sini.1. gunakan DB yang mengunci seluruh tabel untuk setiap kueri (lebih lambat)2. buat aplikasi Anda menjadi lebih pintar atau lebih baik (antrean berurutan sisi klien)

1. Pengembangan yang mudah/cepat dan pemeliharaan di masa mendatang.

umumnya, Anda akan menemukan bahwa SQL lebih cepat untuk dikembangkan pada awalnya, tetapi perubahan bisa lebih sulit untuk diterapkan.NoSQL mungkin memerlukan sedikit lebih banyak perencanaan, tetapi lebih mudah untuk melakukan kueri ad hoc atau perubahan skema.

Pertanyaan yang mungkin perlu Anda tanyakan pada diri sendiri lebih seperti:

1. "Apakah saya perlu memiliki pertanyaan intens atau analisis mendalam yang lebih cocok untuk Peta/Pengurangan?"

2. "apakah saya perlu sering mengubah skema saya?

3. "apakah data saya sangat relasional? dalam hal apa?"

4. "apakah vendor di balik DB pilihan saya memiliki pengalaman yang cukup untuk membantu saya saat saya membutuhkannya?"

5. "apakah saya memerlukan fitur khusus seperti pengindeksan GeoSpasial, pencarian teks lengkap, dll?"

6. "seberapa dekat dengan waktu nyata saya akan membutuhkan data saya? apakah akan merugikan jika saya tidak melihat catatan terbaru muncul di kueri saya hingga 1 detik kemudian? tingkat latensi apa yang dapat diterima?"

7. "apa yang benar-benar saya butuhkan dalam hal fail-over"

8. "seberapa besar data saya? apakah akan muat di memori? apakah akan muat di satu komputer? apakah masing-masing record besar atau kecil?

9. "seberapa sering data saya akan berubah? apakah ini arsip?"

Jika Anda akan memiliki banyak pelanggan (saluran?) masing-masing dengan skema inventaris mereka sendiri, DB berbasis dokumen mungkin memiliki kelebihannya. Saya ingat suatu kali saya melihat sistem e-niaga dengan inventaris dan memiliki hampir 235 tabel! Kemudian lagi, jika Anda memiliki data relasional tertentu, solusi SQL benar-benar dapat memiliki beberapa keuntungan juga.

Saya pasti bisa melihat bagaimana saya bisa membangun solusi menggunakan mongo, couch, riak atau orientdb dengan batasan yang diberikan. Tapi untuk mana yang terbaik? Saya akan mencoba berbicara langsung dengan vendor DB, dan mungkin menonton kaset nosql