11 Database Open Source Teratas untuk Proyek Anda Selanjutnya

Data adalah segalanya. Dan dengan ekstensi, begitu pula database. Berikut adalah beberapa opsi open source yang fantastis untuk proyek kick-ass Anda berikutnya.


Untuk dunia yang didominasi begitu lama oleh setelan database seperti Oracle dan SQL Server, sekarang tampaknya ada banyak solusi yang tak ada habisnya. Salah satu alasannya adalah inovasi yang didorong oleh Open Source – pengembang yang benar-benar berbakat yang ingin menggaruk gatal dan menciptakan sesuatu yang dapat mereka nikmati..

Bagian lainnya adalah munculnya model bisnis baru, di mana bisnis mempertahankan versi komunitas dari produk mereka untuk mendapatkan perhatian dan daya tarik, sementara juga menyediakan penawaran komersial dan tambahan.

Hasil?

Lebih banyak basis data yang bisa diikuti oleh satu orang. Tidak ada stat resmi tentang ini, tetapi saya cukup yakin kami memiliki lebih dari seratus opsi yang tersedia hari ini jika Anda menggabungkan semuanya mulai dari basis data objek spesifik tumpukan hingga proyek yang tidak terlalu populer dari universitas.

Saya tahu, itu juga menakutkan saya. Terlalu banyak opsi – terlalu banyak dokumentasi untuk dijalani – dan kehidupan yang begitu singkat. ��

Itu sebabnya saya memutuskan untuk menulis artikel ini, menyajikan sepuluh dari database terbaik yang dapat Anda gunakan untuk meningkatkan solusi Anda, apakah membangun untuk diri sendiri atau orang lain.

Tidak ada MySQL

Harap dicatat: daftar ini tidak akan mengandung MySQL, meskipun ini bisa dibilang solusi database Open Source paling populer di luar sana.

Mengapa? Hanya karena MySQL ada di mana-mana – itu yang dipelajari semua orang pertama kali, didukung oleh hampir setiap CMS atau kerangka kerja di luar sana, dan itu sangat, sangat bagus untuk sebagian besar kasus penggunaan. Dengan kata lain, MySQL tidak perlu “ditemukan”. ��

Karena itu, harap perhatikan bahwa yang berikut ini tidak selalu merupakan alternatif untuk MySQL. Dalam beberapa kasus, mereka mungkin, sementara dalam kasus lain mereka adalah solusi yang sama sekali berbeda untuk kebutuhan yang sama sekali berbeda. Jangan khawatir, karena saya juga akan membahas penggunaannya.

Catatan khusus: kompatibilitas

Sebelum kita mulai, saya juga harus menyebutkan bahwa kompatibilitas adalah sesuatu yang perlu Anda ingat. Jika Anda memiliki proyek yang, untuk alasan apa pun, hanya mendukung mesin basis data tertentu, pilihan Anda cukup banyak.

Misalnya, jika Anda menjalankan WordPress, artikel ini tidak berguna bagi Anda. �� Demikian pula, mereka yang menjalankan situs statis di JAMStack tidak akan mendapatkan apa-apa dengan mencari alternatif terlalu serius.

Terserah Anda untuk mengetahui persamaan kompatibilitas. Namun, jika Anda memiliki papan tulis kosong dan arsitekturnya terserah Anda, berikut adalah beberapa rekomendasi yang rapi.

PostgreSQL

Jika Anda berasal dari tanah PHP (WordPress, Magento, Drupal, dll.), Maka PostgreSQL akan terdengar asing bagi Anda. Namun, solusi basis data relasional ini telah ada sejak 1997 dan merupakan pilihan utama di komunitas seperti Ruby, Python, Go, dll.

Bahkan, banyak pengembang akhirnya “lulus” ke PostgreSQL untuk fitur yang ditawarkannya, atau hanya untuk stabilitas. Sulit untuk meyakinkan seseorang dalam penulisan singkat seperti ini, tetapi anggap PostgreSQL sebagai produk yang dirancang secara cermat dan tidak pernah mengecewakan Anda..

Ada banyak klien SQL yang baik yang tersedia untuk terhubung ke database PostgreSQL untuk administrasi dan pengembangan.

Fitur unik

