?

Log in

No account? Create an account

Previous Entry | Next Entry

Ближайший мастер-класс #Highload в 2016 году:

- 18 июня 2016 в Москве, билеты и запись: http://devconf.ru

- 26 июня 2016 в Санкт-Петербурге, запись: php.spb.ru/ms/sign-up.html

Новые вопросы просьба отправлять сюда:
>>> http://spb-borodin.livejournal.com/2267.html <<<

Comments

( 111 comments — Leave a comment )
Page 1 of 2
<<[1] [2] >>
demjanich
Dec. 20th, 2012 03:24 pm (UTC)
У вас есть книга или что-нибудь в этом роде по highload, что можно купить онлайн. Т.к. нет возможности посетить мастер-классы.
spb_borodin
Dec. 21st, 2012 08:23 am (UTC)
из онлайна пока есть только жж для вопросов
(no subject) - demjanich - Dec. 21st, 2012 08:30 am (UTC) - Expand
(no subject) - spb_borodin - Dec. 21st, 2012 08:48 am (UTC) - Expand
demjanich
Dec. 21st, 2012 09:42 am (UTC)
А что в это время делать этим 1000 пользователям, если они что-то обновляют в своих профайлах или добавляют что-то на ленту новостей, сохраняем в каком-то промежуточном состоянии в памяти? Каким образом?

И еще вопрос, как собирать ленту, если друзья раскинуты по разным серверам?
spb_borodin
Dec. 21st, 2012 10:09 am (UTC)
Отдыхать.. им будет написано, что сайт недоступен. Вам кажется, что это проблема? Умножьте слово проблема на 0.002%. На фоне обычных багов из-за говнокода это будет незаметно.

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

Edited at 2012-12-21 10:10 am (UTC)
(no subject) - demjanich - Dec. 21st, 2012 10:27 am (UTC) - Expand
(no subject) - spb_borodin - Dec. 21st, 2012 11:23 am (UTC) - Expand
jon_black
Jan. 21st, 2013 03:21 pm (UTC)
Друзья, а кому-нибудь удалось записаться на анонсированный мастер-класс?
spb_borodin
Jan. 22nd, 2013 07:30 am (UTC)
был в отпуске почти весь январь, поэтому на заявки никто не отвечал
(Deleted comment)
spb_borodin
Jan. 30th, 2013 11:59 am (UTC)
Re: Ваш мастер класс
Видео нет, его не будет. Записать можно, 10 минут максимум. Но зато все, кому надо, могут в любое время позже без ограничений задавать вопросы по скайпу.

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

Да, и по скайпу я вам тоже уже ответил.

Edited at 2013-01-30 12:00 pm (UTC)
(Anonymous)
Feb. 3rd, 2013 09:36 pm (UTC)
Шардинг
Обычно, в качестве параметра шардинга выбирают ID пользователя (user_id) – это позволяет делить данные по серверам равномерно и просто. Т.о. при получении личных сообщений пользователей алгоритм работы будет такой:
Определить, на каком сервере БД лежат сообщения пользователя исходя из user_id
Инициализировать соединение с этим сервером
Выбрать сообщения

