Yugabyte CTO Menguraikan Jalur PostgreSQL ke Cloud Terdistribusi – Seperti yang lain, Yugabyte adalah perusahaan database yang membangun database terdistribusi berkinerja tinggi untuk mendukung beban kerja cloud yang besar dan terdistribusi secara geografis.
Yugabyte CTO Menguraikan Jalur PostgreSQL ke Cloud Terdistribusi
Baca Juga : PostgreSQL Telah Menjangkau Setiap Bagian Industri dan Setiap Bagian Pemerintahan
pgsql – Namun, Yugabyte tidak memulai dari awal. Inti dari kodenya adalah PostgreSQL, database open source dengan sejarah yang membentang beberapa dekade. Tetapi PostgreSQL awalnya dibuat untuk dijalankan hanya di satu komputer, jadi tim Yugabyte telah membangun kembali keberanian untuk menskalakan.
VentureBeat duduk bersama CTO dan salah satu pendiri Karthik Ranganathan untuk memahami apa yang dipinjam perusahaan dan apa yang dibangun timnya untuk membuat alat tersebut. Ranganathan, yang terlibat erat dalam gelombang pertama aktivitas NoSQL modern sebagai pemimpin teknik di Facebook, menceritakan kisah tersebut.
Wawancara ini telah diedit agar lebih singkat dan jelas.
VentureBeat: Akibatnya, Anda membuat PostgreSQL versi besar yang direplikasi dan di-shard. Mengapa Postgres?
Karthik Ranganathan: Kami melihat bahwa Postgres sebenarnya adalah database yang tumbuh paling cepat. Itu terjadi karena banyak alasan, tetapi saya hanya akan fokus pada tiga alasan. Alasan No. 1 adalah karena sepenuhnya terbuka. Ini sangat transparan tentang peta jalan fitur. Alasan kedua adalah database open source yang benar-benar dapat diambil dan dijalankan oleh perusahaan cloud modern mana pun tanpa harus khawatir harus membayar untuk Oracle atau server Db2 atau SQL. Dan alasan No. 3 itu adalah database open source yang paling kaya fitur. Ini memiliki fitur yang benar-benar dapat menandingi database lain, seperti Oracle, Db2, atau SQL server.
VentureBeat: Jadi bagaimana Yugabyte mulai mengubahnya?
Ranganathan: Memodernisasi aplikasi sebenarnya mudah. Itulah salah satu alasan mengapa kami memilih Postgres. Kami juga sepenuhnya open source. Kami menggunakan kembali bagian atas Postgres sepenuhnya sehingga kami hampir kompatibel dengan Postgres. Seperti dalam arti jika Anda memiliki aplikasi yang berjalan di Postgres, itu hanya berjalan. Tetapi Anda perlu mencari cara untuk membuatnya berjalan dengan baik di substrat terdistribusi. Jadi pesan kami yang coba kami sampaikan adalah bahwa jika orang memilih Postgres untuk menjalankan aplikasi di cloud, kami telah melakukan pekerjaan untuk membuat Postgres berjalan di cloud. Jika Anda berharap untuk mengembangkan aplikasi di cloud, Anda memiliki kebutuhan ketersediaan tinggi atau kebutuhan replikasi yang dibangun ke dalam model data, itu adalah hal-hal yang dapat kami tangani dengan sangat baik.
VentureBeat: Saya ingat, katakanlah 20 hingga 30 tahun yang lalu, Postgres dan MySQL adalah dua pemimpin. Tapi MySQL benar-benar melompat keluar dan menjadi dasar untuk tumpukan LAMP, yang berkembang biak. Kemudian sepertinya dalam beberapa tahun terakhir, Postgres menjadi pusat perhatian dan mulai menghasilkan lebih banyak minat dan lebih banyak kegembiraan. Menurut Anda mengapa demikian?
Ranganathan: Pertama, 30 tahun yang lalu, open source [database tidak] menjadi norma. Jika Anda memberi tahu orang-orang, “Hei, ini database open source,” mereka akan berkata, “Oke? Apa artinya? Apa itu? Apa artinya? Dan kenapa aku harus bersemangat?” Dan seterusnya. Saya ingat karena di Facebook saya adalah bagian dari tim yang membangun database open source bernama Cassandra, dan kami tidak tahu apa yang akan terjadi. Kami berpikir, “Oke, inilah hal yang kami keluarkan di sumber terbuka, dan mari kita lihat apa yang terjadi.” Dan ini pada tahun 2007.
Kembali pada hari itu, penting untuk menggunakan lisensi terbatas — seperti GPL — untuk mendorong orang berkontribusi dan tidak hanya mengambil barang dari sumber terbuka dan tidak pernah memberi kembali. Jadi itulah alasan mengapa banyak proyek berakhir dengan lisensi seperti GPL.
Sekarang, MySQL melakukan pekerjaan yang sangat baik dalam mematuhi beban kerja yang datang di web saat itu. Mereka adalah beban kerja tingkat dua pada awalnya. Ini tidak terlalu kritis, tetapi seiring waktu mereka menjadi sangat kritis, dan komunitas MySQL selaras dengan sangat baik dan itu memberi mereka kecepatan.
Namun seiring berjalannya waktu, seperti yang Anda ketahui, open source telah menjadi kebutuhan pokok. Dan sebagian besar infrastruktur mulai menjadi open source. Semakin terbuka semakin baik, bukan? Dan [lebih sedikit] pembatasan berarti siapa pun dapat mengontrol peta jalan, siapa pun dapat berkontribusi untuk itu. Jika ada perusahaan besar yang menginginkan perbaikan dan tidak ada yang punya waktu untuk melakukannya, mereka dapat berinvestasi dalam membangun tim di sekitarnya. Semua ini menjadi lebih mudah dengan komunitas yang sangat transparan dan terbuka.
Postgres benar-benar bersenang-senang karena itu, tetapi juga karena Postgres memiliki serangkaian fitur yang sangat kuat . Ketika Anda membandingkannya dengan Oracle dan SQL Server dan Db2 dan trigger serta prosedur tersimpan dan indeks parsial — itu hanya memiliki banyak fitur kompleks yang terpasang di dalamnya. Itu membuatnya layak bagi orang-orang yang pindah dari database yang ada yang sebagian besar di- prem. Jika Anda ingin menjalankannya di cloud, Anda harus menemukan database setara yang dapat mendukung aplikasi itu. Dan kebetulan itu adalah Postgres. Jika Anda menghubungkan kebangkitan MySQL dengan kebangkitan LAMP stack, Anda dapat menghubungkan kebangkitan PostgreSQL dengan kebangkitan gerakan cloud.
VentureBeat: Anda menyebutkan bahwa di level teratas, level tertinggi, Anda sepenuhnya kompatibel dengan Postgres. Apakah itu berarti mesin penyimpanan di bawahnya telah Anda ganti?
Ranganathan: Sebenarnya lebih dari itu. Kami telah mengganti mesin penyimpanan, antara lain, tetapi kami telah membuat database sepenuhnya direplikasi dan sangat tersedia. Jadi sebenarnya tidak ada satu titik kegagalan.
Anda dapat mengabstraksikan bagian atas Postgres itu sendiri ke dalam hal-hal yang menerima kueri yang melakukan pemeriksaan keamanan dan verifikasi yang menghitung cara Anda menjalankan kueri. Dan kemudian, Anda tahu, lanjutkan dan lakukan eksekusi. Kami telah mempertahankan semua itu.
Apa yang kami ubah bukan hanya mesin penyimpanan. Ini juga merupakan mesin replikasi. Data Anda mungkin berada di satu node atau sekelompok node lain, bukan? Jadi node ini tidak hanya perlu memahami bahwa data berada di mesin penyimpanan yang berbeda. Itu juga perlu tahu tentang lokasi potongan data yang berbeda. Bit kedua sekarang adalah data Anda direplikasi, jika Anda gagal, Anda akan ingin beberapa node lain mengambil alih secara instan. Jadi, Anda perlu tahu cara gagal ke simpul yang tepat untuk mengambilnya. Ini hampir merupakan masalah keanggotaan yang dinamis. Dan bit ketiga ada di sekitar katalog sistem. Kami memiliki tempat di mana kumpulan tabel yang Anda buat disimpan. Itu hanya disimpan sebagai sekelompok file di Postgres. Kami benar-benar perlu membuat itu direplikasi dan sangat tersedia juga.
Dan akhirnya, kami mengatasi masalah [terungkap] ketika Anda membuat tabel di mesin No. 1 dan No. 2 harus mengenalinya secara instan. Anda tidak dapat memiliki jeda ini di mana tabel mengatakan itu tidak ada atau Anda memicu kegagalan ALTER TABLE. Kita harus melakukan semua jenis hal ini ketika kita mengganti lapisan bawah.
VentureBeat: Ketika saya melihat banyak literatur Anda, Anda mendorong YugabyteDB sebagai database SQL. Tetapi Anda juga memiliki API NoSQL . Bagaimana cara kerjanya? Apakah NoSQL hanya lapisan yang diterjemahkan ke dalam SQL di bawah ini? Atau mereka mandiri?
Ranganathan: Itu berdampingan. Itu bagian inti lain dari IP bagi kami. Setengah dari tim kami memiliki darah basis data dari Oracle, dan sekelompok tim inti lainnya berasal dari Facebook, tempat kami sebenarnya membangun beberapa basis data NoSQL pertama, termasuk Cassandra. Saya pikir kami “Aha!” saat, setelah membangun kedua sisi, adalah mungkin untuk membangun mesin penyimpanan di mana format datanya seragam. Cara Anda mengakses data tidak bergantung pada format kueri.
Tujuan kami adalah menyederhanakan pembuatan aplikasi cloud-native. Secara alami, kami tidak ingin memihak. Kami tidak ingin mengatakan, “Lihat, kami hanya SQL. Kalian semua NoSQL [orang-orang] melakukannya dengan salah. Anda perlu pindah ke SQL.” Pesan itu tidak pernah berhasil.
Kami mengatakan bahwa melakukan keduanya adalah keuntungan nyata. Ada beberapa hal yang dilakukan NoSQL yang sangat bagus. Jadi kami katakan, untuk membangun database yang sempurna, kami harus menghibridisasi kedua sisi dengan sempurna. Memilih API SQL dan memasukkan semua NoSQLisme di dalamnya akan memakan waktu yang sangat lama. Ini akan menjadi seperti ini selama bertahun-tahun.
Biarkan saya memberi Anda contoh sederhana. Jika pengandar klien SQL — pengandar JDBC — hanya mengetahui satu simpul, dan Anda mengatakan “Hubungkan ke simpul ini,” hanya itu yang dilakukannya. Klien NoSQL adalah klien pintar, di mana setelah Anda terhubung ke satu node, ia akan menemukan semua node lainnya. Ini akan menemukan node yang Anda tambahkan atau Anda hapus. Ia akan menemukan lokasi berbagai simpul ini untuk mengatakan, “Lihat, ini di AS Barat. Itu di US Central. Ini di AS Timur. Saya hanya bisa membaca dari Barat AS.” Anda dapat melakukan segala macam hal yang sangat kuat dengan klien NoSQL.
Sekarang sulit untuk menggabungkan keduanya karena Anda memerlukan perubahan tingkat driver di sisi SQL, yang merupakan fitur inti DB. Sulit bagi perusahaan untuk melakukan ini sambil mengejar ketinggalan. Jadi kami mengatakan kami akan mengikuti pendekatan alternatif, di mana kami memberikan beberapa API di atas database. Kami akan membangun lapisan kueri yang dapat diperluas yang lebih lengkap daripada lapisan kueri Postgres. Tentu saja, yang kami miliki adalah Express, tetapi kami juga mendukung API yang kompatibel dengan Apache Cassandra. Ini adalah API yang sama sekali berbeda, tetapi data disimpan dalam penyimpanan yang sama. Mekanisme replikasinya sama, tetapi pola aksesnya dioptimalkan untuk NoSQL.
VentureBeat: Apakah itu berarti saya bisa melakukan kueri SQL, memilih tabel tertentu, dan itu akan menemukan kolom yang tepat dan melakukan itu dan kemudian saya bisa berbalik dan di meja yang sama saya bisa melakukan kueri seperti Cassandra?
Ranganathan: Tidak di meja yang sama. Anda dapat memiliki tabel SQL yang berada tepat di sebelah tabel NoSQL dan Anda dapat membuat keduanya konsisten secara transaksional. Semua replikasi Anda, enkripsi saat istirahat — semua itu diurus untuk Anda. Tapi tidak di meja yang sama.
Tujuan kami adalah untuk melayani layanan mikro yang membutuhkan skala dan distribusi yang luar biasa atau skala besar tetapi juga integritas relasional yang luar biasa. Kita bisa pergi dua arah. Tetapi kenyataannya adalah bahwa aplikasi Anda akan terlihat murni satu atau yang lain. Baik SQL atau NoSQL.
VentureBeat: Anda berbicara tentang konsistensi transaksional. Bagaimana Anda mempertahankannya di dua gaya tabel yang berbeda? Satu sisi mendapatkan Yugabyte Cloud Query Language (YCQL) gaya Cassandra dan yang lainnya mendapatkan SQL?
Ranganathan: Tabel dapat berupa transaksional multi-baris atau baris tunggal. Anda dapat memilih untuk melakukan transaksi multi-baris atau multi-tabel di sisi NoSQL. Kami menambahkan ke dunia itu — Anda dapat memiliki indeks, dan itu adalah hal baru yang kami bawa ke dunia itu. Tetapi di sisi SQL, semua tabel adalah transaksional default ke tingkat tertinggi. Anda benar-benar tidak dapat memilih keluar dari transaksi dengan SQL.
Kedua tabel ini adalah silo yang memiliki API masing-masing. Tetapi Anda dapat menggunakan API masing-masing ini. Anda dapat menggunakan pembungkus data asing Postgres untuk menghubungkannya. Anda dapat melakukan hal-hal menarik. Misalnya, Anda dapat mendeklarasikan tabel eksternal di sisi Postgres untuk mengatakan “Lihat, itu tabel eksternal yang dapat Anda akses.” Anda dapat melakukan hal-hal seperti itu. Namun selain itu, Anda tidak dapat mengakses data secara silang karena kami ingin membangun breed terbaik — bukan common denominator terendah — di kedua sisi.
VentureBeat: Ada sejumlah ekstensi PostgreSQL, seperti informasi geografis atau alat GIS . Bisakah Anda bekerja dengan mereka?
Ranganathan: Mereka melakukannya. Setidaknya pada lapisan kueri, semua ekstensi berfungsi. Mereka yang mengenai lapisan penyimpanan Postgres tidak akan karena kami mengganti mesin penyimpanan. Jadi informasi geografis berfungsi, tetapi kami masih membangun indeks GIST. Anda dapat membuat kueri, tetapi kueri tidak akan efisien hari ini karena kami tidak memiliki dukungan indeks GIST. Itu lebih dari setengah hal yang lebih rendah, kan? Kita harus mengatur data sesuai dengan tugas GIS tetapi begitu kita melakukannya, itu akan bekerja dengan baik. Tetapi bagian atas sudah berfungsi.
VentureBeat: Apakah menurut Anda orang menggunakan satu sisi API lebih banyak daripada yang lain?
Ranganathan: Postgres sedang terbakar. Itu bahkan tidak dekat. Sisi YCQL [NoSQL side] besar, tetapi banyaknya penggunaan, jumlah aplikasi, dan jumlah orang yang menggunakannya di sisi Postgres sungguh luar biasa. Ini hanya mengejutkan.