PostgreSQL memiliki beberapa fitur menarik dibandingkan dengan database relasional lainnya (khususnya, MySQL), seperti:

  • Tipe data bawaan untuk Array, Range, UUID, Geolocation, dll.
  • Dukungan asli untuk penyimpanan dokumen (gaya JSON), XML, dan penyimpanan nilai kunci (Hstore)
  • Replikasi sinkron dan asinkron
  • Skrip dalam PL, Perl, Python, dan lainnya
  • Pencarian teks lengkap

Favorit pribadi saya adalah mesin geolokasi (yang menghilangkan rasa sakit ketika bekerja dengan aplikasi berbasis lokasi – coba temukan semua titik terdekat secara manual, dan Anda akan tahu apa yang saya maksud) dan dukungan untuk array (banyak proyek MySQL dibatalkan karena kekurangan array, memilih untuk string yang dipisahkan koma yang terkenal).

Kapan harus menggunakan PostgreSQL

PostgreSQL selalu merupakan pilihan yang lebih baik daripada mesin basis data relasional lainnya. Yaitu, jika Anda memulai proyek baru dan telah digigit oleh MySQL sebelumnya, ini adalah saat yang tepat untuk mempertimbangkan PostgreSQL. Saya punya teman yang menyerah berjuang melawan kegagalan kunci transaksi misterius MySQL dan melanjutkan secara permanen. Jika Anda memutuskan hal yang sama, Anda tidak akan bereaksi berlebihan.

PostgreSQL juga memiliki keunggulan yang jelas jika Anda memerlukan fasilitas NoSQL parsial untuk model data hybrid. Karena dokumen dan penyimpanan nilai kunci didukung secara asli, Anda tidak perlu berburu, menginstal, mempelajari, dan memelihara solusi basis data lainnya.

Ketika tidak menggunakan PostgreSQL

PostgreSQL tidak masuk akal ketika model data Anda tidak berhubungan dan / atau ketika Anda memiliki persyaratan arsitektur yang sangat spesifik. Misalnya, pertimbangkan Analytics, tempat laporan baru terus-menerus dibuat dari data yang ada. Sistem seperti itu sangat berat dan menderita ketika skema yang ketat diterapkan pada mereka. Tentu, PostgreSQL memiliki mesin penyimpanan dokumen, tetapi banyak hal mulai berantakan ketika Anda berurusan dengan kumpulan data besar.

Dengan kata lain, selalu gunakan PostgreSQL, kecuali jika Anda tahu 100% apa yang Anda lakukan! ��

Lihat ini SQL & PostgreSQL untuk kursus Pemula jika tertarik belajar lebih banyak.

MariaDB

MariaDB dibuat sebagai pengganti MySQL, oleh orang yang sama yang mengembangkan MySQL.

Bingung?

Ya, sebenarnya, setelah MySQL diambil alih oleh Oracle pada 2010 (dengan mengakuisisi Sun Microsystems, yang, kebetulan, juga merupakan cara Oracle mengendalikan Jawa), pencipta MySQL memulai proyek sumber terbuka baru bernama MariaDB.

Mengapa semua detail yang membosankan ini penting, Anda bertanya? Itu karena MariaDB dibuat dari basis kode yang sama dengan MySQL (di dunia open source, ini dikenal sebagai “forking” proyek yang ada). Akibatnya, MariaDB disajikan sebagai pengganti “drop-in” untuk MySQL.

Artinya, jika Anda menggunakan MySQL dan ingin bermigrasi ke MariaDB, prosesnya sangat mudah sehingga Anda tidak akan percaya..

Sayangnya, migrasi semacam itu adalah jalan satu arah. Kembali dari MariaDB ke MySQL tidak mungkin, dan jika Anda mencoba menggunakan kekuatan, korupsi database permanen dipastikan!

Fitur unik

