• XSS.stack #1 – первый литературный журнал от юзеров форума

Подскажите решение для поиска строк из огромного количества данных

Отслеживать

TOPCHEK

Bruteforce
Пользователь
Регистрация
25.12.2022
Сообщения
311
Решения
2
Реакции
314
Гарант сделки
1
Для простого понимания что я ищу, возьму пример https://haveibeenpwned.com/Passwords или https://haveibeenpwned.com/ там содержится несколько миллиардов строк, базы могут весить более 1 ТБ.
И на удивление, поиск занимает около 1 секунды. Даже не 10 секунд, не минуту, а около 1-2 сек.
Так вот. Кто знает такое решение? Это кастомная разработка или уже готовая система поиска? Ведь если с нуля разрабатывать на любом ЯП данный поиск, то он в любом случае будет занимать более чем 1 секунду поиска. А здесь ровно 1-2 сек отклик на запрос.
Буду благодарен за любую полезную информацию.
 
как веб разраб скажу что проект достигает высокой скорости поиска благодаря хранению хэшированных (хэши быстрее сравнить чем сами пароли) паролей, оптимизированным структурам данных, распределенной инфраструктуре и возможному кэшированию. Разрабы также могли провести оптимизацию кода, обеспечивая быстрый отклик на запросы в огромных базах данных.
 
hackeryaroslav сказал(а):
как веб разраб скажу что проект достигает высокой скорости поиска благодаря хранению хэшированных (хэши быстрее сравнить чем сами пароли) паролей, оптимизированным структурам данных, распределенной инфраструктуре и возможному кэшированию. Разрабы также могли провести оптимизацию кода, обеспечивая быстрый отклик на запросы в огромных базах данных.
Ясно. Спасибо за ответ. Что на счёт помимо поиска ещё и вывод строк которые требуется найти?
Например совмещать поиск по почтам + пароли. Вводим почту - выводятся все пароли от неё. Тут уже немного другой алгоритм поиска будет. Но скорости абсолютно те же.
 
TOPCHEK сказал(а):
Ясно. Спасибо за ответ. Что на счёт помимо поиска ещё и вывод строк которые требуется найти?
Например совмещать поиск по почтам + пароли. Вводим почту - выводятся все пароли от неё. Тут уже немного другой алгоритм поиска будет. Но скорости абсолютно те же.
не жалко было чуть времени потратить на твой вопрос, подробно распишу:
  1. Данные хранятся в базе данных Elasticsearch. Это распределенная поисковая система, оптимизированная для быстрого full-text поиска и анализа больших объемов данных. Она позволяет делать миллионы запросов в секунду.
  2. Данные индексируются в Elasticsearch таким образом, чтобы поиск по хешам паролей и email был максимально быстрым. Используются перевернутые индексы и другие структуры для оптимизации.
  3. Для ускорения поиска используется кэширование на нескольких уровнях - в самом Elasticsearch, а также в frontend части с помощью Redis и Varnish. Это в свою очередь позволяет снимать нагрузку с базы данных.
  4. Весь стек технологий (Elasticsearch, базы данных, веб-сервисы) масштабируется горизонтально на несколько серверов, что позволяет распределить нагрузку и увеличить производительность.
Ну если коротко то это просто комбинация готовых решений (Elasticsearch) и custom оптимизаций специально под задачи этого проекта.

Реализовать такую же производительность с нуля на обычном языке программирования будет сложно, но нет ничего невозможного, верно?)) Потребуются распределенные базы данных, кэширование, оптимизации структур данных и алгоритмов поиска. Лучше использовать готовые решения вроде той же Elasticsearch.

Что касается поиска по почте и вывода связанных паролей - здесь тот же принцип. Данные структурируют и индексируют оптимальным образом для быстрого поиска, используют кэширование и масштабирование для производительности. Реализация не тривиальна, но возможна с готовыми решениями для поиска и хранения больших данных. Фухх, если где то ошибся, подправьте
 
hackeryaroslav как я понимаю, это веб-разработка? Искать программистов направленных на веб надо для работы с Elasticsearch? И где лучше искать их?
 
TOPCHEK сказал(а):
hackeryaroslav как я понимаю, это веб-разработка? Искать программистов направленных на веб надо для работы с Elasticsearch? И где лучше искать их?
да, ты прав. А вот с их поисками помочь наврятли смогу помочь.
 
Для работы с огромным массивом данных рекомендую посмотреть в сторону опенсорсного решения от Яндекс - ClickHouse. Очень быстрая СУБД. От почты берите хеш и индексируйте его.
 
