Dasar-dasar Pemodelan Data - PostgreSQL vs. Cassandra vs. MongoDB

Pengembang aplikasi biasanya menghabiskan banyak waktu untuk mengevaluasi beberapa basis data operasional untuk menemukan satu basis data yang paling sesuai dengan kebutuhan beban kerja mereka. Kebutuhan ini termasuk pemodelan data yang disederhanakan, jaminan transaksional, kinerja baca / tulis, penskalaan horizontal dan toleransi kesalahan. Secara tradisional, seleksi ini dimulai dengan kategori database SQL vs NoSQL karena setiap kategori menyajikan serangkaian pertukaran yang jelas. Kinerja tinggi dalam hal latensi rendah dan throughput tinggi biasanya diperlakukan sebagai persyaratan yang tidak dapat dikompromikan dan karenanya diharapkan dalam setiap basis data yang dipilih.

Posting ini bertujuan untuk membantu pengembang aplikasi memahami pilihan SQL vs NoSQL dalam konteks kebutuhan pemodelan data suatu aplikasi. Kami menggunakan satu database SQL, yaitu PostgreSQL, dan 2 database NoSQL, yaitu Cassandra dan MongoDB, sebagai contoh untuk menjelaskan dasar-dasar pemodelan data seperti membuat tabel, memasukkan data, melakukan pemindaian, dan menghapus data. Dalam posting lanjutan, kami akan membahas topik-topik lanjutan seperti indeks, transaksi, gabungan, arahan time-to-live (TTL) dan pemodelan data dokumen berbasis JSON.

Bagaimana NoSQL berbeda dari SQL dalam Pemodelan Data?

Database SQL meningkatkan ketangkasan aplikasi melalui jaminan transaksional ACID serta kemampuannya untuk meminta data menggunakan GABUNGAN secara tak terduga di atas model data relasional yang dinormalisasi yang ada.

Dengan arsitektur monolitik / single-node dan penggunaan model replikasi master-slave untuk redundansi, database SQL tradisional kehilangan dua kemampuan penting - skalabilitas penulisan linier (mis., Sharding otomatis di beberapa node) dan kegagalan data secara otomatis / nol kehilangan data. Ini berarti volume data yang dicerna tidak dapat melebihi throughput penulisan maksimal dari satu node. Selain itu, beberapa kehilangan data sementara harus diharapkan pada failover (pada arsitektur penyimpanan apa-apa bersama) mengingat bahwa komit baru-baru ini tidak akan muncul di replika budak belum. Upgrade downtime nol juga sangat sulit dicapai di dunia basis data SQL.

DB NoSQL biasanya didistribusikan di alam di mana data dipartisi atau dibelokkan ke beberapa node. Mereka mengamanatkan denormalisasi yang berarti data yang dimasukkan juga perlu disalin beberapa kali untuk melayani pertanyaan spesifik yang ada dalam pikiran Anda. Tujuan menyeluruh adalah untuk mengekstrak kinerja tinggi dengan secara eksplisit mengurangi jumlah pecahan yang diakses selama waktu baca. Oleh karena itu pernyataan bahwa NoSQL mengharuskan Anda untuk memodelkan kueri Anda sementara SQL mengharuskan Anda untuk memodelkan data Anda.

Fokus NoSQL untuk mencapai kinerja tinggi pada gugus terdistribusi dinyatakan sebagai alasan utama untuk beberapa kompromi pemodelan data yang mencakup hilangnya transaksi ACID, GABUNG, dan indeks sekunder global yang konsisten.

Persepsi umum adalah bahwa meskipun database NoSQL memberikan skalabilitas penulisan linier dan toleransi kesalahan yang tinggi, hilangnya jaminan transaksional membuat mereka tidak layak untuk data penting-misi.

Tabel berikut merinci bagaimana pemodelan data NoSQL berbeda dari SQL.

SQL vs NoSQL - Perbedaan Pemodelan Data Kunci

SQL & NoSQL: Mengapa Anda Membutuhkan Keduanya?

