Di artikel kedua kami akan memberi tahu Anda tentang tiga lagi:
Dan artikel ketiga akan membahas kesimpulannya.
Catatan: Ini hanya akan berfokus pada teknologi yang mendasarinya, dan fitur seperti fitur perusahaan sebagian besar akan diabaikan (jika sesuai).
TileD B
TileDB adalah database yang dibangun di sekitar array multidimensi . Ini memungkinkan Anda untuk menyederhanakan pekerjaan dengan tipe data yang tidak cukup cocok dengan sistem manajemen basis data relasional (RDBMS) yang ada, misalnya, larik padat dan jarang , bingkai data . TileDB secara khusus disesuaikan untuk kasus penggunaan seperti genomik dan data geospasial .
Fitur penting
- Backend data yang dapat dialihkan dengan dukungan untuk Amazon S3 , MinIO, dan lainnya.
- Integrasi penyimpanan untuk HDFS , PrestoDB , Apache Spark , Dask, dan lainnya.
- Binding bahasa untuk C / C ++ , Python , R , Java dan Go .
Yang paling saya sukai
Kami menyukai database yang "sangat terspesialisasi", dipertajam untuk kumpulan jenis data dan tugas tertentu. RDBMS tradisional, tentu saja, bagus dalam keserbagunaan relatifnya untuk mencakup berbagai kasus penggunaan (tidak main-main). Namun terkadang ada kasus ekstrim ketika pada tahap terakhir (a) kemampuan sistem "konvensional" tidak cukup, dan (b) tugas tersebut sangat penting untuk bisnis Anda.
Kami mengharapkan sistem serupa lainnya muncul seiring berkembangnya spesialisasi kasus penggunaan database dan munculnya area subjek baru. RDBMS lama yang baik, tentu saja, tidak akan kemana-mana, tetapi saya ingin melihat bagaimana TileDB dan sistem serupa lainnya berevolusi dan memperluas batasan dari apa yang mungkin. Kami berharap akan ada database yang sangat "dapat diretas", non-monolitik yang akan memiliki antarmuka untuk menghubungkan plugin sehingga Anda dapat bekerja dengan tipe data yang sangat spesifik untuk kasus penggunaan tertentu. Tapi lebih dari itu nanti.
Pertanyaan untuk proyek
- ? TileDB , , , ? .
- - ? , «TileDB -». ?
Materialize
Materialize dipasarkan sebagai "database SQL streaming pertama yang sebenarnya", dan mungkin itu tidak berlebihan! Ini pada dasarnya adalah database relasional yang "kompatibel dengan kabel" dengan PostgreSQL , tetapi dengan satu perbedaan penting: ia menawarkan tampilan terwujud yang diperbarui secara real-time.
Ada definisi Materialize tentang " penyimpanan streaming ", yang tampaknya berfungsi untuk itu .
Dalam Postgres standar, misalnya, Anda harus memperbarui tampilan material secara manual:
CREATE MATERIALIZED VIEW my_view (/* ... */);
REFRESH MATERIALIZED VIEW my_view;
/* The underlying tables change */
REFRESH MATERIALIZED VIEW my_view;
/* More stuff happens */
REFRESH MATERIALIZED VIEW my_view;
Ini dapat dilakukan pada frekuensi apa pun, misalnya, menggunakan skrip atau tugas penjadwal. Apa yang belum kami lihat (meskipun kami selalu sangat ingin melihat) adalah database yang secara native mendukung pembaruan tambahan dari tampilan yang terwujud. Ya, memang: Materialize melacak perubahan dalam sumber data tertentu dan memperbarui tampilan bergantung pada perubahan dalam sumber ini.
Bahkan jika Materialize tidak menang atau bertahan di pasar cukup lama, kemampuan yang ditawarkannya harus terus berlanjut dan hampir pasti akan direplikasi di database lain.
Fitur penting
- , ( Postgres), JSON, CSV , Kafka Kinesis, .
- : «» (timely dataflow) «» (differential dataflow). , . Materialize, , , Materialize — « », , .
- Materialize «» Postgres, psql Postgres.
Terwujud berpotensi dapat menggantikan banyak. Hal yang paling jelas: sistem memungkinkan Anda menggunakan semua gudang proses yang tersedia untuk memperbarui tampilan terwujud Anda secara progresif. Tapi itu bukan kemenangan besar.
Jauh lebih penting bagi kami adalah bahwa Materialize memungkinkan kami untuk menonaktifkan bagian-bagian dari tumpukan data yang dialokasikan untuk melacak perubahan dalam sumber data. Ini dapat dilakukan secara native :
CREATE SOURCE click_events
FROM KAFKA BROKER 'localhost:9092' TOPIC 'click_events'
FORMAT AVRO USING CONFLUENT SCHEMA REGISTRY 'http://localhost:8081';
Database Anda sekarang "tahu" tentang sumber data yang dapat digunakannya untuk membuat tampilan material yang diperbarui secara otomatis. Bagi saya, "pipelining" asli ini tampak lebih ajaib daripada pembaruan tampilan otomatis. Jika Anda menjalankan, misalnya, fungsi tanpa server, atau tugas Heron , atau pipeline data Flink , yang hanya melacak, dan menambahkan operator di sana
INSERT, maka Materialize akan memungkinkan Anda untuk memotong bagian tumpukan itu.
Pertanyaan untuk proyek
- Mengapa database terpisah dan bukan ekstensi Postgres ? Kami yakin ada alasan arsitektural yang bagus mengapa ekstensi tidak akan berfungsi seperti ini di sini, tetapi saya ingin tahu alasannya.
- Seberapa mudah membuat ekstensi untuk sumber data lain? Bagaimana seseorang bisa menulis, misalnya, ekstensi untuk Apache Pulsar ? Apakah ada rencana untuk membuka API bagi pengembang untuk tujuan ini?
Prisma
Prisma bukanlah database daripada sekumpulan alat untuk mengabstraksi database Anda sebanyak mungkin . Sistem saat ini kompatibel dengan PostgreSQL , MySQL dan SQLite di sisi database, dan dengan JavaScript dan TypeScript dalam hal bahasa (dengan prospek mendukung database dan bahasa lain di masa mendatang). Ini disebut sebagai "lapisan data untuk aplikasi modern", yang umumnya benar.
"Cara emas" menggunakan Prisma adalah seperti ini:
- Tentukan tipe data Anda di tingkat aplikasi menggunakan skema SDL Prisma.
- Berdasarkan skema yang dibuat, buat kode yang sangat idiomatis untuk bahasa pilihan Anda.
- Bersiaplah untuk membuat REST API, GraphQL API, dan apa pun yang ingin Anda buat.
Kami memahami keraguan beberapa orang tentang alat seperti Prisma. Ada sekelompok besar pengembang yang menentang abstraksi database. Mereka tidak membutuhkan DSL dan GUI yang cerdas. Mereka ingin menulis SQL sederhana dan membuat semua kode interaksi database dengan tangan. Kami memahami keinginan untuk mempertahankan tingkat kendali ini, tetapi kami tetap menyarankan Anda meluangkan waktu 20-30 menit untuk mencoba Prisma. Kami pikir ini melakukan pekerjaan yang cukup baik untuk menemukan titik terbaik antara brute force dan SQL mentah.
Fitur penting
- Prisma SDL , . .
- Prisma Migrate ( , SQL). , A , .
- Prisma Studio — , Prisma.
Skema DSL Prisma memungkinkan Anda tidak hanya menentukan tipe data yang diperlukan untuk aplikasi Anda, tetapi juga menentukan pembuat kode mana yang ingin Anda gunakan, serta informasi koneksi untuk database yang Anda hubungkan.
Selain itu, jenis enumerasi (enum) disediakan, penjelasan praktis seperti
@id, @relationdan @default. Mengingatkan migrasi database DSL dari ActiveRecord dan Ecto , dan IDL, mirip dengan yang digunakan di Protocol Buffer dan Thrift .
Saya ingin melihat adaptasi skema SDL Prisma atau sesuatu yang serupa sebagai standar bahasa-independen (cocok untuk perpustakaan khusus bahasa). Status quo mengasumsikan bahwa setiap bahasa pemrograman menciptakan kembali roda. Kami pikir akan bermanfaat untuk memiliki cara yang tidak bergantung pada bahasa untuk menentukan jenis yang menentukan interaksi antara aplikasi dan database.
Omong-omong, terima kasih khusus kepada Prisma untuk dokumentasinya yang luar biasa. Kami pasti menganggap ini sebagai perbedaan penting, dan jika dokumentasi Anda tidak termasuk dalam bagian "Yang paling saya sukai" dari entri blog, Anda harus menginvestasikan lebih banyak sumber daya untuk membuat whitepaper.
Pertanyaan untuk proyek
Akankah Prisma juga berguna dalam bahasa yang sudah banyak menggunakan pemetaan relasional objek (ORM)? Jika menggunakan ActiveRecord untuk Ruby atau Ecto untuk Elixir, apa insentif untuk beralih?