Apakah reka bentuk nilai kunci biasa bagi pangkalan data Redis?

Sistem log masuk pengguna

Sistem yang merekodkan maklumat log masuk pengguna Kami telah memudahkan perniagaan dan hanya meninggalkan satu jadual.

Reka bentuk pangkalan data hubungan

mysql>select*fromlogin;

+----------+---------- ------+-------------+---------------------+

　| user_id|name|login_times|last_login_time|

　+---------+----------------+-------- -----+---------------------+

　|1|kenthompson|5|2011-01-0100:00:00 |

|2|dennisritchie|1|2011-02-0100:00:00|

|3|JoeArmstrong|2|2011-03-0100:00:00|

　+---------+----------------+-------------+----- -----------------+

Kunci utama jadual user_id, nama mewakili nama pengguna, login_times mewakili bilangan log masuk pengguna, setiap kali pengguna log masuk, login_times akan meningkat secara automatik, dan last_login_time dikemas kini kepada masa semasa.

Reka bentuk REDIS

Tukar data hubungan ke dalam pangkalan data KV Kaedah saya adalah seperti berikut:

Nama jadual kunci: Nilai kunci utama: Nama lajur

. Nilai lajur nilai

biasanya menggunakan titik bertindih sebagai pemisah Ini adalah peraturan tidak bertulis. Sebagai contoh, dalam sistem php-adminforredis, kunci dipisahkan dengan titik bertindih secara lalai, jadi user:1user:2 dan kunci lain akan dibahagikan kepada satu kumpulan. Jadi data perhubungan di atas ditukar kepada data kv dan direkodkan seperti berikut:

Setlogin:1:login_times5

Setlogin:2:login_times1

Setlogin:3:login_times2

Setlogin:1:last_login_time2011-1-1

Setlogin:2:last_login_time2011-2-1

Setlogin:3:last_login_time2011-3-1

set :1 :name"kenthompson"

setlogin:2:name "dennisritchie"

setlogin:3:name"JoeArmstrong"

Jika kunci utama diketahui, anda boleh gunakan kaedah dapatkan dan tetapkan Dapatkan atau ubah suai nama pengguna, masa log masuk dan masa log masuk terakhir.

Pengguna umum tidak boleh tahu ID mereka sendiri, mereka hanya tahu nama pengguna mereka, jadi mesti ada hubungan pemetaan dari nama ke ID Reka bentuk di sini berbeza daripada di atas.

set"log masuk:kenthompson:id"1

set"log masuk:dennisritchie:id"2

set"log masuk:JoeArmstrong:id"3

Dengan cara ini, setiap kali pengguna log masuk, logik perniagaan adalah seperti berikut (versi python), r ialah objek redis, dan nama ialah nama pengguna yang diketahui.

　#Dapatkan id pengguna

uid=r.get("login:%s:id"%name)

　#Tingkatkan bilangan log masuk pengguna secara automatik

Berikut ialah ayat yang mungkin difrasa semula: ret = r.incr("login:%s:login_times" % uid)

　#Kemas kini masa log masuk terakhir pengguna

ret=r.set("login:%s:last_login_time " %uid,datetime.datetime.now())

Jika keperluan hanya untuk mengetahui ID, mengemas kini atau mendapatkan masa log masuk terakhir dan bilangan log masuk pengguna, tiada perbezaan antara pangkalan data hubungan dan pangkalan data kv. Satu melalui btreepk dan satu lagi melalui cincangan, kedua-duanya berfungsi dengan baik.

Katakan terdapat keperluan berikut untuk mencari pengguna N yang log masuk baru-baru ini. Pemaju mempunyai rupa dan ia agak mudah, ia boleh dilakukan dengan hanya satu sql.

Sila pilih semua lajur daripada jadual "log masuk", mengisih mengikut lajur "last_login_time" dalam tertib menurun dan hadkan saiz set hasil kepada N

Selepas DBA memahami keperluan, pertimbangkan jadual masa hadapan jika Ia agak besar, jadi buat indeks pada last_login_time. Dengan mengakses rekod N bermula dari bahagian paling kanan indeks, dan kemudian melaksanakan operasi pemulangan jadual N, pelan pelaksanaan mempunyai kesan yang ketara.

Apakah reka bentuk nilai kunci pangkalan data Redis biasa

Dua hari kemudian, saya perlu tahu siapa yang paling kerap log masuk. Bagaimana untuk menangani jenis perhubungan yang sama? DEV berkata ia mudah

　select*fromloginorderbylogin_timesdesclimitN

　DBA melihat dan perlu mencipta indeks pada login_time. Adakah anda fikir ada sesuatu yang salah? Setiap medan dalam jadual mempunyai petikan utama.

Punca masalah ialah penyimpanan data pangkalan data hubungan tidak cukup fleksibel, dan data hanya boleh disimpan menggunakan jadual timbunan yang disusun dalam baris. Struktur data bersatu bermakna anda mesti menggunakan indeks untuk menukar laluan akses SQL untuk mengakses lajur tertentu dengan cepat, dan peningkatan laluan akses bermakna anda mesti menggunakan maklumat statistik untuk membantu, jadi banyak masalah timbul.

Tiada indeks, tiada rancangan statistik, dan tiada pelan pelaksanaan Ini adalah pangkalan data kv.

Sebagai tindak balas kepada keperluan untuk mendapatkan N keping data terkini, ciri masuk dahulu keluar terakhir bagi senarai terpaut dalam Redis sangat sesuai. Kami menambah sekeping kod selepas kod log masuk di atas untuk mengekalkan senarai terpaut log masuk dan mengawal panjangnya supaya pengguna log masuk N terbaharu sentiasa disimpan di dalamnya.

