Хранение новостей в распределенной БД и СУБД

Question

Привет всем: Если я храню статьи новостей в БД с различными категориями, такими как «Технология», «Финансы» и «Здоровье», будет ли распределенная база данных хорошо работать в этой системе по сравнению с РСУБД? В каждой из новостных статей были бы прикреплены новостные статьи, а также несколько других элементов. Мне интересно, будет ли запрос быстрее.

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

Я думаю о решении проблемы в правильном направлении, и будет ли DDB даже лучшим решением? Через несколько лет может быть 5 миллионов предметов, но даже тогда ....

Answer 1

Независимо от того, использовать ли распределенную базу данных или хранилище ключей, зависит от ваших эксплуатационных требований, чем от проблемы вашего домена.

Когда люди спрашивают, как сделать время упорядоченных запросов в Riak, мы обычно предлагают несколько стратегий (хотя ни один из них не являются серебристо-пулей, как Riak не хватает упорядоченного запросы диапазона):

1) Если вы часто получая доступ к определенному размеру времени, разбивайте свои данные на ведра, которые отражают этот период. Например, все данные за указанный день, час или минуту будут либо сохранены, либо связаны с ведром, содержащим соответствующую временную метку. Если бы я хотел всех технических новостей с сегодняшнего дня, имя ведра могло бы быть «tech-20100616». По мере ввода ваших данных добавьте соответствующие ссылки из шкалы времени в фактический элемент.

2) Если данные более ориентированы на последовательность и не связаны с конкретным моментом времени, используйте ссылки для создания цепочки данных, связанных назад во времени, вперёд или с обоими. (Это хорошо работает и для версий данных, например, для страниц вики). Возможно, вам также понадобится сохранить объект, который просто указывается во главе списка.

Эти стратегии в стороне, Riak, вероятно, не является 100% -ным решением для самой последней информации, но может быть лучше для более длительного хранения. Вы могли бы объединить его с чем-то вроде Redis, memcached или даже MongoDB (который имеет отличную производительность, если ваши данные слегка временны и могут поместиться в памяти), чтобы удерживать скользящий индекс последнего материала.