Задачу определения конкретного сервера можно решать двумя путями:
Хранить в одном месте хеш-таблицу с соответствиями “пользователь=сервер”. Тогда, при определении сервера, нужно будет выбрать сервер из этой таблицы. В этом случае узкое место – это большая таблица соответсвия, которую нужно хранить в одном месте. Для таких целей очень хорошо подходят базы данных “ключ=значение”
Определять имя сервера с помощью числового (буквенного) преобразования. Например, можно вычислять номер сервера, как остаток от деления на определенное число (количество серверов, между которыми Вы делите таблицу). В этом случае узкое место – это проблема добавления новых серверов – Вам придется делать перераспределение данных между новым количеством серверов.
Users(id,avatar, city, name),
Messages(id, userid_from, user_id_to, message).
А если messages хранятся на разных серверах...
NoSQL key/value(user_id, serialize(
array('Servers' => array(
'm1' =>array('tables_name' => array('messages1','messages12'),
'm12'=>array('tables_name' => array('messages101')
)
)
а дальше images, comments, т.е таких NoSQL таблиц получается много, а не одна. На одном сервере SQL(200 000 записей), записи разбиваются 200 таблиц(в одной таблице 1000 записей. Далее сервера,таблицы переполняются. Серверов нету :), нарушаем правило 1000-записей(расширяем каждую таблицу на серверах до 2000 записей), докупаем ещё сервер, запускаем скрипт, который будет отрезать от таблиц >1000 записей и записывать на новый сервер, нужно пробегаться по NoSQL(Memcahe) таблицам и редактировать связи с новыми серверами, правильно я понимаю?
user(1:m):photos => (1:m) comments => (1:m) likes. Т.е связи один-ко-многим реализуем без JOIN-во вообще, а только с помощью NoSQL таблиц соответствий.
Вопрос в том, как поддерживать в актуальном состоянии эту структуру при добавлении новых серверов(не редактируя код), не будут эти NoSQL базы узким местом?
spb_borodin
Feb. 3rd, 2013 09:47 pm (UTC)
Re: Шардинг
> В этом случае узкое место – это большая таблица соответсвия

Как же у страха глаза велики. Не существует этой проблемы. Делаем так. Кладем табличку соответствия в файлы. Например, по 10% от таблицы на файл, всего 10 штук. Файлы просто инклюдим. Это будет кеш. В качестве альтернативы можно хранить эту информацию в локальных мемкешах или APC.

> В этом случае узкое место – это проблема добавления новых серверов –
> Вам придется делать перераспределение данных между новым количеством серверов.

Не придется. При добавлении нового сервера ничего не происходит. Вообще. Но можно:
1) Указать в карте спотов, что новых пользователей нужно завести на новом сервере.
2) Собрать 10% случайных пользователей с наиболее тормозного сервера в сети и перенести их профайлы на новый сервер. Последовательно блокируем 1000 юзеров, копируем, разблокируем. 1000 юзеров на 5 минут не будут обслуживаться. Это мелочь.
Re: Шардинг - (Anonymous) - Feb. 3rd, 2013 10:36 pm (UTC) - Expand
Re: Шардинг - spb_borodin - Feb. 4th, 2013 12:27 am (UTC) - Expand
Re: Шардинг - spb_borodin - Feb. 3rd, 2013 09:52 pm (UTC) - Expand
Re: Шардинг - spb_borodin - Feb. 3rd, 2013 09:54 pm (UTC) - Expand
spb_borodin
Feb. 28th, 2013 10:10 pm (UTC)
Тут поступил каммент от некого слушателя, который потом его стер.. но гугл помнит все, поэтому я коммент восстановил, без ссылки на жж автора.

------------------------------

Дмитрий, я был шокирован - за семь часов семинара я почерпнул аж ноль процентов нового!

Более того - я бы не позволил вам говорить многие вещи совсем, дабы не смущать молодые умы слишком уж откровенным булшитом!

за тех пару лет, как вы начали ездить, в компьютерном мире изменилось многое!

обновите свою программу ;)

ps Это говорит тот человек, которому (по словам всех присутствующих) Вы сказали "Это не важно", "Это не имеет смысла" и "Вы программист?"

pps полтора ляма уников в день (по факту)? Вы мне будете рассказывать о том, что "Когда вы будете заниматься высоконагруженым проэктом, тогда и противоречте мне"? Проверяйте инфу, перед кем вы читаете семинар. 400 серверов на этих пару людей? это смешно!
spb_borodin
Feb. 28th, 2013 10:25 pm (UTC)
Скажем, я тоже шокирован, что такие воинствующие ламеры существуют. Хотя, за годы собеседований я и более проблемных "клиентов" видел. Ну, мне-то все равно, я человек посторонний, но вы подобным поведением раскрываете перед вашими коллегами свою тотальную техническую несостоятельность. Мало того, что вы не решили ни одной задачи по существу, так вы еще и не поняли, зачем оно нужно и в чем фундаментальная проблема вашего словестного потока в виде ответа. И продолжаете это делать.

1,6М уников в сутки у соц.сети - это не тоже самое, что такое же число уников, например, в сети торрент клиентов, где есть сервера для авторизации, выдачи торрентов и сбора статистики. И не тоже самое для баннерной сети. Один сервер баннерной сети способен в сутки обслужить десятки миллионов уников. Ваш проект принадлежит к последним вариантам.
(Anonymous)
Mar. 7th, 2013 03:14 am (UTC)
Мастер-класс
Хотелось бы узнать будет ли мастер класс в Новосибирске в этом году, и когда примерно если да? Хотелось бы посетить)
(Anonymous)
Mar. 15th, 2013 09:15 am (UTC)
5tr@mail.ru
А будут ли мастер классы в Новосибирскев 2013 году?
(Anonymous)
Apr. 1st, 2013 01:10 pm (UTC)
вопрос про масштабирование
Почему Вы считаете что горизонтальное масштабирование эффективнее, чем вертикальное масштабирование + репликация + балансировщик? С точки зрения кода - не надо писать шардинг стратегии, нагрузка более сбалансированная, т.к. например 1 000 000 первых зарегистрированных пользователей, которые находятся на одном шарде, скорее всего записывались по мере добавления, и вероятность того что эти пользователи реже заходят на сайт выше, соответственно нагрузка на этот шард может быть ниже (ну или представим себе такую ситуация для абстрактного ресурса), то есть надо следить и возможно вручную перебрасывать споты. Кроме того, возможны не такие тривиальные задачи как соц сеть. Например есть данные очень большие N разных не связанных типов, M из которых могут потребоваться на странице, то есть следуя стратегиям горизонтального масштабирования, пришлось бы соединиться к М базам данным. Рассматривается, конечно, только вопрос оптимальности работы с БД, т.е. все без кэша. При вертикальном масштабировании и репликации мы всегда будем иметь только 1 соединение, разбиение на споты соответственно такое же как и при горизонтальном. Если кидать новые вставляемые данные в кэш, а вставку в БД отдать на очереди, в чем может быть явный минус такого подхода?
spb_borodin
Apr. 1st, 2013 02:29 pm (UTC)
Re: вопрос про масштабирование
> Почему Вы считаете что горизонтальное масштабирование эффективнее

