В чем недостаток использования Redis вместо СУБД?

Итак, если, например, я пытаюсь реализовать что-то, что выглядит как графический API Facebook, который должен быть очень быстрым и поддерживать миллионы пользователей, в чем недостаток использования Redis вместо СУБД?

спасибо! Джонатан!--1-->

9
rdbms redis replace scalability

1 ответов

существует множество потенциальных преимуществ и потенциальных недостатков использования Redis вместо классической РСУБД. Они действительно очень разные животные.

фокусировка только на потенциальных недостатках:

  • Redis-это хранилище в памяти: все данные должны поместиться в памяти. СУБД обычно хранит данные на дисках и кэширует часть данных в памяти. С помощью СУБД вы можете управлять большим количеством данных, чем у вас есть память. С редисом, ты не может.

  • Redis-это сервер структуры данных. Нет языка запросов (только команды) и нет поддержки реляционной алгебры. Вы не можете отправлять специальные запросы (например, вы можете использовать SQL в СУБД). Все доступы к данным должны быть предвидены разработчиком, и должны быть разработаны надлежащие пути доступа к данным. Много гибкости теряется.

  • Redis предлагает 2 варианта для настойчивости: регулярные snapshotting и добавлять только файлы. Ни один из них не такой, как надежен, как настоящий транзакций сервер, обеспечивающий повторить/отменить лесозаготовки, блок checksuming, точка-в-время восстановления, флешбеки возможности и т. д...

  • Redis предлагает только базовую безопасность (с точки зрения прав доступа) на уровне экземпляра. Все СУБД предоставляют подробные списки управления доступом к объектам (или управление ролями).

  • уникальный экземпляр Redis не масштабируется. Он работает только на одном ядре процессора в однопоточном режиме. Чтобы получить масштабируемость, несколько Экземпляры Redis должны быть развернуты и запущены. Распределение и сегментирование осуществляется на стороне клиента (т. е. разработчик должен заботиться о них). Если вы сравните их с уникальным экземпляром Redis, большинство СУБД обеспечивают большую масштабируемость (обычно обеспечивая параллелизм на уровне соединения). Они мульти-обработаны (Oracle, PostgreSQL, ...) или многопоточный (MySQL, Microsoft SQL Server, ... ), принимая преимущества многоядерных машин.

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

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

29