Предложения / Мнения по реализации быстрого и эффективного способа поиска списка элементов в очень большом наборе данных

Question

Пожалуйста, прокомментируйте и критикуйте подход.

Сценарий : у меня большой набор данных (200 миллионов записей) в плоском файле. Данные имеют вид - 10-значный номер телефона, за которым следуют 5-6 двоичных полей. Каждую неделю я буду получать файлы Delta, которые будут содержать только изменения данных.

Проблема : Учитывая список элементов, мне нужно выяснить, присутствует ли каждый элемент (который будет десятизначным числом) в наборе данных.

Подход, который я запланировал :

• Будет анализировать набор данных и помещать его в базу данных (необходимо выполнить в начале неделю) как у MySQL или Postgres. Причина, по которой я хочу иметь СУРБД в Первый шаг - я хочу получить полные данные временных рядов.

• Затем сгенерируйте какое-нибудь хранилище значений ключей из этой базы данных с помощью последние действительные данные, которые поддерживают операцию, чтобы выяснить, является ли каждый элемент присутствует в наборе данных или нет (думая, что-то БД NOSQL, как и Redis, здесь оптимизирован для поиска. Должен иметь настойчивость и распространяться). Эта структура данных будет доступна только для чтения .

• Запросите это хранилище значений ключей, чтобы выяснить, присутствует ли каждый элемент (если возможно, сопоставьте список значений сразу, а не по одному предмету за раз). Хотите, чтобы это было невероятно быстро. Будет использовать эту функцию в качестве бэк-энда для REST API

Sidenote : я предпочитаю Python.

Answer 1

Несколько соображений для быстрого поиска:

• Если вы хотите проверять набор чисел за раз, вы можете использовать Redis SINTER, который выполняет пересечение наборов.
• Вы могли бы выиграть от использования структуры сетки, распределяя диапазоны номеров по некоторой хэш-функции, такой как первая цифра телефонного номера (возможно, есть лучшие, вам придется поэкспериментировать), это, например, уменьшит размер на узел, когдаиспользуя оптимальный хэш, до почти 20 миллионов записей при использовании 10 узлов.
• Если вы ожидаете дублирования запросов, что весьма вероятно, вы можете кэшировать последние n запрошенных телефонных номеров в меньшем наборе и запросить этот первый.