Дело не в эффективности (хотя, оно действительно эффективнее и на мелких данных). Дело в том, что это единственный способ сделать проект. Вертикальное масштабирование, какие бы способы под этим не подразумевались, это для недальновидных тимлидов-консерваторов. Все привыкли так делать. На больших проектах с 1000 только sql серверов трижды вертикаль не прокатит.

> С точки зрения кода - не надо писать

Верно. Ваш подход - ничего не писать. Ну, не пишите :) А когда случится проблема, придется тратить время. Мы - это небольшое время тратим сначала, в не в день Д.

> соответственно нагрузка на этот шард может быть ниже

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

> При вертикальном масштабировании и репликации мы всегда будем иметь только 1 соединение

При горизонтальном масштабировании - тоже, ровно один коннект к базе.
Re: вопрос про масштабирование - (Anonymous) - Apr. 1st, 2013 09:02 pm (UTC) - Expand
(Anonymous)
May. 14th, 2013 07:39 pm (UTC)
Комплексные запросы.
Здравствуйте.

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

С Уважением Павел.
spb_borodin
May. 14th, 2013 10:16 pm (UTC)
Re: Комплексные запросы.
Вы описали задачу "анкетный поиск" (поиск товаров, баннеров для выдачи и т.д.). Можете посмотреть в Топфейсе, как он работает, где участвуют все анкетные поля (более 20 шт).

1. Архитектура проекта, вернее, ее часть "горизонтальное масштабирование", не имеет отношения к вашей задаче. Ее смысл - хранить 100 млн профайлов. Но не производить никаких действий, кроме читать/писать над одним из профайлов или его составляющего. Я это называю социальная информация.

2. Описанная задача - всего лишь один из компонент проекта. Это - справочная информация, т.к. уже не принадлежит юзеру. В ней задействованы только те поля, что нужны для поиска, а не весь профайл целиком. Решается задача элементарно, все запихнули в таблички (небольшая сложность, как их разбить) и далее сколько угодно сложные выборки с сортировкой на обычном sql select. С этой точки зрения, задача целиком вписывается в проект.

Поэтому
> Ведь в данном случае нельзя определить где находятся данные
ничего определять и не нужно.

