Halo semua! Nama saya Golov Nikolay. Sebelumnya, saya bekerja di Avito dan mengelola Platform Data selama enam tahun, yaitu saya mengerjakan semua database: analitis (Vertica, ClickHouse), streaming dan OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Selama waktu ini, saya berurusan dengan sejumlah besar database - sangat berbeda dan tidak biasa, dan dengan kasus penggunaannya yang tidak standar.
Saat ini saya bekerja di ManyChat. Intinya, ini adalah startup – baru, ambisius, dan berkembang pesat. Dan ketika saya pertama kali bergabung dengan perusahaan ini, sebuah pertanyaan klasik muncul: “Apa yang harus diambil oleh startup muda dari pasar DBMS dan database?”
Pada artikel ini, berdasarkan laporan saya di , saya akan menjawab pertanyaan ini. Versi video dari laporan ini tersedia di .
Database yang umum dikenal tahun 2020
Ini tahun 2020, saya melihat sekeliling dan melihat tiga jenis database.
Tipe pertama - database OLTP klasik: PostgreSQL, SQL Server, Oracle, MySQL. Mereka sudah ditulis sejak lama, namun masih relevan karena begitu akrab dengan komunitas pengembang.
Tipe kedua adalah basis dari "nol". Mereka mencoba untuk menjauh dari pola klasik dengan meninggalkan SQL, struktur tradisional dan ACID, dengan menambahkan sharding bawaan dan fitur menarik lainnya. Misalnya Cassandra, MongoDB, Redis atau Tarantool. Semua solusi ini ingin menawarkan pasar sesuatu yang secara fundamental baru dan menempati ceruk pasar mereka karena ternyata sangat nyaman untuk tugas-tugas tertentu. Saya akan menunjukkan database ini dengan istilah umum NOSQL.
"Nol" sudah berakhir, kami sudah terbiasa dengan database NOSQL, dan dunia, dari sudut pandang saya, mengambil langkah berikutnya - untuk database yang dikelola. Basis data ini memiliki inti yang sama dengan basis data OLTP klasik atau basis data NoSQL baru. Namun mereka tidak memerlukan DBA dan DevOps dan berjalan pada perangkat keras yang dikelola di cloud. Bagi seorang pengembang, ini “hanya sebuah basis” yang berfungsi di suatu tempat, tetapi tidak ada yang peduli bagaimana itu diinstal di server, siapa yang mengkonfigurasi server dan siapa yang memperbaruinya.
Contoh database tersebut:
- AWS RDS adalah wrapper terkelola untuk PostgreSQL/MySQL.
- DynamoDB adalah analog AWS dari database berbasis dokumen, mirip dengan Redis dan MongoDB.
- Amazon Redshift adalah database analitik terkelola.
Ini pada dasarnya adalah database lama, tetapi dibangun di lingkungan terkelola, tanpa perlu bekerja dengan perangkat keras.
Catatan. Contoh diambil untuk lingkungan AWS, namun analognya juga ada di Microsoft Azure, Google Cloud, atau Yandex.Cloud.
Apa yang baru tentang ini? Pada tahun 2020, tidak ada semua ini.
Konsep tanpa server
Yang benar-benar baru di pasaran pada tahun 2020 adalah solusi serverless atau tanpa server.
Saya akan mencoba menjelaskan apa artinya menggunakan contoh layanan reguler atau aplikasi backend.
Untuk menerapkan aplikasi backend biasa, kami membeli atau menyewa server, menyalin kode ke dalamnya, mempublikasikan titik akhir di luar dan secara teratur membayar sewa, listrik, dan layanan pusat data. Ini adalah skema standar.
Apakah ada cara lain? Dengan layanan tanpa server, Anda bisa.
Apa fokus dari pendekatan ini: tidak ada server, bahkan tidak ada penyewaan mesin virtual di cloud. Untuk menyebarkan layanan, salin kode (fungsi) ke repositori dan publikasikan ke titik akhir. Kemudian kita cukup membayar untuk setiap panggilan ke fungsi ini, mengabaikan perangkat keras tempat fungsi tersebut dijalankan.
Saya akan mencoba mengilustrasikan pendekatan ini dengan gambar.
Penerapan klasik. Kami memiliki layanan dengan beban tertentu. Kami memunculkan dua instans: server fisik atau instans di AWS. Permintaan eksternal dikirim ke instance ini dan diproses di sana.
Seperti yang Anda lihat pada gambar, server tidak ditangani secara merata. Satu sudah 100% dimanfaatkan, ada dua permintaan, dan satu lagi hanya 50% - menganggur sebagian. Jika bukan tiga permintaan yang diterima, tetapi 30, maka seluruh sistem tidak akan mampu mengatasi beban dan akan mulai melambat.
Penerapan tanpa server. Dalam lingkungan tanpa server, layanan tersebut tidak memiliki instans atau server. Ada kumpulan sumber daya panas tertentu - wadah Docker kecil yang disiapkan dengan kode fungsi yang diterapkan. Sistem menerima permintaan eksternal dan untuk masing-masing permintaan tersebut, kerangka kerja tanpa server memunculkan wadah kecil berisi kode: sistem memproses permintaan khusus ini dan mematikan wadah tersebut.
Satu permintaan - satu kontainer diangkat, 1000 permintaan - 1000 kontainer. Dan penerapan pada server perangkat keras sudah menjadi pekerjaan penyedia cloud. Itu sepenuhnya tersembunyi oleh kerangka kerja tanpa server. Dalam konsep ini kami membayar untuk setiap panggilan. Misalnya, satu panggilan masuk sehari - kami membayar untuk satu panggilan, satu juta panggilan masuk per menit - kami membayar satu juta. Atau sebentar lagi, ini juga terjadi.
Konsep penerbitan fungsi tanpa server cocok untuk layanan tanpa kewarganegaraan. Dan jika Anda memerlukan layanan statefull (negara bagian), maka kami menambahkan database ke layanan tersebut. Dalam hal ini, ketika bekerja dengan status, setiap fungsi statefull hanya menulis dan membaca dari database. Apalagi dari database salah satu dari tiga jenis yang dijelaskan di awal artikel.
Apa batasan umum dari semua database ini? Ini adalah biaya dari server cloud atau perangkat keras yang terus digunakan (atau beberapa server). Tidak masalah apakah kami menggunakan database klasik atau terkelola, apakah kami memiliki Devops dan admin atau tidak, kami tetap membayar sewa perangkat keras, listrik, dan pusat data 24/7. Jika kita memiliki basis klasik, kita membayar untuk master dan slave. Jika database shardingnya memuat banyak, kami membayar untuk 10, 20, atau 30 server, dan kami membayar terus-menerus.
Kehadiran server yang dicadangkan secara permanen dalam struktur biaya sebelumnya dianggap sebagai kejahatan yang diperlukan. Basis data konvensional juga memiliki kesulitan lain, seperti batasan jumlah koneksi, batasan skala, konsensus yang terdistribusi secara geografis - semuanya dapat diselesaikan dalam basis data tertentu, tetapi tidak sekaligus dan tidak ideal.
Basis data tanpa server - teori
Pertanyaan tahun 2020: apakah mungkin membuat database tanpa server juga? Semua orang pernah mendengar tentang backend tanpa server... mari kita coba membuat database tanpa server?
Ini kedengarannya aneh, karena database merupakan layanan statefull, tidak terlalu cocok untuk infrastruktur tanpa server. Pada saat yang sama, status database sangat besar: gigabyte, terabyte, dan dalam database analitis bahkan petabyte. Tidak mudah untuk mengembangkannya dalam container Docker yang ringan.
Di sisi lain, hampir semua database modern berisi sejumlah besar logika dan komponen: transaksi, koordinasi integritas, prosedur, ketergantungan relasional, dan banyak logika. Untuk logika database yang cukup banyak, keadaan yang kecil sudah cukup. Gigabytes dan Terabytes secara langsung hanya digunakan oleh sebagian kecil dari logika database yang terlibat dalam mengeksekusi query secara langsung.
Oleh karena itu, idenya adalah: jika bagian dari logika memungkinkan eksekusi tanpa kewarganegaraan, mengapa tidak membagi basis menjadi bagian-bagian Stateful dan Stateless.
Tanpa server untuk solusi OLAP
Mari kita lihat seperti apa pemotongan database menjadi bagian Stateful dan Stateless menggunakan contoh praktis.
Misalnya, kami memiliki database analitis: data eksternal (silinder merah di sebelah kiri), proses ETL yang memuat data ke dalam database, dan analis yang mengirimkan kueri SQL ke database. Ini adalah skema operasi gudang data klasik.
Dalam skema ini, ETL dilakukan satu kali secara kondisional. Maka Anda harus terus-menerus membayar server tempat database berjalan dengan data yang diisi dengan ETL, sehingga ada sesuatu untuk mengirim pertanyaan.
Mari kita lihat pendekatan alternatif yang diterapkan di AWS Athena Tanpa Server. Tidak ada perangkat keras khusus permanen tempat data unduhan disimpan. Alih-alih ini:
- Pengguna mengirimkan kueri SQL ke Athena. Pengoptimal Athena menganalisis kueri SQL dan mencari penyimpanan metadata (Metadata) untuk data spesifik yang diperlukan untuk menjalankan kueri.
- Pengoptimal, berdasarkan data yang dikumpulkan, mengunduh data yang diperlukan dari sumber eksternal ke penyimpanan sementara (database sementara).
- Kueri SQL dari pengguna dijalankan di penyimpanan sementara dan hasilnya dikembalikan ke pengguna.
- Penyimpanan sementara dihapus dan sumber daya dilepaskan.
Dalam arsitektur ini, kami hanya membayar proses eksekusi permintaan. Tanpa permintaan - tanpa biaya.
Ini adalah pendekatan yang berhasil dan diterapkan tidak hanya di Athena Tanpa Server, tetapi juga di Redshift Spectrum (di AWS).
Contoh Athena menunjukkan bahwa database Tanpa Server berfungsi pada kueri nyata dengan puluhan dan ratusan Terabyte data. Ratusan Terabyte akan memerlukan ratusan server, namun kami tidak perlu membayarnya - kami membayar permintaannya. Kecepatan setiap permintaan (sangat) rendah dibandingkan dengan database analitis khusus seperti Vertica, namun kami tidak membayar untuk periode waktu henti.
Basis data seperti itu dapat diterapkan untuk kueri analitis ad-hoc yang jarang terjadi. Misalnya, ketika kita secara spontan memutuskan untuk menguji hipotesis pada sejumlah besar data. Athena sangat cocok untuk kasus ini. Untuk permintaan reguler, sistem seperti itu mahal. Dalam hal ini, cache data dalam beberapa solusi khusus.
Tanpa server untuk solusi OLTP
Contoh sebelumnya membahas tugas OLAP (analitis). Sekarang mari kita lihat tugas OLTP.
Mari kita bayangkan PostgreSQL atau MySQL yang scalable. Mari kita tingkatkan PostgreSQL atau MySQL yang dikelola secara reguler dengan sumber daya minimal. Ketika instance menerima lebih banyak beban, kami akan menghubungkan replika tambahan yang mana kami akan mendistribusikan sebagian dari beban baca. Jika tidak ada permintaan atau pemuatan, kami mematikan replikanya. Contoh pertama adalah master, dan sisanya adalah replika.
Ide ini diimplementasikan dalam database bernama Aurora Serverless AWS. Prinsipnya sederhana: permintaan dari aplikasi eksternal diterima oleh armada proxy. Melihat peningkatan beban, ia mengalokasikan sumber daya komputasi dari instance minimal yang telah dihangatkan sebelumnya - koneksi dibuat secepat mungkin. Menonaktifkan instance terjadi dengan cara yang sama.
Di dalam Aurora terdapat konsep Unit Kapasitas Aurora, ACU. Ini (secara kondisional) adalah sebuah instance (server). Setiap ACU tertentu dapat menjadi master atau slave. Setiap Unit Kapasitas memiliki RAM, prosesor, dan disk minimalnya sendiri. Oleh karena itu, satu adalah master, sisanya adalah replika yang hanya dapat dibaca.
Jumlah Unit Kapasitas Aurora yang berjalan adalah parameter yang dapat dikonfigurasi. Jumlah minimum bisa satu atau nol (dalam hal ini, database tidak berfungsi jika tidak ada permintaan).
Saat pangkalan menerima permintaan, armada proksi meningkatkan Aurora CapacityUnits, sehingga meningkatkan sumber daya kinerja sistem. Kemampuan untuk menambah dan mengurangi sumber daya memungkinkan sistem untuk “menyulap” sumber daya: secara otomatis menampilkan ACU individual (menggantinya dengan yang baru) dan meluncurkan semua pembaruan terkini pada sumber daya yang ditarik.
Basis Aurora Tanpa Server dapat menskalakan beban membaca. Namun dokumentasi tidak mengatakan hal ini secara langsung. Rasanya mereka bisa mengangkat multi-master. Tidak ada keajaiban.
Basis data ini sangat cocok untuk menghindari pengeluaran uang dalam jumlah besar pada sistem dengan akses yang tidak dapat diprediksi. Misalnya, saat membuat MVP atau memasarkan situs kartu nama, kita biasanya tidak mengharapkan beban yang stabil. Oleh karena itu, jika tidak ada akses, kami tidak membayar biayanya. Ketika beban tak terduga terjadi, misalnya setelah konferensi atau kampanye periklanan, banyak orang mengunjungi situs dan beban meningkat drastis, Aurora Serverless secara otomatis mengambil beban ini dan dengan cepat menghubungkan sumber daya yang hilang (ACU). Kemudian konferensi berlalu, semua orang lupa tentang prototipe, server (ACU) menjadi gelap, dan biaya turun ke nol - nyaman.
Solusi ini tidak cocok untuk beban tinggi yang stabil karena tidak menskalakan beban penulisan. Semua koneksi dan pemutusan sumber daya ini terjadi pada apa yang disebut “titik skala” – suatu titik waktu ketika database tidak didukung oleh transaksi atau tabel sementara. Misalnya, dalam seminggu titik skala mungkin tidak terjadi, dan pangkalan tersebut bekerja dengan sumber daya yang sama dan tidak dapat diperluas atau dikontrak.
Tidak ada keajaiban - ini PostgreSQL biasa. Namun proses penambahan dan pemutusan mesin sebagian dilakukan secara otomatis.
Tanpa server berdasarkan desain
Aurora Tanpa Server adalah database lama yang ditulis ulang untuk cloud guna memanfaatkan beberapa manfaat Tanpa Server. Dan sekarang saya akan memberi tahu Anda tentang basis, yang awalnya ditulis untuk cloud, untuk pendekatan tanpa server - Desain tanpa server. Itu segera dikembangkan tanpa asumsi akan berjalan di server fisik.
Pangkalan ini disebut Kepingan Salju. Ini memiliki tiga blok kunci.
Yang pertama adalah blok metadata. Ini adalah layanan dalam memori cepat yang memecahkan masalah keamanan, metadata, transaksi, dan pengoptimalan kueri (ditunjukkan pada ilustrasi di sebelah kiri).
Blok kedua adalah sekumpulan cluster komputasi virtual untuk perhitungan (dalam ilustrasi terdapat sekumpulan lingkaran biru).
Blok ketiga adalah sistem penyimpanan data berbasis S3. S3 adalah penyimpanan objek tanpa dimensi di AWS, seperti Dropbox untuk bisnis tanpa dimensi.
Mari kita lihat cara kerja Snowflake, dengan asumsi awal yang dingin. Artinya, ada database, data dimuat ke dalamnya, tidak ada query yang berjalan. Oleh karena itu, jika tidak ada permintaan ke database, maka kami telah meningkatkan layanan Metadata dalam memori yang cepat (blok pertama). Dan kami memiliki penyimpanan S3, tempat data tabel disimpan, dibagi menjadi apa yang disebut mikropartisi. Untuk mempermudah: jika tabel berisi transaksi, maka partisi mikro adalah hari terjadinya transaksi. Setiap hari adalah mikropartisi terpisah, file terpisah. Dan ketika database beroperasi dalam mode ini, Anda hanya membayar untuk ruang yang ditempati oleh data tersebut. Selain itu, tarif per kursi sangat rendah (terutama mengingat kompresi yang signifikan). Layanan metadata juga berfungsi terus-menerus, tetapi Anda tidak memerlukan banyak sumber daya untuk mengoptimalkan kueri, dan layanan tersebut dapat dianggap sebagai shareware.
Sekarang mari kita bayangkan pengguna datang ke database kita dan mengirimkan query SQL. Kueri SQL segera dikirim ke layanan Metadata untuk diproses. Oleh karena itu, setelah menerima permintaan, layanan ini menganalisis permintaan tersebut, data yang tersedia, izin pengguna dan, jika semuanya baik-baik saja, menyusun rencana untuk memproses permintaan tersebut.
Selanjutnya, layanan memulai peluncuran cluster komputasi. Cluster komputasi adalah sekelompok server yang melakukan perhitungan. Artinya, ini adalah cluster yang dapat berisi 1 server, 2 server, 4, 8, 16, 32 - sebanyak yang Anda mau. Anda mengajukan permintaan dan peluncuran cluster ini segera dimulai. Ini benar-benar membutuhkan beberapa detik.
Selanjutnya, setelah klaster dimulai, mikropartisi yang diperlukan untuk memproses permintaan Anda mulai disalin ke dalam klaster dari S3. Artinya, bayangkan untuk mengeksekusi query SQL Anda memerlukan dua partisi dari satu tabel dan satu dari tabel kedua. Dalam hal ini, hanya tiga partisi yang diperlukan yang akan disalin ke cluster, dan tidak semua tabel seluruhnya. Itulah sebabnya, dan justru karena semuanya terletak dalam satu pusat data dan terhubung melalui saluran yang sangat cepat, seluruh proses transfer terjadi dengan sangat cepat: dalam hitungan detik, sangat jarang dalam hitungan menit, kecuali jika kita berbicara tentang beberapa permintaan yang sangat besar. Oleh karena itu, partisi mikro disalin ke cluster komputasi, dan, setelah selesai, kueri SQL dijalankan pada cluster komputasi ini. Hasil dari permintaan ini bisa berupa satu baris, beberapa baris atau sebuah tabel - semuanya dikirim secara eksternal ke pengguna sehingga dia dapat mendownloadnya, menampilkannya di alat BI-nya, atau menggunakannya dengan cara lain.
Setiap kueri SQL tidak hanya dapat membaca agregat dari data yang dimuat sebelumnya, tetapi juga memuat/menghasilkan data baru dalam database. Artinya, ini bisa berupa kueri yang, misalnya, menyisipkan catatan baru ke tabel lain, yang mengarah pada munculnya partisi baru di kluster komputasi, yang, pada gilirannya, secara otomatis disimpan dalam satu penyimpanan S3.
Skenario yang dijelaskan di atas, mulai dari kedatangan pengguna hingga peningkatan cluster, memuat data, mengeksekusi kueri, memperoleh hasil, dibayar berdasarkan tarif menit penggunaan cluster komputasi virtual yang dimunculkan, gudang virtual. Tarifnya bervariasi tergantung pada zona AWS dan ukuran klaster, namun rata-rata adalah beberapa dolar per jam. Cluster yang terdiri dari empat mesin dua kali lebih mahal dibandingkan cluster yang terdiri dari dua mesin, dan cluster yang terdiri dari delapan mesin masih dua kali lebih mahal. Pilihan 16, 32 mesin tersedia, tergantung kompleksitas permintaan. Tetapi Anda hanya membayar untuk menit-menit ketika cluster benar-benar berjalan, karena ketika tidak ada permintaan, Anda melepaskan tangan Anda, dan setelah 5-10 menit menunggu (parameter yang dapat dikonfigurasi) cluster akan keluar dengan sendirinya, membebaskan sumber daya dan menjadi bebas.
Skenario yang sepenuhnya realistis adalah ketika Anda mengirim permintaan, cluster muncul, secara relatif, dalam satu menit, itu menghitung satu menit lagi, kemudian lima menit untuk mematikan, dan Anda akhirnya membayar tujuh menit pengoperasian cluster ini, dan tidak selama berbulan-bulan dan bertahun-tahun.
Skenario pertama dijelaskan menggunakan Snowflake dalam pengaturan pengguna tunggal. Sekarang mari kita bayangkan ada banyak pengguna, yang mendekati skenario sebenarnya.
Katakanlah kita memiliki banyak analis dan laporan Tableau yang terus-menerus membombardir database kita dengan sejumlah besar query SQL analitis sederhana.
Selain itu, katakanlah kita memiliki Ilmuwan Data yang kreatif yang mencoba melakukan hal-hal mengerikan dengan data, beroperasi dengan puluhan Terabyte, menganalisis miliaran dan triliunan baris data.
Untuk dua jenis beban kerja yang dijelaskan di atas, Snowflake memungkinkan Anda membangun beberapa cluster komputasi independen dengan kapasitas berbeda. Selain itu, cluster komputasi ini bekerja secara independen, tetapi dengan data umum yang konsisten.
Untuk kueri ringan dalam jumlah besar, Anda dapat membuat 2-3 klaster kecil, yang masing-masing terdiri dari 2 mesin. Perilaku ini dapat diterapkan antara lain dengan menggunakan pengaturan otomatis. Jadi Anda berkata, “Kepingan salju, buatlah kelompok kecil. Jika beban di atasnya meningkat melebihi parameter tertentu, naikkan yang kedua, ketiga. Saat beban mulai mereda, padamkan kelebihannya.” Sehingga tidak peduli berapa banyak analis yang datang dan mulai melihat laporan, setiap orang memiliki sumber daya yang cukup.
Pada saat yang sama, jika analis tertidur dan tidak ada yang melihat laporannya, cluster mungkin menjadi gelap sepenuhnya, dan Anda berhenti membayarnya.
Pada saat yang sama, untuk kueri yang berat (dari Data Scientist), Anda dapat meningkatkan satu cluster yang sangat besar untuk 32 mesin. Cluster ini juga akan dibayar hanya untuk menit dan jam ketika permintaan raksasa Anda berjalan di sana.
Peluang yang dijelaskan di atas memungkinkan Anda untuk membagi tidak hanya 2, tetapi juga lebih banyak jenis beban kerja ke dalam kelompok (ETL, pemantauan, materialisasi laporan,...).
Mari kita rangkum Kepingan Salju. Basisnya menggabungkan ide bagus dan implementasi yang bisa diterapkan. Di ManyChat, kami menggunakan Snowflake untuk menganalisis semua data yang kami miliki. Kami tidak memiliki tiga cluster, seperti pada contoh, tetapi dari 5 hingga 9, dengan ukuran berbeda. Kami memiliki 16 mesin konvensional, 2 mesin, dan juga 1 mesin super kecil untuk beberapa tugas. Mereka berhasil mendistribusikan beban dan memungkinkan kami menghemat banyak.
Basis data berhasil menskalakan beban membaca dan menulis. Ini adalah perbedaan besar dan terobosan besar dibandingkan dengan “Aurora” yang sama, yang hanya membawa beban membaca. Snowflake memungkinkan Anda menskalakan beban kerja penulisan Anda dengan kluster komputasi ini. Artinya, seperti yang saya sebutkan, kami menggunakan beberapa cluster di ManyChat, cluster kecil dan super kecil terutama digunakan untuk ETL, untuk memuat data. Dan analis sudah tinggal di cluster menengah, yang sama sekali tidak terpengaruh oleh beban ETL, sehingga mereka bekerja dengan sangat cepat.
Oleh karena itu, database ini sangat cocok untuk tugas OLAP. Namun sayangnya, hal ini belum berlaku untuk beban kerja OLTP. Pertama, database ini berbentuk kolom, dengan segala konsekuensinya. Kedua, pendekatannya sendiri, ketika untuk setiap permintaan, jika perlu, Anda menaikkan cluster komputasi dan membanjirinya dengan data, sayangnya, belum cukup cepat untuk memuat OLTP. Menunggu beberapa detik untuk tugas OLAP adalah normal, namun untuk tugas OLTP hal ini tidak dapat diterima; 100 mdtk akan lebih baik, atau 10 mdtk akan lebih baik lagi.
Total
Database tanpa server dimungkinkan dengan membagi database menjadi bagian Stateless dan Stateful. Anda mungkin telah memperhatikan bahwa dalam semua contoh di atas, bagian Stateful, secara relatif, menyimpan partisi mikro di S3, dan Stateless adalah pengoptimalnya, bekerja dengan metadata, menangani masalah keamanan yang dapat diangkat sebagai layanan Stateless ringan yang independen.
Mengeksekusi kueri SQL juga dapat dianggap sebagai layanan ringan yang dapat muncul dalam mode tanpa server, seperti kluster komputasi Snowflake, hanya mengunduh data yang diperlukan, menjalankan kueri, dan “keluar”.
Basis data tingkat produksi tanpa server sudah tersedia untuk digunakan dan berfungsi. Database tanpa server ini sudah siap menangani tugas OLAP. Sayangnya, untuk tugas OLTP mereka digunakan... dengan nuansa, karena ada keterbatasan. Di satu sisi, ini adalah kerugiannya. Namun di sisi lain, ini adalah sebuah peluang. Mungkin salah satu pembaca akan menemukan cara untuk membuat database OLTP sepenuhnya tanpa server, tanpa batasan Aurora.
Saya harap menurut Anda ini menarik. Tanpa server adalah masa depan :)
Sumber: www.habr.com