Как оптимизировать работу парсера для обработки большого объема отзывов с маркетплейса и хранения данных в базе объемом 450 ГБ? Как справиться с возможными проблемами масштабирования и эффективно обеспечить добавление отзывов в базу данных при использовании множества воркеров? Предложение использования других технологий для хранения данных, таких как PostgreSQL, партицирование, шардинг или репликация, их преимуществ и недостатков в сравнении с MySQL. Какие аспекты нужно учитывать при выборе оптимального стека технологий для данной задачи?
1. Выбор наилучшей архитектуры для парсинга маркетплейса: - Использование асинхронных библиотек или фреймворков, таких как Scrapy, для параллельной обработки запросов и увеличения производительности. - Оптимизация кода парсера для минимизации времени обработки каждого элемента страницы и улучшения скорости парсинга. - Использование кэширования данных для уменьшения количества запросов к маркетплейсу и ускорения работы парсера. - Работа с API маркетплейса, если доступен, для получения данных более эффективным способом. 2. Оптимизация работы с большим объемом данных и хранение в базе объемом 450 ГБ: - Использование индексации для быстрого поиска и доступа к данным. - Оптимизация запросов к базе данных для минимизации нагрузки на сервер и увеличения производительности. - Разграничение данных по временным или другим признакам для уменьшения размера таблиц и улучшения производительности. - Использование дополнительных технологий, таких как кэширование данных или использование специализированных хранилищ данных для оптимального хранения и доступа к данным. 3. Проблемы масштабирования и эффективное добавление отзывов в базу при использовании множества воркеров: - Использование распределенной архитектуры для запуска нескольких воркеров парсера параллельно. - Разделение задач парсинга и записи данных для ускорения процесса и уменьшения конфликтов при одновременной записи. - Мониторинг работы воркеров и оптимизация процесса для улучшения производительности и стабильности работы. 4. Выбор технологий для хранения данных: - PostgreSQL может быть более подходящим выбором для работы с большими объемами данных и увеличением производительности в сравнении с MySQL. - Партицирование данных поможет улучшить производительность запросов к базе данных и оптимизировать распределение данных. - Шардинг позволит распределить данные по нескольким серверам для улучшения производительности и масштабируемости. - Репликация данных обеспечит надежность и отказоустойчивость базы данных, позволяя масштабировать приложение при увеличении объема данных. При выборе оптимального стека технологий для данной задачи необходимо учитывать следующие аспекты: производительность, масштабируемость, отказоустойчивость, надежность, удобство использования, стоимость поддержки и развития, совместимость с другими инструментами и технологиями, а также возможность интеграции с существующей инфраструктурой.
100к событий в секунду с торговой платформы это сюр, такое практически нереально, (ну может в самый первый раз когда база пустая).
С высокой вероятностью там так - вы собираете в секунду 100к информационных единицы (отзывы, товары, ..) но в базе из них обновить и добавить считанные процент из этого, и вот в этот момент есть способы как оптимизировать, например перенести обработку из медленной базы данных (медленные они, потому что универсальные и транзакционные) в оперативную память.
Типовой пример - модуль, который собирается загружать данные по какому то классу информации, может определить, с какой частью данных в базе это пересекается, выгрузить их все (пока данных не миллионы - это оправдано) в оперативную память и проводить сравнение прямо во время загрузки, отправляя в базу только важные данные.
Отсюда архитектура - отдельно дубовые парсеры-загрузчики (их можно размещать буквально где угодно, они получают команду на загрузку и молотят, выдавая json-чики пакетами в виде результата), отдельно узлы-обработчики, которые на каждый пакет данных от загрузчиков делает нужные запросы в базу данных (или заранее кеширует в памяти, но тут нужно считать, что дешевле - апгрейдить сервер базы данных или держать на дисках кеш-дампы запросов и обновлять их параллельно БД, в этом случае кстати БД остается как конечное хранилище и аналитики). Ну и про базу данных, они на запись медленные только если там индексы распиханы по максимуму, хороший способ, если загрузка в базу редкая (например раз в сутки длится час) то можно отключить на это время индексы, провести загрузку, вернуть индексы - это кратно ускоряет процесс ЗАГРУЗКИ но не проверки целостности и поиск данных, т.е. подходит именно когда анализ проводится не в БД.
В общем разделять нужно задачи - загрузки данных, сохранение данных, и аналитические запросы по этим данным - каждая из этих задач требует свой способ хранения данных и организации индексов, если все пытаться мешать в одно место - будут затыки и тормоза.
p.s. у меня крутился сервис, годами собирающий терабайты данных на скорости 4к-10к событий в секунду (time series), хранить это в классической базе я не стал, а организовал хранилище на файлах, поверх которых в базе данных собирается аггрегированная выжимка и индексы.
Это было оправдано, так как разработка аналитического сервиса шла уже в процессе загрузки и это была суть работы, т.е. нельзя заранее определить, что из этих данных и как может понадобиться, база данных строилась каждый раз под задачу, проходом по всем данным (больше времени занимала их распаковка - json с упаковкой zstd)