MongoDB atau CouchDB - cocok untuk produksi? [Tutup]

Saya bertanya-tanya apakah ada yang bisa memberi tahu saya apakah MongoDB atau CouchDB siap untuk lingkungan produksi .

Saya sekarang melihat solusi penyimpanan ini (saya mendukung MongoDB saat ini), namun proyek ini masih sangat muda dan saya memperkirakan bahwa saya harus bekerja cukup keras untuk meyakinkan manajer saya bahwa kita harus mengadopsi ini teknologi baru.

Yang ingin saya ketahui adalah:

1. Siapa yang menggunakan MongoDB atau CouchDB hari ini di lingkungan produksi?

2. Bagaimana Anda menggunakan MongoDB / CouchDB?

3. Masalah apa (jika ada) yang Anda temui ketika Anda mengadopsi mekanisme penyimpanan baru ini (dan bagaimana Anda mengatasinya)?

4. Bagaimana Anda menangani masalah migrasi yang harus Anda tangani?

5. Apakah Anda memiliki pengalaman baik / buruk dengan salah satu solusi yang ingin Anda bagikan?

Saya adalah CTO dari 10gen (pengembang MongoDB) jadi saya agak bias, tetapi saya juga mengelola beberapa situs yang menggunakan MongoDB dalam produksi.

businessinsider telah menggunakan mongo dalam produksi selama lebih dari setahun sekarang. Mereka menggunakannya untuk semuanya mulai dari pengguna dan posting blog, hingga setiap gambar di situs.

shopwiki menggunakannya untuk beberapa hal termasuk analitik waktu nyata dan lapisan caching. Mereka melakukan lebih dari 1000 menulis per detik ke database yang cukup besar.

Jika Anda pergi ke halaman Deployment Produksi mongodb Anda akan melihat beberapa orang yang menggunakan mongo dalam produksi.

Jika Anda memiliki pertanyaan tentang skala atau ruang lingkup penyebaran produksi, posting di daftar pengguna kami dan kami akan dengan senang hati membantu.

The BBC dan meebo.com menggunakan CouchDB dalam produksi dan begitu juga salah satu klien saya. Berikut adalah daftar orang lain yang menggunakan Couch: CouchDB in the wild

Tantangan utama adalah mengetahui bagaimana mengatur dokumen Anda dan berhenti berpikir dalam hal data relasional.

SourceForge menggunakan MongoDB. Lihat presentasi ini atau baca di sini .

Kami menjalankan CouchDB sebagai replacemant untuk MySQL untuk toko kami (70.0000 item / toko, total 4 juta atribut dari semua item, koneksi silang antar item).

Tujuan kami adalah:

1. Replikasi mudah dari master-db ke beberapa klien dengan dokumen yang berbeda.

2. Data cepat yang dihitung sebelumnya seperti "berapa banyak bagian yang saya miliki dengan atribut ini dan filter itu, sesuai dengan kondisi itu"

fakta:

1. Toko-toko kami sekarang berjalan jauh lebih cepat daripada dengan MySQL (dan database mysql membutuhkan tambahan 1-3 hari pra-perhitungan (sehingga pembaruan dua kali sebulan), membuat data siap untuk penghitungan dan penyaringan produk, CouchDB membutuhkan 5 jam, jadi kami dapat memperbarui data produk setiap malam)
2. Menyiapkan (difilter) distribusi & cadangan data ke node toko cepat dan mudah

tetapi juga:

