Lima gudang data yang berbeda, masing-masing menjawab pertanyaan yang lain menjawab buruk: SQL terdistribusi untuk data bisnis transaksional, kolom lebar untuk telemetri high-write, gudang dalam memori untuk keadaan efemer, penyimpanan objek untuk berkas, dan basis data vektor untuk pencarian semantik. Memilih dengan benar adalah sebagian besar rekayasa data, dan hampir selalu dilakukan oleh inersia.
| Ukuran | Nilai | Sumber | Diukur |
|---|---|---|---|
| Penyimpanan data yang berbeda dalam produksi | 5 (YugabyteDB, ScyllaDB, Redis/Valkey, MinIO, Qdrant) | kubectl get statefulsets,deployments --all-namespaces | |
| Topologi SQL terdistribusi | yb-master and yb-tserver as separate stateful sets | kubectl get statefulsets -n kamo | |
| Berkas migrasi SQL di bawah kendali versi | 90 | find . -name '*.sql' across all service repositories | |
| Migrasi mesin basis data produksi selesai | 1 (CockroachDB to YugabyteDB, live data) | service configuration history; port 26257 retired in favour of 5433 |
Apa gedung itu mengajarkan kita
Jawaban default untuk ke mana data pergi adalah apa pun proyek terakhir yang digunakan. Itulah bagaimana sebuah bisnis berakhir menjalankan agregasi analitis melawan basis data mengambil pesanan pelanggan, atau menjaga tiga puluh gigabyte file yang diunggah dalam baris tabel. Kami memilih setiap toko melawan beban kerja, dan kami bermigrasi ketika kami salah — platform sebelumnya berjalan pada mesin SQL terdistribusi yang berbeda dan pindah dari itu, yang benar-benar sulit untuk dilakukan dengan data produksi dan lebih berharga sebagai pengalaman daripada jumlah diskusi arsitektur apapun.
SQL terdistribusi bukanlah pengganti drop-in untuk basis data node tunggal, dan caranya berbeda adalah cara yang menggigit. Sebuah transaksi melihat satu snapshot untuk seluruh hidupnya bahkan dalam mode baca-commit, sehingga membaca kedua dari baris di dalam satu transaksi tidak mengamati menulis transaksi lain yang dikommit di antara — kode yang benar pada node tunggal adalah salah di sini. Konflik baca-dan-tulis muncul sebagai kesalahan yang dapat dicoba ulang pada transaksi yang tidak pernah menulis apapun. Ini bukan kasus tepi eksotis; mereka adalah Selasa, dan mereka adalah mengapa kami berhati-hati tentang apa yang kami janjikan pada pekerjaan data.
Penyimpanan objek membawa setiap berkas yang diunggah, dengan deduplikasi berdasarkan isi, dan itu memiliki pelajarannya sendiri: sebuah unggahan yang gagal dapat meninggalkan baris yang kemudian dicoba ulang untuk deduplikasi, menghasilkan berkas yang sistem percaya ada dan tidak dapat dilayani. Kami menemukan itu dalam produksi. Sekarang ini adalah sesuatu yang kami periksa dalam sistem apapun yang kami bangun yang deduplikasi apapun.
Dibangun dengan
- YugabyteDB
- ScyllaDB
- Redis
- Valkey
- MinIO
- Qdrant
- PostgreSQL wire protocol
- Hibernate
Apa ini memenuhi syarat kita untuk
Katakan pada kami apa yang Anda coba lakukan
Sebuah percakapan singkat biasanya cukup untuk mengatakan apakah kami orang yang tepat. jika kami tidak, kami akan mengatakannya dan menunjukkan tempat yang lebih baik.