Meskipun MariaDB pada dasarnya adalah tiruan dari MySQL, itu tidak sepenuhnya benar. Sejak diperkenalkannya database, perbedaan antara keduanya telah berkembang. Pada saat penulisan, mengadopsi MariaDB perlu menjadi keputusan yang dipikirkan dengan matang di pihak Anda. Yang mengatakan, ada banyak hal baru yang terjadi di MariaDB yang dapat membantu Anda melakukan transisi ini:

  • Benar-benar gratis dan terbuka: Karena tidak ada entitas tunggal yang mengendalikan MariaDB, Anda bisa bebas dari perizinan yang tiba-tiba dan kekhawatiran lainnya.
  • Beberapa lebih banyak pilihan mesin penyimpanan untuk kebutuhan khusus: misalnya, mesin Spider untuk transaksi yang didistribusikan; ColumnStore untuk pergudangan data besar-besaran; mesin ColumnStore untuk penyimpanan paralel dan terdistribusi; dan masih banyak lagi.
  • Peningkatan kecepatan atas MySQL, terutama karena mesin penyimpanan Aria untuk kueri yang kompleks.
  • Kolom dinamis untuk baris berbeda dalam sebuah tabel.
  • Kemampuan replikasi yang lebih baik (misalnya, replikasi multi-sumber)
  • Beberapa fungsi JSON
  • Kolom virtual

. . . Dan masih banyak lagi. Melelahkan untuk mengikuti semua fitur MariaDB. ��

Kapan harus menggunakan MariaDB

Anda harus MariaDB jika Anda ingin pengganti MySQL yang benar, ingin tetap pada kurva inovasi, dan jangan berencana untuk kembali ke MySQL lagi. Satu kasus penggunaan yang sangat baik adalah penggunaan mesin penyimpanan baru di MariaDB untuk melengkapi model data relasional yang ada dari proyek Anda.

Kapan tidak menggunakan MariaDB

Kompatibilitas dengan MySQL adalah satu-satunya perhatian di sini. Yang mengatakan, itu menjadi kurang masalah karena proyek-proyek seperti WordPress, Joomla, Magento, dll., Sudah mulai mendukung MariaDB. Saran saya adalah jangan menggunakan MariaDB untuk menipu CMS yang tidak mendukungnya, karena ada banyak trik khusus basis data yang akan membuat sistem crash dengan mudah.

CockroachDB

Tim di belakang CockroachDB tampaknya terdiri dari masokis. Dengan nama produk seperti itu, tentunya mereka ingin membalikkan semua peluang melawan mereka dan tetap menang?

Ya tidak cukup.

Gagasan di balik “kecoa” adalah bahwa ia adalah serangga yang dibuat untuk bertahan hidup. Tidak peduli apa yang terjadi – predator, banjir, kegelapan abadi, makanan busuk, pemboman, kecoak menemukan cara untuk bertahan hidup dan berkembang biak.

Idenya adalah bahwa tim di belakang CockroachDB (terdiri dari mantan insinyur Google) frustrasi dengan keterbatasan solusi SQL tradisional ketika datang ke skala besar. Itu karena secara historis solusi SQL seharusnya di-host pada satu mesin (data tidak sebesar itu). Untuk waktu yang lama, tidak ada cara untuk membangun sekelompok database yang menjalankan SQL, itulah sebabnya MongoDB menarik begitu banyak perhatian.

Bahkan ketika replikasi dan pengelompokan keluar di MySQL, PostgreSQL, dan MariaDB, itu paling menyakitkan. CoackroachDB ingin mengubahnya, menghadirkan sharding yang mudah, clustering, dan ketersediaan tinggi ke dunia SQL.

Kapan harus menggunakan CockroachDB

CockroachDB adalah impian arsitek sistem menjadi kenyataan. Jika Anda bersumpah dengan SQL dan telah mendidih pada kemampuan penskalaan MongoDB, Anda akan menyukai CockroachDB. Sekarang Anda dapat dengan cepat mengatur cluster, melemparkan pertanyaan padanya, dan tidur nyenyak di malam hari. ��

Ketika tidak menggunakan CockroachDB

Lebih baik iblis yang Anda kenal dari pada yang tidak Anda kenal. Maksud saya, jika RDBMS Anda saat ini bekerja dengan baik untuk Anda dan Anda pikir Anda bisa mengelola rasa sakit yang ditimbulkannya, tetaplah menggunakannya. Untuk semua genius yang terlibat, CockroachDB adalah produk baru, dan Anda tidak ingin berjuang melawannya nanti. Alasan utama lainnya adalah kompatibilitas SQL – jika Anda melakukan hal-hal SQL yang eksotis dan mengandalkannya untuk hal-hal penting, CockroachDB akan menghadirkan terlalu banyak kasus tepi sesuai keinginan Anda.