Решений для полнотекстового поиска, поисковых машин и прочих узко специфичных задач у меня нет.
(Anonymous)
May. 20th, 2013 06:44 pm (UTC)
Как определить спот для создания нового экземпляра су
Здравствуйте, Дмитрий.

Я уже писал вопрос о комплексных запросах, у меня возник еще один.
У меня на одной физической машине поднято несколько инстансов MySQL на разных портах.
Каждый инстанс содержит в себе несколько шард, насколько я понял Вы их называете спотами.
Информация о коннектах к шардам расположена в конфиге приложения.
Вопрос заключается в том, как при создании нового экземляра шардируемой сущности определить шарду в которой должен быть создан экземляр, ведь значение ключа появится только после того, как будет создана запись, соответственно нужно отслеживать хотя бы общее кол-во шардируемых сущностей для расчета точки сохранения?

Т.е. пришел запрос на создание нового пользователя в соц.сети или нового сообщения на форуме, как определить где создать сущность, какие вы посоветуете стратегии?

С Уважением Павел.
spb_borodin
May. 20th, 2013 10:23 pm (UTC)
Re: Как определить спот для создания нового экземпляра
Один инстанс - это и есть шард. А в нем - споты.

Имеется карта спотов (конфиг). В ней заранее, до регистрации юзера, уже записано, где будут хранится его данные. При создании что-то делать уже поздно. Карта наполняется предварительно, с некоторым запасом вперед, по команде админа, скриптом проекта.

Созданный юзер имеет свой уникальный номер. Это автоматически дает номер спота, а все споты уже подготовлены.

И в реальности, на проде, не нужно держать на одной тачке более одного инстанса mysql.
(Anonymous)
May. 22nd, 2013 01:11 pm (UTC)
Ключи
Здравствуйте, Дмитрий.

Тут уже задавался подобный вопрос, но все же спрошу по поводу своей конкретной реализации.
Сделал 2 базы, одна из них для генерации ключей, в которой содержится одна табличка с одной bigint автоинкрементной колонкой. Новый ключ получается путем вставки в эту таблицу строки.
Вторая база отвечает за лукап ключей. В ней прописывается пара - шарда/ключ.
Терзают большие сомнения не станет ли генератор ключей узким местом и насколько рискованно так делать, ведь получается, что при падении сервера выдающего ключи создание новых экземпляров данных будет невозможно.

P.S. Рассматривал разные варианты с составными ключами, где ключ является суммой таймстампа, шарды и некого инкрементного значения, но они мне не нравятся(возможно зря, ведь такие методы используют Instagram и другие).

С Уважением Павел.
spb_borodin
May. 23rd, 2013 10:14 pm (UTC)
Re: Ключи
Практически ничего не понял в вопросе, поэтому ответить не могу.

1. Никогда не мешайте в кучу проблемы архитектуры некоторых данных и проблемы отказоустойчивости (падений). Упадет - поднимите. А если не написать вообще ничего - то и нечему будет падать .-)

2. Разумеется, все можно защитить от падений, сделав синхронные или асинхронные реплики, бекапы. После разработки.

3. Никаких сложных решений с составными ключами, хешами и т.д. Все держится на автоинкременте, вернее, его логической заменой на сиквенс. Хотя, есть важный случай, когда нужно извращаться с ключами объектов - в mongodb. Чтобы их автошардинг правильно работал, без перекоса.

4. Что в вашем понимании пара шард/ключ мне не ведомо. Шард - это сервер. Мы оперируем спотами (на одном шарде тысячи спотов). Карта спотов действительно (упомянутый lookup) в оригинале содержится в таблице, но она размножена по всему проекту, поэтому ее просто никто и не читает напрямую. Падать нечему.

В общем, спрашивайте понятнее.
(Anonymous)
May. 24th, 2013 05:55 pm (UTC)
Пояснения и материал
Здравствуйте, Дмитрий.

Извиняюсь за путаницу, это просто вопрос терминологии. Дело в том, что я не посещал ваши мастер-классы, а терминологию сформировал из найденных в интернете источников по вопросам шардирования.
То что Вы называете шардами, я зову - инстансы, то что вы зовете спотами, у меня - шарды :)