1. Memahami peta / mengurangi dan batas tidak memiliki bergabung cukup sulit
2. Tidak ada operasi pada data seperti "hapus di mana" atau "perbarui di mana" tanpa program eksternal
3. Replikasi bekerja dengan baik, kecuali ada masalah; maka sangat sulit untuk mencari tahu apa alasannya (untuk pemula)
4. Instalasi CouchDB tanpa binari (ya ada beberapa di alam bebas, tetapi tidak untuk setiap OS / versi) bisa sulit, jika Anda bukan pecandu Linux. Tetapi Komunitas CouchDB sangat membantu (#couchdb), dan untungnya ada perusahaan di luar sana (cloudant, iriscouch) yang menawarkan layanan dari bisnis gratis ke bisnis besar.
5. CouchDB bergerak maju, jadi ada banyak perubahan (peningkatan) yang mungkin mengubah cara Anda bekerja. Tetapi hal-hal mendasar tetap stabil.

Hasilnya: MySQL sebagai basis data untuk pembuatan dan pemeliharaan data dapat diandalkan dan mudah dipahami dan ditangani. Saya pikir kita tidak akan mengubah ini. Tapi saya juga tidak ingin ketinggalan kekuatan pandangan CouchDB dan kemudahan pengaturan replikasi.

Sofa produksi terkadang menyebabkan masalah setelah berbulan-bulan bekerja karena kesalahan konfigurasi dan logrotate yang terlupakan (tampilan gedung terlalu lama atau hang, replikasi berhenti), tetapi data tidak pernah hilang, dan selalu dapat dengan mudah direset.

Saya menggunakan CouchDB dalam produksi. Saat ini ia menyimpan semua bidang 'opsional' yang tidak ada dalam skema DB asli. Dan saat ini saya sedang berpikir tentang memindahkan semua data ke CouchDB.

Saya akui itu langkah yang cukup berisiko. Pertama, karena belum v1.0. Dan kedua, karena ini adalah drive-lapar. Menurut perhitungan saya, file CouchDB (dengan indeks) ~ 30 kali lebih besar dari database MySQL dengan baris yang sama. Tapi saya cukup yakin itu akan berhasil dengan baik.

CouchDB 0.11 (dirilis pada akhir Maret) adalah rilis fitur-beku untuk 1.0. Ini berarti kami akan menjaga kompatibilitas dengan API saat ini untuk 1.0, jadi sekarang adalah waktu yang tepat untuk melihat CouchDB lagi jika Anda belum lama.

The CouchDB 0,11 sumber kode rilis tersedia di sini. Ada penginstal biner dan barang lainnya yang terhubung di sini.

Saya tidak tahu apa-apa tentang MongoDB, tetapi dari FAQ CouchDB :

Apakah CouchDB Siap Diproduksi?

Ya, lihat InTheWild untuk daftar sebagian proyek menggunakan CouchDB. Tinjauan bagus lainnya adalah Studi Kasus CouchDB

Juga, beberapa tautan:

• Re: Kondisi CouchDB saat ini?
• SimpleDB, CouchDB, dan Penyimpanan Data "BARU" Lainnya - Umpan Balik

Kami menggunakan couchdb dalam produksi dan telah sejak sebelum proyek berjalan di bawah payung Apache.

Kami menggunakannya untuk menyimpan semua yang mungkin kami gunakan dbms, ditambah semua jenis data tidak terstruktur. Secara pribadi, saya sangat suka bagaimana Anda bisa membuang semua jenis data ke dalamnya dan menggunakan tampilan untuk memilah apa yang tidak Anda butuhkan tergantung pada situasinya.

Bagian tersulit adalah menjauh dari pola pikir dbms. Kami menulis utilities migrasi kami ketika format penyimpanan berubah hanya untuk aman, jadi itu tidak benar-benar masalah.

Kami belum memiliki pengalaman negatif, tapi sekali lagi kami belum memiliki pengaturan di bawah segala macam beban. Saya pikir hal-hal akan bekerja dengan baik karena kami memiliki dua server tipe budak yang mereplikasi dari satu server master yang mendapatkan semua penulisan. Saya cukup yakin bahwa kita tidak harus melakukannya dengan cara seperti itu agar replikasi berfungsi dengan benar, tetapi itulah cara kita mengaturnya di awal dan macet.

Kami menggunakan CouchDB untuk menyimpan pesan masuk dan keluar seluler dan untuk melaporkan lalu lintas ini melalui beberapa tampilan khusus yang saya tulis. Bagian depan ditulis dengan Python. Kami tidak memiliki masalah teknis nyata, dan sudah berjalan sejak akhir Desember. Satu-satunya rintangan yang saya temui pada awalnya adalah berpikir dalam hal MapReduce, tetapi begitu saya belajar bagaimana melakukannya, segalanya berjalan dengan lancar.

Kami saat ini menggunakan MongoDB dalam produksi sebagai lapisan caching serta mesin penyimpanan untuk mengimpor dan memanipulasi data produk. Kami adalah perusahaan eCommerce yang mengelola lebih dari dua juta produk (100+ juta atribut), mencakup 10+ distributor dan tanpa MongoDB, tugas ini hampir mustahil.

Kami saat ini menggunakan mongodb sebagai layanan penyimpanan file untuk kolaborasi kami melalui LAN. Juga, proyek-proyek seperti trello menggunakan mongodb sebagai backend datastore mereka. Saya telah menggunakan couchdb sebelumnya, tetapi tidak dalam kapasitas produksi.

Kami menggunakan MongoDB dalam produksi di layanan backend seluler kami yaitu Netmera. Kami menggunakannya untuk menyimpan semua data pengguna dan konten.

Saya telah menggunakan CouchDB dalam produksi selama hampir 2 tahun sekarang. Tidak ada pekerjaan migrasi karena proyek dimulai langsung dengan implementasi CouchDB. Ini berfungsi sebagai database yang menyimpan data produk elektronik tunggal dari awal hingga pengemasan.

Karena kami menjual sensor dengan permintaan akurasi tinggi, kami melakukan banyak pengujian pada tahap yang berbeda dan semua ini akan disimpan dalam satu dokumen di CouchDB.

Ada beberapa kurva belajar yang saya pelajari dari pengalaman saya, yaitu memanfaatkan sepenuhnya pandangan (atau juga dikenal sebagai pandangan permanen). Tampilan harus menjadi "filter kecil" dari sebagian kecil dari Database yang akan sering dipanggil.

Databse CouchDB saya tidak segila perusahaan raksasa lainnya. Tapi sejauh ini, saya masih baik-baik saja. Saat ini saya memiliki 24.000 dokumen pada 700MB.

Fitur dari CouchDB yang saya suka adalah 'replikasi', 'simpan revisi dokumen'.

Saya telah membaca banyak ulasan bagus tentang MongoDB dan saya ingin mencobanya jika ada kesempatan.

Kami menggunakan mongodb untuk produksi

www.beachfront.io - hampir 5k permintaan tulis per detik www.beachfrontbuilder.com - 500 permintaan baca / tulis per detik, pertahankan data pengguna 10 juta & olap.

Satu-satunya tantangan yang dihadapi seputar pengarsipan data, kami atasi dengan menerapkan komponen khusus kami.

Pertanyaan ini telah menerima jawaban tetapi sekarang satu hari lagi NoSQL DB sedang tren untuk banyak fitur-fiturnya yang hebat. Itu adalah Couchbase; yang berjalan seperti CouchbaseLitepada platform seluler dan Couchbase Serverdi sisi server Anda.

Berikut adalah beberapa fitur utama Couchbase Lite.

Couchbase Lite adalah mesin basis data yang ringan, berorientasi pada dokumen (NoSQL), dapat disinkronkan yang cocok untuk ditanamkan ke dalam aplikasi seluler.

Berarti ringan:

Tertanam — mesin basis data adalah pustaka yang ditautkan ke aplikasi, bukan proses server terpisah. Ukuran kode kecil — penting untuk aplikasi seluler, yang sering diunduh melalui jaringan seluler. Waktu startup yang cepat — penting karena perangkat seluler memiliki CPU yang relatif lambat. Penggunaan memori rendah — kumpulan data seluler tipikal relatif kecil, tetapi beberapa dokumen mungkin memiliki lampiran multimedia yang besar. Kinerja yang baik — angka pasti tergantung pada data dan aplikasi Anda, tentu saja.

Berorientasi pada dokumen berarti:

Menyimpan catatan dalam format JSON yang fleksibel alih-alih membutuhkan skema atau normalisasi yang telah ditentukan sebelumnya. Dokumen dapat memiliki lampiran biner berukuran sewenang-wenang, seperti konten multimedia. Format data aplikasi dapat berkembang seiring waktu tanpa memerlukan migrasi eksplisit. Pengindeksan MapReduce menyediakan pencarian cepat tanpa perlu menggunakan bahasa permintaan khusus.

Dapat disinkronkan berarti:

Dua salinan basis data dapat disinkronkan melalui algoritma replikasi yang efisien, andal, terbukti. Sinkronisasi dapat berdasarkan permintaan atau berkelanjutan (dengan latensi beberapa detik). Perangkat dapat disinkronkan dengan subset dari database besar di server jauh. Mesin sinkronisasi mendukung koneksi jaringan yang terputus-putus dan tidak dapat diandalkan. Konflik dapat dideteksi dan diselesaikan, dengan logika aplikasi dalam kontrol penuh penggabungan. Pohon revisi memungkinkan topologi replikasi yang kompleks, termasuk server-ke-server (untuk beberapa pusat data) dan peer-to-peer, tanpa kehilangan data atau konflik salah. Couchbase Lite menyediakan API asli untuk pengembangan iOS (Objective-C) dan Android (Java) yang mulus. Selain itu, ini termasuk Couchbase Lite Plug-in untuk PhoneGap,

Anda dapat menjelajahi lebih lanjut di Couchbase Lite

dan Server Couchbase

Ini akan menjadi hal besar berikutnya.

Berbicara produksi, failover / recovery mulus keduanya memerlukan baby sitter
1- Couchbase, tidak ada failover / recovery mulus, diperlukan intervensi manual.
penyeimbangan ulang membutuhkan terlalu banyak waktu, terlalu banyak risiko jika lebih dari satu simpul hilang.

2 - Mongo dengan pecahan, pemulihan data dari kehilangan server konfigurasi, bukanlah tugas yang mudah

Adobe menggunakan MongoDB untuk perilisan Adobe Experience Manager mereka yang akan datang (sebelumnya Day CQ ) sebagai mesin DB inti.

Beberapa klien di agensi tempat saya bekerja menggunakan CouchDB pada proyek untuk klien besar.

Keduanya adalah DB yang bagus dan layak, menurut saya. :)