Mulai sekarang, kami akan mempertimbangkan solusi basis data non-SQL (atau NoSQL, demikian sebutannya) untuk kebutuhan yang sangat terspesialisasi..

Neo4j

Salah satu perkembangan paling signifikan dalam dekade terakhir adalah data yang terhubung. Dunia di sekitar kita tidak dipartisi menjadi tabel dan baris dan kotak – ini adalah satu kekacauan besar dengan segala sesuatu yang terhubung ke hampir semua hal lain.

Jejaring sosial adalah contoh utama, dan membangun model data serupa menggunakan SQL atau bahkan basis data berbasis dokumen adalah mimpi buruk.

Itu karena struktur data yang ideal untuk solusi ini adalah grafik, yang merupakan binatang yang sama sekali berbeda. Dan untuk itu, Anda memerlukan basis data grafik seperti Neo4j.

Contoh di atas diambil langsung dari situs web Neo4j dan menunjukkan bagaimana mahasiswa terhubung ke departemen dan program studi mereka. Model data seperti itu jelas mustahil dilakukan dengan SQL, karena akan sulit untuk menghindari loop tak terbatas dan overruns memori.

Fitur unik

Database grafik unik dalam dirinya sendiri, dan Neo4j adalah satu-satunya pilihan untuk bekerja dengan grafik. Akibatnya, fitur apa pun yang dimilikinya unik. ��

  • Dukungan untuk aplikasi transaksional dan analitik grafik.
  • Kemampuan transformasi data untuk mencerna data tabel skala besar ke dalam grafik.
  • Bahasa permintaan khusus (Cypher) untuk menanyakan basis data grafik
  • Fitur visualisasi dan penemuan

Ini adalah poin penting untuk mendiskusikan kapan harus menggunakan Neo4j, dan kapan tidak. Jika Anda membutuhkan hubungan berbasis grafik antara data Anda, Anda perlu Neo4j. ��

MongoDB

MongoDB adalah basis data non-relasional pertama yang membuat gelombang besar di industri teknologi dan terus mendominasi perhatian yang adil.

Tidak seperti database relasional, MongoDB adalah “database dokumen,” yang berarti menyimpan data dalam potongan, dengan data terkait digumpal bersama dalam potongan yang sama. Ini paling baik dipahami dengan membayangkan kumpulan struktur JSON seperti ini:

Di sini, tidak seperti struktur berbasis tabel, detail kontak dan tingkat akses pengguna berada di dalam objek yang sama. Mengambil objek pengguna mengambil data yang terkait secara otomatis, dan tidak ada konsep bergabung. Inilah pengantar yang lebih rinci untuk MongoDB.

Fitur unik

MongoDB memiliki beberapa fitur serius (saya hampir ingin menulis “kick-ass” untuk menyampaikan dampaknya, tetapi mungkin tidak tepat di situs web publik, mungkin) fitur yang telah membuat beberapa arsitek berpengalaman meninggalkan tanah relasional selamanya:

  • Skema fleksibel untuk kasus penggunaan khusus / tidak terduga.
  • Sharding dan clustering yang sangat sederhana. Anda hanya perlu mengatur konfigurasi untuk sebuah cluster dan melupakannya.
  • Menambahkan atau menghapus node dari sebuah cluster adalah drop-dead sederhana.
  • Kunci transaksional terdistribusi. Fitur ini tidak ada dalam versi sebelumnya tetapi akhirnya diperkenalkan.
  • Ini dioptimalkan untuk penulisan yang sangat cepat, sehingga sangat cocok untuk data analitik sebagai sistem caching.

Jika saya terdengar seperti juru bicara MongoDB, saya minta maaf, tetapi sulit untuk menjual kelebihan MongoDB. Tentu saja, pemodelan data NoSQL aneh pada awalnya, dan beberapa tidak pernah menguasainya, tetapi bagi banyak arsitek, hampir selalu menang atas skema berbasis tabel.

Kapan harus menggunakan MongoDB