Если Вы не против, я приведу несколько ссылок на материалы.
1) http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram здесь описан путь подразумевающий составной ключ.
2) http://www.slideshare.net/ryanthiessen/mysql-conference-2011-the-secret-sauce-of-sharding-ryan-thiessen - описана смеха которая якобы используется в Facebook. В данном документе шардами называются именно споты, в этом же документе есть рекомендация по поводу поднятия нескольких инстансов MySQL на одной физической машине, а также слова о том, что в коде храниться карта именно инстансов, а не шард(в вашем случае спотов).
3) http://mysqldba.blogspot.ru/2012/02/asyncronous-shard-queries-in-php-using.html - здесь наглядный пример того, зачем нужно поднимать несколько инстансов на одной машине. Связанно это с тем, что репликация обрабатывается двумя потоками, один из которых отвечает за передачу данных, а второй за обновление данных. В результате получается ситуация когда аппаратное обеспечение способно дать производительность в 4 раза большую, чем позволяет программное обеспечение(решение для репликации MySQL). По этому человек запускает не один, а несколько инстансов и тем самым уравнивает производительность ПО и железа.
4) http://www.slideshare.net/jgoulah/the-etsy-shard-architecture-starts-with-s-and-ends-with-hard - этот вариант больше всего схож в тезисах с тем, о чем рассказываете Вы. Основывая на этом документе и на небольшом примерчике http://www.davewentzel.com/content/how-big-bigint я и принял решение использовать сиквенс и сервер с информацией о лукапах.

Спасибо Вам за ответы. Постараюсь больше не путаться в терминологии задавая Вам вопросы :)

Если у Вас есть ссылки на какие-то интересные материалы, буду очень признателен.

С Уважением Павел.
(Anonymous)
Dec. 16th, 2013 02:44 pm (UTC)
Поиск по анкетам
Читаю про всякие хайлоады, вроде все понятно с дейтингом. Кроме одного.
Интересно как вы реализовали поиск по анкетам, Сергей?
У вас есть какая-то общая база серчер для всех пользователей со слейвами?
И по этой базе вы собственно и проходитесь поиском (возраст, пол, город)?
Тогда как вы делаете поиск по юзерам "онлайн". Это же нереально на каждый чих пользователя обновлять какой-нибудь столбец со временем последней активности в серчере
spb_borodin
Dec. 16th, 2013 04:11 pm (UTC)
Re: Поиск по анкетам
В упрощенном варианте - это обычная SQL таблица, содержащая все необходимые параметры по поиску. Под каждый запрос - своя таблица. БД с такой таблицей реплицируется.

Туда в онлайне постоянно пишутся новые параметры от всех юзеров, что в онлайне. Например, получил юзер "просмотр" - мы сразу в поиске сделали "-1", т.е. понизили ему приоритет. Если юзер сам кого-то просмотрел - делаем +1 в приоритете поиска.

Еще небольшой трюк. Т.к. юзеров, все же много, в одной таблице все 50 млн юзеров хранить накладно, приходится делить.
Re: Поиск по анкетам - (Anonymous) - Dec. 16th, 2013 05:58 pm (UTC) - Expand
Re: Поиск по анкетам - spb_borodin - Dec. 16th, 2013 07:11 pm (UTC) - Expand
Re: Поиск по анкетам - (Anonymous) - Dec. 16th, 2013 09:39 pm (UTC) - Expand
Re: Поиск по анкетам - spb_borodin - Dec. 17th, 2013 10:26 am (UTC) - Expand
Re: Поиск по анкетам - (Anonymous) - May. 11th, 2014 09:33 pm (UTC) - Expand
Re: Поиск по анкетам - spb_borodin - May. 11th, 2014 09:55 pm (UTC) - Expand
Re: Поиск по анкетам - (Anonymous) - May. 11th, 2014 11:43 pm (UTC) - Expand
Re: Поиск по анкетам - spb_borodin - May. 11th, 2014 11:45 pm (UTC) - Expand
(no subject) - newordtijambiaf - Dec. 22nd, 2013 01:33 pm (UTC) - Expand
(Anonymous)
Jan. 31st, 2014 07:25 am (UTC)
Проверка уникальности данных
Доброго времени суток Дмитрий!
Если система обладает свойством перекрывать доступ на определённый промежуток времени к слотам данных (при балансировке нагрузки), то каким образом в этот момент проверяется уникальность, например, электронной почты при регистрации? И кэш здесь не поможет, если аккаунтов под 50.000.000.
Видимо, процесс копирования блокирует данные только для владельцев этих данных, а не для всех, и тем более не для самой системы. Те кто просто читают эти данные, по-прежнему получают доступ во время переноса слота. Иначе очень велика вероятность коллизий или ошибок доступа там, где этого быть не должно в принципе.

