Збереження високочастотних подій до бази даних з обмеженим зв'язком

У нас є ситуація, коли я маю справу з масовим припливом подій, що надходять на наш сервер, приблизно в 1000 подій в секунду, в середньому (пік може бути ~ 2000).

Проблема

Наша система розміщена в Heroku і використовує відносно дорогий Heroku Postgres DB , що дозволяє максимально 500 з'єднань DB. Ми використовуємо пул з'єднань для підключення від сервера до БД.

Події відбуваються швидше, ніж може працювати пул підключення БД

Проблема we have is that events come faster than the connection pool can handle. By the time one connection has finished the network roundtrip from the server to the DB, so it can get released back to the pool, more than n additional events come in.

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

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

Обмеження

Інші клієнти можуть захотіти одночасно читати події

Інші клієнти постійно запитують читати всі події з певною клавішею, навіть якщо вони ще не збережені в БД.

Клієнт може запитувати GET api/v1/events?

Чи існують приклади "класів", як це робити?

Можливі рішення

Вкажіть події на нашому сервері

Ми могли б зафіксувати події на сервері (з чергою з максимальною паралельністю 400, щоб пул підключення не закінчився).

Це погана ідея , оскільки:

  • Він вичерпає доступну пам'ять сервера. Узагальнені події, що надійшли в чергу, споживатимуть величезну кількість оперативної пам'яті.
  • Наші сервери перезапускаються кожні 24 години . Це жорсткий ліміт , встановлений Heroku. Сервер може перезапуститись, поки події зачиняються, що призводить до втрати подій, що залишилися.
  • Він вводить стан на сервері, завдаючи шкоди масштабованості. Якщо у нас встановлено кілька серверів, і клієнт хоче прочитати всі затримані + збережені події, ми не дізнаємося, на якому сервері живуть затримані події.

Використовуйте окрему чергу повідомлень

Я припускаю, що ми можемо використовувати чергу повідомлень (наприклад, RabbitMQ ?), Де ми завантажуємо повідомлення в нього та інший кінець - це інший сервер, який займається тільки збереженням подій на БД.

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

Використовуйте декілька баз даних, кожна з яких зберігає частину повідомлень з центральним сервером-координатором DB для керування ними

Іншим рішенням є використання декількох баз даних з центральним "координатором БД/балансуванням навантаження". Після отримання події він цей координатор вибрав би одну з баз даних для написання повідомлення. Це повинно дозволити нам використовувати декілька баз даних Heroku, збільшуючи тим самим ліміт з'єднання до 500 x кількість баз даних.

Після запиту на читання, цей координатор може видати запити SELECT кожній базі даних, об'єднати всі результати і відправити їх назад клієнту, який просив прочитати.

Це погана ідея , оскільки:

  • Ця ідея звучить як ... гм .. надмірна інженерія? Був би кошмар, щоб управляти також (резервні копії і т.д.). Складати та підтримувати складно, і якщо це абсолютно необхідно, це звучить як порушення KISS .
  • Він жертвує Послідовність . Здійснювати транзакції на декількох БД не можна, якщо ми підемо з цією ідеєю.
12
деякі відповіді беруть це до уваги, але я б скоріше запитав: чи абсолютно необхідно, щоб 100% вашої події були правильно вставлені в базу даних, якщо так, то як ви зараз працюєте з проблемою, коли ваш сервер перезавантажується?
додано Автор Walfrat, джерело
Таким чином, ви хочете 100% доступність, але не синхронно. Тоді моя ставка полягала б в тому, щоб спочатку зберегти події локально (ex: files) і експортувати файли на регулярній основі (це може бути tmp-файл, що скасовується, щоб уникнути блокування кожні 30 років). Основи такої системи - це ви можете мати все в один і той же час (без втрат, миттєвого процесу, збереження продуктивності). Ви повинні знати, що ви можете скинути (наприклад: синхронні або реальні 0% втрати), щоб отримати те, що вам потрібно. Однак це залежить від вимоги вашої системи, яку ви не можете бути тим, хто їх виправляв.
додано Автор Walfrat, джерело
Ви дійсно повинні уточнити, чи є ця норма максимальною або середньою. Якщо це пік, яка кількість подій на день?
додано Автор JimmyJames, джерело
"Ми вирішили надзвичайну ситуацію, випустивши порушники високочастотні події більш повільними темпами від клієнтів, але ми все ще хочемо знати, як обробляти цей сценарій у випадку, якщо нам потрібно обробити це високочастотні події." Я не впевнений, як це вирішує проблему. Якщо ви отримуєте більше, ніж можете в середньому, то не уповільнення клієнта означає, що вони постійно будують глибше відставання від подій, які потрібно обробляти?
додано Автор JimmyJames, джерело
Де ваше вузьке місце? Ви згадуєте пул підключень, але це впливає лише на паралельність, а не на швидкість вставки. Якщо у вас є 500 з'єднань і напр. 2000QPS, це має нормально працювати, якщо кожен запит завершується протягом 250 мс, що є довгим часом. Чому це вище 15 мс? Також зверніть увагу, що за допомогою PaaS ви відмовляєтеся від значних можливостей оптимізації, таких як масштабування обладнання бази даних або використання read-replicas для зменшення навантаження на основну базу даних. Heroku не варто, якщо розгортання - це ваша найбільша проблема.
додано Автор amon, джерело
@NicholasKyriakides Правильне обладнання не є мікрооптимізацією. Це основний спосіб масштабування баз даних. Затримка мережі в одному центрі обробки даних тут незначна, <1 мс. Запис на SSD підприємства також становить <1 мс. Для 1000 транзакцій вам знадобиться принаймні 1k IOPS, наприклад жорсткі диски не можуть забезпечити, хоча RAID-0 може допомогти. Компетентний sysadmin повинен мати можливість правильно налаштувати все це. Але ви бачите проблеми. Або у вас є гігантська проблема продуктивності в компоненті програмного забезпечення (це виключено для БД), або ваш PaaS просто дуже поганий. Хмара засмоктує продуктивність.
додано Автор amon, джерело
Чи не є можливим упаковувати декілька подій за один запит, перш ніж надсилати їх по мережі? Я вирішив подібну проблему, якщо кожен клієнт "упакував" усі події, які відбувалися в певний період часу, на один запит, і вони надсилали їх кожні 10 ~ 15 сек. Якщо це варіант, дайте мені пінг, і я розширю його на повну відповідь.
додано Автор T. Sar, джерело
Як саме ви переконалися, що пул з'єднань є проблемою? @amon правильний у своїх розрахунках. Спробуйте надіслати select null на 500 з'єднань. Б'юся об заклад, ви знайдете, що пул підключення не є проблемою.
додано Автор user26009, джерело
Якщо вибору null є проблематичним, то ви, мабуть, маєте рацію. Хоча було б цікаво, де витрачається весь цей час. Жодна мережа не є такою повільною.
додано Автор user26009, джерело
@amon Вузьке місце дійсно є пулом підключень. Я сам запустив ANALYZE , і вони не є проблемою. Я також побудував прототип для перевірки гіпотези пулу з'єднань і перевірив, що це дійсно проблема. База даних і сам сервер живуть на різних машинах, отже, затримка. Крім того, ми не хочемо відмовлятися від Heroku, якщо це абсолютно необхідно, не турбуючись про розгортання - це величезний плюс для нас.
додано Автор Nicholas Kyriakides, джерело
... Цей сценарій змусив нас подумати, що в той час, як ми могли "обходити через дросель" наш вихід на цей раз, досить скоро ми не будемо.
додано Автор Nicholas Kyriakides, джерело
@JimmyJames не буде сповільнювати роботу клієнта, тому що вони постійно створюють глибше відставання від подій, які потрібно обробляти? . Не в цьому випадку. Ми задушили клієнтів, щоб вони послали цю подію з меншими темпами. Для цієї події нам не знадобилося даних, які надсилаються з такою швидкістю, але було б добре. Є події, які ми завжди повинні мати їх. Зараз у нас немає стільки користувачів, що потрібна подія призведе до того ж самого питання, але ми будемо досить скоро з того, що вона виглядає. Я не зовсім вирішую свою поточну проблему ...
додано Автор Nicholas Kyriakides, джерело
@Walfrat Ми не впоралися з цим. Ми тільки уповільнили темп, що події випромінюються як тимчасове рішення. Також: це абсолютно необхідно, щоб 100% вашої події було правильно вставлено в базу даних . Так і ні; Якщо клієнт відправляє подію на сервер, я хочу гарантувати, що він буде доступний для читання іншими клієнтами відразу і через 2,3 роки. Вона не повинна бути негайно вставлена ​​в базу даних, але будь-яке запропоноване рішення буде краще відмовитися.
додано Автор Nicholas Kyriakides, джерело
@JimmyJames Відредаговано питання, це середнє значення.
додано Автор Nicholas Kyriakides, джерело
@usr Мій тест-ремінь працював на 50 з'єднаннях, а не на 500. Я запускаю SELECT NULL і це все ще проблематично. Крім того, я запускаю ANALYZ на запити, і їх час виглядає нормально. Хоча концепція мого питання все ще стоїть, я буду оновлювати її більш точними даними. Я також забув додати розмір запиту, який надсилається через дріт, який є досить великим (у середньому ~ 5 Кб)
додано Автор Nicholas Kyriakides, джерело
Якщо сказати, я розумію, що існують мікро-оптимізації, які я міг би зробити, що допоможе мені вирішити поточну проблему. Мені цікаво, чи існує масштабоване архітектурне рішення для моєї проблеми.
додано Автор Nicholas Kyriakides, джерело
Як правило, я б сказав: коли ви досягаєте меж використовуваної технології, вам потрібно почати перехід на іншу технологію.
додано Автор Dominique, джерело

