Як така компанія, як Amazon, уникає вузьких місць доступу до рівня бази даних?

Якщо ви уявляєте таку компанію, як Amazon (або будь-який інший великий веб-додаток для електронної комерції), який працює в інтернет-магазині в масових масштабах і має лише обмежену кількість фізичних предметів на своїх складах, як вони можуть оптимізувати це так, щоб його не було єдине вузьке місце? Звичайно, вони повинні мати ряд баз даних з реплікацією та багато серверів, які самостійно обробляють навантаження. Однак якщо декілька користувачів обслуговуються окремими серверами і обидва намагаються додати один і той же товар у свій кошик, для якого залишився лише один, для кількості, що залишилася для цього товару, повинно бути якесь "джерело істини". Чи не означає це, що принаймні всі користувачі, які отримують доступ до інформації про продукт для одного елемента, повинні запитувати одну і ту ж базу даних послідовно?

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

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

Не зовсім. Це не проблема, яка потребує 100% ідеального технічного рішення, оскільки обидва випадки помилок мають бізнес-рішення, яке не дуже дороге:

• Якщо ви неправильно сказали користувачеві, що товар проданий, ви втрачаєте продаж. Якщо ви продаєте мільйони предметів щодня, і це може статися один-два рази на день, він губиться від шуму.
• Якщо ви приймаєте замовлення і обробляючи його, виявите, що товар у вас закінчився, ви просто повідомте замовнику так і даєте їм можливість чекати, поки ви зможете відновити або скасувати замовлення. У вас є один злегка роздратований клієнт. Знову ж не велика проблема, коли 99,99% замовлень справно працюють.

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

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

Поєднання

• хешування
• заточування
• тиражування
• розповсюдження
• високий провал
• магазини ключових цінностей

Немає ніякої магії, просто все більш складні ситуації. Як і DNS, він зроблений для масштабування.

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

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

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

Очевидно, що "малоцінні" позиції є проблематичними

• Предмети з високим рівнем запасів

Не турбуйтеся перевіряти рівень акцій. Просто розмістіть замовлення

• Предмети з низьким рівнем запасів

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

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

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

Під час великих навантажень, таких як продажі, ви навіть можете вимкнути перевірку запасів і пізніше просто надіслати клієнтам електронну пошту:

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

У цьому відео Мартін Фаулер обговорює бази даних NoSQL:

https://www.youtube.com/watch?v=qI_g07C_Q5I

Один із моментів (десь там) полягає в тому, що такі місця, як Амазонка, вважають за краще радіти 99% людей, приймаючи їх замовлення, не маючи змоги перевірити "напевно", чи є він насправді доступним, і, можливо, дратують дуже невеликий відсоток, маючи сказати "вибачте, схоже, що хтось побив вас на це".

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

(До речі, це чудове відео, якщо вам цікаво NoSQL)