Sebagian besar aplikasi dunia nyata dengan pengalaman pengguna yang menarik seperti Amazon.com, Netflix, Uber, dan Airbnb didukung secara internal oleh campuran kompleks dari beberapa beban kerja. Misalnya. aplikasi e-commerce seperti Amazon.com perlu menyimpan data volume rendah, sangat penting untuk misi seperti pengguna, produk, pesanan, faktur bersama volume tinggi, kurang penting untuk data seperti ulasan produk, pesan helpdesk, aktivitas pengguna, rekomendasi pengguna. Secara alami, aplikasi ini mengandalkan setidaknya satu database SQL bersama setidaknya satu database NoSQL. Dalam penyebaran multi-wilayah dan global, basis data NoSQL juga bertindak sebagai cache terdistribusi secara geografis untuk data yang disimpan dalam sumber kebenaran, database SQL yang berjalan di satu wilayah.

Bagaimana YugaByte DB Menyatukan SQL & NoSQL pada Inti Basis Data Umum?

Dibangun di atas kombinasi unik mesin penyimpanan gabungan terstruktur log, sharding otomatis, replikasi konsensus terdistribusi per-shard, dan transaksi ACID terdistribusi (terinspirasi oleh Google Spanner), YugaByte DB adalah basis data open source pertama di dunia yang keduanya NoSQL (Cassandra & Redis) kompatibel) dan SQL (kompatibel PostgreSQL) pada saat yang sama. Seperti yang ditunjukkan pada tabel di bawah, YCQL, API YA Cassandra DB YugaByte DB, menambahkan gagasan transaksi ACID single-key dan multi-key dan indeks sekunder global ke API NoSQL sehingga mengantarkan pada era NoSQL Transaksional. Selain itu, YSQL, YugaByte DB's PostgreSQL API yang kompatibel, menambahkan gagasan penskalaan linear dan toleransi kesalahan otomatis ke SQL API sehingga memunculkan dunia SQL Terdistribusi. Karena YugaByte DB bersifat transaksional pada intinya, bahkan API NoSQL sekarang dapat digunakan dalam konteks data mission-critical.

YugaByte DB - SQL & NoSQL pada Single Database Core

Seperti yang dijelaskan sebelumnya dalam Memperkenalkan YSQL: A SQL API Terdistribusi Kompatibel PostgreSQL untuk YugaByte DB, pilihan SQL vs NoSQL di YugaByte DB sepenuhnya bergantung pada karakteristik beban kerja mayoritas.

  • Jika beban kerja mayoritas adalah operasi multi-kunci dengan BERGABUNG, maka pilih YSQL dengan pengertian bahwa kunci Anda dapat didistribusikan di beberapa node yang mengarah ke latensi yang lebih tinggi dan / atau throughput yang lebih rendah daripada NoSQL.
  • Jika tidak, pilih salah satu dari kedua API NoSQL dengan pemahaman bahwa Anda akan mendapatkan manfaat kinerja yang lebih tinggi yang dihasilkan dari permintaan yang terutama dilayani dari satu simpul pada satu waktu. YugaByte DB dapat berfungsi sebagai basis data operasional terpadu untuk aplikasi dunia nyata yang kompleks yang biasanya memiliki banyak beban kerja untuk dikelola secara bersamaan.

Lab pemodelan data di bagian selanjutnya didasarkan pada YugaByte DB PostgreSQL dan API yang kompatibel dengan Cassandra sebagai lawan dari database asli. Pendekatan ini menyoroti kesederhanaan berinteraksi dengan dua API yang berbeda (pada dua port yang berbeda) dari cluster database yang sama sebagai lawan dari menggunakan cluster yang sepenuhnya independen dari dua database yang berbeda.

Di bagian berikutnya kita akan membahas laboratorium pemodelan data di tangan untuk mengilustrasikan banyak perbedaan dan beberapa kesamaan antara database yang berbeda.

Lab Pemodelan Data

Instal Basis Data

Mengingat fokus pada pemodelan data (dan bukan pada arsitektur penyebaran yang kompleks), kami akan menginstal basis data dalam wadah Docker pada mesin lokal kami dan kemudian berinteraksi dengan mereka menggunakan masing-masing cangkang baris perintah.

YugaByte DB, database yang kompatibel dengan PostgreSQL & Cassandra

mkdir ~ / yugabyte && cd ~ / yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod + x yb-docker-ctl
buruh pelabuhan menarik yugabytedb / yugabyte
./yb-docker-ctl buat --enable_postgres

MongoDB

docker run --name my-mongo -d mongo: terbaru