MongoDB adalah jembatan crossover yang bagus dari dunia SQL yang terstruktur dan ketat ke Amorf, hampir membingungkan salah satu dari NoSQL. Ia unggul dalam mengembangkan prototipe, karena tidak ada skema yang perlu dikhawatirkan, dan ketika Anda benar-benar perlu meningkatkan skala. Ya, Anda bisa menggunakan layanan cloud SQL untuk menyingkirkan masalah penskalaan DB, tapi itu mahal!

Akhirnya, ada kasus penggunaan di mana solusi berbasis SQL tidak akan dilakukan. Misalnya, jika Anda membuat produk seperti Canva, tempat pengguna dapat membuat desain yang rumit dan dapat mengeditnya nanti, semoga sukses dengan basis data relasional!

Kapan tidak menggunakan MongoDB

Kurangnya skema yang disediakan MongoDB dapat berfungsi sebagai lubang tar bagi mereka yang tidak tahu apa yang mereka lakukan. Ketidakcocokan data, data mati, bidang kosong yang tidak boleh kosong – semua ini dan banyak lagi yang mungkin dilakukan. MongoDB pada dasarnya adalah penyimpanan data “bodoh”, dan jika Anda memilihnya, kode aplikasi harus mengambil banyak tanggung jawab untuk menjaga integritas data.

Jika Anda seorang pengembang, maka Anda akan menemukannya ini berguna.

RethinkDB

Seperti namanya, RethinkDB “Memikirkan kembali” ide dan kemampuan database ketika datang ke aplikasi real-time.

Ketika database diperbarui, tidak ada cara bagi aplikasi untuk mengetahuinya. Pendekatan yang diterima adalah agar aplikasi melepaskan pemberitahuan segera setelah ada pembaruan, yang didorong ke front-end melalui jembatan kompleks (PHP) -> Redis -> Node -> Socket.io adalah salah satu contoh).

Tetapi bagaimana jika pembaruan bisa didorong langsung dari database ke front-end?!

Ya, itulah janji RethinkDB. Jadi jika Anda ingin membuat aplikasi real-time yang benar (game, pasar, analitik, dll.), Rethink DB layak untuk dilihat.

Redis

Ketika datang ke database, hampir terlalu mudah untuk mengabaikan keberadaan Redis. Itu karena Redis adalah basis data dalam memori dan sebagian besar digunakan dalam fungsi pendukung seperti caching.

Mempelajari basis data ini adalah pekerjaan sepuluh menit (secara harfiah!), dan ini adalah toko nilai kunci sederhana yang menyimpan string dengan waktu kedaluwarsa (yang dapat diatur hingga tak terbatas, tentu saja). Apa yang Redis kehilangan dalam fitur yang dibuatnya untuk utilitas dan kinerja. Karena sepenuhnya hidup dalam RAM, membaca dan menulis sangat cepat (beberapa ratus ribu operasi per detik tidak pernah terdengar).

Redis juga memiliki yang canggih sistem pub-sub, yang membuat “database” ini dua kali lebih menarik.

Dengan kata lain, jika Anda memiliki proyek yang dapat mengambil manfaat dari caching atau memiliki beberapa komponen yang didistribusikan, Redis adalah pilihan pertama.

SQLite

Ya, saya berjanji bahwa kami selesai dengan basis data relasional, tetapi SQLite terlalu lucu untuk diabaikan.

SQLite adalah pustaka C ringan yang menyediakan mesin penyimpanan basis data relasional. Segala sesuatu dalam database ini hidup dalam satu file (dengan ekstensi .sqlite) yang dapat Anda tempatkan di sistem file Anda. Dan hanya itu yang Anda butuhkan untuk menggunakannya! Ya, tidak ada perangkat lunak “server” untuk diinstal, dan tidak ada layanan untuk terhubung.

Fitur yang berguna

Meskipun SQLite adalah alternatif yang ringan untuk database seperti MySQL, itu paket cukup pukulan. Beberapa fitur mengejutkannya adalah:

  • Dukungan penuh untuk transaksi, dengan COMMIT, ROLLBACK, dan BEGIN.
  • Dukungan untuk 32.000 kolom per tabel
  • Dukungan JSON
  • Dukungan JOIN 64 arah
  • Subkueri, pencarian teks lengkap, dll.
  • Ukuran basis data maksimum 140 terabyte!
  • Ukuran baris maksimum 1 gigabyte!
  • 35% lebih cepat dari file I / O

