Капитан Пронин

На POSIX системах можно использовать fgrep:

$ cat /tmp/file1.txt
aaa
bbb
ccc
$ cat /tmp/file2.txt
bbb
123
aaa
$ fgrep -f /tmp/file1.txt /tmp/file2.txt
bbb
aaa

Так что на PHP как-то так:

$output = shell_exec('fgrep -f /tmp/file1.txt /tmp/file2.txt > /tmp/dups.txt');

Однако, если требуется выполнять какие-то дополнительные манипуляции, тогда, возможно, лучше сразу импортировать в СУБД.

Добавлено:
упустил факт, что помимо дубликатов нужно оставить и неповторяющиеся значения. Тогда так:

$ sort -u /tmp/file1.txt /tmp/file2.txt
123
aaa
bbb
ccc

$output = shell_exec('sort -u /tmp/file1.txt /tmp/file2.txt > /tmp/dups.txt');

Если верно понял требования, то вот мои мысли.

Использовать Transparent Data Encryption (TDE)

Выполнить шифрование данных на уровне таблиц:
https://www.postgresql.org/docs/current/encryption...
https://dev.mysql.com/blog-archive/controlling-tab...

То есть расшифровывание будет происходить на уровне СУБД, а с точки зрения приложения - обычные запросы LIKE.

CouchDB имеет встроенный механизм репликации.

Sphinx search MVA (multi-valued attributes) / Elasticsearch, либо как указал Василий Банников

SQLite.

Почему?
Можно держать всю БД хоть на диске в одном файле, хоть в памяти (in-memory).
Вместо своего велосипеда написать SQL запрос или составить его с query builder/ORM и получить ответ.
Для скорости - выставить нужные индексы на таблицу.
CSV - несколько хардкорное решение, несмотря на советы от некоторых. Если понадобится изменить какие-то данные/структуру в будущем, то придется сменять файл целиком. А так достаточно может изменить таблицу одним запросом.
В отличие от Redis, можно держать данные также и на диске, при необходимости.

Попробуйте одну из TSDB, как указал Владимир Куц .

В частности, хранилище VictoriaMetrics. В качестве языка запросов применяется PromQL.

Возможность использования в качестве долговременного хранилища данных, подключенного к Prometheus и Grafana.

Что касается преимуществ по отношению с другими, то сходите по ссылке выше.

https://github.com/symisc/vedis/blob/e122fd9941793...

В каких случаях предпочтение следует отдавать хранению информации в файлах

Когда речь идет о конфигурации приложения, о мизерном количестве файлов и при этом нет связей между сущностями. Когда нет одновременного изменения состояния содержимого файлов разными процессами.

Не знаю как дела обстоят на деле, но логично предположить, что отпечаток пальца - это некий идентификатор сродни хэш-сумме. А сохранить такой короткий идентификатор в СУБД с сопутствующей информацией (JSON или что хотите) не должно составлять проблему.
Идентификация человека - это получение этого идентификатора и сопоставление с информацией в СУБД.

В одном из проектов у нас сделали так:
бэкенд представлял из себя REST API, который выдавал каждому клиенту только те данные, которые касались его идентификатора. Для контроля версий данных использовали таблицу с client_id, version, action и каждый клиент скачивал накопившуюся разницу.
Клиенты периодически, раз в 5-10 минут, выполняли polling с сервера с накопившимися изменениями у клиента, при том что сервер централизованно хранил и управлял всеми изменениями.
При сбое коннекта происходила повторная попытка соединения согласно периоду. Так что в офлайне клиенты работали хоть с устаревшими данными, но таки работали.

Судя по структуре данных лучше подходит SQL СУБД. Для начала можно и SQLite, а можно и сразу MySQL.

Если нет инструмента, который строит диаграмму связей моделей, то вручную. Обычно связи между таблицами устанавливаются по именам колонок, в которых есть суффикс ID/_id. Например, OrderID - это внешний ключ к таблице Orders.

Диаграмму связей можно построить в онлайн сервисе www.webgraphviz.com . При помощи простого синтаксиса можно описать связи между таблицами и таким образом, построить диаграмму.

Любую реляционную: MySQL, Postgresql, Firebird. Первую точно можно настроить на малое потребление памяти, если необходимо.
При использовании их легко вырасти, не меняя СУБД.
В долгосрочной перспективе SQLite не подходит.

10 ГБ - это разве большое количество?
Начни с MySQL/MariaDB, не ошибешься. Производительность зависит от правильной архитектуры СУБД и правильного использования индексов.