Заповедник

А что такое?
Фактически, все равно получается распределенная база данных.
Мы уже имеем в ней записи (посты) с полями: "Имя пользователя", "Штамп времени", "Название (идентификатор) темы", "Текст сообщения".
Добавим еще несколько полей: "Язык" (как обязательное поле), "Тематика" (как произвольный тег)...
Хранить можно там же, где и остальные поля – в каждом посте.
Тут, да, надо думать еще, какие теги сделать обязательными, сколько полей оставить для выбора пользователем, наследовать ли теги из тредстарта, как поиск по тегам будет работать, как это вообще будет выглядеть для пользователя...

Но может найти ее по тегам.

Тут главное, не просто "где хранить", а как искать.

Если теги будут хранится вместе с сообщением (любым или первым сообщением темы). То придется перебирать все сообщения. Опрашивать ВООБЩЕ все сообщения.
Естественно такой вариант работать не будет.
Рекомендую вам почитать устройство Kademlia. Там есть поиск по словам (слова из названий файлов). Правда из описания мне не до конца понятно как оно работает.

Для поиска - плюсом к хранению тегов в сообщении - отдельная табличка тегов. Индекс. Синхронизируется после синхронизации времени. До отправки сообщений.
Каждый клиент хранит не только ВСЕ сообщения темы, в которой участвовал, но и индекс тегов ВСЕГО форума.
Ну а как? Очень не хочется создавать раз и навсегда заданную структуру тем в виде "Форум-подфорум-раздел-подраздел-тема".


Если есть индекс тегов, то каждый автор при создании темы может видеть, что по одному тегу "Политика" – миллион тем. По тегам "Политика" + "Европа" уже только 10 тысяч. По тегам "Политика" + "Европа" + "Наполеон" – уже только сотня. И так далее. Допустим, длина тега до 50 символов, 20 полей на 1000 тегов в каждом... – 20 тысяч возможных тегов. Количество комбинаций 20 000 тегов, то есть, число "подразделов" самого "нижнего" уровня будет = 10 в степени 2000. А размер индекса, по байту на символ = 1 Mb табличка (для форумов на русском). Плюс количество известных постов по каждому тегу, итого = 2Mb. Это критично?

Угу. Что-то читал. Понял еще меньше, чем Вы, вероятно.
А Вы что читаете про устройство Kademlia?

Не надо забывать, что индекс - это пара "значение:значение". Просто хранить теги недостаточно, нужно хранить участников, у которых есть что-то связанное с этим тегом (форум). Если хранить только автора, то его можно не найти в сети, когда придется искать тег, если хранить всех участников темы, то объемы начинаются заметно увеличиваться.


А структура "список списков"? В любой теме может быть куча ссылок на другие темы. Я к тому, что смысл тот же самый, но вложенность просто не ограничена ничем, и нет названий форум, подфорум, подраздел и т.п.



Рассчеты по тегам я не понял. Что за поля?



В данный момент ничего. Там общий смысл в том, что у "слов" есть свой хэш. И пользователь хранит "слова", которые являются "ближайшими" к нему. То есть хранит не все теги, а только небольшую часть.
Поиск работает по DHT. Как торрент-клиент ищет конкретные торренты находя все более "близких" клиентов (хэш клиента максимально похож на хэш торрента), так и "слова" можно находить перебирая все более близких по хэшу участников.
Можно скачать и посмотреть eMule - как вживую это выглядит.

Я видел. Тыщу лет назад, правда.

Вы мне пока вот что поясните, пожалуйста.

В нашем обсуждении Вы неоднократно использовали выражение "ближайший", "близкий" хэш.

Я понимаю, что хэш - это значение хэш-функции. А хэш-функция это некий алгоритм преобразования текста произвольной длины в шестнадцатеричную строку определенной длины. Из идентичных текстов будут получены идентичные хэши, из текстов, отличающихся хотя бы на бит - совершенно разные хэши (не считая коллизий). В торрентах это позволяет искать не само совпадение одного гигабайтного файла с другим, а только совпадение их хэшей, что значительно проще. Это понятно. Но разные хэши говорят нам только о том, что исходные тексты были разными. По-моему, один хэш никак не может быть "ближе" или "дальше" от другого. Они просто разные и всё. Один хэш одинаково "далёк" от любого другого. По хэшу нельзя ничего сказать о содержании текста, по которому он создан. Что значит - "ближайший" хэш?

Это как раз основная штука на которой работает DHT и поиск по словам в Kademlia.

Хэш - это число. Например 1,2,3. К единице двойка ближе чем тройка.
"Расстояние" можно считать через разность, через логические битовые операции. Я не помню, но в DHT вроде бы используется логическое И.

Да. Спасибо, я немного разобрался.

То есть, как пример, на узле 2 есть инфа об узлах 1 и 3, на узле 3 - инфа о 2 и 4 и т.д. В реальной DHT просто числа побольше.

Не совсем.
На узле хранится информация о связанных данных, а не участниках (хотя список участников - тоже данные).
Когда вы ищете торрент с хэшем XXXXX вы спрашиваете о его нахождении у участника из вашего списка, который ближе всего к этому числу. Этот участник либо сообщит вам адрес торрента (ip:port), либо, если не имеет таких данных, ip адрес другого участника c еще более "близким" id.
В торрент-клиентах, насколько я вижу, хранится полный список раздающих торрент. Конечно не сразу, но постепенно подгружается. Там PEX и DHT для этого.
В Kademlia еще хранятся адреса файлов в названиях которых есть слова, хэш которых близок вашему id. Точнее не помню, но там вроде бы список слов, и списки файлов отдельно можно искать. То есть хранится набор адресов файлов и набор слов.


Ваше личное дело какие числа использовать Можете от 1 до 10. Только участников будет мало, либо будут повторятся.

И о данных (хэши файлов) и об участниках (хэши ID).

Там фишка в том, что участник (как пример) с "номером" 500 хранит инфу И об участниках с номерами 450-550 И о файлах, чей хэш тоже в пределах "450-550". Поэтому, чтобы найти инфу о файле № 501 нужно найти участника № 501 (или близкого к тому).

Наверное я не совсем внятно выразился.

Хранение информации о данных (файлах, участниках, ключах и т.д.) подразумевает хранение информации о расположении этих данных. То есть адреса участников, у которых эти данные есть. То есть фраза "хранит информацию о файлах, чей хэш в пределах "450-550" нужно читать как "хранит список участников, у которых есть информация о файлах, чей хэш в пределах "450-550"