Коли використовувати сховище ключів / цінностей, наприклад Redis замість / уздовж сторони бази даних SQL?

Я читав чудові речі про ключові / цінні магазини, такі як Redis, але не можу зрозуміти, коли саме час використовувати його в додатку.

Скажіть, я архітектор веб-додатків; Я знаю, який стек я буду використовувати для фронтального, бек-енд-бази, бази даних тощо. Якийсь сценарій, де я б пішов "ой нам також потрібен Redis для X, Y або Z".

Буду вдячний приклади node.js, а також приклади non-node.js.

Я не можу зрозуміти, коли настав час використовувати це в додатку.

Я рекомендую вам прочитати цей підручник, який також містить випадки використання. Оскільки redis досить орієнтований на пам'ять, він дійсно гарний для часто оновлюваних даних у режимі реального часу, таких як сховище сесій, база даних, статистика, кешування та його передові структури даних, що забезпечує багатогранність для багатьох інших сценаріїв.

Redis, однак, не є заміною NoSQL для класичних реляційних баз даних, оскільки він не підтримує багатьох стандартних функцій світу RDBMS, таких як запит ваших даних, який може сповільнити їх. Заміна - це швидше бази даних документів, такі як MongoDB або CouchDB, і redis чудово підходить для доповнення конкретних функціональних можливостей, коли швидкість та підтримка передових структур даних зручні.

Я думаю, що нічого не пояснює кращі випадки використання для Redis, ніж ця стаття: http://antirez.com/post/take-advantage-of-redis-adding-it-to-your-stack.html

Б'юсь об заклад, у вас буде ага! мить . ;)

Цитата попереднього читача:

Раніше я читав про Redis і чув, як компанії використовують його, але ніколи не зрозумів, що це. Прочитавши це, я можу сказати, що зараз я розумію Редіс і наскільки це корисно. Дивовижно, що почувши так багато про це все, що потрібно, була відносно проста стаття.

Цитата зі статті:

Redis багато в чому відрізняється від інших рішень для баз даних: він використовує пам'ять як основну підтримку пам’яті та диск тільки для збереження, модель даних є досить унікальною, вона є однопоточною тощо. Я думаю, що ще одна велика різниця полягає в тому, що для того, щоб скористатися Redis у виробничому середовищі, вам не потрібно переходити на Redis. Ви можете просто використовувати його для того, щоб робити нові речі, які раніше були неможливі, або для того, щоб виправити старі проблеми.

Використовуйте випадки, в яких стаття стосується:

• Повільні списки останніх елементів на домашній сторінці
• Табло та пов'язані з цим проблеми
• Порядок за голосами та часом користувача
• Термін дії закінчується на елементи
• Підрахунок матеріалів
• Унікальні N елементів за певну кількість часу
• Аналіз у реальному часі того, що відбувається, для статистики, анти-спаму чи будь-чого іншого
• Паб / Під
• Черги
• Кешування

• Я хотів би використовувати redis для проектів у режимі реального часу. Я нещодавно робив для однієї системи відстеження GPS, яка раніше була побудована на mysql як базі даних.

  ПЕРЕВАГА

  1. Кожен раз, коли трекер передає дані, мені не потрібно відкривати з'єднання mysql і зберігати його. Ми можемо зберегти його на redis і пізніше перенести на mysql, використовуючи якийсь інший процес. Це дозволить уникнути одночасного з'єднання від мутиплера-трекера до mysql.
  2. Я можу публікувати всі ці дані gps, а інші клієнти (javascript / android) можуть підписатися в режимі реального часу, використовуючи чергу черги на основі redis
  3. Я можу викликати сповіщення в режимі реального часу

Одна справа, що Redis не є реляційною базою даних. Якщо вам знадобиться SQL "ПРИЄДНАЙТЕСЬ", тоді ви не захочете використовувати Redis, а також будь-яку іншу нереляційну базу даних. Redis швидше, ніж більшість реляційних баз даних. Якщо ви будете виконувати лише ключові: запити парних значень, тоді ви хочете використовувати Redis.