6 Відповіді

Я припускаю, що вам потрібно більш ретельно вивчити підхід, який ви відкинули

  • Включіть події на нашому сервері

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

Крім того, ви можете побачити, чи можете ви зняти читання, у ідеалі хочете мати можливість масштабувати їх незалежно від записів. Це може означати вивчення CQRS (розділення відповідальності за запитами команди).

Сервер може перезапуститись, поки події зачиняються, що призводить до того, що ми втратимо затримані події.

У розподіленій системі, я думаю, ви можете бути досить впевнені, що повідомлення будуть втрачені. Можливо, ви зможете пом'якшити деякі наслідки цього, будучи розумним щодо ваших бар'єрів послідовності (наприклад, гарантувати, що запис на довготривале зберігання відбувається - до того, як подія поділиться поза системою).

  • Використовуйте декілька баз даних, кожна з яких зберігає частину повідомлень з центральним сервером координаторів DB для керування ними

Можливо, - я, швидше за все, подивимося на ваші бізнес-межі, щоб побачити, чи є природні місця для розкриття даних.

Є випадки, коли втрата даних є прийнятним компромісом?

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

Як це часто виглядає, це модель на основі потягів з повідомленнями. Постачальник записує повідомлення в упорядкований міцний магазин. Споживач витягує повідомлення з магазину, відстежуючи власну високу позначку води. Push-сповіщення використовуються як пристрій для зменшення затримки - але якщо повідомлення втрачено, повідомлення все одно витягується (зрештою), оскільки споживач витягує регулярний графік (відмінність полягає в тому, що, якщо повідомлення отримано, виклик відбувається раніше ).

See Reliable Messaging Without Distributed Transactions, by Udi Dahan (already referenced by Andy) and Polyglot Data by Greg Young.

11
додано
У розподіленій системі, я думаю, ви можете бути досить впевнені, що повідомлення будуть втрачені . Дійсно? Є випадки, коли втрата даних є прийнятним компромісом? У мене склалося враження, що втрата даних = невдача.
додано Автор Nicholas Kyriakides, джерело
@NicholasKyriakides, як правило, неприйнятно, тому OP запропонувала можливість запису на довготривалий магазин перед випуском події. Перевірте цю статтю і це відео від Udi Dahan, де він більш детально розглядає цю проблему.
додано Автор Andy, джерело

Вхідний потік

Невідомо, якщо 1000 подій/секунди являють собою піки чи це безперервне навантаження:

  • якщо це пік, ви можете використовувати чергу повідомлень як буфер для розподілу навантаження на сервер БД протягом більш тривалого часу;
  • якщо це постійне навантаження, лише черги повідомлень недостатні, оскільки сервер БД ніколи не зможе наздогнати. Потім потрібно подумати про розподілену базу даних.

Запропоноване рішення

Інтуїтивно в обох випадках я звертаюся до Kafka на основі подій потік:

  • All events are systematically published on a kafka topic
  • A consumer would subscribe to the events and store them to the database.
  • A query processor will handle the requests from the clients and query the DB.

Це дуже масштабоване на всіх рівнях:

  • Якщо вузьким місцем є сервер БД, просто додайте декількох користувачів. Кожен може підписатися на тему і записати на інший сервер БД. Однак, якщо розподіл відбувається випадковим чином по серверах БД, процесор запитів не зможе передбачити, що сервер БД буде прийнятий і повинен запитувати кілька серверів БД. Це може призвести до нового вузького місця на стороні запиту.
  • Таким чином, схема розподілу БД може бути передбачена шляхом організації потоку подій на кілька тем (наприклад, за допомогою груп ключів або властивостей, щоб розділити БД відповідно до передбачуваної логіки).
  • Якщо одного сервера повідомлень недостатньо для обробки зростаючого потоку подій введення, ви можете додати розділи kafka , щоб поширювати теми kafka на декілька фізичних серверів.

Пропонуючи клієнтам події, ще не написані в БД

Ви хочете, щоб ваші клієнти мали доступ до інформації, яка ще знаходиться в трубі і ще не була написана до БД. Це трохи делікатніше.

Варіант 1: Використання кешу для доповнення запитів db

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

Дизайн буде виглядати так:

enter image description here

Масштабованість цього шару запитів може бути досягнута шляхом додавання більшої кількості процесорів запитів (кожна в своїй групі споживачів).

Варіант 2: розробка подвійного API

Кращий підхід ІМХО був би запропонувати подвійний API (використовувати механізм окремої групи споживачів):

  • API запитів для доступу до подій у БД та/або створення аналітики
  • потоковий API, який пересилає повідомлення безпосередньо з теми

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

Варіанти

Я запропонував kafka, оскільки він призначений для дуже високих томів/a> з постійними повідомленнями, щоб можна було перезавантажити сервери, якщо потрібно.

Ви можете побудувати подібну архітектуру з RabbitMQ. Однак, якщо вам потрібні стійкі черги,

це може зменшити ефективність . Крім того, наскільки я знаю, єдиним способом досягти паралельного споживання тих самих повідомлень кількома читачами (наприклад, автором + кеш) з RabbitMQ є клонування черг . Таким чином, вища масштабованість може прийти за більш високою ціною.