Akses menggunakan Command Line Shell

Selanjutnya mari kita terhubung ke database menggunakan shell baris perintah untuk API masing-masing.

PostgreSQL

psql adalah shell baris perintah untuk berinteraksi dengan PostgreSQL. Untuk kemudahan penggunaan, YugaByte DB dikirimkan dengan versi psql di direktori bin-nya.

docker exec -it yb-postgres-n1 / home / yugabyte / postgres / bin / psql -p 5433 -U postgres

Cassandra

cqlsh adalah shell baris perintah untuk berinteraksi dengan Cassandra dan database yang kompatibel melalui CQL (the Cassandra Query Language). Untuk kemudahan penggunaan, YugaByte DB dikirimkan dengan versi cqlsh di direktori bin-nya.

Perhatikan bahwa CQL sangat terinspirasi oleh SQL dengan gagasan serupa tentang tabel, baris, kolom, dan indeks. Namun, sebagai bahasa NoSQL, ia menambahkan serangkaian batasan tertentu yang sebagian besar akan kami tinjau selama seri blog kami.

docker exec -it yb-tserver-n1 / home / yugabyte / bin / cqlsh

MongoDB

mongo adalah shell baris perintah untuk berinteraksi dengan MongoDB. Itu dapat ditemukan di direktori bin dari instalasi MongoDB.

buruh pelabuhan exec -itu my-mongo bash
tempat sampah
mongo

Buat Tabel

Kita sekarang dapat berinteraksi dengan database untuk berbagai operasi menggunakan shell baris perintah. Mari kita mulai dengan membuat tabel yang menyimpan informasi tentang lagu yang diterbitkan oleh artis. Lagu-lagu ini kadang-kadang bagian dari album. Atribut opsional lain dari sebuah lagu adalah tahun dirilis, harga, genre dan peringkat kritik. Kami membutuhkan akun untuk atribut tambahan yang mungkin kami butuhkan di masa mendatang melalui bidang ‘tag’ yang dapat menyimpan data semi-terstruktur sebagai pasangan nilai kunci.

PostgreSQL

BUAT TABEL Musik (
    Artis VARCHAR (20) TIDAK NULL,
    SongTitle VARCHAR (30) NOT NULL,
    AlbumTitle VARCHAR (25),
    Tahun INT,
    Harga FLOAT,
    Genre VARCHAR (10),
    FLOAT CriticRating,
    Tag TEKS,
    KUNCI UTAMA (Artis, SongTitle)
);

Cassandra

Buat tabel di Cassandra sangat mirip dengan PostgreSQL. Satu perbedaan besar adalah kurangnya kendala integritas (seperti BUKAN NULL) yang merupakan tanggung jawab aplikasi dan bukan database di dunia NoSQL. Kunci utama terdiri dari kunci partisi (kolom Artis dalam contoh di bawah) dan seperangkat kolom pengelompokan (kolom SongTitle pada contoh di bawah). Kunci partisi menentukan partisi / beling mana untuk menempatkan baris dan kolom pengelompokan menentukan bagaimana data di dalam beling yang diberikan harus diatur.

BUAT myapp KEYSPACE myapp;
GUNAKAN myapp;
BUAT TABEL Musik (
    Artis TEXT,
    SongTitle TEXT,
    AlbumTitle TEXT,
    Tahun INT,
    Harga FLOAT,
    Genre TEXT,
    FLOAT CriticRating,
    Tag TEKS,
    KUNCI UTAMA (Artis, SongTitle)
);

MongoDB

MongoDB mengatur data dalam Basis Data (setara dengan Cassandra Keyspace) yang memiliki Koleksi (setara dengan Tabel) yang memiliki Dokumen (setara dengan Baris dalam Tabel). Sebagai database "schemaless", definisi skema sebelumnya tidak diperlukan dalam MongoDB. Perintah "use database" yang ditunjukkan di bawah ini membuat database pertama kali dipanggil bersamaan dengan perubahan konteks ke database yang baru dibuat. Bahkan koleksi tidak perlu dibuat secara eksplisit tetapi dibuat secara otomatis hanya dengan memasukkan dokumen pertama ke dalam koleksi baru. Perhatikan bahwa database default MongoDB adalah pengujian sehingga setiap operasi tingkat pengumpulan dilakukan tanpa menentukan basis data akan dilakukan dalam konteks default ini.

