Мастер-класс по #Highload: 21 марта в Новосибирске и 7 апреля в Киеве. Просьба ретвитнуть!

HraKK

Мудак
Команда форума
Так будь добр обоснуй это.
У тебя какой опыт преподавания есть?
Сперва добейся. Что, опыт с хайлоадом уже не надо доказывать?

не согласен с манерой
Я не согласен с количеством и качеством информации. А манера как раз у тебя очень хорошая.

Но это не значит, что нужно поступать, как ты.
Честно сказать что я не получил того что хотел? Возможно 99% получили, а я нет. Так что мое мнение засунуть в унитаз? Имеешь полное право, отправь его туда. Ну или задумайся, возможно надо что-то добавить к мастер-классу, а не наезжать на конструктивную критику в стиле местных ламеров, которые пишут что я говно и ничего не шарю. Я такое каждый день слушаю и еще буду слушать. Если ты видишь в критике только деструктив - пропускай ее между ушей.

по сути - лоад балансер шардов. А конкретнее - разве что за пивом, я в конференции не устраиваю и мне за мои знания к сожалению платят только на работе)
 

DiMA

php.spb.ru
Команда форума
Хм.. прекратить троллинг ты не хочешь. На кону весит мочало, начинаем все с начала? .-)
1. Ты посетил 1/3 мастер-класса. На этой основе строишь заключения. Это автоматически дискредитирует все твои дальнейшие заявления.
2. Где "вода"? Теории у меня было 20 минут. Далее одна чистая практика с обучением.
3. С какой целью вести себя на мастер-классе в позе "Все лохи, я понимаю тему, скучно"? Где минимальное уважение к окружающим?
4. Почему не подошел в обед и не представился? Вроде, это по-человечески разумно так делать.. Кагбэ поздно кулаками махать, опосля-то...
5. Почему не сообщил, что у тебя есть высоконагруженный проект? .-)
6. Ты заявил, что сделал что-то лучше. а) Лучше чего, если ты не в теме. б) Поделись же с народом подробностями.
7. Когда на devconf выступают разработчики PHP с кратким анонсом будущей версии, ты плюешься в них, ибо и так все знаешь? .-)
8. Твое мнение обосновано. Никто его в унитаз не спускает (повторно - не сочиняй за меня то, что я не говорил). Ознакомься плз с пунктами выше.
 

whirlwind

TDD infected, paranoid
DiMA я думаю, нужно обязательно первыми предложениями в вашей программе указать:
1. лоад балансера не будет
2. масштабирования SQL не будет
 

DiMA

php.spb.ru
Команда форума
whirlwind шутишь так? Это все есть. Собственно, основная мысль, как балансировать и масштабировать.
 

HraKK

Мудак
Команда форума
4 часа рассказывать про то что шардинг лучше не делением, а ренжем, а поддержку атомарности мемкеш адд? Окей, это не вода. А чистая практика.
Я сливаюсь)

П.С. Маштабируемость SQL используя ее как non-SQL, ничего не имеет общего с маштабированием SQL.
 

DiMA

php.spb.ru
Команда форума
Ты как и прежде, не признал ни единой ошибки и пишешь новые глупости. Основная презентация по архитектуре сводилась к масштабированию данных именно в SQL. No-SQL переводится как "не только SQL", т.е. думание головой не отменялось.
 

whirlwind

TDD infected, paranoid
DiMA да, есть. Ответы на интересующие меня вопросы я получил в течение первых 30 минут. Твои личные слова
- автоматической балансировкой мы не занимаемся, потому что это сложно
- структуру данных мы не меняем, потому что это дорого (соответственно привет все последующие вопросы о выборе datasource)
Только я так и не понял, почему за это нужно было предварительно заплатить?

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

craz

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

DiMA

php.spb.ru
Команда форума
Значит, ты очень хреново слушал. И этого мало, теперь несешь херь.

1. База данных и вся система полностью готовы к миграции данных. Другой вопрос, кто запускает на это команду - админ или скрипт. Заранее сказать, когда и как это понадобится нельзя. Сначала мы храним все в удобном виде, пригодным к миграции и балансировке, только потом, при реальной необходимости используем возможности. Если потребности нет, никто не будет писать никаких управляющих скриптов (преждевременная оптимизация). Я в шоке, если столь простую мысль не понять...

2. Да, базу обновлять очень дорого. И написанный код тоже. Поэтому архитектура позволяет без усилий клепать новые компоненты в проект, не трогая ничего ранее созданного. Каждая новая табличка автоматически входит в систему спотов, к которой применяются общие законы (например, миграция). К примеру, чтобы создать новой компонент из нескольких полей данных - ничего не надо, все готово (берешь и пишешь их). Чтобы создать компонент, которому требуется 2 таблички: добавить их структуру в спец. файл (create table...), запустить скрипт обновления базы (ентер нажать). И все готово, можно писать модель данных, которая оперирует новыми таблицами. Все остальное в проекте уже готово. И самое главное - абстракция. Объект USER может быть применен для любого набора сущностей в проекте! Например, в веб-магазине им может быть товар (описание, комменты и т.д.), группа с перечнем товаров, отдельная страница комментов и т.д.

