Какой дб мне подходит?

0

В настоящее время я использую mysql. Я нахожу, что моя схема становится невероятно сложной. Я ищу найти новый db, который будет соответствовать моим потребностям:

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

cluster
\--news1
   \--word1
   \--word2
\--news2
   \--word3
\--news3
   \--word1
   \--word3

И тогда я применим магию и определю важность каждого слова. Подводя итог всей важности каждого слова, я придаю значение новостной статье. Подведение итогов каждой статьи новостей дает мне важность кластера.

Обратите внимание, что выше кластера есть также подгруппы (например, split by region и т.д.) и категории (например, спорт и т.д.), которые я должен определить важность этого в определенный день как таковой.

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

Также изменится показатель важности. Становится все труднее изменять таблицы, обновлять данные (которые я использую TRUNCATE TABLE), а затем вставлять из null.

В настоящее время я изучаю что-то схематичное, как 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 таблиц (мой фактический db состоит из 26 таблиц такого типа, что добавляет столько дополнительных уровней сложности для обслуживания).

ПРИМЕЧАНИЕ. ЭТО НЕ О ПОЛНОМ ТЕКСТОМ ПОИСКЕ.

  • 1
    Какая база данных вам подходит? Это зависит. Какой у вас тип данных?
  • 0
    покажите нам свою схему и некоторые примеры запросов с планами объяснения, тогда, возможно, мы сможем определить, виноват ли ваш дизайн или база данных.
Теги:

5 ответов

1

Когда схема становится сложной, можно использовать альтернативную диаграмму graph database. Насколько я понимаю ваш домен, у вас есть множество объектов, связанных с другими объектами по-разному. Было бы ли вам разумно моделировать это как граф/сеть сущностей? В качестве пищи для размышлений я взломал пример, используя Neo4j:

новостной анализ-пример http://github.com/neo4j-examples/domain-models/raw/master/news-analysis.png

В graphdb вы можете установить свойства для обоих узлов и отношений, которые могут быть полезны в вашем случае (например, количество слов, которое слово в записи новостей может быть добавлено к отношению к этому слову). Кстати, я добавил дополнительную связь is_related между двумя новостями, так как я думал, что это тоже может быть интересно.

Поделиться
0

Одним словом, да, вы, вероятно, должны смотреть на что-то еще: Cassandra, Hadoop, MongoDB, что-то.

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

Хорошая новость:

  • Это упростит изменение полей.
  • Операции с уменьшением количества карт являются естественным подходом к типу работы, которую вы выполняете. Вы выполняете сокращение карты, а затем сохраняете данные обратно в элемент "новости", и все будет хорошо.

Плохая новость:

  1. Легко потерять следы структуры данных с чем-то вроде Mongo. Hadoop и Hive обычно заставляют вашу схему немного больше. Но в любом случае вам нужно записать какую-либо форму схемы или просто утонуть.

  2. Если вы планируете сделать это для некоторого нетривиального количества данных, тогда вам понадобится "горизонтальная" масштабируемость. MongoDB "хорошо" для этого, Hadoop определенно "лидер" для этого.

Поделиться
0

Postgresql может быть "основан на схеме", но похоже, что вы выбрасываете ребенка с водой для ванны. Если вам не нужен распределенный db или особенно схема без дизайна (который не звучит как небрежно, но вы, кажется, думаете, что это так), то я не уверен, почему вы хотите mongodb. Postgres имеет множество параметров индексирования, и похоже, что его встроенный поиск в полнотекстовом режиме был бы хорош для вас. Если вы привыкли к MySQL и изменяете таблицы (вы упомянули проблемы там), это может быть кошмар, в основном его лучше в Postgres. Я поклонник Postgres и MongoDB - это просто не похоже на то, что есть хорошая причина отойти от реляционного db для данных, которые, безусловно, звучат реляционными по своей природе.

Поделиться
0

Как насчет db4o? db4o

Поделиться
  • 0
    на самом деле не глядя на что-то подобное извините
0

ORM означает "Объектно-реляционный картограф". Не использовать реляционную базу данных не имеет большого смысла. Я буду притворяться, что вы имели в виду "Я хочу, чтобы сериализовать объекты".

Я не понимаю, почему распространение не требуется. Не могли бы вы рассказать об этом?

Лично я бы рекомендовал Кассандру. Он по-прежнему имеет достаточно тесные связи (к которым я имею в виду легко интегрироваться) Hadoop, который вы, вероятно, в конечном итоге захотите для своей обработки. В качестве дополнительного бонуса есть Telephus, поэтому Cassandra прекрасно поддерживает Twisted. Метод разрешения конфликтов Cassandra (в настоящее время временные метки, скоростные векторные часы) может работать для вашей изменяющейся метрики, если вы не возражаете получить старое значение до тех пор, пока показатель не был пересчитан. В противном случае вы можете подняться на уровень и просто сохранить несколько версий данных с разными версиями метрики. Таким образом, если вы решите, что метрика - плохая идея, вам не нужно ее компрометировать.

Кассандра, к сожалению, не имеет чего-то, что сериализует/десериализует объекты очень хорошо. Тем не менее, для тонких оберток, которые вы написали бы (по существу, с помощью нескольких методов), написало бы метод Cassandra @classmethod, действительно ли это большая сделка?

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню