xmoonlight

Всё зависит от процесса обработки данных.
Создание необходимой структуры (БД) из "сырых" данных помогает сильно сократить выч.ресурсы для их дальнейшего анализа и работы с ними.

Нужны узлы связей. Тянете за параметр, получаете гроздь и т.д.
Каждая последующая выборка - из узлов связей предыдущего результата.

Система такая делается крайне просто.
1. Сплитятся все слова в статье и приводится к нижнему регистру.
2. Составляется указатель: список этих слов и процент соответствия групп слов для конкретной статьи.
3. Происходит разметка до тех пор, пока процент соответствия не будет выше порогового значения.
4. Когда очередная статья проверяется - происходит сопоставление и автоматом расставляются теги.

Рекомендую сделать это руками без применения олдскульных инструментов (Эластик, Монго, Постгр, Касандру). Определитесь с тем, какие у вас данные, затем - как их связать.

Обычно, одна нода ("узел") - это один слог (любого слова).
Дальше - стройте граф, проходя по тексту: занося слоги и ставя связи (слева-справа: id-шники соседних "узлов"), и отдельно - локации: id-узла, id-локации (линк, файл, документ, URL и т.п.).

Поиск - путь по нодам даст сразу все локации. (это мнгновенно, т.к. всё по ID происходит)

Требования к системе в порядке приоритета.
1 Возможность запустить это всё на как можно более дешёвом и досутпном железе - это критично т.к. бюджет на инфраструктуту ограничен
2 Скорость поиска
3 Надёжность и отказоустойчивость
4 Лёгкость масштабирования

Все требования исполняются на 100%.

TimescaleDB

Есть файлы

Нужно просто из них создать базу и проиндексировать все необходимые поля.
Раз уж заговорили про собственную базу: бинарный кортеж и затем, бинарное неполносвязное "дерево" из них.
Это позволит искать начиная с любых входных данных сразу весь список объектов.

Видимо, еще недостаточно сенсоров для сбора данных подобного рода, чтобы создать корректно функционирующий продукт.
Да и к тому же, как считает большинство, собака:
1. денег не принесёт
2. не будет делать то, что ей скажут
3. она неспособна на большее, чем уже известно на текущий момент
Аналог: т.е. всё равно, что покупать батарейки за бешеные деньги и "везти" их (время разработки до конечного продукта) к неработающей игрушке.

Моё мнение - кардинально противоположное!
Я - только "ЗА"!

Пусть бинарные последовательности - это предложения.
А набор характеристик в них - это слова.
Пусть разделитель - символ пробела.
Тогда используя этот алгоритм Как определить похожесть двух строк?
мы можем выбрать нужные нам записи с наименьшими затратами на производительность.

Кластеризация: https://habrahabr.ru/post/101338/

E - знак суммы
V - параметр
N - № показателя параметра (от 1..30)
A - индекс из всех искомых цепочек параметров (например, ID пользователя или сессии)
Vm (middle) - средние значения обучения и/или заведомо проверенных данных (эталонных)
Vd - дельта отклонения от эталона.
W - вес (чем меньше, тем лучше)
-----------------
Vm[N]=E(V[N])/N //Средний вес каждого значения из эталонных: средний эталон
Vd[A][N]=abs(Vm[N]-V[A][N]) //Расстояние от эталонного (по каждому из искомых)
W[A]=E(Vd[A][N]) //Суммарная удалённость (по каждому каждого из искомых) от эталона
W=min(W[A]) //Минимальная удалённость из всех (он же - максимальный вес, близкий к эталону)
A - искомый пользователь с максимальной вероятностью к искомым параметрам

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

Итак, информацию:
1. Структурирует (или создаёт правила распределения) - человек (в основном).
2. Хранит - носитель (камень, бумага, магнитные или оптические накопители, и т.д.).
3. Обрабатывает - менеджер хранилища (человек или ПО).

Лично я для долговременного хранения важных данных использую квадрорепликацию.

BigData - это хранилище множества постоянно собираемых однотипных данных, возможно как-то связанных между собой, обычно "расположенных" вдоль оси временной шкалы.
Для чего Вам собирать какие-то данные в таких объемах? - надо Вам решить ДО "погружения" в эту сферу!
И это зависит от конечной цели: возможно, маркетинговой.
Что может дать BigData в "сыром" виде? - большой объем бесполезных данных.
Что можно делать с помощью BigData? - Например, можно узнать зависимости одних параметров от других на выбранном временном отрезке.
Практические решения с применением BigData? - маркетинг, прогнозирование рисков, любая фильтрация, прогнозы и предсказания поведения изменений любых параметров, содержащихся в хранилище BigData.

Каждый hash делайте первичным ключом и затем смотрите тут:
https://dev.mysql.com/doc/refman/5.5/en/innodb-ind...

UPD: я бы добавил, что для обучения и эталонирования образа (на основе множества подобных из БД), нужно удалять из дальнейшей выборки (однократным проходом по всей базе) промежуточные "близкие" "похожие" экземпляры, оставляя определённый процент допуска по параметрам. Таким образом, она не будет расти от "копий" подобных экземпляров.

Почитайте, запомните и повторяйте перед сном:

Нет никакой универсальной "серебряной пули" против проблем в самых сложных проектах, включая обработку "больших" данных.

Моя архитектура проекта, включая архитектуру используемой базы данных для этого проекта, в целом и полностью зависят от функциональных требований!

Я это понимаю, буду каждый раз самостоятельно проектировать архитектуру проекта, включая систему хранения данных (СХД) для этого проекта.

И напоследок: неважно сколько данных и какого типа, важно - как они связаны!

Все просто: объект-группа хранит СВОЙ список идентификаторов пользователей (подписчиков), которые в неё входят. Таким образом при оповещении о новой записи просто проверяются флаги: пользователь существует (и не заблокирован) и уведомления разрешены.

1. Пути к тайлам - в базе.
2. Картинки - в на диске с prefetching and caching в ОЗУ. По-скольку статика: nginx.
В принципе, нужно посчтитать: вполне возможно есть смысл при загрузке "холмы" (или всю матрицу тайлов) закинуть сразу в RAM-drive.
"Холмы": их вершины - это часто используемые тайлы. Как правило - это центры крупных городов (можно набрать статистикой использования).

стандартный запрос к базе - не пойму чему удивляться тут...