Практически нет веб-проектов, которым бы эта архитектура не подошла на 100%. Разумеется, твиттер, чаты и бизнес-задачи - не подойдет (подобные задачи являются мелкими компонентами, частным случаем, на что готовых решений конечно нет). Раз ты упомянул о неком проекте, так будь добр его описать. А не сочинять за других что подойдет, а что нет. И какие советы я пропустил мимо ушей.
 

whirlwind

TDD infected, paranoid
DiMA Ты слепой или какой? Я не спорю с твоими тезисами, я с ними согласен. Я говорю что я не получил того, за чем пришел. Вариантов тут немного: либо все 4 человека с моей команды (включая меня) которые там были - тупые и хреново слушают, либо у вас мутная программа мастер-класса. Уберите из программы то, чего у вас нет на мастер-классе - это и есть совет, который ты никак не хочешь услышать.
 

DiMA

php.spb.ru
Команда форума
1. Опиши свой проект.
2. Что ты хотел получить и в чем именно я слеп, по пунктам. Все свои ошибки я исправлю, если они есть. Спасибо за критику. Не нужно твердить, что я ничего не замечаю.
3. Единственное, что ты *конкретно* написал - про балансировку и неизменность структур, как некоторый косяк. Я тебе ответил, что ты ошибаешься чуток. Кроме тезисов, еще есть решения, которые их воплощают.
 

whirlwind

TDD infected, paranoid
У нас бизнес-проекты, по этому целостность данных критична. Функционал у нас не нарастается, а расширяется - это что касается неизменности структур. Это не косяк. Это то, в чем наши подходы не могут совпадать принципиально - согласно нефункциональным требованиям.

Что я надеялся услышать:
1. роуминг данных по нодам с последующей балансировкой
2. оптимизация существующих структур под требования новой задачи
3. оптимизация транзакций
4. тестирование
5. развертывание

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

Из программы, например что означает фраза "Оптимизация SQL - это не EXPLAIN"? В вашем случае она означает, что вы используете простые запросы. В нашем случае она означает что информация дублируется в специальном виде (например свернутые остатки по счетам). И там и там explain нужен мало. Это самый яркий пример неоднозначности в программе мастер-класса. Но по сути, там почти в каждом пункте интрига ощущается, чего быть не должно имхо.
 

DiMA

php.spb.ru
Команда форума
Давай возьмем абстрактный крупный проект. Основная сложность - как хранить базовые сущности по сотням серверов. Сущность - профайлы юзеров с произвольным набором таблиц, которые могут быть товаром, топиком и т.д. Самая-самая базовая часть обучения - это как именно нужно хранить (читать/писать) профайлы (+куча связных таблиц компонент), чтобы легко выжить при бешеном росте проекта, чтобы в любой момент времени программист смог добавить любой новый функционал. Какие потребности могут возникнуть? От элементарных - организовать поиск, сортировку, фильтрацию по сущностям. До более сложных и заранее непрогнозируемых - например, биллинг, как в твоем случае.

Проблема в том, что ты не видишь общей картины. Уже говорил про "компанию-одного-проекта" - сидите делаете местные костыли, не видя аналогий. Сначала нужно идеально решить самые азы, как хоть что-то хранить, чтобы потом этот метод боком не вышел (считай, каждый день новый функционал добавляем/расширяем). Только потом нужно думать, как выгоднее делать отдельные компоненты. А ты меня упрекаешь, будто я дурак, не подумал о компонентах. Так вот, базовая нагрузка будет заключаться в примитивном характере запросов (но ее много!). Поэтому explain там ни в одном глазу не понадобится (ну, пару раз, когда впервые индекс создан). Нужны оптимизации иного рода.

Далее. Про один из таких компонент я рассказывал. Я раз десять за день повторял, но судя по топику не все тролли поняли... Одно дело - как хранить профайлы поштучно (оперировать сразу 3-мя и более профайлами запрещено - слишком тяжело для хайлода). Другое дело - как сделать компонент, который оперирует всем множеством профайлов. Не ими самими, а только их свойствами. Пример компонента - анкетный поиск по нескольким характеристикам. Этот компонент никакого отношения к системе спотов не имеет. Там нужно чуть-чуть думать об explain. Почему? Потому, что основная забота не как запрос составить (он сложнее, но по прежнему простой), а как оптимизировать общий доступ на самый узкое место компонента - большую поисковую таблицу.

