Разработка временных хранилищ данных

Question

У меня есть приложение для очистки веб-страниц. Пользователи инициируют «отчеты» - какие точки данных они хотели бы очистить. Точки данных могут быть как 1, так и 100 000 точек данных. Многие пользователи инициируют эти отчеты. Множество сканирующих серверов сканируют точки данных. Затем эти точки данных отправляются на центральный сервер (ы). Центральные серверы собирают все точки данных и когда собираются все (достаточные) точки данных для отчета, отчет (excel) генерируется и доставляется клиенту.

Теперь нам нужно хранить данные для хранения отдельных точек данных при их обходе. Затем, когда обход завершен, нам нужно запросить все эти точки данных и построить отчет. Отчет является конечным продуктом, и как только отчет создается, нам не нужно хранить обходные данные; по крайней мере, для обслуживания потребностей клиентов. Сторона примечания: обходные данные архивируются в хранилище данных.

В настоящее время мы используем SQL для хранения этих обходных точек данных при просканировании. Процесс: Дамп всех данных crwaling в SQL -> Когда завершение обхода завершено, что может занять до нескольких часов, верните данные обхода, относящиеся к отчету SQL -> Очистить SQL, например, чистку старше x дней данных. Сервер SQL работает с проблемами масштабируемости - слишком много обходных точек данных. Мы получаем около 100 М данных в день; каждая запись нескольких КБ. Так что это около 400 ГБ данных в день.

Таким образом, мы исследовали несколько вариантов, и было бы полезно получить некоторые комментарии на них:

1. магазин обходов данные в локальном файле CSV. По завершении обхода прочитайте файл CSV для создания отчета. Недостатком является то, что он создает единую точку отказа; сервер, на котором хранятся данные обхода , может спуститься и взять уже обходные данные с .
2. Замените SQL одной из технологий больших данных; хранить данные об обходах в одном из следующих
   • AWS RedShift: запрос на получение данных отчета легко при создании отчета. Я склоняюсь к этому.
   • Большой стол: вставки просты; но учитывая, что это хранилище для ключей, : насколько легко было бы получить 100K или около того отдельных записей назад из базы данных, когда пришло время для создания отчета?
   • DynamoDB
3. Хранить ползать данные в файл в каком-нибудь файловом сервере

Answer 1

Вы можете хранить данные в Кассандре, а затем ETL данные в Redshift и построить приложение отчетности против Redshift. Таким образом, вы гарантируете отсутствие единой точки отказа при проглатывании данных, а также гибкость форматирования или переноса данных через ETL.

Thanks, Jayadeep