2012-06-29 4 views
2

В настоящее время я разрабатываю систему, которая следит за рангами/видами видео YouTube. из LOTS видеороликов youtube (> 500 000 и растущих) на ежедневной основе.Хранение и анализ исторических данных - какая база данных?

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

Мне нужно анализировать эти данные, например:

  • Каких видео выросло много в период между X и Y
  • Plot щелчков в день
  • Plot щелчков в неделю .. .
  • еще некоторые вещи, которые я не знаю еще о

Итак, что пришли в мой веб-2,0 ум был, есть способ базы данных NoSQL может справитесь с этим лучше? Я не совсем изучил эти (почти) новые базы данных и не знаю, на что они способны.

Каким будет ваш совет, какую базу данных использовать? Реляционные или нет? Если нет, то какая база данных NoSQL?

PS: первый приоритет является быстрая оценка и вставка результатов, вторая высокая доступность (или просто репликация)

+0

с учетом производительности, побочный эффект: знаете ли вы, что facbeook построен на MySQL? – Chris

+0

Да, я думаю, что прочитал это в какой-то момент. моя мотивация этого вопроса была в первую очередь моей заботой о «слишком больших таблицах» (не сгруппирована) и быстрой оценке этих исторических данных. Я в настоящее время экспериментирую на mysql, но я не уверен, правильно ли это выбрать. – Stefan

+0

честно, если только слишком большие таблицы являются вашей прежней заботой, я не думаю, что вам придется беспокоиться, если: вы можете использовать индексы, чтобы сузить результаты поиска. Индексы используются как указатели строк, поэтому количество строк не повредит индекс, а просто указывает на эти строки справа ... – Chris

ответ

2

очень трудно дать совет для системы баз данных, потому что она всегда зависит. Однако, учитывая, что Facebook построен на MySQL, он показывает, что, вероятно, производительность для вас не является предел для MySQL.

Что полезно, и вы, вероятно, сделали, создает структуру того, как должна выглядеть ваша структура таблицы. Затем также подумайте о запросах, которые вы хотите выполнить против таблиц.

Если у вас есть нужные индексы (на которые зависит основная и решающая скорость запросов), вам не придется беспокоиться о производительности в MySQL. То, что вы должны учитывать, - это то, что мне пришлось испытать, что есть много интересного, как MySQL относится к индексам. Позвольте мне привести несколько примеров, которые я должен был выяснить во времени:

  • если вы хотите использовать индекс для сканирования диапазона, индекс не может быть использован для ORDER BY больше
  • колонка диапазон должен быть последний в сцепленном индекс для полнотекстового индекса будет использоваться, то же самое для ORDER BY снова

для получения дополнительной информации, полезная ссылка на mysqlperformanceblog.com: http://www.mysqlperformanceblog.com/2009/09/12/3-ways-mysql-uses-indexes/

в общем, если Структур e из базы данных хорошо продуман и индексирование хорошее, по моему опыту, на самом деле не имеет значения, если у вас всего 10 000 строк или 10 миллиардов, время запроса будет примерно одинаковым.