Следующий компонент - твой биллинг. Это просто один из компонент. Не имеет никакого отношения ни к спотам, ни к поиску, ни к чему. Это отдельные сервера с повышенным уровнем изоляции транзакции (не повышенный, а стандартный, это везде в округе - пониженный и транзакции не пишутся на диск ради скорости). Как сделать этот или десятки других возможных компонент чьих проектов - я не знаю, не думал и этому невозможно обучить за 8-10 часов. Ты надеялся, что я забью на общую структуру и сосредоточусь на этом компоненте? Нет, это невозможно. Такие же отдельные компоненты - это сбор отчетов по системе (бизнес-логика), чаты (IM) и пр. Самое главное - как сделать такие отдельные компоненты программисты догадаются сами. Не дураки. И разумеется, если у вас проект это целиком система документооборота (некий компонент в моем понимании), то к большим веб-проектам это не просто отношения не имеет.

Просто нонсенс какой-то... как вам вдвоем в голову пришло нихера не прослушать и придти сюда меня учить? Что за вопросы "Что означает моя фраза ...."? Это же мегапиздец и троллинг. Я рассказывал об этом. Или мне письменно тут пересказать? Напиши мне что-нибудь по делу конкретное - вот тут ошибаюсь, это лучше сделать по другому. Я учту свои ошибки и скажу спасибо. Но на фоне того, как вы облажались с задачей на атомарность (вы же опытные, хайлод есть), то уровень твоих упреков меня немного смущает... Не знать SELECT FOR UPDATE и теорию изоляции транзакций - позорище высшей степени для *умудренных опытом* хайлодщиков (кто с хайлом не сталкивался, этим не интересовались, это простительно).

По твоим пунктам.
1. Я не знаю, что ты под нодой подразумеваешь. Видимо, вся тачка или инстанс целиком. У меня другие представления о "ноде". Более абстрактные и подходящие под любой веб-проект (кроме оговорок, все уже озвучивал).
2. Более непонятно написать не мог? .-) Или ты все про свой проект... надеялся, я телепатически это узнаю и с темой угадаю?
3,4,5. Подробно рассказывал.

Особенно умиляет пункт 3. Оптимизация транзакций. Так не делай транзакцию, мля .-) Я при вас это рассказывал. Смысл оптимизации не транзакцию улучшать, а придумать метод хранения информации так, чтобы данные надежно можно было модифицировать за счет базовой атомарности обычных команд, типа UPDATE ... x=1 WHERE x=0 (тоже позорище, вы не называли способа). Разумеется, не всегда возможно.
 

zerkms

TDD infected
Команда форума
DiMA
Пардон что влазию. Никого не защищаю, никого не обвиняю, просто интересно про атомарность в контексте запроса вида "UPDATE ... x=1 WHERE x=0". Это же де-факто. Как он может быть неатомарен? Или если теоретически может быть - тогда я не знаю смысла термина "атомарность".
 

HraKK

Мудак
Команда форума
Не знать SELECT FOR UPDATE и теорию изоляции транзакций - позорище высшей степени для *умудренных опытом* хайлодщиков
Я этого не знал?:)
как вам вдвоем в голову пришло нихера не прослушать и придти сюда меня учить?
Извините о великий! Удаляюсь с ваших глаз дабы не мусолить Ваш ангельский взор.
 

DiMA

php.spb.ru
Команда форума
Разумеется, де-факто. В некоторых случаях, если чуть более извращенно хранить данные в базе, можно транзакцию выкинуть и обойтись просто апдейтами. Вот где заключается суть оптимизации транзакций, а не насколько вы Explain умеете анализировать. Выкидывание транзакций (которые по дефолту на диск пишут и на максимальном уровне изоляций пашут) - огромный прорыв по скорости. Остается только придумать этот способ. Про это я вещал.

Да-да, все всё знают. После драки поздно кулаками махать.
 

craz

Нестандартное звание
классно вы друга потроллили)) и опять про хайлоад)
 

atv

Новичок
У нас бизнес-проекты, по этому целостность данных критична.
То что мастер класс не охватывает всех типов проектов (и бизнес в частности), неоднократно упоминалось и до мастер класса и на самом мастер классе. Так что тут твоё упущение whirlwind.
Что касается целостности данных, то тема на самом деле волнующая. Имея дело с SQL и транзакциями мы имеем готовые инструменты для обеспечения целостности, и в тоже время проблему с производительностью и масштабируемостью. А готовых инструментов для обеспечения целостности в рамках распределённого хранения данных, я так понимаю, пока не существует. Значит, придётся решать задачу обеспечения целостности самостоятельно. Если справитесь и разработаете хорошие инструменты, то придём на ваш мастер класс whirlwind :)


DiMA, всё забываю спросить, когда рассказывали про споты то в качестве хранилища использовали SQL базу. То что используется SQL база, это просто как пример? Или в данном случае действительно лучше использовать SQL чем NoSql решения? Если лучше то чем? А что если сделать те же споты на NoSql?
 
Сверху