Профи, как бы вы спроектировали БД и сервер?

В папке images?

Настолько абстрактные вопросы, что отвечать конкретно малореально.

1) Если уже 20млн пользователей, то надо ориентироваться на чем это крутиться сейчас и какая посещаемость. Если их еще нет, то это все вилами по воде. При такой ситуации все надо решать практическими тестами исходя из реальной ситуации. Тройка серверов всяко нужна - под базу, под морду, под пхп/питон/что-то другое. А дальше смотреть по нагрузке.

2) Картинки на отдельном сервере. Можно гео-облако сделать. Это так же банально, как очевидно.

3а) Для начала varchar мы бы конвертнули в char, скорее всего. Место ничто, а производительность решает. Конкретная структура здесь будет зависеть от того, какие не основные запросы для поиска происходят по этим полям.

3б) Для "друзей". Никакой попытки сделать хитросвязи с хитровыборками. Только таблица "друг1"=>"поле с перечислением друзей 1 уровня". 3 запросов хватит для выборки 3 рукопожатий. Апдейтить не сложно. По сути это будет умный кэш. Зато таблица будет маленькая, компактная и полностью помещающаяся в память, что при выборке даст отличную скорость.

Непрофессионалу бы такой проект не спустили, так что могли бы сразу и свое профессиональное озвучить.

Посещаги нет. Это проект в разработке. Вилы вилами, но подготовиться нужно.

Представим что у нас мускул.

1. Делать партиционирование? (если да, то по ключу или хешу?(KEY\HASH partitioning)). Для таблицы users и таблицы relations.

2. Какой сервер для БД? Тут скорее важнее скорость работы с дисками. RAID нужен получается?

3. Настройки мускула на которые вы бы обратили внимание.

4. Добавляли бы какие либо надстройки типа memcache?

Заказчик с идеей "а вот сейчас я урою фейсбук, дело только в софте"? 99% что не взлетит:)

Но в любом случае, Вы не оттуда начинаете готовится. Вы описали данные которые будут, но по сути не описали операции, которые с ними будут производиться (кроме весьма нечеткой выборки связей), не описали ожидаемую картину посещаемости. Более того, проект описан как-то уж очень однобоко - или там реально не будет контента? Тогда что это? Попытка сделать граббер базы фконтакта с анализом связей?

Если Вам не нужен поиск, то что бы выбрать из базы строку пользователя с данными - не нужна даже реляционная база данных, достаточно хранилища key-value.

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

Необходимые диски при "тупых" операциях считаются от посещаемости. Посчитайте сколько операций выборки Вам надо в секунду и подберите диск по ттх.

В общем в Вашей постановке задачи. Самое простое key-value хранилище для данных (mongodb например). key-value хранилище в памяти для быстрых выборок по "друзьям" (как вариант memcached или тот же mongodb на вирт. памяти). Диски - подобрать под посещаемость - 100к хитов одно дело, 100млн хитов другое. Картинки - вынести на отдельный сервер или вообще в облако. Под базу, мемкэшед, веб-морду, обработчик данных, картинки - по одному серверу, можно для начала даже виртуальному.

Выборки будут по логину и имени + фамилии(одно поле. назовем его условно "никнейм".). Другие поля в поиске участвовать не будут.

Апдейты редкие. Их можно отбросить. Выборки каждый раз при заходе на сайт. Пользователь ищет кого либо, а мы ему говорим что он его знает через "таких-то" людей.

В таком варианте ища наиболее дешевое и простое решение мы бы сделали так.

Взяли бы сервак с солидным количеством оперативы, сделали бы там вирт. диск из оперативы, скинули бы на него сервер БД в котором было бы только 2 базы "логин+фио" и "связи друзей". Может пару серверов - зависит от количества данных. Набивали бы его при старте серверов и апдейтили бы при апдейтах. Скорость была бы космос.

Под основную базу ssd - их основная проблема сейчас это частые апдейты, но скорость чтения космос. И на каком-нибудь nosql (типа mongodb), т.к. выборки там были бы только по ключам.

Более сложные решения городить преждевременно, ибо premature optimization root of evil.

В устоявшемся проекте мы бы сохранили тот же принцип, только написали бы прожку на сях, которая поиск по данным (опять же, хранящимся в оперативе).

Ну картинки и вебморда отдельно - это понятно, не фиг основной сервер отвлекать.

IMHO, стоит забыть про mysql в этом случае. См. graph-oriented БД, типа Neo4j.

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

Зря вы так на мускул. У меня есть постоянно обновляемая таблица на 200 М строк и нормально

vladimir_112, ага, а может лучше на ассемблере? Задача у ТС почти стандартная, с ней и пхп и питон и мускул спокойно справятся

Пока проект не запущен в продакшен и не выявлены узкие места - писать на С++ имхо извращение. Тонны времени уйдет на постоянные перекомпиляции из за малейшего изменения.

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

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

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