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