PHP Application and MySQL шардинг

[Kathrin]

Привет всем!

Устраиваюсь на новую работу. Позиция Middle developer. Узнала, что спрашивают о шардинге, репликации, кластерах, и немного NoSQL.
Необходимо понимание этих вещей со стороны разработки приложения.
Начала гуглить, читать, смотреть видео с Highload, но везде рассматриваются основные принципы без привязки к приложению. В итоге сильно запуталась ((

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

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

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

Репликация заменяет шардинг?

Репликация это уже следующая тема (http://phpclub.ru/talk/threads/php-application-and-mysql-репликация.72234/).

P.S. Может есть статьи, видео, где доходчего и на пальцах рассказывают о шардингде, репликации, и кластере

 

[Фанат]

Вопроса, как такового, нет.
Единственный сформулированный явно -

Репликация заменяет шардинг?

Остальные вопросы лучше сформулировать точнее.

Шардинг репликацию не заменяет.
Собственно, для реляционных СУБД, шардинг имеет очень мало смысла - классические связи между таблицами уже не построишь.
Как одним запросом выбрать все новости одного автора, если часть их лежит на одном сервере, а часть - на другом?
Получается, если для мускуля и делать шардинг - то это низводить его до ноускл. А смысл?

В этой связи про небольшой объем доработки на уровне приложения верится с трудом.

Про разросшуюся таблицу тоже непонятно.
По индексам десяток миллионов записей должен выбираться нормально.
Для поиска можно было бы прикрутить сфинкс.

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

Слово "доходчиво" пишется как слышится, пытаться написать его "пограмотнее" не нужно.

 

[Kathrin]

Если бы могла сформулировать точнее вопросы, то сделала бы. Пока много каши в голове, просто хочу подготовится к теме, что бы все устаканилось и могла внятно ответить.
А если не далеть шардинг? Например 500 мил записей. NoSQL применять не хотят?
А если применить партиции вместо шардинга + будет кластер или репликация, будут ли партиции работать?
Все новости можно выбрать несколькими конектами и положить потом в кэш или сделать таблицу, в которой будут последнии 1 мил. новостей, для вывода последних новостей и последних новостей автора.

За сумбур извиняюсь.

 

[Kathrin]

Спасибо за ответ, сразу виден опыт в таких вопросах.
И видемо за 4 года нечего в MySQL не изменилось и приходится прилично писать.

 

[флоппик]

Ну, я уже тут писал недавно, шардинг может быть например оправдан по географическому или языковому признаку — группировать русско-говорящих пользователей например в ближайшем для них ДЦ.

 

[флоппик]

Шардинг кстати можно делать через MysqlProxy или SpockProxy — тогда не нужно будет особо трогать само приложение для добавления шардинга.

 

[Kathrin]

Мне кажется читала вчера что то про "географическому или языковому признаку" вроде логично так делать, быстрее работать будет. А можно ссылку на тему?
Хочу почитать, если там есть реализация на стороне приложения, постараюсь вникнуть.
Спасибо, что делитесь опытом, мне сейчас этого не хватает, мное упустила.

 

[Kathrin]

Пойду с дочуркой погуляю, надеюсь получить кучу уведомлений о постах

 

[флоппик]

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

 

[флоппик]

Шардинг обсуждался тут — http://phpclub.ru/talk/threads/mysql-технологии-для-highload.71966/#post-642461

 

[Kathrin]

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

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

 

[Kathrin]

Постараюсь задать точные вопросы, как говорил Фанат.

1. Есть ли встроенные возможности шардинга встроенная или добавляемая сторонним плагином/расширением?
2. Партицианированние - замена шардингу на уровне базы? Если нет, то почему?
3. Если реализован шардинг, и добавляется репликация, какие будут проблемы? И на оборот.

 

[radioheaded]

Собственно, для реляционных СУБД, шардинг имеет очень мало смысла - классические связи между таблицами уже не построишь.
Как одним запросом выбрать все новости одного автора, если часть их лежит на одном сервере, а часть - на другом?

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

 

[Фанат]

radioheaded
А база авторов на каком сервере лежит? А база упоминаемых в статье персон? А база новостей на ту же тему? А база тегов?

Реляционная модель не ограничивается одной-единственной связкой.
Мы нормальную форму не для красоты делаем, а чтобы можно было строить какие угодно связи.
Сегодня надо по авторам, завтра по датам, а послезавтра построить облако тегов.

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

 

[Kathrin]

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

 

[Фанат]

Ну, в общем, да.
NoSQL - это, по сути, окончательно денормализованная РСУБД.
И здесь надо уже решать - нужна нам реляционная база данных, или нет.

 

[grigori]

Фанат, хм, а в какой не-mysql субд шардинг не разрушит реляционность? в постгресе можно создать слой процедур, которые будут проксировать обращения на другие сервера, и некоторые выборки можно будет писать, используя процедуры как таблицы одной базы, но реально это ж фигня, в архитектуре skype в процедуры выносится вся логика и в каждом случае пишется ручками

 

[Фанат]

Ну, строго говоря, в мускуле тоже есть federated еngine
Только вот сомневаюсь я в практической пользе от таких вещей.
В чьей памяти формируется датасет? Чьи индексы используются?
Речь же ведь не просто в обращении на другой сервер, а в построении результирующей таблицы, в использовании индексов.

 

[fixxxer]

Реляционность не пропадает совсем, она остается в рамках единицы шардинга. Так что it depends - смотря каких запросов у нас больше. Скажем, если шардим по user_id и джойнить надо в большинстве случаев с одинаковыми user_id, то полезность РСУБД никуда не девается.

"Низводить" РСУБД до nosql-я чаще приходится по другой причине - из соображений эффективности кэша.

 

[grigori]

ты рыбу ловишь? нет, я рыбу ловлю! аа, я думал, ты рыбу ловишь!