В настоящее время я использую mysql. Я обнаружил, что моя схема становится невероятно сложной. Я ищу новую базу данных, которая будет соответствовать моим потребностям:
Давайте предположим, что я создаю агрегатор новостей (который собирает новости с нескольких веб-сайтов). Затем я запускаю алгоритмы, чтобы определить, действительно ли две новости с разных сайтов относятся к одной и той же теме. Я запускаю этот алгоритм для кластеризации новостей вместе. Отношения изображены ниже:
cluster
\--news1
\--word1
\--word2
\--news2
\--word3
\--news3
\--word1
\--word3
А потом я применю магию и определю важность каждого слова. Суммирование всей важности каждого слова дает мне важность статьи новостей. Суммирование важности каждой новостной статьи дает мне важность кластера.
Обратите внимание, что над кластером также есть подгруппы (например, разделенные по регионам и т. Д.) И категории (например, виды спорта и т. Д.), Которые я должен определить важность этого в конкретный день как таковой.
В прошлом я использовал для этого представления, но я понял, что представления очень медленные. Поэтому я обычно делаю вставку в фактическую таблицу и индексирую их для лучшей производительности. Как вы можете видеть, это приводит к нескольким таблицам, таким как (кластер, важность), (новости, важность), (слова, важность) и т. Д., Которые могут быть довольно грязными.
Также изменится показатель важности. Становится все труднее изменять таблицы, обновлять данные (которые я использую TRUNCATE TABLE), а затем вставлять их с нуля.
В настоящее время я смотрю на что-то без схемы, как Mongodb. Мне не нужна распределенность. Я бы очень хотел что-то достаточно быстрое (которое можно проиндексировать) и что-то более гибкое, чем традиционная RDMBS.
NEW
По просьбе разных людей я опубликую свое использование в этой базе данных (они не являются реальными запросами SQL, так как я надеюсь, что все здесь могут понять)
TABLE word ( word_id, news_id, word )
TABLE news ( news_id, date, site .. )
TABLE clusters ( cluster_id, cluster_leader, cluster_name, ... )
TABLE mapping_clusters_news( cluster_id, news_id)
TABLE word_importance (word_id, score)
TABLE news_importance (news_id, score)
TABLE cluster_importance( cluster_id, score)
TABLE group_importance( cluster_id, score)
Вы можете заметить, что в TABLE_word есть дополнительный столбец news_id. Это должно соответствовать столбцу TABLE_word_importance, потому что одно и то же слово может иметь разное значение в разных статьях (если вы знакомы с tfidf, это в основном что-то вроде этого).
Вся таблица «важности» теперь вычисляет важность каждого объекта путем усреднения важности всех дочерних объектов под ним. Это означает, что важность каждого кластера определяется всеми новостями внутри него, важность каждой новости определяется всеми словами внутри него и т. Д.
TYPICAL USAGE:
1) SELECT clusters FROM db THAT HAS word1, word2, word3, .. ORDER BY cluster_importance_score
2) SELECT words FROM db BELONGING TO THE CLUSTER cluster_id=5 ODER BY word_importance score.
3) SELECT groups ordered by importance score.
Как вы можете видеть, я получаю много оценок от каждого слоя, и кто-то говорит мне использовать материализованное представление для этой цели (которое поддерживает postgresql). Однако, как вы можете видеть, эта простая схема уже состоит из 8 таблиц (моя фактическая база данных состоит из 26 подобных таблиц, что добавляет столько дополнительных уровней сложности для сопровождения).
ПРИМЕЧАНИЕ ЭТОТ НЕ О ПОЛНОТЕКСТОВОМ ПОИСКЕ.