А вопрос у меня в том, как в вашей системе контролируется уникальность соответствующих данных?
spb_borodin
Mar. 19th, 2014 10:58 pm (UTC)
Re: Проверка уникальности данных
Засуньте все 50 млн адресов в одну таблицу. Таблицу на центральном сервере. Обновления спотовых серверов эту таблицу никак не затронут. Боитесь нагрузки на таблицу? Она будет мизерной. Пару запросов на каждую регистрацию, т.е. не больше 1 запроса в секунду при скорости регистрации 30млн юзеров в год. Это ничто на фоне общей нагрузки. Разумеется, такую независимую таблицу можно разбить, засунуть в репликацию и пр. при малейших подозрениях в тормознутости.

Кеш вообще не имеет отношения к хранению данных и вычисления с ними. Ускоряет - да. Но не влияет на логику.

Вот именно так и контролируется. На центрально сервере под что-то создали сразу 10 таблиц и пишем туда, не паримся.
(Anonymous)
Mar. 19th, 2014 10:49 pm (UTC)
ORM
Используете ли вы какой-либо ORM?
spb_borodin
Mar. 19th, 2014 10:53 pm (UTC)
Re: ORM
Нет. Использовать его - огромный регресс собственных способностей.
Re: ORM - (Anonymous) - Mar. 20th, 2014 12:58 pm (UTC) - Expand
Re: ORM - spb_borodin - Mar. 20th, 2014 03:28 pm (UTC) - Expand
Re: ORM - (Anonymous) - Mar. 20th, 2014 10:00 pm (UTC) - Expand
Re: ORM - spb_borodin - Mar. 20th, 2014 11:01 pm (UTC) - Expand
(Anonymous)
Jun. 17th, 2014 09:25 pm (UTC)
Очереди
Здравствуйте, бы у вас а мастер-классе devconf 2014.
Не сосвсем понял как у вас устроены очереди. Те получается сначало приходит какоето событие и его php код ложит в очередь, затем асинхронно другие php worker-ы берут из очереди события и пишут их в базы или очереди хранят http запросы?

Вы говорили что очереди могут сутки копить события пока решаются возможные проблемы с их обработчиками, а кто в это время отдает пользователям страницы?
spb_borodin
Jun. 18th, 2014 03:29 pm (UTC)
Re: Очереди
Первый скрипт (веб-контроллер) проверяет действие юзера, его пост/гет запрос: авторизация, валидация данных и т.д. Этот скрипт делает все, кроме непосредственной записи в SQL, т.к. эта операция может зависнуть. Далее кидаем измененный объект в очередь (либо целиком его, если поместится, либо какой-то id). Возможно, не в одну очередь, а сразу в 5, если в сохранении изменения объекта заинтересованы разные компоненты системы (запись профайла, поиск, расчет ТОП, контроль спама, статистика).

Очереди хранят сериализованные объекты (массивы из php). HTTP хранить не нужно. Этим занимается nginx.

Если обработчик данных не работает (сломали что-то), то очередь не разбирается. Юзера видят старую не обновленную информацию. На чтение мы все выдаем из базы на прямую. Запись - откладываем.
Re: Очереди - (Anonymous) - Jun. 19th, 2014 07:11 am (UTC) - Expand
Re: Очереди - spb_borodin - Jun. 19th, 2014 09:10 am (UTC) - Expand
(Anonymous)
Jun. 18th, 2014 04:06 am (UTC)
Здравствуйте, был на вашем мастер классе devconf 2014
Как я понимаю для стартапа главное предусмотреть шардинг основной сущности по спотам, вопрос что еще стоит предусмотреть сразу а что отложить на будущее?
spb_borodin
Jun. 18th, 2014 03:24 pm (UTC)
Да, план минимум - начать хранить все основные данные в SQL таблицах с учетом разбивки на споты. Обязательно заведите 2 инстанса sql, чтобы баги отлавливались еще на этапа разработки. Здесь же - разделение между хранением информацией и поисковыми таблицами для поиска/сортировки.