gunakan myNewDatabase;

Dapatkan Informasi Tentang Meja

PostgreSQL

Musik
Tabel "public.music"
    Kolom | Ketik | Collation | Tidak dapat dibatalkan | Default
-------------- + ----------------------- + ----------- + ---------- + --------
 artis | karakter bervariasi (20) | | bukan nol |
 songtitle | karakter bervariasi (30) | | bukan nol |
 albumtitle | karakter bervariasi (25) | | |
 tahun | integer | | |
 harga | presisi ganda | | |
 genre | karakter bervariasi (10) | | |
 mengkritik | presisi ganda | | |
 tag | teks | | |
Indeks:
    "music_pkey" KUNCI UTAMA, btree (artis, songtitle)

Cassandra

MUSIK TABEL DESCRIBE;
CREATE TABLE myapp.music (
    teks artis,
    teks judul lagu,
    teks albumtitle,
    tahun int,
    harga mengambang,
    teks bergenre,
    tag teks,
    PRIMARY KEY (artis, songtitle)
) DENGAN CLUSTERING ORDER BY (songtitle ASC)
    AND default_time_to_live = 0
    DAN transaksi = {'diaktifkan': 'salah'};

MongoDB

gunakan myNewDatabase;
tampilkan koleksi;

Masukkan Data ke dalam Tabel

PostgreSQL

INSERT INTO Music
    (Artis, Judul Lagu, Judul Album,
    Tahun, Harga, Genre, Kritik,
    Tag)
NILAI (
    'No One You Know', 'Call Me Today', 'Agak Terkenal',
    2015, 2.14, 'Negara', 7,8,
    '{"Composers": ["Smith", "Jones", "Davis"], "LengthInSeconds": 214}'
);
INSERT INTO Music
    (Artis, Judul Lagu, Judul Album,
    Harga, Genre, KritikRating)
NILAI (
    'No One You Know', 'My Dog Spot', 'Hei Sekarang',
    1.98, 'Negara', 8.4
);
INSERT INTO Music
    (Artis, Judul Lagu, Judul Album,
    Harga, Genre)
NILAI (
    'The Acme Band', 'Look Out, World', 'The Buck Mulai Di Sini',
    0,99, 'Batuan'
);
INSERT INTO Music
    (Artis, Judul Lagu, Judul Album,
    Harga, Genre,
    Tag)
NILAI (
    'The Acme Band', 'Still In Love', 'The Buck Mulai Di Sini',
    2.47, 'Rock',
    '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": {"Seattle": "20150625", "Cleveland": "20150630"}, "rotasi": Berat}'
);

Cassandra

Pernyataan Cassandra INSERT terlihat sangat mirip dengan PostgreSQL pada umumnya. Namun, ada satu perbedaan besar dalam semantik. INSERT sebenarnya adalah operasi yang tidak aktif di Cassandra di mana baris diperbarui dengan nilai terbaru jika baris sudah ada.

Sama dengan pernyataan PostgreSQL INSERT di atas.

MongoDB

Meskipun MongoDB juga merupakan basis data NoSQL mirip dengan Cassandra, operasi sisipannya tidak memiliki perilaku semantik yang sama dengan Cassandra. Insert MongoDB () tidak memiliki kemungkinan peningkatan yang membuatnya mirip dengan PostgreSQL. Perilaku menyisipkan default tanpa spesifik _id akan menyebabkan dokumen baru ditambahkan ke koleksi.

db.music.insert ({
artis: "No One You Know",
   songTitle: "Call Me Today",
    albumTitle: "Agak Terkenal",
    tahun: 2015,
    harga: 2,14,
    genre: "Negara",
    tag: {
Komposer: ["Smith", "Jones", "Davis"],
DurasiInSekon: 214
}
   }
);
db.music.insert ({
    artis: "No One You Know",
    songTitle: "My Dog Spot",
    albumTitle: "Hey Now",
    harga: 1,98,
    genre: "Negara",
    criticRating: 8.4
   }
);
db.music.insert ({
    artis: "The Acme Band",
    songTitle: "Awas, Dunia",
    albumTitle: "The Buck Starts Here",
    harga: 0,99,
    genre: "Rock"
   }
);
db.music.insert ({
    artis: "The Acme Band",
    songTitle: "Still In Love",
    albumTitle: "The Buck Starts Here",
    harga: 2,47,
    genre: "Rock",
    tag: {
        radioStationsPlaying: ["KHCR", "KBQX", "WTNR", "WJJH"],
        tourDates: {
            Seattle: "20150625",
            Cleveland: "20150630"
        },
        rotasi: "Berat"
}
    }
);