8
додано
@NicholasKyriakides Я інтерпретував " Інші клієнти постійно запитують для читання всі події з певним ключем , навіть якщо вони ще не збережені в БД ще . "як необхідність зробити DB запит (" all ") і об'єднати його з вхідними подіями (тут обробляється" кеш ", безпосередньо подається з входу), усуваючи подвоєння. Якщо з "всім" ви мали на увазі лише "все нове", ми могли б спростити: без кешу, без злиття та читання з БД або пересилання нових подій
додано Автор Christophe, джерело
Так. Моя перша думка не полягає у випадковому розподілі, тому що це може збільшити навантаження на обробку для запитів (наприклад, запит обох численних БД у більшості випадків). Можна також розглянути розподілені БД (наприклад, Ignite?). Але для того, щоб зробити будь-який усвідомлений вибір, потрібно добре розуміти схеми використання БД (що ще є у db, як часто це запитується, які запити, чи існують обмеження на транзакції поза окремими подіями, тощо ...).
додано Автор Christophe, джерело
@NicholasKyriakides Дякуємо! 1) Я просто думав про декілька незалежних серверів баз даних, але з чіткою схемою розбиття (ключ, географія тощо), які могли бути використані для ефективного відправлення команд. 2) Інтуїтивно , можливо тому, що Kafka розроблений для дуже висока пропускна здатність з постійними повідомленнями необхідно перезавантажити сервери?). Я не впевнений, що RabbitMQ є таким же гнучким для розподілених сценаріїв, а стійкі черги знижують продуктивність
додано Автор Christophe, джерело
Зоряний; Що ви маєте на увазі під розподілена база даних (наприклад, використовуючи спеціалізацію сервера за групами ключів) ? Також чому Кафка замість RabbitMQ? Чи існує особлива причина для вибору одного над іншим?
додано Автор Nicholas Kyriakides, джерело
Для 1) Отже, це дуже схоже на мою ідею Використання декількох баз даних , але ви говорите, що я не повинен просто випадковим чином (або круглим) поширювати повідомлення кожній базі даних. Чи не так?
додано Автор Nicholas Kyriakides, джерело
Мені цікаво, чому локальний кеш потрібно взагалі? Вся ідея використання декількох баз даних/авторів полягає в тому, що події зберігаються миттєво і майже не спостерігається відставання. Чому не просто читати прямо з БД?
додано Автор Nicholas Kyriakides, джерело
, навіть якщо вони ще не збережені в БД. . Я мав на увазі те, що якщо рішення буде вибрано, що приймає, що завжди буде відставання від подій, які ще не були написані, то клієнти, які читають, хотіли б також отримати відставання. Ідея мульти-БД в значній мірі не означає відставання (теоретично) = ніколи незбережені події БД = немає потреби в кеші.
додано Автор Nicholas Kyriakides, джерело
Просто хочеться сказати, що, незважаючи на те, що кафка може дати дуже високу пропускну здатність, це, ймовірно, виходить за межі більшості потреб людей. Я виявив, що справа з кафкою та її API була великою помилкою для нас. RabbitMQ не сутуляться, і він має інтерфейс, який можна очікувати від MQ
додано Автор Ankit, джерело

Якщо я правильно розумію поточний потік:

  1. Отримати та подію (я припускаю через HTTP?)
  2. Запит на підключення з пулу.
  3. Вставити подію до БД
  4. Відкрийте підключення до пулу.

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

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

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

6
додано

Припущення

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

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

Рішення

Assuming that you have correctly identified your bottleneck - latency between your process and the Postgres database - that is the primary problem to solve for. The Рішення needs to account for your consistency Обмеження with other clients wanting to read the events as soon as practicable after they are received.

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

Вам потрібно буде зберігати чергу подій локально, яка періодично записується і записується до db, або після досягнення заданого розміру, або після закінчення часу. Процес повинен контролювати цю чергу, щоб запустити флеш у сховище. Навколо має бути багато прикладів, як керувати одночасною чергою, яка періодично видаляється на вашій мові - Ось приклад у C# , з періодичного потоку пакетної обробки бібліотеки Serilog.

This SO answer describes the fastest way to flush data in Postgres - although it would require your batching store the queue on disk, and there is likely a problem to be solved there when your disk disappears upon reboot in Heroku.

Обмеження

Another answer has already mentioned CQRS, and that is the correct approach to solve for the Обмеження. You want to hydrate read models as each event is processed - a Mediator pattern can help encapsulate an event and distribute it to multiple handlers in-process. So one handler may add the event to your read model that is in-memory that clients can query, and another handler can be responsible for queuing the event for its eventual batched write.

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

5
додано

Події відбуваються швидше, ніж може працювати пул підключення до БД

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

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

Інші клієнти можуть захотіти одночасно читати події

Це обмеження можливе лише в тому випадку, якщо події зберігаються в базі даних без будь-якої обробки (сирі події). Якщо події обробляються до збереження в базі даних, то єдиний спосіб отримати події з бази даних.

Якщо клієнти просто хочуть запитувати сирі події, то я пропоную використовувати пошукову систему, наприклад Elastic Search. Ви навіть отримаєте API запиту/пошуку безкоштовно.

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

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

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

3
додано

Я б відкинув heroku всі разом, тобто сказав би, що я б відкинув централізований підхід: кілька записів, що пік максимального підключення до басейну є однією з головних причин, чому db-кластери, де винайдено, головним чином, не завантажують запис db (s) з запитами на читання, які можуть виконуватися іншими блоками в кластері, я б спробував з топологією master-slave, більше того - як хтось інший вже згадував, маючи власні установки db, можна налаштувати все система, щоб переконатися, що час розповсюдження запиту буде правильно оброблено.

Удачі

1
додано