Який сховище даних найкраще підходить для мого сценарію?


10

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

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

Отже, якщо в таблиці А буде 10 000 користувачів та 500 записів, у цій таблиці буде 5M записів. Я завжди зберігаю дані на один день у цих таблицях, а опівночі я архівую історичні дані в HBase. Ця налаштування працює чудово, і у мене поки що немає проблем з продуктивністю.

Останнім часом відбулися певні зміни в бізнес-вимогах, і тепер деякі атрибути в базовій таблиці A (для 15 - 20 записів) змінюватимуться кожні 20 секунд, і виходячи з цього, я повинен перерахувати деякі значення для всіх цих записів варіацій у таблиці B для всі користувачі. Незважаючи на те, що змінюється лише 20 головних записів, мені потрібно зробити перерахунок та оновити 200 000 записів користувачів, що займає більше 20 секунд, і до цього часу відбудеться наступне оновлення, що призведе до черги всіх запитів Select Select. Я отримую приблизно 3 запиту / 5 секунд від користувачів онлайн, що призводить до 6-9 Вибір запитів. Щоб відповісти на запит api, я завжди використовую поля таблиці Б.

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

Хтось тут може запропонувати кращу альтернативу? Чи допомагає мені тут реляційна база даних noql +? Чи є якісь платформи / сховища даних, які дозволять мені часто оновлювати дані, не блокуючи, і водночас надають мені гнучкість виконання обраних запитів у різних полях сутності?


Вам справді потрібно зберігати всі ці дані? Це звучить якось так, ніби вам краще було б обчислити за запитом. Якщо ви можете обчислити 200k записів за трохи більше 20 секунд, ви можете обчислити ці 20 записів * 3 користувачів = 60 записів взагалі за один раз. Можливо, ви могли б подивитися, які користувачі в даний час перебувають в мережі, і оптимізувати ще більше? Схоже, ви генеруєте безліч даних, які ніхто ніколи не використовує (протягом часу дані все ще принаймні справедливі)
thorsten müller

Генерація лише для зареєстрованих користувачів - дуже хороший варіант thorsten. Я теж про це думав, але все-таки це не зовсім масштабований підхід. Моя платформа буде використовуватися лише в денний час, а тому протягом цього часу більшість користувачів будуть активними. Будь-які інші пропозиції, товариш?
глечики

@Jugs - Це все ще залишає питання про те, чи можна просто розраховувати на льоту. Чи є у оновлювати записи, або ж додаток просто потрібні дані , щоб бути там?
Бобсон

Боюся, я не можу обчислити під час руху, оскільки таблиця записів B класифікується для користувача (від 5 зірок до 1 зірки), і після цих обчислень ми робимо рейтинг знову для користувача. Весь процес для користувача займає 500 мсек , і якщо я це зробити на льоту, це буде впливати на час відповіді API
глечиків

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

Відповіді:


1

Схоже, таблиця B- це якийсь кеш. Але такий кеш, який знижує продуктивність ..

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

У будь-якому випадку , якщо у вас є 30 секунд затримки на оновлення 20 записів - це невдача в архітектурі програмного забезпечення (я помиляюся, якщо ваша БД обчислює перші 10 ^ 100 знаків PI для кожного запису).

Як я знаю, реляційна БД без потворних SQL-запитів, з індексами та з меншою кількістю 1 000 000 записів буде ідеально працювати майже для всіх запитів.

Спробуйте відмовитися від використання таблиці Bта додайте до своєї таблиці відповідні індекси A(у більшості сучасних баз даних є допоміжний інструмент). Далі: спробуйте оптимізувати структуру даних (таблицю A) та запиту (використовуючи аналізатор запитів або за допомогою SQL-експертів), щоб прискорити обчислення. Якщо ви оновите лише 20 записів - наявність індексів не зашкодить продуктивності процесу оновлення , але значно покращить швидкість вибору .


1

Питання справді полягає в тому, яка система обчислює запис, який потрібно вставити в B, і розмір даних B.

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

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

У 99% випадків, коли я бачу подібну проблему, це пояснюється тим, що запис B обчислюється збереженою програмою. Це покладає все навантаження на db-сервер

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

Таким чином, ваше оновлення Повідомлення запустить робочий процес, який проходить циклічно через користувачів та створить повідомлення оновлення B для кожного користувача

Другий робочий процес B збирає оновленого користувача X з даними. Подія створює запис B і оновлює БД

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

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


0

Якщо ви працюєте в Amazon, я вважав би DynamoDB. Це на основі флеш-пам'яті. Ось посилання на нього: https://aws.amazon.com/dynamodb/ .

Які види RDBMS ви використовуєте? Ви можете збільшити продуктивність, використовуючи UDF або обчислене поле у ​​поданні. Чи виконуєте ви обчислення в базі даних за допомогою одного запиту на оновлення, або вибираєте дані з бази даних, виконуєте обчислення в іншому процесі, а потім завантажуєте їх назад?

Oracle налаштовано за замовчуванням для використання режиму зйомки, тобто рядки не блокуються під час оновлення, а паралельні вибори отримують початкове значення. SQL Server налаштований за замовчуванням з песимістичною одночасністю, тому паралельний вибір буде заблокований до завершення оновлення. Деякі версії SQL Server можна перевести в режим знімків, однак це значно збільшує навантаження на таблицю темп.

У якому середовищі ти працюєш? Якщо це RDBMS на екземплярі EC2 в Amazon, то спробуйте помістити файли даних БД на локальний флеш-диск. Я бачив різницю в порядку перенесення файлів з EBS на локальний диск.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.