HighLoad в платформі для інтернет-магазинів автозапчастин

image

минулому топіку ми обіцяли розповісти про внутрішній устрій нашої платформи www.abcp.uk (SaaS рішення). Сьогодні ми розповімо про найцікавішому модулі платформи — складах для зберігання прайс-листів.

Як було на початку?

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

Для стримування продуктивності системи при зростанні даних ми провели багато програмних оптимізацій і навіть купили серйозну СГД Hewlett-Packard StorageWorks за 25 тисяч євро, куди помістили нашу базу MySQL (у розрахунку на високу швидкість роботи дискової системи), але цих поліпшень вистачало ненадовго, а час минав.

Як виявилося, етап стресу для нашої команди триватиме більше двох років. Якщо б ми знали реальні терміни розробки, це був би сильний удар по нашій мотивації. Але ми не знали :) Тому у нас все вийшло.

image

Вибір варіанта рішення

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

У той час про HighLoad ми знали лише те, що це дуже круто, що є якісь конференції на цю тему і в інтернеті повно цікавих статей. Було модно використовувати в проектах NoSQL рішення, говорити слова типу «шардінг» і все таке подібне. Також ми знали, що Oracle — це дуже потужна база даних, яка до того ж вміє масштабуватися і тому розглядали такий варіант.

Після довгих мук ми відкинули:

  1. Потужну субд Oracle. Т. к. це дорого і складно.
  2. Багато різних справжніх NoSQL. Оскільки на той момент вони були недостатньо надійними або не витримували вимог за змішаною навантаженні читання/оновлення.
У підсумку переміг звичний MySQL (innoDB). Перевірене рішення, безкоштовно, багато фахівців. На всі граблі ми вже з ним настали, тому для нашої команди ця СУБД була ідеальним для створення нової версії зберігання прайс-листів із заявленими характеристиками. Слово «шардінг» нам теж допомогло.

І ось що у нас вийшло

Нова система зберігання прайс-листів являє собою варіант розподілений на основі простих, недорогих і зрозумілих MySQL, які ми використовуємо в режимі NoSQL, тобто просто INSERT, UPDATE, DELETE, SELECT. Без всяких JOIN і з мінімальною кількістю умов WHERE.

image

На даний момент сервіс зберігає ~750 млн записів про товари. Протягом доби продавці повністю оновлюють третину інформації (~250 млн записів). Кількість операцій UPDATE приблизно в 10 разів більше, ніж кількість операцій SELECT. Швидкість заливки/оновлення прайсу в сервісі на даний момент становить 30000 позицій в секунду, що дозволяє оновити вищезазначені ~250 мільйонів за 10% добового часу.

Схема виглядає як еталонний приклад горизонтального масштабування БД, але, звичайно, всередині нової служби все набагато складніше. Для більш швидкого оновлення були розроблені і окремі модулі (теж у форматі шардинга) для конвертації «зоопарку» прайс-листів у еталонний формат, і окремі diff-служби, обчислюють різницю між прайс-листами (це працює швидше, ніж повне оновлення прайс-листа). Ще одним повністю виправдав себе рішенням стало впровадження в якості «серця» системи — сервера RabbitMQ. Саме використання асинхронних черг наштовхнуло нашу команду на ряд ідей, які дозволяють значно прискорити роботу системи.

Зрозуміло, ми досягли відмінних економічних показників. Приміром, якщо значно розширювати підсистему зберігання позицій на складах, то щомісячна собівартість зберігання/використання одного мільйона позицій складе ~100 рублів. Навіть при поточному курсі валюти.

Також, підбираючи найбільш оптимальне обладнання для створених модулів, ми отримали додатковий економічний виграш приблизно на 10-20%.

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

На сьогодні все, до зустрічі в наступному топіку!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.