TOPCHEK сказал(а):
Для простого понимания что я ищу, возьму пример https://haveibeenpwned.com/Passwords или https://haveibeenpwned.com/ там содержится несколько миллиардов строк, базы могут весить более 1 ТБ.
И на удивление, поиск занимает около 1 секунды. Даже не 10 секунд, не минуту, а около 1-2 сек.
Так вот. Кто знает такое решение? Это кастомная разработка или уже готовая система поиска? Ведь если с нуля разрабатывать на любом ЯП данный поиск, то он в любом случае будет занимать более чем 1 секунду поиска. А здесь ровно 1-2 сек отклик на запрос.
Буду благодарен за любую полезную информацию.
постораюсь чотка без воды.
- посаветевлся бы с профи логаводами.
- искал бы решание на базе No-SQL,конкретние Redis, блогадаря хронение многово в оперативе он шустри.
- если лень (совсем) то какойта эластик в контейнере будет не плох
- ну если прям кровь из носа надо сйчас тогда GREP.
 
hackeryaroslav сказал(а):
не жалко было чуть времени потратить на твой вопрос, подробно распишу:
  1. Данные хранятся в базе данных Elasticsearch. Это распределенная поисковая система, оптимизированная для быстрого full-text поиска и анализа больших объемов данных. Она позволяет делать миллионы запросов в секунду.
  2. Данные индексируются в Elasticsearch таким образом, чтобы поиск по хешам паролей и email был максимально быстрым. Используются перевернутые индексы и другие структуры для оптимизации.
  3. Для ускорения поиска используется кэширование на нескольких уровнях - в самом Elasticsearch, а также в frontend части с помощью Redis и Varnish. Это в свою очередь позволяет снимать нагрузку с базы данных.
  4. Весь стек технологий (Elasticsearch, базы данных, веб-сервисы) масштабируется горизонтально на несколько серверов, что позволяет распределить нагрузку и увеличить производительность.
Ну если коротко то это просто комбинация готовых решений (Elasticsearch) и custom оптимизаций специально под задачи этого проекта.

Реализовать такую же производительность с нуля на обычном языке программирования будет сложно, но нет ничего невозможного, верно?)) Потребуются распределенные базы данных, кэширование, оптимизации структур данных и алгоритмов поиска. Лучше использовать готовые решения вроде той же Elasticsearch.

Что касается поиска по почте и вывода связанных паролей - здесь тот же принцип. Данные структурируют и индексируют оптимальным образом для быстрого поиска, используют кэширование и масштабирование для производительности. Реализация не тривиальна, но возможна с готовыми решениями для поиска и хранения больших данных. Фухх, если где то ошибся, подправьте
можешь порекомендовать хорошие проект Elastic Search ?
все счем смог подружиться было OpenSearch
 
Последнее редактирование:
darkmode_code сказал(а):
Для работы с огромным массивом данных рекомендую посмотреть в сторону опенсорсного решения от Яндекс - ClickHouse. Очень быстрая СУБД. От почты берите хеш и индексируйте его.
интересно что там яндекс написали
 
darkmode_code сказал(а):
Для работы с огромным массивом данных рекомендую посмотреть в сторону опенсорсного решения от Яндекс - ClickHouse. Очень быстрая СУБД. От почты берите хеш и индексируйте его.
отписался в личке
 
MOYAGOLUBUSHKA сказал(а):
постораюсь чотка без воды.
- посаветевлся бы с профи логаводами.
- искал бы решание на базе No-SQL,конкретние Redis, блогадаря хронение многово в оперативе он шустри.
- если лень (совсем) то какойта эластик в контейнере будет не плох
- ну если прям кровь из носа надо сйчас тогда GREP.
Можно что-то что не использует оперативную память? А точнее использует в количестве несколько килобайт/мегабайт, не более.
 

Точный поиск подстроки в строке

ÐоиÑк в ÑÑÑокаÑ, маÑÑиваÑ, поÑледоваÑелÑноÑÑÑÑ. ТоÑнÑй поиÑк подÑÑÑоки в ÑÑÑоке.
algolist.manual.ru
 
MOYAGOLUBUSHKA сказал(а):
постораюсь чотка без воды.
- посаветевлся бы с профи логаводами.
- искал бы решание на базе No-SQL,конкретние Redis, блогадаря хронение многово в оперативе он шустри.
- если лень (совсем) то какойта эластик в контейнере будет не плох
- ну если прям кровь из носа надо сйчас тогда GREP.
Ребутнул сервак, редис обнулится. Редис только для кеша.
clickhouse довольно хорошее решение для bigdata, использовали для проекта аналитики маркетплейсов, примерно 1.7 тб данных было. Поиск довольно шустро шел
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх