Ще се опитам да отговоря на въпроса ви, но ще започна с нещо, което в началото може да изглежда странно:ако не се интересувате от вътрешните елементи на Redis, не би трябвало да ви пука за това как типовете данни се внедряват вътрешно. Това е по проста причина:за всяка операция на Redis ще намерите времевата сложност в документацията и, ако имате набор от операции и времева сложност, единственото друго нещо, от което се нуждаете, е някаква представа за използването на паметта (и т.к. ние правим много оптимизации, които може да варират в зависимост от данните, най-добрият начин да получите тези последни цифри е да направите няколко тривиални теста в реалния свят).
Но тъй като попитахте, ето основната реализация на всеки тип данни на Redis.
- Стрингове се реализират с помощта на библиотека за динамични низове на C, така че да не плащаме (асимптотично казано) за разпределения в операциите за добавяне. По този начин имаме O(N) добавяния, например, вместо да имаме квадратично поведение.
- Списъци се изпълняват с свързани списъци.
- Комплекти и Хешове се реализират с хеш таблици.
- Сортирани комплекти се реализират със списъци за пропускане (особен тип балансирани дървета).
Но когато списъците, наборите и сортираните набори са малки по брой елементи и размер на най-големите стойности, се използва различно, много по-компактно кодиране. Това кодиране се различава за различните типове, но има функцията, че е компактен блок от данни, който често принуждава O(N) сканиране за всяка операция. Тъй като използваме този формат само за малки обекти, това не е проблем; сканирането на малък O(N) blob забравя за кеша така че на практика е много бързо и когато има твърде много елементи, кодирането автоматично се превключва на собственото кодиране (списък с връзки, хеш и т.н.).
Но въпросът ви всъщност не беше само за вътрешните елементи, а идеята ви беше Какъв тип да използвате, за да постигнете какво? .
Стрингове
Това е основният тип на всички видове. Това е един от четирите типа, но е и основният тип на сложните типове, тъй като списъкът е списък от низове, наборът е набор от низове и т.н.
Низът на Redis е добра идея във всички очевидни сценарии, при които искате да съхранявате HTML страница, но също и когато искате да избегнете конвертирането на вече кодираните си данни. Така например, ако имате JSON или MessagePack, можете просто да съхранявате обекти като низове. В Redis 2.6 можете дори да манипулирате този вид обектен сървър, като използвате Lua скриптове.
Друго интересно използване на низове са растерните изображения и като цяло масиви от байтове с произволен достъп, тъй като Redis експортира команди за достъп до произволни диапазони от байтове или дори единични битове. Например, проверете тази добра публикация в блога:Бързи и лесни показатели в реално време с помощта на Redis.
Списъци
Списъците са добри, когато е вероятно да докоснете само крайните точки на списъка:близо до опашката или близо до главата. Списъците не са много добри за разделяне на страници, тъй като произволният достъп е бавен, O(N). Така че доброто използване на списъците са обикновени опашки и стекове или обработка на елементи в цикъл с помощта на RPOPLPUSH със същия източник и дестинация за "завъртане" на пръстен от артикули.
Списъците също са добри, когато искаме просто да създадем ограничена колекция от N елемента, където обикновено имаме достъп само до горните или долните елементи или когато N е малко.
Набори
Наборите са неподредено събиране на данни, така че те са добри всеки път, когато имате колекция от елементи и е много важно да проверите наличието или размера на колекцията по много бърз начин. Друго страхотно нещо за наборите е поддръжката за надникване или изскачане на произволни елементи (команди SRANDMEMBER и SPOP).
Наборите също са добри за представяне на релации, например "Какви са приятелите на потребител X?" и т.н. Но други добри структури от данни за този вид неща са сортирани набори, както ще видим.
Наборите поддържат сложни операции като пресечки, обединения и така нататък, така че това е добра структура от данни за използване на Redis по „изчислителен“ начин, когато имате данни и искате да извършите трансформации върху тези данни, за да получите някакъв изход.
Малките набори са кодирани по много ефективен начин.
Хешове
Хешовете са перфектната структура на данни за представяне на обекти, съставени от полета и стойности. Полетата на хешове могат също да бъдат атомно увеличени с помощта на HINCRBY. Когато имате обекти като потребители, публикации в блогове или някакъв друг вид елемент , хешовете вероятно са най-добрият начин, ако не искате да използвате собствено кодиране като JSON или подобно.
Имайте предвид обаче, че малките хешове се кодират много ефективно от Redis и можете да помолите Redis атомарно да GET, SET или да увеличава отделни полета по много бърз начин.
Хешовете могат да се използват и за представяне на свързани структури от данни, като се използват препратки. Например проверете изпълнението на коментарите на lamernews.com.
Сортирани набори
Сортираните набори са единствените други структури от данни, освен списъци, които поддържат подредени елементи . Можете да правите много готини неща с сортирани комплекти. Например, можете да имате всички видове Най-важно нещо списъци във вашето уеб приложение. Водещи потребители по резултат, водещи публикации по показвания на страници, топ каквото и да е, но един екземпляр на Redis ще поддържа тонове операции за вмъкване и получаване на най-горните елементи в секунда.
Сортираните множества, подобно на обикновените множества, могат да се използват за описване на релации, но те също така ви позволяват да ранжирате списъка с елементи и да запомните подреждането. Например, ако си спомня приятели на потребител X със сортиран набор, мога лесно да ги запомня по реда на прието приятелство.
Сортираните набори са добри за приоритетни опашки.
Сортираните набори са като по-мощни списъци, където вмъкването, премахването или получаването на диапазони от средата на списъка винаги е бързо. Но те използват повече памет и са O(log(N)) структури от данни.
Заключение
Надявам се, че предоставих малко информация в тази публикация, но е много по-добре да изтеглите изходния код на lamernews от http://github.com/antirez/lamernews и да разберете как работи. Много структури от данни от Redis се използват в Lamer News и има много улики за това какво да използвате за решаване на дадена задача.
Съжалявам за правописните грешки, тук е полунощ и съм твърде уморен да прегледам публикацията;)
