Передумови :
я створив веб-додаток, який хотів би мати можливість досить масштабувати. Я знаю, що я не Google або Twitter, але мій додаток використовує досить великий об'єм даних для кожного користувача і, таким чином, має досить високі вимоги до даних. Я хочу бути готовим до масштабування досить добре, не пізніше переробляти все пізніше.
Я вважаю себе розробником програмного забезпечення, а не експертом по базі даних. Тому я розміщую тут. Сподіваюся, хтось із значно більшим досвідом роботи з базами даних може дати мені поради.
Маючи відносно велику кількість користувачів, але нічого подібного до номерів у Facebook, я очікую, що у вас є БД, який виглядає так:
Один "Великий стіл":
- 250 мільйонів записів
- 20 стовпців
- Приблизно 100 ГБ даних
- Має індексований іноземний ключ bigint (20)
- Має індексовану колонку varchar (500) string_id
- Має стовпець "значення" int (11)
4 інші таблиці:
- По 10 мільйонів записів кожен
- Приблизно 2 - 4 ГБ даних кожен
- кожна з цих таблиць має 4 - 8 стовпців
- один стовпчик - дата-дата_створене
- один стовпець - це колонка varchar (500) string_id
- один або два стовпчики з кожної з цих таблиць будуть вибрані в об'єднанні
Одна з цих таблиць використовується для зберігання середніх значень - її схема - bigint (20) id, varchar (20) string_id, datetime date_create, float prose_value
Що я хочу зробити - два відносно дорогі запити:
Обчисліть нові середні значення:
- За допомогою іноземного ключа виберіть до великої таблиці до декількох мільйонів окремих записів.
- Обчисліть нове середнє, групуючи по string_id.
- Вставте результати в таблицю середніх значень.
- Як створено в даний час, цей запит використовує два об'єднання.
Створюйте денормовані записи, які доступні лише для читання для обслуговування користувачів:
- Використовуйте іноземний ключ, щоб вибрати з великого столу десь 1000-1000 записів.
- Об’єднайтеся з кожною з інших чотирьох таблиць у найновішому записі за допомогою стовпця "id".
- Вставте результати в денормалізовану таблицю.
- Ці записи призначені для використання в передній частині для відображення інформації для користувачів.
- Як створено в даний час, цей запит використовує чотири приєднання.
Я планую запустити кожен із цих дорогих запитів на пакетній базовій базі даних, яка підштовхне його результати до сервера БД в реальному часі, який обробляє запити користувачів. Ці запити будуть виконуватись через рівні проміжки часу. Я не вирішив, як часто. Середній запит можна робити, можливо, раз на день. Запит на денормалізацію повинен бути частішим - можливо, кожні кілька хвилин.
Кожен з цих запитів в даний час виконується за кілька секунд у MySQL на дуже низькій версії машини із набором даних із 100 К-записами у "великій таблиці". Мене хвилює як моя здатність до масштабування, так і витрати на масштабування.
Запитання :
- Чи здається цей підхід здоровим? Чи є щось очевидно з цим з точки зору великої картини?
- Чи RDBMS - це правильний інструмент, чи я повинен дивитись на інші рішення "великих даних", як на щось із сімейства Hadoop? Моя схильність - використовувати RDBMS, оскільки дані структуровані і добре вписуються у реляційну модель. Але в певний момент я розумію, що я більше не можу використовувати RDBMS. Це правда? Коли цей комутатор знадобиться?
- Чи буде це працювати? Чи можуть ці запити виконуватись у розумний проміжок часу? Я можу зачекати, можливо, години на запит №1, але запит №2 повинен закінчитися за лічені хвилини.
- Що я повинен розглянути з точки зору обладнання? Якими можуть бути вузькі місця оперативної пам’яті та процесора? Я вважаю, що важливо зберігати індекси в оперативній пам'яті. Чи є ще щось, що я повинен розглянути?
- В якийсь момент мені, мабуть, доведеться розділити свої дані та використовувати декілька серверів. Чи здається, що мій випадок використання вже є в цій категорії, чи мені вдасться деякий час вертикально масштабувати одну машину? Чи буде це працювати з 10-кратними даними? 100x?