В чому сенс декількох баз даних Redis?

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

Якщо я сегментую на декілька баз даних, все ще залишається однопоточним, і я все ще можу використовувати лише одне ядро. Якщо я лише запускаю інший екземпляр Redis в тому ж полі, я можу використовувати додаткове ядро. Крім того, я не можу назвати бази даних Redis або давати їм будь-який більш логічний ідентифікатор. Отже, маючи все сказане, чому / коли я коли-небудь хочу використовувати декілька баз даних Redis, а не просто розкручувати додатковий екземпляр Redis для кожної додаткової бази даних, яку я хочу? І, відповідно, чому Redis не намагається використовувати додаткове ядро ​​для кожної додаткової бази даних, яку я додаю? Яка перевага бути однопоточним в базі даних?

В основному, бази даних Redis в одному і тому ж екземплярі не відрізняються від схем екземплярів бази даних RDBMS.

Отже, маючи все сказане, чому / коли я коли-небудь хочу використовувати декілька баз даних Redis, а не просто розкручувати додатковий екземпляр Redis для кожної додаткової бази даних, яку я хочу?

Є одна очевидна перевага використання баз даних redis в тому самому екземплярі redis, і це управління. Якщо ви створили окремий екземпляр для кожної програми, і скажімо, у вас є 3 додатки, це 3 окремі екземпляри Redis, кожен з яких, ймовірно, потребує раб для HA у виробництві, так що це 6 загальних примірників. З точки зору управління, це стає безладним дуже швидко, оскільки вам потрібно стежити за всіма ними, робити оновлення / виправлення тощо. Якщо ви не плануєте перевантажувати Redis з високим входом / виводом, один екземпляр з веденим простішим і простіше в управлінні за умови, що він відповідає вашій умові угоди.

Ви не хочете використовувати кілька баз даних в одному екземплярі redis. Вона застаріла, і, як ви зазначали, кілька примірників дозволяють вам скористатися декількома ядрами. Якщо ви користуєтесь вибором бази даних, вам доведеться зробити рефактор під час оновлення. Моніторинг та управління кількома прикладами не є важким і не болючим.

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

Як сказав Джонатон, не використовуйте команду ключів. Набагато кращі показники ви знайдете, якщо просто створити ключовий індекс. Щоразу, коли ви додаєте ключ, додайте ім'я ключа до набору. Команда ключів не дуже корисна, коли ви збільшуєте масштаб, оскільки для повернення знадобиться значний час.

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

Щодо одинарної різьби, врахуйте, що redis призначений для швидкості та атомності. Впевнені дії, що змінюють дані в одному db, не потрібно чекати на іншому db, але що робити, якщо ця дія зберігається у дамп-файлі чи обробці транзакцій на рабах? З цього моменту ви починаєте потрапляти в бур’яни програмування паралельності.

Використовуючи кілька екземплярів, ви перетворюєте складність багатопотокової передачі на простішу систему стилю передачі повідомлень.

Навіть Сальваторе Санфіліппо (творець Redis) вважає поганою ідеєю використовувати декілька БД в Redis. Дивіться його коментар тут:

https://groups.google.com/d/topic/redis-db/vS5wX8X4Cjg/discussion

Я розумію, як це може бути корисним, але, на жаль, я вважаю, що помилки в базі даних Redis є моїм найгіршим рішенням у дизайні Redis взагалі ... без будь-якого реального посилення, це робить внутрішні органи набагато складнішими. Реальність полягає в тому, що бази даних не змінюються масштабно з кількох причин, як-от активний термін дії ключів і VM. Якщо вибір БД можна виконати за допомогою рядка, я можу бачити, що ця функція використовується як масштабований словник O (1) словника, що замість цього не є.

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

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

2. Я б не рекомендував будувати навколо використання KEYSкоманди, оскільки це O (n), і це не так добре. Що ви використовуєте для цього, що можете досягти іншим способом? Можливо, redis - це не найкращий варіант для вас, якщо KEYSжиттєво важлива функціональність.

3. Я думаю, що вони згадують про переваги одного потокового сервера у своїх FAQ, але головне - простота - вам не потрібно зациклюватися на одночасності. Кожна дія блокується, тому жодна дві речі не можуть одночасно змінювати базу даних. В ідеалі у вас є один (або більше) екземплярів на ядро ​​кожного сервера, а для розподілу ключів між ними використовуйте послідовний алгоритм хешування (або проксі). Звичайно, ви втратите деяку функціональність - трубопроводи працюватимуть лише для речей на одному сервері, сортування стає складніше тощо.

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

Бази даних Redis можуть використовуватися в рідкісних випадках розгортання нової версії програми, де нова версія вимагає роботи з різними об'єктами.

Використання декількох баз даних в одному екземплярі може бути корисним у наступному сценарії:

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

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

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

Використовуючи бази даних, ви можете використовувати той самий хмарний екземпляр Redis для надання послуг (скажімо) розробників, UAT та виробництва, або декількох примірників вашої програми, або що-небудь ще - таким чином, використовуючи більше виділеної пам’яті і, таким чином, трохи більше витрат, ефективний.

У випадку використання, на який я переглядаю, є кілька прикладів програми, яка використовує 200-300K кожен, але мінімальний розмір мого хмарного провайдера - 1М. Ми можемо об'єднати 10 примірників на одному Redis, не створюючи зубців в будь-яких межах, і таким чином заощадити близько 90% вартості хостингу Redis. Я вдячний, що існують обмеження та проблеми щодо цього підходу, але я вважав, що це варто згадати.