Блог

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

Итак, допустим, я владелец Facebook (ахах), и каждый день мой сайт посещают миллионы людей, тысячи и тысячи изображений, видео, журналов и т. Д..

Как мне сохранить все эти данные?

Есть ли у меня больше баз данных на разных серверах по всему миру, а затем я подключаюсь к ним из одного места?

Использую ли я внутреннюю систему API, которая запрашивает информацию с других серверов, на которых хранятся данные?

Например, я знаю, что у Facebook много центров обработки данных по всему миру и сотни серверов..

Как они подключаются к этим серверам? Хранятся ли профили в разных местах, и когда я подключаюсь к своему профилю, я буду использовать этот конкретный сервер? Или есть один главный сервер, который поддерживается сотнями других серверов по всему миру?

Есть ли способ использовать PHP таким образом, чтобы я подключался к разным серверам и к разным базам данных MySQL (???) для хранения и извлечения данных, когда захочу?

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

Большое вам спасибо.

Я постараюсь ответить на ваш (большой) вопрос, но не с точки зрения Facebook, поскольку их архитектура в значительной степени известна.

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

Первым является HTTP-сервер или тот, который принимает все запросы. Перейдя к «www.your-facebook.com «, вы связываетесь со службой по IP-адресу. Естественно, у вас, вероятно, будет более одного IP-адреса, но, допустим, у вас есть одна точка входа.

Что теперь происходит? У вас есть программное обеспечение HTTP-сервера, скажем, Apache, и оно обрабатывает входящие соединения. Поскольку Apache создает поток для каждого подключенного пользователя, для этой операции требуется определенный объем памяти. В конце концов, у него закончится память, а затем дерьмо попадает в вентилятор, материал перестает работать, ваш сайт недоступен. Поэтому вам нужно как-то масштабировать эту часть вашего приложения, которая соединяет ваш PHP-код / MySQL db с людьми, которые хотят взаимодействовать с ним.

Предположим, вы успешно масштабировали свой Apache, и у вас есть кластер компьютеров, который может принимать новые компьютеры для масштабирования. Вы решили свою первую проблему.

Следующая часть — это фактический уровень, который выполняет всю работу. Принимает входные данные от пользователя и сохраняет их где-то (MySQL), и это самая большая проблема, с которой вы столкнетесь — почему? Из-за базы данных.

Базы данных хранят свои данные на носителях, таких как жесткие диски. Жесткие диски, будь то SSD или механические, ограничены их способностью записывать или извлекать данные. Если я не ошибаюсь, скорость передачи данных в оперативной памяти составляет около 6 ГБ / сек. Не говоря уже о том, что время поиска также намного меньше, чем у HDD.

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

Какие здесь есть варианты? Их много, я не буду упоминать всех

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

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

3. Получите лучшее оборудование, особенно хранилище (например, FusionIO)

4. Заплатите за лучший механизм хранения (например, TokuDB)

5. Уменьшите нагрузку на базу данных с помощью кэширования. Данные, которые запрашивают ваши пользователи, вероятно, меняются не так часто, чтобы вам приходилось запрашивать базу данных каждый раз (скажем, вы просматриваете чей-то профиль, какова вероятность, что они будут менять его каждую секунду?). Вот почему Facebook широко использует Memcached — систему, которая хранит небольшие фрагменты данных в оперативной памяти, ее легко масштабировать, а что нет. Самое главное, это чертовски быстро!

6. Используйте другие решения рядом с MySQL. MySQL (и некоторые другие базы данных) не подходят для любого типа хранения или извлечения данных. Кто-то упоминал NoSQL раньше. Решения NoSQL быстры, но все еще незрелы. Они не делают так много, как это делают реляционные базы данных. Они используют методы задержки записи на диск (они хранят кэшированную копию данных, которые им нужно записать в ОЗУ), чтобы они могли добиться высокой скорости вставки. Вот почему нет ничего необычного в потере данных при использовании NoSQL.

Тема о MySQL против «вставить базу данных или что-то еще здесь» обширна, я не хочу вдаваться в это, но помните — каждое хранилище данных в конечном итоге сохраняет данные на жестком диске. Разница (физическая, конечно) заключается в том, как они оптимизируют их сброс на сам диск.

Я также не упомянул различные отчеты, которые вы можете запускать, собирая данные (сколько мужчин в возрасте от 19 до 21 года нажали на объявление X между 01:15 и 13: 37 CET и тому подобное), которые на самом деле собирает Facebook (страшные вещи!).).

Третье — язык, склеивающий хранилище данных (MySQL) и вывод (HTTP-сервер). PHP.

Как вы можете видеть, большая часть работы здесь уже выполнена Apache и MySQL. Оптимизация на уровне PHP невелика, даже facebook получил небольшие результаты (они утверждают, что 50%, но это ДО 50%). Я много пробовал хип-хоп, он не так быстр, как утверждает. Естественно, ребята из Facebook уже упоминали об этом, так что неудивительно. Преимущество, которое они получают, заключается в том, что они заменили Apache своим собственным сервером, встроенным в HipHop. Некоторые люди утверждают, что «язык X лучше, чем язык Y», и они правы, но это не всегда так. У каждого языка есть свои преимущества и недостатки.

Например, PHP широко распространен, но он медленный для определенных операций (например, реализация Trie с более чем 1 миллиардом записей). Это отлично подходит для таких вещей, как эхо-кодирование некоторого HTML после синтаксического анализа выходных данных из БД. Быстро вставлять и извлекать данные из базы данных, и это составляет около 90% использования PHP — поговорите с БД, отобразите данные, завершите.

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

С другой стороны, почему использование C НЕ удобно? Потому что есть больше людей, которые знают, как использовать PHP, чем те, кто использует C . Также ГОРАЗДО медленнее разрабатывать веб-приложения на C . Конечно, они будут выполняться быстрее, но кто заметит разницу между 1 миллисекундой и 1 микросекундой?

Этот пост больше похож на информативный пост в блоге, я знаю, что в нем нет ресурсов для подтверждения моих утверждений, но любой, кто работал с большими наборами данных или веб-сайтами, будет знать, что P.I.T.A. всегда является компонентом хранения данных. Некоторые вещи, которые я сказал, вероятно, не всем подойдут, но в ДВУХ СЛОВАХ это то, как вы могли бы оптимизировать свой сайт.

К сожалению, на ваш вопрос нет простого ответа. Для части MySQL вам нужно будет исследовать масштабирование базы данных. Вы можете начать смотреть на это здесь: http://www.mysql.com/why-mysql/scaleout/mixi.html . Существует несколько различных способов настройки веб-сайтов Apache / PHP в ферме серверов. Один из них включает в себя настройку циклического DNS. Это добавление записи DNS с несколькими разными IP-адресами. Затем ваш DNS выдает другой IP-адрес каждый раз, когда запрашивается запись, чтобы нагрузка распределялась по нескольким серверам. Вы также можете настроить кластеризацию с помощью MySQL, Apache и Heartbeat, но это скорее решение для обеспечения высокой доступности, чем решение для масштабирования.

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

Я не говорю, что то, что я описываю ниже, является Святым Граалем, но это, безусловно, вариант:

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

Для большого количества пользователей у вас должен быть сервер с большим объемом памяти и скоростью. Настройте php.ini, чтобы разрешить большее использование памяти. На сервере с большим количеством пользователей должно быть доступно от 4 до 12 ГБ. Кроме того, сэкономьте ресурсы, закрыв среду рабочего стола. Если у вас так много пользователей, вы можете рассмотреть CDN, а также создать очередь запросов к базе данных.