Базы данных и работа с крупными проектами

#php #mysql #sql #sql_server

Здравствуйте

Меня интересует теоретический вопрос по строению и выбору баз данных для крупных
проектов.

Для примера возьмем такие проекты как социальные сети, сайты по изучению иностранных
языков, глобальные чат системы, например twitter.

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

Как я понял 1 таблицы для данных пользователей 1на со словами и 1на для избранных
слов всех пользователей, пользователь заходит на сайт под своей сессией, заходит в
свой словарик и ему по его id пользователя вытаскиваются слова из общей таблицы избранных
слов. И вот тут мне не понятно, там в таблице миллиарды слов, каким образом за секунду
будет обработан запрос найти среди этих слов избранные слова пользователя.

Или используются другие способы и специальные базы данных при такой нагрузке для
реализации этого?
    

Ответы

Ответ 1

Допустим, LinguaLeo использует MySQL. Нужно сказать, что LinguaLeo это 36,300 посещений
в день. И если разделим на 24 и допустим, что со всего мира на сайте сидит 1.5к постоянно
в онлайне (очень приблизительно). Или в пиках даже пусть 5к одновременно и 95% всех
запросов к таблице MySQL это запросы типа SELECT, то с такой задачей справится без
проблем обычный сервер на два ксеона и 4 диска в раиде 0. Поверьте. 

Правильно настореная MySQL БД может просто очень-очень быстро работать. И такого
стака как PHP и MySQL может быть очень предостаточно. У MySQL очень быстро работают
SELECT запросы. У noSQL быстрее работают INSERT-подобные запросы. Twitter скорее использует
noSQL, потому что у них нужно много записывать одновременно. Хотя вот я нашел стак
технологии твиттера:


2006 Ruby on Rails MySQL
2008+ Ruby on RailsMySQL (TweetStore, Flock) Redis, Memcache
2010+ Netty (reverse proxy) JVM (java, scala) MySQL (TweetStore, Flock, etc) Redis,
Memcache


Как ни странно, но Twitter использует MySQL. Хотя вполне логично, что небольшие INSERT-подобные
запросы для сохранения твитов в MySQL проходят тоже довольно-таки быстро. И тоже видно,
что они с Ruby (который был как back-end в начале) перешли на Java в 2010м году.

К вопросу как это происходит (со словарем). Стак технологий js, jquery, mysql. Insert
data through ajax into mysql database описание как записать данные в MySQL.


Ответ 2

Во-первых, нужно определиться, что нужно: latency или throughput.


Latency - минимальное время ответа на запрос.
Throughput - количество запросов в секунду.


Разные части системы оптимизируют разные задачи.

В примере про словарь используется кеширование данных - при многократных обращениях
к данным запрос в базу идет всего несколько раз.

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

Можно выделить 1 нагруженную таблицу на отдельный сервер. Это будет вертикальный шардинг.

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

Это базовые подходы любого высоконагруженного проекта.


Ответ 3

Помимо SQL-баз данных есть еще технологии NoSQL и способы изначально структурированного
хранения данных в виде объектов, массивов, коллекций и пр. Например, в JSON или XML.

В случае с LinguaLeo и соцсетями именно так все и работает. Все данные профиля, настройки,
предпочтения, словарики и слова хранятся в объектах JSON, которые по сути своей ничего
общего с SQL не имеют. Запросы к ним строятся по-другому.

Когда пользователь логинится в систему, его данные/метаданные подгружаются из объектов
JSON и "расставляются" по атрибутам/переменным.

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

UPDATE

Многое зависит от типов данных и их структурированности. Совсем необязательно, что
данные всегда должны храниться в sql/nosql-базах. Некоторые данные вполне могут находиться
в неструктурированных хранилищах, в BLOB'ах, на файловой системе и т.д. Например, хранилище
Exchange - это по сути такая же БД для хранения объектов с разными mime-типами (бинари,
картинки, текст, гипертекст и пр.). Звук, изображения и тяжёлые BLOB'ы логичнее всего
хранить на файловой системе, не утруждая себя mime-кодированием/декодированием. Именно
так хранят эти данные Facebook, VK, Amazon и др.

При правильной референсности (реляции с ID пользователя) и защищенности периметра/внутренней
сети с безопасностью не будет проблем, потому что такие сложные проекты - это всегда
разнесёнка, то если огромный распределённый кластер. Например, веб-сайты *.microsoft.com
в свое время обслуживались NLB-кластером из 5600 узлов. Трудно поверить, но это так.