Comments 59
Впечатляюще, отличная работа и анализ требований для результата!
Несколько миллионов уникальных товаров-вот это загнул, конечно)))
Ваши миллисекунды ничего не значат, когда для получения товара требуется три часа.
Это после того, как получено сообщение о том, что товар на точке выдачи, и покупатель уже приехал на эту самую точку.
Скорость работы сайта влияет на комфорт его использования. Когда ты ищешь в гугле конкретный шуруповерт, и открываешь деталку товара, если деталка не грузится 1-2 секунды, велика вероятность что ты закроешь вкладку и кликнешь на другую ссылку в гугле.
А время генерации страницы зависит от выполнения десятков запросов, и становится критичным чтобы конкретный запрос отвечал за столько то миллисекунд.
А вот это что-то новенькое! Обычные мантры, которую я привык выслушивать за последние пять лет в малом бизнесе, это «Кому нужен наш товар – спокойно подождут 10-15 секунд, пока не загрузится», «Подумаешь, 15 секунд, а вон у них страница товара за 30 секунд загружается», «Да кто там секунды считать будет, у всех так» и пр.
Ну про 1-2 секунды я наверное перегнул, но 10-15, в екоме связанном с едой и продуктами, это авария.
Наверное если товар уникальный, то действительно скорость работы сайта не так важна.
Нет, на самом деле про 1-2 секунды – не перегнули. Даже если товар уникальный. Мантры не мои, моё твёрдое убеждение как разработчика: страница с любым товаром должна грузиться максимум в пределах секунды. Кстати, в одной из компаний вопрос именно так и был поставлен: больше 1 секунды – это проблема, которую следует решать в срочном порядке.
10-15 секунд на этапе подбора товаров ждать ответа будут только отъявленные флегматики. Большинство будут пылать негодованием уже после 2-3-4 секунды
Скорость открытия страницы очень важна, когда бродишь по каталогу, подбирая одинаковые изделия от разных производителей таким образом, чтоб всё приехало в вовремя. Да возможно какой-то "помощник" помог бы, но пока всё приходиться делать ручками.
У вас с математикой проблемы:
300 000 запросов в минуту * 60* 24 = 430 млн запросов в сутки.
Откуда 5 млрд?
5 млрд карточек вроде, а не запросов.
Но все равно непонятно что это за единица карточка/сутки.
Может на тот момент у них требования были 300.000, а сейчас выросли больше...
Вообщем никаких ответов, только предположения.
Там нет соответствия 1 запрос - 1 карточка товара. Каталог это тоже набор карточек товаров в миниатюре. Там в одном запросе до 80 таких карточек может быть.
Особенно порадовало:
«Наш e-commerce-сайт за ~20 лет вырос из небольшого PHP-проекта в крупный монолит с несколькими миллионами уникальных товаров.»
«Одним из самых жестких требований к сервису было отдавать всю эту информацию в 99% случаев не более чем за 30 мс. При этом необходимо было иметь возможность хранить не менее 10 млн уникальных товаров и выдерживать в пике не менее 300 тысяч запросов в минуту»
Насколько миллионов это в любом случае меньше 10. Иначе говорят десятки миллионов.
Даже если у вас 9 млн. Товаров то они тупо влезают в ОЗУ. Если считать что карточка 4096 байт, то надо всего 38 Гб ОЗУ.
Вы взяли для тестов сервер с 32 Гб. ОЗУ и 8 CPU - возьмите 128 Гб ОЗУ и побольше процессоров и проблем не будет.
Ещё вопрос кто может генерить 5 млрд. Запросов в сутки?
Страница выдачи обычно не более 100 товаров.
Как правило меньше но-фиг с ним.
Допустим пользователь маньяк и готов просмотреть 100 страниц.
5 млрд /(10000)= 500 000 пользователей в сутки
которые шерстят списки товаров 24*7?
У Амазона 80-90 посетителей в сутки,
EBay - 20 млн.
Avito от 6 до 10 млн.
Вы пишите что у вас 1.6 млн уникальных посетителей в день. Что может быть правдой, но все равно не стыкуется с вашими данными по запросам.
Странные у вас данные…..
Не понимаю я ваших замечаний.
Я полагаю, что у них сейчас система способна обработать до 5 млрд запросов в сутки.
300к запросов в минуту - изначальное требование к системе.
То, что товары влезают в ОЗУ - так это сейчас они влезают. Добавятся новые данные, увеличится кол-во товаров, и всё, система не работает, нужно больше ОЗУ. Да и все равно останется инвалидация и прогрев.
Ну даже чтобы просто показать первые 100 товаров, надо все равно сформировать весь список согласно правлам выбранной сортировки, акции там на товары и тп маркетинг.
Боюсь, что 4кб на карточку товара будет маловато. Тут либо пытаться запихать карточку в требуемый объем, либо таки делать масштабируемую систему. Ребята пошли по второму пути, теперь рост объемов бизнеса не потребует срочного рефакторинга. Нормальный подход.
Почему маловато? В оперативке по сути храеятся указатели на атрибуты товара и их значение. Сильно объем может добавить название и описание товара, но это килобайта 2. Поэтому 4кб это прям очень расписанная карточка. К тому же это дело можно шардировать, чтобы распараллелить нагрузку. Объем на самом деле не большой по меркам текущей стоимости оперативки. Тем более это каталог товара, который редко меняется (в плане описания характеристик). В общем, если у вас 5 лярдов запррсов в сутки, то с серверами на 128 и 256 гигов вопросов не должно врзникнуть.
Ну смотрите, я отталкиваюсь от указанной в статье задачи сервиса: "Его задача — агрегировать информацию непосредственно о товаре (название, описание, технические характеристики, габариты, картинки и т. п.), наложить на эту информацию определенную бизнес-логику и отдать её фронту". Понимаю, что изображения - это ссылочный тип, но учитывая 2 байта на символ Unicode там и без того за 4кб карточка переедет легко. А еще на фронт ее, небось, в JSON надо отдавать (overhead не XML, конечно, но тоже немаленький). В общем, предположение о размере у меня выше 4 кб.
Шардирование - один из вариантов решения проблемы, но в случае шардирования все данные хранятся в "горячем" хранилище с конской стоимостью и еще перед ними стоит индексный маршрутизатор, являющийся точкой отказа, который тоже надо масштабировать. Есть и у шардирования проблемы.
На самом деле команда автора реализовала CQRS и совместила с кэшированием. Попали на eventual consistency, как и в любой событийной модели и решили задачу. Я бы, правда, решал ее через хэширование объектов и сравнение хэшей, чтобы не перечитывать ровно все данные из холодного хранилища в background-потоке. Быстрее синхронизация будет. Но на суть алгоритма не виляет, это - нюансы имплементации.
Ещё нашел данные
У Амазона около 12 млн «своих продуктов» и около 300-600 млн продуктов на маркетлейсе
Безос не звонил с предложением Вас купить?
в нашем случае в качестве шины синхронизации он оказался идеальным.
Мы обнаружили, что со временем данные в горячем хранилище разъезжаются с таковыми в холодном.
Идеальная синхронизация.
Мы обнаружили, что со временем данные в горячем хранилище разъезжаются с таковыми в холодном.
Почему возникла эта проблема если при изменении данных в холодном хранилище вызывается событие на обновление данных в горячем?
Видимо, было много точек изменения данных, не все покрыли хуками
да причин много может быть, от неправильной обработки эвентов, до пучка космических протонов попавших в регистры процессора). Мы так до конца и не победили это. Решение с реконсиляцией оказывается в нашем случае дешевле поиска и устранения всех причин
Можно, пожалуйста, пояснить, в чем была проблема положить весь каталог в оперативную память? 1 Тб не хватило?
Тогда не вышло бы написать сервис на go для кеширования. :)
Был у меня на эксплуатации такой проект, когда разработка весь каталог в память запихала... Сначала 20к единиц было.. всё летало.. потом 40к.. потом 60к.. всё вроде работало нормально, но стартовало очень долго..
А потом в одну прекрасную ночь проект взял и не запустился, потому что был зашит таймаут на ожидание данных в 10 минут, за которые данные не успевали прогрузиться из балы..
Разрабы крепко спят.. а ты ни чего сделать не можешь, так как откат резлиза тут уже не спасёт. В общем не считать оперативку - безлимитным хранилищем, куда всё можно положить.
стоимость/эффективность не дает)
странные у вас з/п программистов: https://www.dns-shop.ru/product/a3191630faebed20/operativnaa-pamat-kingston-fury-beast-black-kf432c16bbk264-64-gb/
Насчет прогрева. Используем ehcache в качестве кешей, самые критичные делаем персистенс на диске, очень хорошо помогает. Единственный неприятный момент, аппсервер (у нас java) падал пару раз из-за проблем с оперативной памятью, кеш не закрывался корректно, и при следующем запуске по факту его не было.
Для го есть https://github.com/olric-data/olric . Но мы как то пока не решились отказаться от персистентного хранилища.
Я немного о другом, у Ehcache есть возможность настроить трех-уровневое кеширование включая уровень холодного хранения: https://www.ehcache.org/documentation/3.11/tiering.html
Очень удобная вещь. Надо только грамотно реализацию сериализатора сделать.
Напомнило обсуждение штатовского McMaster. https://avva.livejournal.com/3696656.html
Интересная статья и знакомые страдания. У меня у самого сто раз было такое, что вроде бы простые вещи требуют нереальных наворотов. Однако потом часто оказывается, что изобретал велосипед и нужно все переделывать) В статье ничего не сказано про изучение существующего опыта, а ведь eBay и Amazon уже все это проходили в больших масштабах, и наверняка инфа об их архитектурах открытая
Скажите, пожалуйста, был ли анализ применения иерархических баз данных типа ключ - значение? Парк зеркальных серверов такого типа мне кажется решил бы проблему? Такие БД, как правило, хранят актуальные данные в кеше. У вас действительно 5 000 000 000 товарных позиций?
Нет не было. Ну и мне кажется все широко распространённые актуальные БД (постгрес, мускул и т.п.) при достаточных объемах выделенного ОЗУ могут засунуть все данные в кеш. Тут другой вопрос, что любое сетевое взаимодействие это очень медленно по сравнению с походом в память). Мы проводили эксперимент где в качестве кеша использовали 2 ноды мемкеша и в памяти процесса ничего не хранили. Время ответа выросло в среднем в 6.6 раза, а в 99 перцинтиле в 17 раз.
Ни постгресс, мускул не идут ни в какое сравнение с иерархическими БД ключ - значение. Эти базы не транзакционны и быстры на много порядков. При этом у их есть накат журналов изменений. Инициация сетевого обмена - проблема, только в том случае, если БД не имеет пула готовых к коннекту соединений и инициирует новый процесс в ОС. Эта проблема давно решена (созданием пула соединений). Мой Вам совет - ройте в направлении иерархичных БД. Классически случай Cache (но он за деньги). Сейчас есть Йота DB. Пробуйте - уверен - это сработает.
у нас более миллиона товаров доступных к продаже, и раза в 4 больше всех остальных.
5ккк это сколько карточек товаров формирует сервис за одни сутки
Вы пишете что у вас более 10 млн товаров, теперь количество товаров упало до 1 млн. - в 10 раз. При этом у вас откуда-то 5 млрд карточек который надо в сутки показать.
При этом, в Т.З было 300 тыс запросов в минуту на максимуме - то похоже тоже перебор.
Откуда у вас цифры порядка миллиардов???
10 млн товаров это по ТЗ нефункциональные требования. Сейчас уникальных SKU которые можно зайти на сайт и купить сильно больше 1 млн. Даже ближе к 2 млн. Всего уникальных SKU про которые "знает" сервис примерно в 3 раза больше того что можно сейчас купить.
На сервис поступает в пике 300к запросов в минуту. В одном запросе может быть требование выдать карточки товара как для 1го товара так и для например 80. Из этого и прилучается, что сервис за сутки всего формирует 5млрд карточек товара.
Я уже писал выше:
У вас с математикой проблемы:
300 000 запросов в минуту * 60* 24 = 430 млн запросов в сутки.
10 млн товаров / 300000 запросов /мин = 33 минуты
Всю вашу базу за пол часа высосут.
Вы пишите что в запросе от 1 до 80 карточек, пусть будет 100.
Тогда чтобы 5 млрд карточек скачать надо:
5 млрд /100 = 50 млн запросов.
Откуда у вас столько пользователей чтобы сгенерить 50 млн запросов?
У wildberris вроде как 50 млн пользователей. Не думаю что 50 млн пользователей каждый день в магазине что-то ищут.
Статью только переименовать. Какие карточки ? Языковые типа anki ? Лично мне слово карточка в первую очередь вызывает ассоциацию с банковскими продуктами - дебетовыми или кредитными картами. Ну, край, могли быть карточки лояльности.
У каждого своя профдеформация
Можно конечно и на Феррари в магазин ездить - она мощнее и быстрее, но Тойота - для этого дела подходит так же хорошо и даже лучше.. Поэтому в качестве промежуточной базы - у нас Эластик и никаких - велосипедов)) Не нужно вам 300мкс
Как мы обслуживаем 5 млрд карточек в сутки с задержкой меньше 1 мс