　#Tambahkan orang semasa log masuk ke senarai terpaut

　ret=r.lpush("login:last_login_times",uid)

　#Simpan senarai terpaut dengan hanya N digit

ret=redis.ltrim("login:last_login_times",0,N-1)

Dengan cara ini, anda perlu mendapatkan id orang log masuk terkini, kod berikut boleh digunakan

last_login_list=r .lrange("login:last_login_times",0,N-1)

Selain itu, untuk mencari orang yang paling kerap log masuk, sortedset sangat sesuai untuk keperluan seperti sortedset dan kedudukan Kami menggabungkan pengguna dan masa log masuk Disimpan secara seragam dalam sortedset.

zaddlogin:login_times51

zaddlogin:login_times12

zaddlogin:login_times23

Dengan cara ini, jika pengguna log masuk, set isihan tambahan akan dikekalkan, set kod tambahan akan dikekalkan. berikut

#Bilangan masa log masuk untuk pengguna ini meningkat sebanyak 1

ret=r.zincrby("login:login_times",1,uid)

Jadi bagaimana untuk dapatkan pengguna dengan masa log masuk paling banyak, susun mengikut urutan terbalik Ambil pengguna peringkat ke-N

ret=r.zrevrange("login:login_times",0,N-1)

Ia boleh dilihat bahawa DEV perlu menambah 2 baris kod DBA tidak perlu mempertimbangkan indeks atau apa-apa.

Sistem TAG

Teg adalah perkara biasa dalam aplikasi Internet Jika direka dengan pangkalan data hubungan tradisional, ia akan menjadi agak tidak jelas. Kita ambil contoh mencari buku untuk melihat kelebihan redis dalam hal ini.

Reka bentuk pangkalan data hubungan

Dua jadual, satu untuk butiran buku dan satu untuk tag, menunjukkan tag setiap buku. Terdapat berbilang tag dalam buku.

mysql>select*frombook;

+------+------------------------ ----------------------------------------+

　|id|nama|pengarang|

　+----- -------------------------------------+------------- --- +

|1|TheRubyProgrammingLanguage|MarkPilgrim|

|1|Rubyonrail|DavidFlanagan|

|1|ProgrammingErlang|JoeArmstrong|

---------------------------------------------------- ------ --+

mysql>select*fromtag;

+---------+---------+

|tag |book_id|

　+---------+---------+

　|delima|1|

　|delima|. 2|

|web|2|

|erlang|3|

+---------+--- ------ +

Jika terdapat keperluan sedemikian, bagaimana untuk mencari buku di ruby ​​​​dan web, jika ia adalah pangkalan data hubungan

pilihb.nama,b. authorfromtagt1,tagt2,bookb

Wheret1.tagname='web'andt2.tagname='ruby'andt1.book_id=t2.book_idandb.id=t1.book_id

Jadual tag dikaitkan secara automatik dua kali dan kemudian dikaitkan dengan buku ini. SQL ini masih agak kompleks. Bagaimana jika keperluannya ialah Ruby, tetapi bukan buku web

Data perhubungan sebenarnya tidak sesuai untuk operasi set ini.

Reka bentuk REDIS

Pertama sekali, data buku mesti disimpan, sama seperti di atas.

setbook:1:name"TheRubyProgrammingLanguage"

Setbook:2:name"Rubyonrail"

Setbook:3:name"ProgrammingErlang"

setbook: 1:pengarang"MarkPilgrim"

Setbook:2:author"DavidFlanagan"

Setbook:3:author"JoeArmstrong"

jadual tag Kami menggunakan set untuk menyimpan data, kerana Set pandai mencari persimpangan dan kesatuan

sadtag:ruby1

sadtag:ruby2

sadtag:web2

sadtag:erlang3

Kemudian , buku milik ruby ​​​​tetapi juga milik web?

　inter_list=redis.sinter("tag.web","tag:ruby")

　Iaitu, buku kepunyaan ruby ​​​​tetapi bukan milik web ?

inter_list=redis.sdiff("tag.ruby","tag:web")

Koleksi buku itu milik ruby ​​​​dan web?

inter_list=redis .sunion("tag.ruby","tag:web")

Ia sangat mudah.

Daripada dua contoh di atas, kita dapat melihat bahawa dalam beberapa senario, pangkalan data hubungan anda mungkin boleh mereka bentuk sistem yang memenuhi keperluan anda, tetapi ia sentiasa berasa pelik dilakukan secara mekanikal.

Terutama dalam contoh log masuk ke sistem, pengindeksan perniagaan sering dibuat. Dalam sistem yang kompleks, ddl (buat indeks) boleh mengubah rancangan pelaksanaan. Oleh kerana SQL dalam sistem lama dengan perniagaan yang kompleks adalah semua jenis pelik, menyebabkan SQL lain menggunakan rancangan pelaksanaan yang berbeza, masalah ini sukar untuk diramalkan. Terlalu sukar untuk memerlukan DBA memahami semua SQL dalam sistem ini. Masalah ini amat serius dalam Oracle, dan setiap DBA mungkin pernah menghadapinya. Walaupun terdapat kaedah DDL dalam talian sekarang, DDL masih tidak begitu mudah untuk sistem seperti MySQL. Apabila bercakap tentang meja besar, DBA bangun awal pagi untuk beroperasi pada waktu perniagaan yang rendah, saya sering melakukannya. Sangat mudah untuk menggunakan Redis untuk mengendalikan permintaan ini, dan hanya memerlukan DBA untuk menganggarkan kapasiti.

Atas ialah kandungan terperinci Apakah reka bentuk nilai kunci biasa bagi pangkalan data Redis?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!