Kapan harus menggunakan SQLite

SQLite adalah basis data yang sangat khusus yang berfokus pada pendekatan yang dilakukan tanpa basa-basi. Jika aplikasi Anda relatif sederhana dan Anda tidak ingin kerumitan dari database lengkap, SQLite adalah kandidat yang serius. Masuk akal khususnya untuk aplikasi demo dan CMS ukuran kecil hingga menengah.

Ketika tidak menggunakan SQLite

Meskipun mengesankan, SQLite tidak mencakup semua fitur SQL standar atau mesin basis data favorit Anda. Klaster, prosedur tersimpan, dan ekstensi skrip tidak ada. Juga, tidak ada klien untuk terhubung, meminta dan menjelajahi database. Akhirnya, ketika ukuran aplikasi bertambah, kinerja akan menurun.

Cassandra

Sementara banyak yang menyatakan bahwa akhir zaman sudah dekat bagi Jawa, sesekali masyarakat menjatuhkan bom dan membungkam para kritikus.. Cassandra adalah salah satu contohnya.

Cassandra termasuk dalam keluarga basis data “columnar”. Abstraksi penyimpanan di Cassandra adalah sebuah kolom, bukan satu baris. Idenya di sini adalah untuk menyimpan semua data dalam satu kolom secara fisik pada disk, meminimalkan waktu pencarian.

Fitur unik

Cassandra dirancang dengan menggunakan use case tertentu dalam pikirannya – berurusan dengan banyak beban tulis dan tidak ada toleransi untuk downtime. Ini menjadi nilai jual yang unik.

  • Performa menulis yang sangat cepat. Cassandra adalah basis data tercepat di luar sana ketika menangani banyak beban penulisan.
  • Skalabilitas linier. Artinya, Anda dapat terus menambahkan sebanyak mungkin node ke sebuah cluster seperti yang Anda inginkan, dan akan ada peningkatan nol dalam kompleksitas atau kerapuhan cluster.
  • Toleransi partisi yang tak tertandingi. Artinya, bahkan jika beberapa node dalam cluster Cassandra turun, database dirancang untuk tetap berkinerja tanpa kehilangan integritas.
  • Pengetikan statis

Kapan harus menggunakan Cassandra

Logging dan analitik adalah dua kasus penggunaan terbaik untuk Cassandra. Tapi bukan itu saja – titik baiknya adalah ketika Anda perlu menangani data berukuran sangat besar (Apple memiliki penyebaran Cassandra yang menangani 400+ petabyte data sementara di Netflix menangani 1 triliun permintaan sehari) dengan benar-benar nol downtime. Ketersediaan tinggi adalah salah satu keunggulan Cassandra.

Saat tidak menggunakan Cassandra

Skema penyimpanan kolom Cassandra juga memiliki kekurangan. Model data agak datar, dan jika Anda membutuhkan agregasi, maka Cassandra gagal. Selain itu, ini mencapai ketersediaan tinggi dengan mengorbankan konsistensi (ingat teorema CAP untuk sistem terdistribusi), yang membuatnya kurang cocok untuk sistem di mana akurasi membaca yang tinggi diperlukan.

Skala waktu

Perkembangan baru menuntut jenis database baru, dan Internet of Things (IoT) adalah salah satu fenomena tersebut. Salah satu database open source terbaik untuk itu adalah Skala waktu.

Skala waktu adalah jenis apa yang disebut basis data “seri waktu”. Ini berbeda dari database tradisional pada waktu itu adalah poros utama yang menjadi perhatian, dan analitik dan visualisasi set data besar adalah prioritas utama. Database time series jarang melihat perubahan dalam data yang ada; contohnya adalah pembacaan suhu yang dikirim oleh sensor di rumah kaca – data baru terus terakumulasi setiap detik, yang menarik untuk analisis dan pelaporan.

Mengapa tidak hanya menggunakan database tradisional dengan bidang stempel waktu? Nah, ada dua alasan utama untuk itu:

  • Basis data tujuan umum tidak dioptimalkan untuk bekerja dengan data berbasis waktu. Untuk jumlah data yang sama, basis data keperluan umum akan jauh lebih lambat.
  • Basis data perlu menangani sejumlah besar data karena data baru terus mengalir dan menghapus data atau mengubah skema; nanti, bukan pilihan.