Еще - максимум слабой связности проекта. Чтобы разные компоненты проекта ничего не знали друг о друге. Я показывал пару слайдов об этом на примере с поиском и очередями. Это уже касается культуры программирования, а не схемы хранения данных.
вопрос по спотам - (Anonymous) - Jun. 19th, 2014 07:22 am (UTC) - Expand
Re: вопрос по спотам - spb_borodin - Jun. 19th, 2014 09:20 am (UTC) - Expand
Re: вопрос по спотам - (Anonymous) - Jun. 20th, 2014 10:58 am (UTC) - Expand
Re: вопрос по спотам - spb_borodin - Jun. 20th, 2014 11:02 am (UTC) - Expand
(Anonymous)
Jun. 19th, 2014 01:26 pm (UTC)
Снова о спотах
Дима, здравствуйте!

Был на мастер-классе на DevConf, но хочется еще немного уточнить: в споте хранится вся информация, связанная с пользователем (или с другой главной сущностью в проекте), поэтому зная id пользователя мы можем сразу выбрать все данные связанные с ним через JOIN внутри спота. Но что делать, если есть еще другие сущности (например, сообщения), не относящиеся к пользователю? Как узнать, в каком споте будет сообщение id=XXX? Создавать справочник, в котором по id сообщения можно узнать id пользователя, а потом уже выбирать данные из спота данного пользователя?
Или, например, есть еще товары, которые к пользователям никакого отношения не имеют. В каком споте хранится товар id=1234?
spb_borodin
Jun. 19th, 2014 01:38 pm (UTC)
Re: Снова о спотах
http://spb-borodin.livejournal.com/1453.html?thread=193453#t193453
Только что ответил на подобный вопрос. Ок, еще разок.

Спот - это набор всех SQL таблиц, хранящих инфо обо всей жизнедеятельности 1000 юзеров.

1. Юзером может быть профайл пользователя (его сообщения, профайл, стена, фотки), товар, группа, страница с комментами (новости, блог, СМИ) и т.д. Да, под объектом USER может скрываться совершенно разное. Ничего страшного в этом нет. У реального юзера будут задействованы таблицы photo, message, а в таблице, описывающим характеристики товара (т.к. текущий объект юзер, а не товар), будет пустота. У USER, в котором скрывается товар, будут пустые таблицы с сообщениями, зато таблица с описанием товара будет заполнена.

2. Если юзер и товар кардинально отличаются, то заведите 2-3 спотовых пространства. Одно - на профайлы юзеров. Второе - на товары. Но эти объекты очень похожи: профайл (куча неструктурированных полей), фото людей и товара, комменты на доске и т.д.

3. Сообщения - это часть социальной информации, не отделима от юзера. Хранится в отельной таблице. И согласно пункту 2 можно завести отдельное спотовое пространство, только для таблиц с сообщениями. Информация о товаре - это тоже соц.информация, принадлежащая товару. Близкий аналог товара - группа. А разницы между юзером и группой практически нет. Товары к юзерам отношения не имеют, это верно. Товар - это другой юзер. Юзер юзеру - независимый равноправный объект.

4. Ограничьте число сообщения юзера до 100 000 и не занимайтесь надуманной проблемой, что делать со спаммерами, написавшими 100 001-е сообщение.
gorazio82
Jun. 24th, 2014 07:46 am (UTC)
А не могли бы вы поделиться скриптом для бекапов базы?Ж)
spb_borodin
Jun. 24th, 2014 07:48 am (UTC)
Не в курсе, как оно работает. Админская задача.
(Anonymous)
Jun. 25th, 2014 01:13 pm (UTC)
Андрей
Здравствуйте!
Вопрос по LEFT JOIN.
При таком соединении все последующие таблицы "лепятся" на равных условиях к первой или каждая "лепится" в связке с предыдущей, и третья, к примеру, работает с результатами только второй, но не первой? Спасибо заранее!
spb_borodin
Jun. 26th, 2014 08:19 pm (UTC)
Re: Андрей
Хм, я могу ошибаться с объяснением этого вопроса.

