Документация по Redis: новое за полгода

Redis logo
С полгода назад публиковал здесь ссылку на свой перевод документации по Redis.

Для тех, кто не знает, что такое Redis — Redis, это NoSQL-база данных. Для тех, кто не знает, что такое NoSQL — Redis, это круто.

За прошедшее время в Redis накопились немалые изменения. Теперь все они отражены в обновлённом переводе. Здесь рассмотрим основное.

Хэши

Новый тип данных, представляющий собой, собственно, хэши :)

Теперь не надо хранить поля объекта в куче различных ключей типа user:10:name, user:10:surname. Всё в одном, да и удалить этого user’а-10 теперь можно одним запросом.

Упорядоченные множества

Были они, честно говоря, ещё и на момент прошлого перевода, но в нестабильной версии.

Теперь всё стабильно, плюс новые полезные команды для работы с ними.

Кто не в курсе, упорядоченные множества: коллекция элементов, отсортированных по определённому значению. Подходят для реализации аналога индексов в реляционных базах.

Транзакции

Не совсем такие, к каким мы привыкли, но выполняют своё основное предназначение: позволяют исполнить последовательность команд в виде одной атомарной операции.

Система подписок

Ещё один удобный вариант реализации очереди сообщений. В веб-приложениях подходит для демонов, обрабатывающих поступающие данные (рассылка писем, индексирование …)

Всякое другое

Наконец появился атомарный SET + EXPIRE, а то раньше приходилось бояться, что между этими двумя командами вклинится апокалипсис.

Также в ближайшее время обещают снять все ограничения на действия с волатильными ключами (теми, для которых установлен таймаут). Сейчас их нельзя сохранять (просто удаляться нафиг), это, конечно, обосновано с точки зрения архитектуры сервера, но ужасно раздражает. Надеемся, что скоро этого не будет.

Конфигурирование на лету

Ещё много новых полезных команд (PERSIST, APPEND, SUBSTR, ZRANK …) и новых опций к уже существующим.

Также немало переработаны внутренности сервера, связанные с виртуальной памятью, AOF-режимом и т.д.

Вобщем, Redis ещё охуеннее!

, , ,

Высокие нагрузки, оптимизация и всякое такое

И снова здравствуйте!

Как оказалось, День Знаний на самом деле сегодня, поэтому продолжаем разговор.

Отложим практику и займёмся теорией и немного философией.

Поговорим про оптимизацию приложений. А так как преждевременная оптимизация — смертный грех, то про оптимизацию нагруженных приложений.
Не будем лезть в подробности, а просто попробуем разобраться в каких местах вообще следует оптимизировать.

Также затронем вопрос, а могут ли интерпретируемые динамические языки (в первую очередь наш PHP) с их невысоким быстродействием использоваться для построения высоконагруженных систем.

Остальной текст под катом

, , ,

Пользователи на сайте: Memcached vs MySQL-JOIN

Здравствуйте, дорогие друзья, с вами снова Блог ГО.

Сегодня, в День Знаний, разберём одну тему. Тема, не так, чтобы для старших классов, но уже и не для дошкольников.

Рассмотрим один из вариантов хранения данных о пользователях в мемкэше.

Постановка задачи

Есть, допустим, сайт, а на нём есть зарегистрированные пользователи. Их данные хранятся, обычно, в таблице наподобие следующей:

CREATE TABLE `users` (
	`user_id`  INT UNSIGNED NOT NULL AUTO_INCREMENT,
	`username` VARCHAR(20)  NOT NULL,              -- Имя
	`surname`  VARCHAR(20)  NOT NULL,              -- Фамилия
	`nickname` VARCHAR(50)  NULL DEFAULT NULL,     -- Ник
	`avatar`   BOOL         NOT NULL DEFAULT "0",  -- Наличие аватара
	`status`   ENUM("active", "banned", "deleted") DEFAULT "active", -- Активный, забаненый, удалённый
	-- ...
	PRIMARY KEY (`user_id`)
	-- ...
);

Остальной текст под катом

, ,