Daripada re-hash banyak dokumentasi lain yang ada di alam liar, saya akan membuat daftar beberapa di sekitar untuk beberapa info latar belakang di sekitar Redis + ServiceStack's Redis Client:
- Apa yang harus dipikirkan saat mendesain aplikasi NoSQL Redis
- Mendesain Basis Data NoSQL menggunakan Redis
- Ikhtisar Umum Redis dan .NET
- Versi tanpa skema dan Migrasi Data dengan Klien C# Redis
Tidak ada keajaiban - Redis adalah kanvas kosong
Pertama saya ingin menunjukkan bahwa menggunakan Redis sebagai penyimpanan data hanya menyediakan kanvas kosong dan tidak memiliki konsep entitas terkait dengan sendirinya. yaitu hanya menyediakan akses ke struktur data comp-sci terdistribusi. Bagaimana hubungan disimpan pada akhirnya tergantung pada driver klien (yaitu ServiceStack C# Redis Client) atau pengembang aplikasi, dengan menggunakan operasi struktur data primitif Redis. Karena semua struktur data utama diimplementasikan di Redis, pada dasarnya Anda memiliki kebebasan penuh tentang bagaimana Anda ingin menyusun dan menyimpan data Anda.
Pikirkan bagaimana Anda akan menyusun hubungan dalam kode
Jadi cara terbaik untuk memikirkan cara menyimpan barang di Redis, adalah dengan mengabaikan sepenuhnya tentang bagaimana data disimpan dalam tabel RDBMS dan memikirkan bagaimana data itu disimpan dalam kode Anda, yaitu menggunakan kelas koleksi C# bawaan di memori - yang dicerminkan Redis dalam perilakunya dengan struktur data sisi servernya.
Meskipun tidak memiliki konsep entitas terkait, Set . bawaan Redis dan SortedSet struktur data menyediakan cara ideal untuk menyimpan indeks. Misalnya. Set Red Redis koleksi hanya menyimpan maksimal 1 kemunculan elemen. Ini berarti Anda dapat dengan aman menambahkan item/kunci/id ke dalamnya dan tidak peduli apakah item tersebut sudah ada karena hasil akhirnya akan sama jika Anda menyebutnya 1 atau 100 kali - yaitu idempoten, dan pada akhirnya hanya 1 elemen yang tetap disimpan di set. Jadi kasus penggunaan yang umum adalah ketika menyimpan grafik objek (akar agregat) adalah menyimpan ID Entitas Anak (alias Kunci Asing) ke dalam Set setiap kali Anda menyimpan model.
Memvisualisasikan data Anda
Untuk visualisasi yang baik tentang bagaimana Entitas disimpan di Redis, saya sarankan menginstal Redis Admin UI yang bekerja dengan baik dengan Klien C# Redis ServiceStack karena menggunakan konvensi penamaan kunci di bawah ini untuk memberikan tampilan hierarkis yang bagus, mengelompokkan entitas yang Anda ketikkan bersama-sama (terlepas dari semua kunci yang ada di keyspace global yang sama).
Untuk melihat dan mengedit Entitas, klik tombol Edit link untuk melihat dan mengubah representasi JSON internal entitas yang dipilih. Semoga Anda dapat membuat keputusan yang lebih baik tentang cara mendesain model setelah Anda dapat melihat cara penyimpanannya.
Bagaimana POCO / Entitas disimpan
Klien C# Redis bekerja dengan POCO apa pun yang memiliki satu kunci utama - yang secara default diharapkan menjadi Id (meskipun konvensi ini dapat diganti dengan ModelConfig). Pada dasarnya POCO disimpan ke dalam Redis sebagai JSON serial dengan typeof(Poco).Name dan Id digunakan untuk membentuk kunci unik untuk instance itu. Contoh:
urn:Poco:{Id} => '{"Id":1,"Foo":"Bar"}'
POCO di C# Client secara konvensional diserialisasi menggunakan Json Serializer ServiceStack yang cepat di mana hanya properti dengan getter publik yang diserialisasi (dan setter publik untuk mendapatkan de-serialized kembali).
Default dapat diganti dengan [DataMember] attrs tetapi tidak direkomendasikan karena hal itu memperburuk POCO Anda.
Entitas di-blobbed
Jadi mengetahui bahwa POCO di Redis hanya digumpalkan, Anda hanya ingin menyimpan data root non-agregat pada POCO Anda sebagai properti publik (kecuali jika Anda sengaja ingin menyimpan data yang berlebihan). Konvensi yang baik adalah menggunakan metode untuk mengambil data terkait (karena tidak akan diserialisasi), tetapi juga memberi tahu aplikasi Anda metode mana yang membuat panggilan jarak jauh untuk membaca data.
Jadi pertanyaan apakah Umpan harus disimpan dengan Pengguna apakah itu data root non-agregat atau tidak, yaitu apakah Anda ingin mengakses umpan pengguna di luar konteks pengguna atau tidak? Jika tidak, maka tinggalkan List<Feed> Feeds properti di User ketik.
Mempertahankan Indeks Kustom
Namun, jika Anda ingin agar semua umpan dapat diakses secara independen, yaitu dengan redisFeeds.GetById(1) maka Anda ingin menyimpannya di luar pengguna dan memelihara indeks yang menghubungkan 2 entitas.
Seperti yang Anda perhatikan ada banyak cara untuk menyimpan hubungan antara entitas dan bagaimana Anda melakukannya sebagian besar masalah preferensi. Untuk entitas anak dalam induk>anak hubungan Anda selalu ingin menyimpan ParentId dengan entitas anak. Untuk Induk, Anda dapat memilih untuk menyimpan koleksi ChildIds dengan model dan kemudian lakukan pengambilan tunggal untuk semua entitas anak untuk menghidrasi kembali model.
Cara lain adalah dengan mempertahankan indeks di luar dto induk dalam Set-nya sendiri untuk setiap instance induk. Beberapa contoh bagus dari ini adalah dalam kode Sumber C# dari demo Redis StackOverflow di mana hubungan Users > Questions dan Users > Answers disimpan di:
idx:user>q:{UserId} => [{QuestionId1},{QuestionId2},etc]
idx:user>a:{UserId} => [{AnswerId1},{AnswerId2},etc]
Meskipun C# RedisClient menyertakan dukungan untuk konvensi Parent/Child default melalui TParent.StoreRelatedEntities(), TParent.GetRelatedEntities<TChild>() dan TParent.DeleteRelatedEntities() API tempat indeks dipertahankan di belakang layar yang terlihat seperti:
ref:Question/Answer:{QuestionId} => [{answerIds},..]
Secara efektif, ini hanyalah beberapa dari kemungkinan opsi Anda, di mana ada banyak cara berbeda untuk mencapai tujuan yang sama dan di mana Anda juga memiliki kebebasan untuk menjalankannya sendiri.
Kebebasan mengetik yang longgar dan tanpa skema dari NoSQL harus diterapkan dan Anda tidak perlu khawatir mencoba mengikuti struktur kaku yang telah ditentukan sebelumnya yang mungkin Anda kenal saat menggunakan RDBMS.
Kesimpulannya, tidak ada jalan yang benar yang nyata untuk menyimpan data di Redis, mis. Klien C# Redis membuat beberapa asumsi untuk menyediakan API tingkat tinggi di sekitar POCO dan itu menggumpalkan POCO dalam nilai string aman biner Redis - meskipun ada klien lain yang lebih suka menyimpan properti entitas di Redis Hash (Kamus) sebagai gantinya . Keduanya akan bekerja.