По JOIN таблицы не лепятся, а группируются (не знаю, точного слова). К каждой строке первой таблицы лепится копия второй таблицы. Да, сколько строк, столько раз это и будет сделано.

Но, в запросе, разумеется, будет написано
LEFT JOIN table2 ON table1.id=table2.id

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

LEFT JOIN table2 ON table1.id=table2.id
и
LEFT JOIN table2 ... WHERE ... table1.id=table2.id

В общем, берем очередную строку из первой таблицы столько раз, сколько строк с совпадающим ID найдено во второй. Далее, эту итоговую таблицу еще раз так же лепим/группируем со всеми строками третьей таблицы (но отбрасываем все лишние комбинации по "ON" правилу). И так далее, со всеми JOIN. Потом на итог накладывается WHERE, GROUP, ORDER, LIMIT и фильтр по выдаваемым полям из начала SELECT.
(Anonymous)
Jun. 26th, 2014 07:43 pm (UTC)
Здравствуйте. Я хочу уточнить насчет синхронизации и атомарности SQL. Вы говорили про необходимость обеспечения атомарности отельных запросов или группы запросов?
spb_borodin
Jun. 26th, 2014 08:13 pm (UTC)
Атомарность нужна там, где этого требует логика. Кроме программиста, написавшего кусок кода (включая SQL), никто на это не ответит :)

И если атомарность нужна, то на уровне группы запросов, разумеется. Один запрос сам по себе всегда и так атомарен. Нет неатомарных команд, не только в SQL, а практически нигде =)

Пример 1. Статистика. Скрипт ставит +1 в 3 таблицы. Просто 3 апдейта, без разницы, в каком порядке. Атомарность не нужна.

Пример 2. Взять число из первой таблицы, вычислить синус, записать ответ во вторую таблицу, а в первую 3-й знак после запятой. Тут никак не обойтись без атомарности всех запросов, иначе в базе будет бардак и условие не выполнится, все помешают и параллельно перезатрут данные друг друга.
(Anonymous)
Jun. 27th, 2014 10:04 am (UTC)
Откуда споты
Дмитрий, очень интересно узнать а откуда и как появилась идея со спотами?
и была ли она в первое версии topface на ruby?
spb_borodin
Jun. 27th, 2014 11:06 am (UTC)
Re: Откуда споты
Эта идея старая, была придумана за много лет до Топфейса. А самая первая версия, что была на Руби, вообще не имели никакого масштабирования.
(Anonymous)
Jun. 27th, 2014 10:16 am (UTC)
Почему шардинг базы?
Дмитрий, еще интересно узнать почему вы выбрали вариант с горизонтальным масштабированием базы хотя многие крупные проекты обошлись без этого? Например фотострана многое решила за счет c++ и кешей, ifunny перешли на mongodb итд
spb_borodin
Jun. 27th, 2014 11:13 am (UTC)
Re: Почему шардинг базы?
Да, я слышал один раз доклад по структуре фотостраны. Масштабирование это назвать сложно. Там реально все данные в одной таблице. Хоть обвешайся кешами, а проблему отсутствия масштабирования в этом проекте это не решит.

Монго - примерно на 50% повторяет идею горизонтального масштабирования. Является неуправляем, подвисающим, неоптимальным черным ящиком, который, по идее, должен все реализовать. Начинающие программисты им очень восхищаются, т.к. это дает возможность скинуть на дядю (черный ящик) самую главную фичу их проекта - масштабирование. В некоторых небольших проектах работает. Опытные программеры, хлебнувшие горя, выпиливают его отовсюду и никому не рекомендуют повторять ошибок. Но, для мелкого проекта, на пару серверов максимум, это удобно и прокатит.

Помимо честного горизонтального масштабирования, когда любой компонент системы реально разбить еще на N частей и так до бесконечности, никаких иных вариантов нет.
Page 1 of 2
<<[1] [2] >>
( 111 comments — Leave a comment )