Query a Table

Perbedaan yang paling signifikan antara SQL dan NoSQL dalam hal permintaan pemodelan adalah pada penggunaan klausa FROM dan WHERE. SQL memungkinkan klausa FROM untuk menyertakan beberapa tabel dan klausa WHERE memiliki kompleksitas arbitrer (termasuk BERGABUNG lintas tabel). Namun, NoSQL cenderung memberikan batasan keras pada klausa FROM untuk hanya memiliki satu tabel yang ditentukan dan klausa WHERE untuk selalu memiliki kunci primer yang ditentukan. Ini karena fokus kinerja tinggi NoSQL yang kami diskusikan sebelumnya yang bertujuan untuk mengurangi interaksi lintas-tabel dan lintas-kunci. Interaksi tersebut dapat memperkenalkan komunikasi lintas-simpul latensi tinggi ke dalam waktu respons kueri dan karenanya sebaiknya dihindari sama sekali. Misalnya. Cassandra mensyaratkan bahwa kueri dibatasi oleh operator (hanya =, IN, <,>, =>, <= diizinkan) pada kunci partisi kecuali ketika menanyakan indeks sekunder (di mana hanya = operator diizinkan).

PostgreSQL

Berikut ini adalah 3 jenis kueri yang dapat dilayani dengan mudah oleh database SQL.

  • Kembalikan semua lagu oleh artis
  • Kembalikan semua lagu oleh artis, yang cocok dengan bagian pertama dari judul
  • Kembalikan semua lagu oleh artis, dengan kata tertentu di judul tetapi hanya jika harganya kurang dari 1,00
SELECT * FROM Music
WHERE Artist = 'No One You Know';
SELECT * FROM Music
WHERE Artist = 'No One You Know' DAN SongTitle LIKE 'Call%';
SELECT * FROM Music
WHERE Artist = 'No One You Know' DAN SongTitle LIKE '% Today%'
DAN Harga> 1,00;

Cassandra

Dari pertanyaan PostgreSQL yang tercantum di atas, hanya yang pertama yang akan bekerja dengan Cassandra yang tidak dimodifikasi karena operator LIKE tidak diperbolehkan pada kolom pengelompokan seperti SongTitle. Hanya operator = dan IN yang diizinkan dalam kasus ini.

SELECT * FROM Music
WHERE Artist = 'No One You Know';
SELECT * FROM Music
WHERE Artist = 'No One You Know' DAN SongTitle IN ('Call Me Today', 'My Dog Spot')
DAN Harga> 1,00;

MongoDB

Seperti yang ditunjukkan pada contoh sebelumnya, metode utama untuk menanyakan MongoDB adalah metode db.collection.find (). Metode ini dikualifikasikan oleh nama koleksi (musik dalam contoh di bawah) yang akan ditanyakan secara sangat eksplisit sehingga permintaan di seluruh koleksi tidak diizinkan.

db.music.find ({
  artis: "No One You Know"
 }
);
db.music.find ({
  artis: "No One You Know",
  songTitle: / Panggilan /
 }
);

Baca Semua Baris Dari Tabel

Membaca semua baris hanyalah kasus khusus dari pola kueri umum yang kami amati sebelumnya.

PostgreSQL

PILIH *
DARI Musik;

Cassandra

Sama seperti pernyataan SELECT PostgreSQL di atas.

MongoDB

db.music.find ({});

Ubah Data dalam Tabel

PostgreSQL

PostgreSQL menyediakan pernyataan UPDATE untuk memodifikasi data. Itu tidak memungkinkan kemungkinan upert sehingga pernyataan itu akan gagal jika baris sudah tidak ada dalam database.

MEMPERBARUI Musik
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';

Cassandra

Cassandra juga memiliki pernyataan UPDATE yang mirip dengan PostgreSQL. UPDATE juga semantik yang sama dengan pernyataan INSERT.

Sama dengan pernyataan PostgreSQL UPDATE di atas.

