Предложение по разработке базы данных для фермы блогов - PullRequest
Новая
       7

Предложение по разработке базы данных для фермы блогов

1 голос
/ 05 ноября 2011

Я создаю что-то похожее на Blogfarm, и я столкнулся с небольшим препятствием. Я использовал многопользовательскую базу данных Wordpress в качестве ссылки и заметил, что для каждого создаваемого блога создается уникальная таблица.

Таким образом, если в ферме будет, скажем, «х» миллионов пользователей (просто странная мысль), то в идеале в базе данных должно быть «х» миллионов таблиц, если принять пользователя для каждого блога.

  1. Является ли тот, который используется Wordpress MU, хорошим дизайном БД? Если да, то как это повлияет на производительность базы данных с таким количеством «х» миллионов таблиц?

  2. Поскольку я только начинаю кодировать, я могу выбирать любую базу данных, которая мне нравится. В настоящее время я использую PostgreSQL в сочетании с Ruby on Rails. Как вы думаете, база данных NoSQL (например, MongodB) пригодится в этой ситуации? Если нет, почему / почему нет? Я еще не видел ни одной платформы блога, работающей на базе данных NoSQL.

  3. Как это делают такие большие парни, как Blogger, Tumblr или Squarespace?

Любая помощь очень ценится, спасибо.

Ссылка:

http://www.aeonscope.net/2006/12/29/wordpress-migration/

1 Ответ

2 голосов
/ 05 ноября 2011

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

  2. Мой честный совет заключается в следующем. Сделайте самое простое и на данный момент забудьте о проблемах масштабируемости. 99,999% веб-сайтов не используют достаточно трафика, чтобы оправдать какие-либо конкретные проблемы, а 0,001% сайтов, которые имеют, будут иметь ресурсы для фактической перезаписи. любая база кода, поэтому она масштабируется. В этом контексте используйте следующее правило:

    • RBDMS, как правило, достаточно хороши для большинства применений. Кроме того, они чрезвычайно стабильны и хорошо поддерживаются. РБДМС существует уже около 40 лет. : -)
    • Базы данных NoSQL имеют несколько очень специфических применений, где они сияют (например, хранение документов, таблицы миллиардов строк, огромные ограничения масштабируемости), с другой стороны, у них есть ошибки (см. BASE против ACID ), и они действительно представляют повышенный риск, поскольку они являются новыми, менее понятными концепциями.

  3. Я полагаю, что они делают это через некую форму шардинга . Другими словами, да, вы могли бы разделить миллионы таблиц на тысячи серверов.

Суть в том, что этот архитектурный выбор является компромиссом. Если у вас есть сайты с большим трафиком, вам понадобится больше серверов БД, и это позволит вам масштабировать по горизонтали . С другой стороны, если у вас много сайтов с небольшим трафиком, вам, вероятно, не нужно так много масштабировать.

...