В прошлом топике мы обещали рассказать о внутреннем устройстве нашей платформы www.abcp.ru (SaaS решение). Сегодня мы расскажем о самом интересном модуле платформы — складах для хранения прайс-листов.
Как было в начале?
Уже на второй год работы платформы мы столкнулись с растущими потребностями клиентов в объёмах строк прайс-листов, которые необходимо хранить в базе данных. На этот момент данные хранились просто в одной таблице обычного MySQL. Оказалось, что типичный магазин хочет подключить к своему магазину 7 миллионов позиций товаров, но не может платить больше 5000 рублей в месяц. Мы не были готовы к такому повороту ни технически ни экономически, поэтому сдерживали клиентов как могли, а в это время разрабатывали систему хранения, выдерживающую значительные объёмы данных (до 50 миллиардов записей).
Для сдерживания производительности системы при росте данных мы провели много программных оптимизаций и даже купили серьёзную СХД Hewlett-Packard StorageWorks за 25 тысяч евро, куда поместили нашу базу MySQL (в расчёте на высокую скорость работы дисковой системы), но этих улучшений хватало ненадолго, а время шло.
Как оказалось, этап стресса для нашей команды продлится более двух лет. Если бы мы знали реальные сроки разработки, это был бы сильный удар по нашей мотивации. Но мы не знали :) Поэтому у нас всё получилось.
Выбор варианта решения
Входные данные были такие: система должна хранить очень много записей (определили, что 50 миллиардов будет более чем достаточно), ежедневно может обновляться примерно половина этих данных. Необходимо добиться децентрализации в хранении данных и допускать частичную деградацию при проблемах с оборудованием.
В то время о HighLoad мы знали лишь то, что это очень круто, что есть какие-то конференции на эту тему и что в интернете полно интересных статей. Было модно использовать в проектах NoSQL решения, говорить слова типа “шардинг” и всё такое подобное. Также мы знали, что Oracle — это очень мощная база данных, которая к тому же умеет масштабироваться и поэтому рассматривали и такой вариант.
После долгих мучений мы отбросили:
- Мощную субд Oracle. Т.к. это дорого и это сложно.
- Много разных настоящих NoSQL. Т.к. на тот момент они были недостаточно надёжными либо не выдерживали требований по смешанной нагрузке чтение/обновление.
В итоге победил привычный MySQL (innoDB). Проверенное решение, бесплатно, много специалистов. На все грабли мы уже с ним наступили, поэтому для нашей команды эта СУБД была идеальным для создания новой версии хранения прайс-листов с заявленными характеристиками. Слово “шардинг” нам тоже помогло.
И вот что у нас получилось
Новая система хранения прайс-листов представляет собой распределённый вариант на основе простых, недорогих и понятных MySQL, которые мы используем в режиме NoSQL, т.е. просто INSERT, UPDATE, DELETE и SELECT. Без всяких JOIN и с минимальным количеством условий в WHERE.
На данный момент сервис хранит ~750 млн записей о продаваемых товарах. В течение суток продавцы полностью обновляют треть информации (~250 млн записей). Количество операций UPDATE примерно в 10 раз больше, чем количество операций SELECT. Скорость заливки/обновления прайсов в сервисе на данный момент составляет 30000 позиций в секунду, что позволяет обновить вышеупомянутые ~250 миллионов за 10% суточного времени.
Схема выглядит как эталонный пример горизонтального масштабирования БД, но, конечно, внутри новой службы всё гораздо сложнее. Для более быстрого обновления были разработаны и отдельные модули (тоже в формате шардинга) для конвертации “зоопарка” прайс-листов в эталонный формат, и отдельные diff-службы, вычисляющие разницу между прайс-листами (это работает быстрее, чем полное обновление прайс-листа). Ещё одним полностью оправдавшим себя решением стало внедрение в качестве «сердца» системы — сервера RabbitMQ. Само использование асинхронных очередей натолкнуло нашу команду на ряд идей, позволяющих значительно ускорить работу системы.
Разумеется, мы достигли отличных экономических показателей. К примеру, если значительно расширять подсистему хранения позиций на складах, то ежемесячная себестоимость хранения/использования одного миллиона позиций составит ~100 рублей. Даже при текущем курсе валюты.
Также, подбирая наиболее оптимальное оборудование для созданных модулей, мы получили дополнительный экономический выигрыш примерно на 10-20%.
Если вы разрабатываете проекты в области торговли автозапчастями, то можете использовать наше API для хранения прайс-листов и поиска по ним (доступ предоставляем по запросу).
На сегодня всё, до встречи в следующем топике!