как добиться высокой производительности с очень большой базой данных

Question

Мне всегда было интересно, как такой большой сайт, как facebook, может быть быстрее, чем любой другой сайт, хотя очень большой объем данных, которые хранятся каждый день ...
что они используют для хранения информации, и если я использую sql server для хранения, например, news feed - это нормально или что-то еще (лента новостей будет храниться в отдельной таблице, которая называется News).
с другой стороны, что может произойти, если я соединю множество огромных таблиц друг с другом - это должно быть медленно (возможно) или не имеет значения, насколько большой стол!?

спасибо:)

Answer 1

Когда вы говорите о масштабировании по размеру Facebook, это совсем другой балл-парк.По последним оценкам, датацентр Facebook имеет около 60000 серверов (шестьдесят тысяч).Только кэш оценивается примерно в 30 ТБ (терабайт) в большом кластере Memcached .Хотя их серверная часть все еще остается MySQL, она используется в качестве хранилища значений ключей, в соответствии с общедоступной доступной информацией :

• Facebook использует MySQL, но в основном какпостоянное хранилище с ключом-значением, перемещение объединений и логики на веб-серверы, поскольку там легче выполнять оптимизацию (на «другой стороне» слоя Memcached).

Существуют различные другиеиспользуемых там технологий:

• HipHop для компиляции PHP в нативный код
• Стог сена для хранения медиа (фото)
• BigPipe для доставки HTTP
• Кассандра для поиска по входящим сообщениям

Вы также можете посмотреть ключевой адрес SIGMOD 2010 в этом году Создание Facebook: производительность в большом масштабе .Они даже представляют свой базовый внутренний API:

cache_get ($ids,
    'cache_function',
    $cache_params,
    'db_function',
    $db_params);

Так что, если вы соедините точки, вы увидите, что в таком масштабе вы больше не говорите о «большой базе данных».Вы говорите об огромных кластерах сервисов, хранилище значений ключей, разделенных на тысячи серверов, о множестве технологий, используемых вместе, и так далее, и т. Д.

В качестве дополнительного примечания вы также можете увидеть довольно хорошую презентацию Внутренние элементы MySpace .Хотя технологический стек совершенно другой (на основе Microsoft .Net и SQL Server, с огромным акцентом на передачу сообщений через Service Broker ), существуют сходные моменты в подходе к хранилищу.Подводя итог: разделение прикладного уровня .

Answer 2

Согласно тексту ссылки и другим страницам Facebook использует технику под названием Sharding.

Он просто использует группу баз данных с небольшой частью сайта в каждой базе данных. Простой алгоритм принятия решения о том, какую базу данных использовать, мог бы использовать первую букву в имени пользователя в качестве индекса для базы данных. Одна база данных для «a», одна для «b» и т. Д. Я уверен, что Facebook имеет более продвинутую схему, чем эта, но принцип тот же.

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

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

Я думаю, что часть мониторинга важнее для успеха производительности, чем реальные методы, используемые для повышения производительности. Вы не можете создать быстрый сайт, слепо бросая на него «заклинания хорошей производительности». Вы должны знать, где и почему у вас есть узкие места, прежде чем вы сможете их устранить.

Answer 3

Зависит от того, что Facebook работает очень быстро, потому что у него есть ферма серверов, поэтому запросы оптимизируются, и каждый отдельный запрос обращается ко многим серверам.

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

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

Answer 4

Зависит от узкого места в производительности.Одной из проблем часто является использование неправильной технологии для этой проблемы, например, использование реляционной БД, когда объектная БД или хранилище документов будут лучше, или наоборот.

Некоторые люди пытаются использовать одну и ту же БД для всегочто не всегда ответ.Иногда полезно иметь несколько денормализаций одних и тех же данных для разных целей.

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

Методы распределения также могут помочь с масштабированием.