Компромисс между скоростью поиска и стоимостью хранения данных для больших текстовых данных
У меня есть AWS EC2 инстанс, я пытаюсь найти компромисс между скоростью поиска в файлах и стоимостью хранения. Я управляю большими объемами текстовых данных (~350 ГБ в файлах .txt), которые хранятся на жестком диске Amazon st1 HDD. Этот вариант является бюджетным, но существенно плохо влияет на скорость поиска.
Для сравнения, я использовал ripgrep для поиска текста, и мне потребовалось около 18 часов, чтобы ripgrep прошелся по всем файлам на диске st1 - это чрезвычайно долго. Ожидается, что эти поисковые запросы будут инициироваться одним пользователем несколько раз в неделю.
Одно из решений, о котором я подумал, заключается в том, чтобы во время поисковых запросов, программно обновлять диск st1 до SSD накопителя gp3 с помощью AWS SDK для повышения производительности. Поиск ripgrep на обновленном SSD занимает около 20 минут, что значительно быстрее по сравнению с диском st1. После я могу понизить диск до уровня st1, когда поиск будет завершен. Стоимость такого обновления до SSD составит $0,38 за 6 часов, что не дорого, а сам процесс масштабирования накопителя занимает около 12 минут. Однако у этого плана есть проблема: AWS разрешает только одно изменение диска каждые 6 часов. Представьте себе сценарий, когда диск только что был понижен, и сразу после этого пользователь запрашивает новый поиск - тогда он будет вынужден ждать 6 часов, прежде чем диск будет улучшен до SSD чтобы начать ускоренный поиск.
Ранее я экспериментировал с созданием инвертированного индекса для повышения скорости поиска. Но, к сожалению, это оказалось весьма неэффективным для меня - при использования индекса, операции поиска подстроки были примерно в 100 раз медленнее по сравнению с использованием ripgrep.
Более того, я рассматривал возможность использования Amazon RDS с PostgreSQL для управления и поиска в моих данных, но у меня огромный объём данных - миллиарды записей. Такой подход был бы непомерно дорогим для моего бюджета.
Поэтому я оказался в затруднительном положении. Я ищу решение, которое оптимально сбалансирует стоимость и скорость поиска без дорогостоящих управляемых баз данных или неэффективных методов индексирования. Как вы думаете, является ли мое решение наилучшим из возможных? Буду очень признателен любым воображениям!