MongoDB

Operasi pembaruan MongoDB () dapat memperbarui dokumen yang ada seluruhnya atau hanya dapat memperbarui bidang tertentu. Secara default, ini memperbarui hanya satu dokumen dengan semantik mati mati. Pembaruan multi-dokumen dan perilaku aktif dapat dihidupkan dengan mengatur tanda tambahan pada operasi. Misalnya. contoh di bawah ini memperbarui genre artis tertentu di seluruh lagu artis.

db.music.update (
  {"artis": "The Acme Band"},
  {
    $ set: {
      "genre": "Disco"
    }
  },
  {"multi": true, "upsert": true}
);

Hapus Data dari Tabel

PostgreSQL

HAPUS DARI Musik
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';

Cassandra

Sama seperti pernyataan DELETE PostgreSQL di atas.

MongoDB

MongoDB memiliki dua jenis operasi untuk menangani penghapusan dokumen - deleteOne () / deleteMany () dan hapus (). Keduanya menghapus dokumen tetapi memiliki hasil pengembalian yang berbeda.

db.music.deleteMany ({
        artis: "The Acme Band"
    }
);

Hapus Meja

PostgreSQL

DROP TABLE Music;

Cassandra

Sama seperti pernyataan DROP TABLE PostgreSQL di atas;

MongoDB

db.music.drop ();

Ringkasan

Perdebatan SQL vs NoSQL telah berlangsung lebih dari satu dekade sekarang. Ada 2 aspek dari perdebatan ini: arsitektur inti basis data (monolitik, transaksional SQL vs terdistribusi, NoSQL non-transaksional) dan pendekatan pemodelan data (model data Anda dalam SQL vs modelkan pertanyaan Anda di NoSQL).

Dengan basis data transaksional yang terdistribusi seperti YugaByte DB, bagian inti arsitektur basis data dari perdebatan dapat dikesampingkan dengan mudah. Ketika volume data tumbuh melampaui apa yang dapat dituliskan ke dalam satu node, arsitektur terdistribusi penuh yang memungkinkan skalabilitas penulisan linier dengan sharding / rebalancing otomatis menjadi harus dimiliki. Selain itu, sebagaimana dijelaskan dalam pos ini dari Google Cloud, arsitektur transaksional, sangat konsisten sekarang diterima secara luas untuk memberikan kelincahan pengembang dan operasi yang lebih tinggi daripada arsitektur non-transaksional, akhirnya konsisten.

Datang ke debat pemodelan data, adalah adil untuk mengatakan bahwa pendekatan pemodelan data SQL dan NoSQL sangat penting untuk aplikasi dunia nyata yang kompleks. Pendekatan model-data-Anda Anda memungkinkan pengembang untuk memenuhi kebutuhan bisnis yang berubah dengan lebih mudah, sementara pendekatan model-permintaan-Anda NoSQL memungkinkan pengembang yang sama mengelola volume data yang besar dengan latensi rendah dan throughput tinggi. Inilah tepatnya alasan YugaByte DB mengimplementasikan baik SQL dan NoSQL API pada inti umum alih-alih mempromosikan bahwa satu pendekatan benar-benar lebih baik daripada yang lain. Selain itu, dengan memastikan kompatibilitas kawat dengan bahasa basis data populer termasuk PostgreSQL dan Cassandra, YugaByte DB memastikan bahwa pengembang tidak perlu mempelajari bahasa lain untuk mendapatkan manfaat dari inti basis data terdistribusi sangat konsisten.

Posting ini membantu kami memahami perbedaan dasar-dasar pemodelan data antara PostgreSQL, Cassandra dan MongoDB. Dalam posting berikutnya dalam seri, kita akan masuk ke konsep pemodelan data canggih seperti indeks, transaksi, GABUNG, arahan TTL dan dokumen JSON.

Apa berikutnya?

  • Bandingkan YugaByte DB ke database seperti Amazon DynamoDB, Cassandra, MongoDB dan Azure Cosmos DB.
  • Mulai dengan YugaByte DB di macOS, Linux, Docker dan Kubernetes.
  • Hubungi kami untuk mempelajari lebih lanjut tentang lisensi, penetapan harga atau untuk menjadwalkan tinjauan teknis.

Awalnya diterbitkan di YugaByte Database Blog.