Fitur unik

Timescale DB memiliki beberapa fitur menarik yang membedakannya dari database lain dalam kategori yang sama:

  • Itu dibangun di atas PostgreSQL, bisa dibilang database relasional open source terbaik di luar sana. Jika proyek Anda sudah menjalankan PostgreSQL, Timescale akan meluncur masuk.
  • Querying dilakukan melalui sintaks SQL yang sudah dikenal, mengurangi kurva belajar.
  • Kecepatan menulis yang sangat cepat – jutaan sisipan per detik tidak pernah terdengar sebelumnya.
  • Miliaran baris atau petabyte data – ini bukan masalah besar bagi Timescale.
  • Fleksibilitas sejati dengan skema – pilih dari relasional atau schemaless sesuai kebutuhan Anda.

Tidak masuk akal untuk membicarakan kapan harus menggunakan atau tidak menggunakan Timescale DB. Jika IoT adalah domain Anda, atau Anda mencari karakteristik basis data yang serupa, Timescale patut dicoba.

CouchDB

CouchDB adalah solusi basis data kecil yang rapi yang duduk diam di sudut dan memiliki pengikut yang kecil namun berdedikasi. Itu diciptakan untuk menangani masalah-masalah kehilangan jaringan dan akhirnya penyelesaian data, yang kebetulan menjadi masalah sangat berantakan sehingga pengembang malah akan berganti pekerjaan daripada menghadapinya..

Pada dasarnya, Anda dapat menganggap cluster CouchDB sebagai kumpulan node terdistribusi besar dan kecil, beberapa di antaranya diharapkan offline. Segera setelah sebuah node online, ia mengirimkan data kembali ke cluster, yang secara perlahan dan hati-hati dicerna, akhirnya menjadi tersedia untuk seluruh cluster.

Fitur unik

CouchDB adalah sesuatu dari jenis yang unik ketika datang ke database.

  • Kemampuan sinkronisasi data offline-pertama
  • Versi khusus untuk peramban seluler dan web (PouchDB, CouchDB Lite, dll.)
  • Tahan-tahan, reliabilitas yang teruji pertempuran
  • Pengelompokan mudah dengan penyimpanan data yang berlebihan

Kapan menggunakan CouchDB

CouchDB dibuat untuk toleransi offline dan tetap tidak tertandingi dalam hal ini. Kasus penggunaan yang umum adalah aplikasi seluler tempat sebagian data Anda berada pada instance CouchDB di ponsel pengguna (karena di situlah dihasilkannya). Yang menarik adalah bahwa Anda tidak dapat bergantung pada perangkat pengguna untuk terhubung setiap saat, yang berarti database harus oportunistik dan siap untuk menyelesaikan pembaruan yang saling bertentangan di kemudian hari. Ini dicapai dengan menggunakan yang mengesankan Protokol Replikasi Sofa.

Kapan tidak menggunakan CouchDB

Mencoba menggunakan CouchDB di luar kasus penggunaan yang dimaksudkan akan menyebabkan bencana. Ini menggunakan penyimpanan jauh lebih banyak daripada apa pun di luar sana, hanya karena perlu mempertahankan salinan data yang berlebihan dan hasil resolusi konflik. Akibatnya, kecepatan menulis juga sangat lambat. Akhirnya, CouchDB tidak cocok sebagai mesin skema tujuan umum, karena tidak cocok dengan perubahan skema.

Kesimpulan

Saya harus meninggalkan banyak kandidat menarik seperti Riak, jadi daftar ini harus diambil sebagai panduan daripada perintah. Saya harap saya dapat mencapai tujuan saya dengan artikel ini – menyajikan tidak hanya kumpulan rekomendasi basis data, tetapi juga secara singkat mendiskusikan di mana dan bagaimana mereka harus digunakan (dan dihindari!).

Jika Anda penasaran untuk mempelajari basis data maka periksa Udemy untuk beberapa kursus online yang brilian.

TAGS:

  • Basis data

  • Sumber Terbuka

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map