За останні 20 років я бачив декілька великих модульних конструкцій баз даних, і досить часто бачив сценарій, запропонований Девідом, коли програми мають доступ для запису до власної схеми / набору таблиць і читають доступ до іншої схеми / набір таблиць. Найчастіше ці дані, до яких програма / модуль отримує доступ лише для читання, можуть бути описані як "головні дані" .
У той час я не бачив проблем, які попередні відповіді підказують, що я мав би їх бачити, тому думаю, що варто детальніше ознайомитися з питаннями, висунутими в попередніх відповідях.
Сценарій: ви прив’язуєте пару компонентів до RDBMS безпосередньо, і ви бачите, що один конкретний компонент стає продуктивним вирізом
Я погоджуюся з цим коментарем, за винятком того, що це також аргумент для того, щоб мати копію даних на локальному рівні для мікросервісу для читання. Тобто, більшість зрілих баз даних підтримують реплікацію, і тому, без будь-яких зусиль розробника, "головні дані" можуть бути фізично копійовані до бази даних мікросервісу, якщо це потрібно чи потрібно.
Деякі можуть розпізнати це в старій формі як "база даних підприємств", що реплікує основні таблиці на "відомчу базу даних". Справа в тому, що в цілому добре, якщо база даних робить це для нас із вбудованою реплікацією змінених даних (лише дельтати, у двійковій формі та з мінімальними витратами на вихідну базу даних).
І навпаки, коли наш вибір бази даних не дозволяє це підтримка реплікації "з полиці", тоді ми можемо потрапити в ситуацію, коли ми хочемо підштовхнути "майстерні дані" до баз даних мікросервісу, і це може призвести до значних зусиль розробника та також бути суттєво менш ефективним механізмом.
можливо, ви хочете денормалізувати базу даних, але ви не можете, оскільки це вплине на всі інші компоненти
Для мене це твердження просто невірне. Денормалізація - це "адитивна" зміна, а не "руйнівна зміна", і жодна заявка не повинна порушуватися через денормалізацію.
Єдиний спосіб цього розбиття програми полягає в тому, що код програми використовує щось на кшталт "select * ..." і не обробляє зайвий стовпець. Для мене це буде помилка в додатку?
Як денормалізація може порушити програму? Мені це здається FUD.
Залежність схеми:
Так, програма зараз залежить від схеми бази даних, і це означає, що це повинно бути головною проблемою. Хоча додавання будь-якої додаткової залежності, очевидно, не є ідеальною, я відчуваю, що залежність від схеми бази даних не була проблемою, і чому це могло бути так? Невже мені пощастило?
Основні дані
Схема, до якої ми, як правило, хочемо, щоб мікросервіс мав доступ лише для читання, - це найчастіше те, що я б назвав " головними даними " для підприємства. У ньому є основні дані, які є важливими для підприємства.
Історично це означає, що схема, від якої ми додаємо залежність, є і зрілою, і стабільною (дещо фундаментальною для підприємства та незмінною).
Нормалізація
Якщо 3 дизайнерів баз даних перейдуть і спроектують нормалізовану схему db, вони опиняться в одній конструкції. Гаразд, може бути певна варіація 4NF / 5NF, але не дуже. Більше того, існує ряд питань, які дизайнер може задати, щоб підтвердити модель, щоб дизайнер міг бути впевненим, що вони потрапили до 4NF (я занадто оптимістичний? Чи люди намагаються потрапити до 4NF?).
оновлення: Під 4NF тут я маю на увазі, що всі таблиці в схемі дісталися до їх найвищої нормальної форми до 4NF (усі таблиці нормалізувались до 4NF).
Я вважаю, що процес проектування нормалізації є причиною, чому дизайнерам баз даних, як правило, притаманна ідея залежно від нормалізованої схеми бази даних.
Процес нормалізації приводить конструкцію БД до відомої "правильної" конструкції, і відхилення від цього повинні бути денормалізацією для продуктивності.
- Можливі варіанти на основі типів БД, що підтримуються (JSON, ARRAY, підтримка типу Geo тощо)
- Деякі можуть заперечити варіацію на основі 4NF / 5NF
- Ми виключаємо фізичні зміни (тому що це не має значення)
- Ми обмежуємо це дизайном OLTP, а не дизайном DW, оскільки це схеми, до яких ми хочемо надати доступ лише для читання
Якби 3 програмісти, де їм було призначено реалізувати (як код), очікування було б для 3-х різних реалізацій (потенційно дуже різних).
Для мене потенційно виникає питання "віри в нормалізацію".
Порушення змін схеми?
Денормалізація, додавання стовпців, зміна стовпців для більшого зберігання, розширення дизайну новими таблицями тощо - це все безперебійні зміни, і дизайнери БД, які дісталися до 4-ї нормальної форми, будуть впевнені в цьому.
Порушення змін, очевидно, можливе шляхом відміни стовпців / таблиць або внесення змін у тип перерви. Можливо, так, але на практиці я взагалі не відчував жодних проблем. Можливо, тому, що зрозуміло, що таке переломні зміни, і ці вдало вдалися?
Мені буде цікаво почути випадки порушення змін схеми в контексті спільних схем лише для читання.
Що важливіше та найважливіше у мікросервісі: його API чи його базі даних? API, тому що це його договір з рештою світу.
Хоча я згоден з цим твердженням, я думаю, що є важливий застереження, який ми можемо почути від Enterprise Architect, який є "Дані живе назавжди" . Тобто, хоча API може бути найважливішим, дані також є досить важливими для підприємства в цілому, і це буде важливо дуже довго.
Наприклад, коли виникає вимога заповнити сховище даних для бізнес-аналізу, то схема та підтримка CDC набувають важливого значення з точки зору ділової звітності незалежно від API.
Проблеми з API?
Тепер, якщо API були ідеальними та легкими, усі пункти суперечать, оскільки ми завжди обирали API, а не локальний доступ лише для читання. Таким чином, мотивація навіть для розгляду локального доступу лише для читання полягає в тому, що можуть виникнути деякі проблеми з використанням API, який уникає локальний доступ.
What motivates people to desire local read-only access?
Оптимізація API:
LinkedIn провели цікаву презентацію (з 2009 р.) Щодо оптимізації їх API та чому це важливо для них в їх масштабі. http://www.slideshare.net/linkedin/building-consistent-restful-apis-in-a-highperformance-en Environment
Коротше кажучи, коли API повинен підтримувати безліч різних випадків використання, він може легко потрапити в ситуацію, коли він підтримує один варіант використання оптимально, а решта досить погано з точки зору мережі та з точки зору бази даних.
Якщо API не має тієї самої складності, як LinkedIn, то ви можете легко отримати сценарії, де:
- API отримує набагато більше даних, ніж потрібно (марно)
- API Chatty API, куди вам доведеться дзвонити API багато разів
Так, ми можемо додати кешування API звичайно, але в кінцевому підсумку виклик API - це віддалений виклик, і існує ряд оптимізацій, доступних розробникам, коли дані локальні.
Я підозрюю, що там є набір людей, які можуть додати його як:
- Низька реплікація основних даних у базу даних мікросервісу (без витрат на розробку та технічно ефективна)
- Віра в нормалізацію та стійкість програм до змін схеми
- Можливість легко оптимізувати кожен випадок використання та потенційно уникнути балакучих / марнотратних / неефективних віддалених дзвінків API
- Плюс ще деякі переваги з точки зору обмежень та узгодженого дизайну
Ця відповідь задовго вийшла. Вибачення !!