Hai semua! Nama saya Golov Nikolay. Sebelum ini, saya bekerja di Avito dan menguruskan Platform Data selama enam tahun, iaitu, saya bekerja pada semua pangkalan data: analitikal (Vertica, ClickHouse), penstriman dan OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Pada masa ini, saya berurusan dengan sejumlah besar pangkalan data - sangat berbeza dan luar biasa, dan dengan kes bukan standard penggunaannya.
Saya sedang bekerja di ManyChat. Pada dasarnya, ini adalah permulaan - baharu, bercita-cita tinggi dan berkembang pesat. Dan apabila saya mula-mula menyertai syarikat itu, satu soalan klasik timbul: "Apakah yang perlu diambil oleh pemula muda sekarang daripada pasaran DBMS dan pangkalan data?"
Dalam artikel ini, berdasarkan laporan saya di , saya akan menjawab soalan ini. Versi video laporan tersedia di .
Pangkalan data yang biasa diketahui 2020
Sudah 2020, saya melihat sekeliling dan melihat tiga jenis pangkalan data.
Jenis pertama - pangkalan data OLTP klasik: PostgreSQL, SQL Server, Oracle, MySQL. Mereka telah lama ditulis, tetapi masih relevan kerana mereka begitu biasa dengan komuniti pembangun.
Jenis kedua ialah asas daripada "sifar". Mereka cuba beralih daripada corak klasik dengan meninggalkan SQL, struktur tradisional dan ACID, dengan menambahkan sharding terbina dalam dan ciri menarik yang lain. Sebagai contoh, ini ialah Cassandra, MongoDB, Redis atau Tarantool. Semua penyelesaian ini ingin menawarkan pasaran sesuatu yang pada asasnya baru dan menduduki niche mereka kerana ia ternyata sangat mudah untuk tugasan tertentu. Saya akan menandakan pangkalan data ini dengan istilah payung NOSQL.
"Sifar" telah berakhir, kami terbiasa dengan pangkalan data NOSQL, dan dunia, dari sudut pandangan saya, mengambil langkah seterusnya - untuk pangkalan data terurus. Pangkalan data ini mempunyai teras yang sama seperti pangkalan data OLTP klasik atau pangkalan data NoSQL baharu. Tetapi mereka tidak memerlukan DBA dan DevOps dan berjalan pada perkakasan terurus di awan. Untuk pembangun, ini adalah "hanya pangkalan" yang berfungsi di suatu tempat, tetapi tiada siapa yang peduli bagaimana ia dipasang pada pelayan, siapa yang mengkonfigurasi pelayan dan siapa yang mengemas kininya.
Contoh pangkalan data sedemikian:
- AWS RDS ialah pembungkus terurus untuk PostgreSQL/MySQL.
- DynamoDB ialah analog AWS bagi pangkalan data berasaskan dokumen, serupa dengan Redis dan MongoDB.
- Amazon Redshift ialah pangkalan data analitik terurus.
Ini pada dasarnya adalah pangkalan data lama, tetapi dibesarkan dalam persekitaran terurus, tanpa perlu bekerja dengan perkakasan.
Catatan. Contoh diambil untuk persekitaran AWS, tetapi analognya juga wujud dalam Microsoft Azure, Google Cloud atau Yandex.Cloud.
Apa yang baru tentang ini? Pada tahun 2020, tiada satu pun daripada ini.
Konsep tanpa pelayan
Apa yang benar-benar baharu di pasaran pada tahun 2020 ialah penyelesaian tanpa pelayan atau tanpa pelayan.
Saya akan cuba menerangkan maksud ini menggunakan contoh perkhidmatan biasa atau aplikasi bahagian belakang.
Untuk menggunakan aplikasi bahagian belakang biasa, kami membeli atau menyewa pelayan, menyalin kod padanya, menerbitkan titik akhir di luar dan kerap membayar sewa, elektrik dan perkhidmatan pusat data. Ini adalah skema standard.
Adakah terdapat cara lain? Dengan perkhidmatan tanpa pelayan anda boleh.
Apakah fokus pendekatan ini: tidak ada pelayan, bahkan tidak menyewa contoh maya dalam awan. Untuk menggunakan perkhidmatan, salin kod (fungsi) ke repositori dan terbitkannya ke titik akhir. Kemudian kami hanya membayar untuk setiap panggilan ke fungsi ini, mengabaikan sepenuhnya perkakasan di mana ia dilaksanakan.
Saya akan cuba menggambarkan pendekatan ini dengan gambar.
Penggunaan klasik. Kami mempunyai perkhidmatan dengan beban tertentu. Kami menimbulkan dua kejadian: pelayan fizikal atau kejadian dalam AWS. Permintaan luaran dihantar ke keadaan ini dan diproses di sana.
Seperti yang anda lihat dalam gambar, pelayan tidak dilupuskan secara sama rata. Satu 100% digunakan, terdapat dua permintaan, dan satu hanya 50% - sebahagiannya melahu. Jika tidak tiga permintaan tiba, tetapi 30, maka keseluruhan sistem tidak akan dapat menampung beban dan akan mula perlahan.
Arahan tanpa pelayan. Dalam persekitaran tanpa pelayan, perkhidmatan sedemikian tidak mempunyai kejadian atau pelayan. Terdapat kumpulan tertentu sumber yang dipanaskan - bekas Docker kecil yang disediakan dengan kod fungsi yang digunakan. Sistem menerima permintaan luaran dan bagi setiap daripada mereka rangka kerja tanpa pelayan menimbulkan bekas kecil dengan kod: ia memproses permintaan khusus ini dan membunuh bekas.
Satu permintaan - satu kontena dinaikkan, 1000 permintaan - 1000 kontena. Dan penggunaan pada pelayan perkakasan sudah pun menjadi kerja penyedia awan. Ia disembunyikan sepenuhnya oleh rangka kerja tanpa pelayan. Dalam konsep ini kami membayar untuk setiap panggilan. Sebagai contoh, satu panggilan datang sehari - kami membayar untuk satu panggilan, sejuta datang seminit - kami membayar untuk satu juta. Atau dalam satu saat, ini juga berlaku.
Konsep penerbitan fungsi tanpa pelayan sesuai untuk perkhidmatan tanpa negara. Dan jika anda memerlukan perkhidmatan statefull (negeri), maka kami menambah pangkalan data pada perkhidmatan tersebut. Dalam kes ini, apabila ia datang untuk bekerja dengan keadaan, setiap fungsi statefull hanya menulis dan membaca daripada pangkalan data. Selain itu, daripada pangkalan data mana-mana daripada tiga jenis yang diterangkan pada permulaan artikel.
Apakah had biasa semua pangkalan data ini? Ini ialah kos pelayan awan atau perkakasan yang sentiasa digunakan (atau beberapa pelayan). Tidak kira sama ada kami menggunakan pangkalan data klasik atau terurus, sama ada kami mempunyai Devops dan pentadbir atau tidak, kami masih membayar sewa perkakasan, elektrik dan pusat data 24/7. Jika kita mempunyai asas klasik, kita membayar untuk tuan dan hamba. Jika ia adalah pangkalan data sharded yang sangat dimuatkan, kami membayar untuk 10, 20 atau 30 pelayan, dan kami membayar secara berterusan.
Kehadiran pelayan yang disimpan secara kekal dalam struktur kos sebelum ini dianggap sebagai kejahatan yang perlu. Pangkalan data konvensional juga mempunyai kesukaran lain, seperti had pada bilangan sambungan, sekatan skala, konsensus teragih geo - entah bagaimana ia boleh diselesaikan dalam pangkalan data tertentu, tetapi tidak sekaligus dan tidak ideal.
Pangkalan data tanpa pelayan - teori
Soalan 2020: adakah mungkin untuk membuat pangkalan data tanpa pelayan juga? Semua orang pernah mendengar tentang bahagian belakang tanpa pelayan... mari cuba jadikan pangkalan data tanpa pelayan?
Ini kedengaran pelik, kerana pangkalan data adalah perkhidmatan statefull, tidak begitu sesuai untuk infrastruktur tanpa pelayan. Pada masa yang sama, keadaan pangkalan data adalah sangat besar: gigabait, terabait, dan dalam pangkalan data analitik walaupun petabait. Tidak begitu mudah untuk menaikkannya dalam bekas Docker yang ringan.
Sebaliknya, hampir semua pangkalan data moden mengandungi sejumlah besar logik dan komponen: transaksi, penyelarasan integriti, prosedur, kebergantungan hubungan dan banyak logik. Untuk logik pangkalan data yang agak banyak, keadaan kecil sudah memadai. Gigabait dan Terabait digunakan secara langsung oleh hanya sebahagian kecil logik pangkalan data yang terlibat dalam melaksanakan pertanyaan secara langsung.
Sehubungan itu, ideanya ialah: jika sebahagian daripada logik membenarkan pelaksanaan tanpa kewarganegaraan, mengapa tidak membahagikan pangkalan kepada bahagian Stateful dan Stateless.
Tanpa pelayan untuk penyelesaian OLAP
Mari lihat bagaimana pemotongan pangkalan data kepada bahagian Stateful dan Stateless mungkin kelihatan seperti menggunakan contoh praktikal.
Sebagai contoh, kami mempunyai pangkalan data analisis: data luaran (silinder merah di sebelah kiri), proses ETL yang memuatkan data ke dalam pangkalan data, dan penganalisis yang menghantar pertanyaan SQL ke pangkalan data. Ini ialah skim operasi gudang data klasik.
Dalam skim ini, ETL dilakukan secara bersyarat sekali. Kemudian anda perlu sentiasa membayar untuk pelayan di mana pangkalan data berjalan dengan data yang diisi dengan ETL, supaya ada sesuatu untuk menghantar pertanyaan.
Mari lihat pendekatan alternatif yang dilaksanakan dalam Tanpa Pelayan AWS Athena. Tiada perkakasan khusus secara kekal untuk menyimpan data yang dimuat turun. Daripada ini:
- Pengguna menyerahkan pertanyaan SQL kepada Athena. Pengoptimum Athena menganalisis pertanyaan SQL dan mencari stor metadata (Metadata) untuk data khusus yang diperlukan untuk melaksanakan pertanyaan.
- Pengoptimum, berdasarkan data yang dikumpul, memuat turun data yang diperlukan daripada sumber luaran ke dalam storan sementara (pangkalan data sementara).
- Pertanyaan SQL daripada pengguna dilaksanakan dalam storan sementara dan hasilnya dikembalikan kepada pengguna.
- Storan sementara dikosongkan dan sumber dikeluarkan.
Dalam seni bina ini, kami hanya membayar untuk proses melaksanakan permintaan. Tiada permintaan - tiada kos.
Ini adalah pendekatan yang berfungsi dan dilaksanakan bukan sahaja dalam Athena Serverless, tetapi juga dalam Redshift Spectrum (dalam AWS).
Contoh Athena menunjukkan bahawa pangkalan data Tanpa Pelayan berfungsi pada pertanyaan sebenar dengan puluhan dan ratusan Terabait data. Beratus-ratus Terabait akan memerlukan ratusan pelayan, tetapi kami tidak perlu membayar untuknya - kami membayar untuk permintaan tersebut. Kelajuan setiap permintaan adalah (sangat) rendah berbanding dengan pangkalan data analisis khusus seperti Vertica, tetapi kami tidak membayar untuk tempoh masa henti.
Pangkalan data sedemikian boleh digunakan untuk pertanyaan ad-hoc analitikal yang jarang berlaku. Sebagai contoh, apabila kita secara spontan memutuskan untuk menguji hipotesis pada sejumlah besar data. Athena sesuai untuk kes ini. Untuk permintaan biasa, sistem sedemikian mahal. Dalam kes ini, cache data dalam beberapa penyelesaian khusus.
Tanpa pelayan untuk penyelesaian OLTP
Contoh sebelumnya melihat tugas OLAP (analitik). Sekarang mari kita lihat tugasan OLTP.
Mari bayangkan PostgreSQL atau MySQL yang boleh berskala. Mari kita tingkatkan contoh terurus biasa PostgreSQL atau MySQL dengan sumber yang minimum. Apabila contoh menerima lebih banyak beban, kami akan menyambungkan replika tambahan yang akan kami agihkan sebahagian daripada beban bacaan. Jika tiada permintaan atau beban, kami matikan replika. Contoh pertama ialah tuan, dan selebihnya adalah replika.
Idea ini dilaksanakan dalam pangkalan data yang dipanggil Aurora Serverless AWS. Prinsipnya mudah: permintaan daripada aplikasi luaran diterima oleh kumpulan proksi. Melihat peningkatan beban, ia memperuntukkan sumber pengkomputeran daripada keadaan minimum pra-panas - sambungan dibuat secepat mungkin. Melumpuhkan kejadian berlaku dengan cara yang sama.
Di dalam Aurora terdapat konsep Unit Kapasiti Aurora, ACU. Ini adalah (bersyarat) contoh (pelayan). Setiap ACU tertentu boleh menjadi tuan atau hamba. Setiap Unit Kapasiti mempunyai RAM sendiri, pemproses dan cakera minimum. Sehubungan itu, seorang adalah tuan, selebihnya dibaca replika sahaja.
Bilangan Unit Kapasiti Aurora ini berjalan ialah parameter boleh dikonfigurasikan. Kuantiti minimum boleh menjadi satu atau sifar (dalam kes ini, pangkalan data tidak berfungsi jika tiada permintaan).
Apabila pangkalan menerima permintaan, kumpulan proksi meningkatkan Aurora CapacityUnits, meningkatkan sumber prestasi sistem. Keupayaan untuk menambah dan mengurangkan sumber membolehkan sistem "menimbang" sumber: secara automatik memaparkan ACU individu (menggantikannya dengan yang baharu) dan melancarkan semua kemas kini semasa kepada sumber yang ditarik balik.
Pangkalan Aurora Tanpa Pelayan boleh menskalakan beban bacaan. Tetapi dokumentasi tidak mengatakan ini secara langsung. Mungkin rasanya mereka boleh mengangkat multi-master. Tiada sihir.
Pangkalan data ini sangat sesuai untuk mengelak daripada membelanjakan sejumlah besar wang pada sistem dengan akses yang tidak dapat diramalkan. Sebagai contoh, apabila membuat MVP atau memasarkan tapak kad perniagaan, kami biasanya tidak menjangkakan beban yang stabil. Sehubungan itu, jika tiada akses, kami tidak membayar untuk contoh. Apabila beban yang tidak dijangka berlaku, contohnya selepas persidangan atau kempen pengiklanan, ramai orang melawat tapak dan beban meningkat secara mendadak, Aurora Serverless secara automatik mengambil beban ini dan menyambungkan sumber yang hilang (ACU) dengan cepat. Kemudian persidangan itu berlalu, semua orang lupa tentang prototaip, pelayan (ACU) menjadi gelap, dan kos turun kepada sifar - mudah.
Penyelesaian ini tidak sesuai untuk beban tinggi yang stabil kerana ia tidak menskalakan beban tulisan. Semua sambungan dan pemotongan sumber ini berlaku pada apa yang dipanggil "titik skala" - titik masa apabila pangkalan data tidak disokong oleh transaksi atau jadual sementara. Sebagai contoh, dalam masa seminggu titik skala mungkin tidak berlaku, dan asas berfungsi pada sumber yang sama dan tidak boleh berkembang atau mengecut.
Tiada keajaiban - ia adalah PostgreSQL biasa. Tetapi proses menambah mesin dan memutuskan sambungannya adalah sebahagiannya automatik.
Tanpa pelayan mengikut reka bentuk
Aurora Serverless ialah pangkalan data lama yang ditulis semula untuk awan untuk memanfaatkan beberapa faedah Tanpa Pelayan. Dan sekarang saya akan memberitahu anda tentang pangkalan, yang pada asalnya ditulis untuk awan, untuk pendekatan tanpa pelayan - Tanpa Pelayan mengikut reka bentuk. Ia segera dibangunkan tanpa andaian bahawa ia akan berjalan pada pelayan fizikal.
Pangkalan ini dipanggil Snowflake. Ia mempunyai tiga blok utama.
Yang pertama ialah blok metadata. Ini ialah perkhidmatan dalam memori pantas yang menyelesaikan isu dengan keselamatan, metadata, urus niaga dan pengoptimuman pertanyaan (ditunjukkan dalam ilustrasi di sebelah kiri).
Blok kedua ialah satu set kelompok pengkomputeran maya untuk pengiraan (dalam ilustrasi terdapat satu set bulatan biru).
Blok ketiga ialah sistem penyimpanan data berasaskan S3. S3 ialah storan objek tanpa dimensi dalam AWS, seperti Dropbox tanpa dimensi untuk perniagaan.
Mari lihat cara Snowflake berfungsi, dengan mengandaikan permulaan yang sejuk. Iaitu, terdapat pangkalan data, data dimuatkan ke dalamnya, tidak ada pertanyaan yang sedang berjalan. Sehubungan itu, jika tiada permintaan kepada pangkalan data, maka kami telah meningkatkan perkhidmatan Metadata dalam memori yang pantas (blok pertama). Dan kami mempunyai storan S3, di mana data jadual disimpan, dibahagikan kepada mikropartisi yang dipanggil. Untuk kesederhanaan: jika jadual mengandungi urus niaga, maka partisi mikro ialah hari transaksi. Setiap hari adalah partition mikro yang berasingan, fail berasingan. Dan apabila pangkalan data beroperasi dalam mod ini, anda hanya membayar untuk ruang yang diduduki oleh data. Selain itu, kadar setiap tempat duduk adalah sangat rendah (terutama dengan mengambil kira pemampatan yang ketara). Perkhidmatan metadata juga berfungsi secara berterusan, tetapi anda tidak memerlukan banyak sumber untuk mengoptimumkan pertanyaan, dan perkhidmatan itu boleh dianggap sebagai perisian kongsi.
Sekarang mari kita bayangkan bahawa pengguna datang ke pangkalan data kami dan menghantar pertanyaan SQL. Pertanyaan SQL dihantar segera ke perkhidmatan Metadata untuk diproses. Sehubungan itu, apabila menerima permintaan, perkhidmatan ini menganalisis permintaan, data yang tersedia, kebenaran pengguna dan, jika semuanya baik, merangka pelan untuk memproses permintaan.
Seterusnya, perkhidmatan memulakan pelancaran kluster pengkomputeran. Kluster pengkomputeran ialah kluster pelayan yang melakukan pengiraan. Iaitu, ini adalah kluster yang boleh mengandungi 1 pelayan, 2 pelayan, 4, 8, 16, 32 - seberapa banyak yang anda mahu. Anda melontarkan permintaan dan pelancaran kluster ini serta-merta bermula. Ia benar-benar mengambil masa beberapa saat.
Seterusnya, selepas kluster dimulakan, mikropartisi yang diperlukan untuk memproses permintaan anda mula disalin ke dalam kluster dari S3. Iaitu, mari bayangkan bahawa untuk melaksanakan pertanyaan SQL anda memerlukan dua partition dari satu jadual dan satu dari yang kedua. Dalam kes ini, hanya tiga partition yang diperlukan akan disalin ke kelompok, dan bukan semua jadual sepenuhnya. Itulah sebabnya, dan tepat kerana semuanya terletak dalam satu pusat data dan disambungkan oleh saluran yang sangat pantas, keseluruhan proses pemindahan berlaku dengan sangat cepat: dalam beberapa saat, sangat jarang dalam beberapa minit, melainkan kita bercakap tentang beberapa permintaan yang besar . Oleh itu, partisi mikro disalin ke kluster pengkomputeran, dan, setelah selesai, pertanyaan SQL dilaksanakan pada kluster pengkomputeran ini. Hasil permintaan ini boleh menjadi satu baris, beberapa baris atau jadual - ia dihantar secara luaran kepada pengguna supaya dia boleh memuat turunnya, memaparkannya dalam alat BInya atau menggunakannya dengan cara lain.
Setiap pertanyaan SQL bukan sahaja boleh membaca agregat daripada data yang dimuatkan sebelum ini, tetapi juga memuatkan/menjana data baharu dalam pangkalan data. Iaitu, ia boleh menjadi pertanyaan yang, sebagai contoh, memasukkan rekod baharu ke dalam jadual lain, yang membawa kepada kemunculan partition baharu pada kelompok pengkomputeran, yang seterusnya, disimpan secara automatik dalam storan S3 tunggal.
Senario yang diterangkan di atas, dari ketibaan pengguna kepada peningkatan kluster, memuatkan data, melaksanakan pertanyaan, mendapatkan keputusan, dibayar pada kadar untuk minit menggunakan kluster pengkomputeran maya yang dinaikkan, gudang maya. Kadarnya berbeza-beza bergantung pada zon AWS dan saiz kelompok, tetapi secara purata ia adalah beberapa dolar sejam. Segugus empat mesin adalah dua kali lebih mahal daripada segugus dua mesin, dan segugus lapan mesin masih dua kali lebih mahal. Pilihan 16, 32 mesin tersedia, bergantung pada kerumitan permintaan. Tetapi anda hanya membayar untuk minit tersebut apabila kluster benar-benar berjalan, kerana apabila tiada permintaan, anda agak melepaskan tangan anda, dan selepas 5-10 minit menunggu (parameter yang boleh dikonfigurasikan) ia akan keluar dengan sendirinya, membebaskan sumber dan menjadi bebas.
Senario yang benar-benar realistik ialah apabila anda menghantar permintaan, kluster itu muncul, secara relatifnya, dalam seminit, ia mengira satu minit lagi, kemudian lima minit untuk ditutup, dan anda akhirnya membayar untuk tujuh minit operasi kluster ini, dan bukan untuk bulan dan tahun.
Senario pertama yang diterangkan menggunakan Snowflake dalam tetapan pengguna tunggal. Sekarang mari kita bayangkan bahawa terdapat ramai pengguna, yang lebih dekat dengan senario sebenar.
Katakan kami mempunyai banyak penganalisis dan laporan Tableau yang sentiasa mengebom pangkalan data kami dengan sejumlah besar pertanyaan SQL analitikal yang mudah.
Di samping itu, katakan bahawa kami mempunyai Saintis Data inventif yang cuba melakukan perkara besar dengan data, beroperasi dengan berpuluh-puluh Terabait, menganalisis berbilion dan trilion baris data.
Untuk dua jenis beban kerja yang diterangkan di atas, Snowflake membolehkan anda menaikkan beberapa kelompok pengkomputeran bebas dengan kapasiti yang berbeza. Selain itu, kluster pengkomputeran ini berfungsi secara bebas, tetapi dengan data konsisten biasa.
Untuk sejumlah besar pertanyaan ringan, anda boleh menaikkan 2-3 kelompok kecil, kira-kira 2 mesin setiap satu. Tingkah laku ini boleh dilaksanakan, antara lain, menggunakan tetapan automatik. Jadi anda berkata, "Kepingan salji, naikkan gugusan kecil. Jika beban padanya meningkat melebihi parameter tertentu, naikkan kedua, ketiga yang serupa. Apabila beban mula berkurangan, padamkan lebihan itu.β Supaya tidak kira berapa ramai penganalisis datang dan mula melihat laporan, semua orang mempunyai sumber yang mencukupi.
Pada masa yang sama, jika penganalisis sedang tidur dan tiada siapa yang melihat laporan, kluster mungkin menjadi gelap sepenuhnya, dan anda berhenti membayarnya.
Pada masa yang sama, untuk pertanyaan berat (daripada Data Scientists), anda boleh menaikkan satu kelompok yang sangat besar untuk 32 mesin. Kelompok ini juga akan dibayar hanya untuk minit dan jam tersebut apabila permintaan gergasi anda dijalankan di sana.
Peluang yang diterangkan di atas membolehkan anda membahagikan bukan sahaja 2, tetapi juga lebih banyak jenis beban kerja ke dalam kelompok (ETL, pemantauan, pewujudan laporan,...).
Mari kita ringkaskan Snowflake. Asas menggabungkan idea yang indah dan pelaksanaan yang boleh dilaksanakan. Di ManyChat, kami menggunakan Snowflake untuk menganalisis semua data yang kami ada. Kami tidak mempunyai tiga kelompok, seperti dalam contoh, tetapi dari 5 hingga 9, dengan saiz yang berbeza. Kami mempunyai 16-mesin konvensional, 2-mesin, dan juga 1-mesin yang sangat kecil untuk beberapa tugas. Mereka berjaya mengagihkan beban dan membolehkan kami menjimatkan banyak.
Pangkalan data berjaya menskalakan beban membaca dan menulis. Ini adalah perbezaan yang besar dan satu kejayaan besar berbanding dengan "Aurora" yang sama, yang hanya membawa beban bacaan. Kepingan salji membolehkan anda menskalakan beban kerja penulisan anda dengan kelompok pengkomputeran ini. Iaitu, seperti yang saya nyatakan, kami menggunakan beberapa kluster dalam ManyChat, kluster kecil dan super-kecil digunakan terutamanya untuk ETL, untuk memuatkan data. Dan penganalisis sudah pun hidup pada kelompok sederhana, yang sama sekali tidak dipengaruhi oleh beban ETL, jadi mereka bekerja dengan sangat cepat.
Sehubungan itu, pangkalan data sangat sesuai untuk tugas OLAP. Walau bagaimanapun, malangnya, ia belum lagi terpakai untuk beban kerja OLTP. Pertama, pangkalan data ini adalah kolumnar, dengan semua akibat yang berikutnya. Kedua, pendekatan itu sendiri, apabila untuk setiap permintaan, jika perlu, anda menaikkan kluster pengkomputeran dan membanjirinya dengan data, malangnya, belum cukup pantas untuk memuatkan OLTP. Menunggu saat untuk tugasan OLAP adalah perkara biasa, tetapi untuk tugasan OLTP ia tidak boleh diterima; 100 ms adalah lebih baik, atau 10 ms adalah lebih baik.
Jumlah
Pangkalan data tanpa pelayan boleh dilakukan dengan membahagikan pangkalan data kepada bahagian Stateless dan Stateful. Anda mungkin perasan bahawa dalam semua contoh di atas, bahagian Stateful, secara relatifnya, menyimpan partition mikro dalam S3, dan Stateless ialah pengoptimum, bekerja dengan metadata, mengendalikan isu keselamatan yang boleh dibangkitkan sebagai perkhidmatan Stateless ringan bebas.
Melaksanakan pertanyaan SQL juga boleh dianggap sebagai perkhidmatan keadaan ringan yang boleh muncul dalam mod tanpa pelayan, seperti kelompok pengkomputeran Snowflake, memuat turun hanya data yang diperlukan, melaksanakan pertanyaan dan "keluar".
Pangkalan data peringkat pengeluaran tanpa pelayan sudah tersedia untuk digunakan, ia berfungsi. Pangkalan data tanpa pelayan ini sudah sedia untuk mengendalikan tugas OLAP. Malangnya, untuk tugas OLTP ia digunakan... dengan nuansa, kerana terdapat batasan. Di satu pihak, ini adalah tolak. Tetapi, sebaliknya, ini adalah peluang. Mungkin salah seorang pembaca akan mencari cara untuk menjadikan pangkalan data OLTP tanpa pelayan sepenuhnya, tanpa had Aurora.
Saya harap anda mendapati ia menarik. Tanpa pelayan adalah masa depan :)
Sumber: www.habr.com