Эта тема создана для ваших вопросов, которые обязательно должны появится после мастер-класса "Разработка крупного масштабируемого web 2.0 проекта с нуля"
В шардинге обычно используется какой-то критерий разбиения. Наиболее распространены следующие: 1. По диапазону первичного ключа 2. При помощи хеш-функции, учитывающей кол-во шардов. 3. При помощи центрального "словаря", в котором хранятся соответствия ключей определенному шарду.
В нашем проекте первый вариант не подходит, т.к. id пользователей (id - это id пользователей Вконтакте) сильно варьируются и распределение по диапазону будет очень неравномерным. Второй вариант обладает недостатком при добавлении нового шарда. Каким-то образом надо перераспределять данные со старых шардов. Трейтий вариант - центральный "словарь" - это единая точка отказа + потенциально узкое место по нагрузке.
Скажите, пожалуйста, какой из этих вариантов все же предпочтительнее и как вы решаете существующие в нем проблемы?
Re: Шардингspb_borodinDecember 24 2010, 11:04:02 UTC
1. Не знаю, что вы имеете ввиду под первичным ключом, но это не важно. На каждого юзера (пусть у них есть логины или что-то еще) нужно завести user_id. Это последовательно увеличивающийся сиквенс.
2. Разумеется, никакие формулы ни в каком приближении недопустимы.
3. Центральный словарь нужно использовать. Он называется "Карта спотов". Стоп - это минимальный кусочек данных, из которых и состоит весь шардинг, т.е. вся база. В одном споте хранится сразу 500-10000 юзеров (например, 1000). Спотами очень удобно манипулировать, переносить, добавлять и т.д.
4. Небольшим проектам, до 10 млн юзеров, думать про единую точку и отказы категорически не нужно. Не пытайтесь заниматься преждевременной оптимизацией. Никакой нагрузки в карте спотов вообще нет. Ее мгновенно кеширует файловая система каждой тачки в сети и ни на какой центральный сервер никто не обращается. В общем, указанных вами опасений нет и думать про них не нужно.
5. Проблем в этом методе нет. Это единственный приемлемый способ из всех, что я знаю.
Re: Шардинг
anonymous
December 24 2010, 11:41:50 UTC
Вот, к примеру, реализуем карту спотов как таблицу mysql с двумя полями (конечно, индексированных) user_id, spot_id и представим, что у нас 10 млн. пользователей. Т. е. получем таблицу из 10 млн. строк. Запросы к данной таблице не будут тормозить? (может ведь быть и не 10, а 50-100 млн. строк, т.е. это решение рано или поздно упрется в этот порог).
"Ее мгновенно кеширует файловая система каждой тачки в сети и ни на какой центральный сервер никто не обращается". Т.е., например, на каждой машине, которая один раз обратилась к центральному словарю, можно закешировать (на диске, в памяти) данные карты спотов и потом брать их локально. Но в этом случае, я так понимаю, при переносе спотов надо эти кеши обязательно очищать?
Re: Шардингspb_borodinDecember 24 2010, 12:04:31 UTC
1. При 10 млн юзеров в таблице карты будет 10.000 записей.
2. Запросы к ней тормозить не будут, таблица мелкая и осядет в ОЗУ.
3. Самое важное. Никаких запросов к этой таблицы не будет вообще! Это весь секрет. Они не нужны. Смысл центрального сервера - хранить суперважную информацию, но чтобы ее никто в реалтайме не читал. Иначе да - он свалится. Поэтому я и говорю - никакой проблемы производительности или единой точки отказа нет (вернее, есть конечно с некой натяжкой, но думать про это категорически нельзя на вашем текущем этапе разработки, есть более важные вещи).
4. Да, кеш надо будет очистить. Опять таки, это мелкая программерская задача, а не серьезный вопрос по архитектуре. Не стоит зацикливаться на этом вопросе.
5. По команде все сервера идут на центральный и делают копию таблицы в php файлах (как массив). Далее скрипты просто инклюдят небольшие куски конфига, что кешируется в ФС. Обычно такая команда поступает при выкладке нового релиза, автоматически.
Использование фреймворковdkozhukharDecember 25 2010, 18:13:16 UTC
Дмитрий, добрый вечер! Скажите, пожалуйста, есть ли смысл в использовании различных php фреймворков в высоконагруженных системах? или лучше обходиться "своими силами"? я читал Ваши статьи, но четкого ответа, для себя, не смог найти.
Comments 68
Reply
Reply
Reply
Reply
1. По диапазону первичного ключа
2. При помощи хеш-функции, учитывающей кол-во шардов.
3. При помощи центрального "словаря", в котором хранятся соответствия ключей определенному шарду.
В нашем проекте первый вариант не подходит, т.к. id пользователей (id - это id пользователей Вконтакте) сильно варьируются и распределение по диапазону будет очень неравномерным.
Второй вариант обладает недостатком при добавлении нового шарда. Каким-то образом надо перераспределять данные со старых шардов.
Трейтий вариант - центральный "словарь" - это единая точка отказа + потенциально узкое место по нагрузке.
Скажите, пожалуйста, какой из этих вариантов все же предпочтительнее и как вы решаете существующие в нем проблемы?
Reply
2. Разумеется, никакие формулы ни в каком приближении недопустимы.
3. Центральный словарь нужно использовать. Он называется "Карта спотов". Стоп - это минимальный кусочек данных, из которых и состоит весь шардинг, т.е. вся база. В одном споте хранится сразу 500-10000 юзеров (например, 1000). Спотами очень удобно манипулировать, переносить, добавлять и т.д.
4. Небольшим проектам, до 10 млн юзеров, думать про единую точку и отказы категорически не нужно. Не пытайтесь заниматься преждевременной оптимизацией. Никакой нагрузки в карте спотов вообще нет. Ее мгновенно кеширует файловая система каждой тачки в сети и ни на какой центральный сервер никто не обращается. В общем, указанных вами опасений нет и думать про них не нужно.
5. Проблем в этом методе нет. Это единственный приемлемый способ из всех, что я знаю.
Reply
"Ее мгновенно кеширует файловая система каждой тачки в сети и ни на какой центральный сервер никто не обращается". Т.е., например, на каждой машине, которая один раз обратилась к центральному словарю, можно закешировать (на диске, в памяти) данные карты спотов и потом брать их локально. Но в этом случае, я так понимаю, при переносе спотов надо эти кеши обязательно очищать?
Reply
2. Запросы к ней тормозить не будут, таблица мелкая и осядет в ОЗУ.
3. Самое важное. Никаких запросов к этой таблицы не будет вообще! Это весь секрет. Они не нужны. Смысл центрального сервера - хранить суперважную информацию, но чтобы ее никто в реалтайме не читал. Иначе да - он свалится. Поэтому я и говорю - никакой проблемы производительности или единой точки отказа нет (вернее, есть конечно с некой натяжкой, но думать про это категорически нельзя на вашем текущем этапе разработки, есть более важные вещи).
4. Да, кеш надо будет очистить. Опять таки, это мелкая программерская задача, а не серьезный вопрос по архитектуре. Не стоит зацикливаться на этом вопросе.
5. По команде все сервера идут на центральный и делают копию таблицы в php файлах (как массив). Далее скрипты просто инклюдят небольшие куски конфига, что кешируется в ФС. Обычно такая команда поступает при выкладке нового релиза, автоматически.
Reply
Reply
Reply
Reply
Leave a comment