Berikut daftar situs yang dikerahkan produksi dengan mongoDB

• The New Yorks Times : Menggunakannya dalam aplikasi pembuatan formulir untuk pengiriman foto. Kurangnya skema Mongo memberi produsen kemampuan untuk menentukan kombinasi bidang formulir kustom apa pun.
• SourceForge : digunakan untuk penyimpanan back-end di halaman depan SourceForge, halaman proyek, dan halaman unduhan untuk semua proyek.
• Sedikit
• Etsy
• IGN : mendukung analitik traffic real-time IGN dan API Konten RESTful.
• Justin.tv : mendukung alat analitik internal Justin.tv untuk virality, retensi pengguna, dan statistik penggunaan umum yang tidak dapat disediakan oleh solusi out-of-the-box.
• Posterous
• Intuit
• Foursquare : Basis data Sharded Mongo digunakan untuk sebagian besar data di foursquare.
• Business Insider : Menggunakannya sejak awal 2008. Semua data situs, termasuk posting, komentar, dan bahkan gambar, disimpan di MongoDB.
• Github : digunakan untuk aplikasi pelaporan internal.
• Penguji : memigrasikan situs mereka dari Cold Fusion dan SQL Server ke Drupal 7 dan MongoDB.
• Grooveshark : saat ini menggunakan Mongo untuk mengelola lebih dari satu juta sesi pengguna unik per hari.
• Buzzfeed
• Diskus
• Evite : Digunakan untuk analitik dan pelaporan cepat.
• Squarespace
• Shutterfly : digunakan untuk berbagai persyaratan penyimpanan data yang persisten dalam Shutterfly. MongoDB membantu Shutterfly membangun layanan yang tak tertandingi yang memungkinkan hubungan yang lebih dalam dan lebih pribadi antara pelanggan dan mereka yang paling berarti dalam hidup mereka.
• Kocar-kacir
• Bagikan ini
• Mongohq : menyediakan platform hosting untuk MongoDB dan juga menggunakan MongoDB sebagai back-end untuk layanannya. Halaman pusat hosting kami menyediakan informasi lebih lanjut tentang MongoHQ dan opsi hosting MongoDB lainnya.

dan banyak lagi ...

Diambil dari: http://lineofthought.com/tools/mongodb

Anda dapat memeriksa basis data atau alat lain di sana juga.

MongoDB memiliki beberapa masalah dengan perizinan untuk bisnis, saya tidak yakin dengan detailnya tetapi departemen hukum kami memberi tahu kami tanpa syarat bahwa kami tidak diizinkan menggunakan MongoDB dalam produk kami.