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

whirlwind

TDD infected, paranoid
>Особенно умиляет пункт 3. Оптимизация транзакций. Так не делай транзакцию, мля .-)

Слушай, тебе реально на рынок пальцами разводить. Такое ощущение, что с задачами сложнее увеличить счетчик ты просто никогда не сталкивался. 4 часа втюхивать про cas и блокировки, ну это хайлоад, согласен. Засчитывайте слив.
 

zerkms

TDD infected
Команда форума
А готовых инструментов для обеспечения целостности в рамках распределённого хранения данных, я так понимаю, пока не существует
atv
В оракле есть распределённые транзакции. Позволяют поддерживать целостность на ферме серверов.
 

atv

Новичок
Слушай, тебе реально на рынок пальцами разводить. Такое ощущение, что с задачами сложнее увеличить счетчик ты просто никогда не сталкивался.
Коллеги, давайте вернёмся в мирное русло. Мне кажется есть определённое недопонимание.
Как я понял, Дима хочет сказать что вместо транзакций можно использовать блокировки, рассматривая проблему только в условиях многопоточности. А whirlwind (не знаю имени), подразумевает ещё такой аспект транзакций как rollback, в случае провала какой либо операции по обновлению данных. Блокировки этого не дают. Значит, очевидно, нужно самостоятельно об этом заботиться.
 

atv

Новичок
В оракле есть распределённые транзакции. Позволяют поддерживать целостность на ферме серверов.
Уже хорошо, значит задача решаема. Жаль, только, что дороговатое решение :(
 

DiMA

php.spb.ru
Команда форума
atv

Нет, это не пример, все реально. Если хранить много разной информации о юзере (топике, товаре), то проще использовать те же самые таблички. Зачем мучаться с nosql? Не надо. Предположим, мы реализовали полную архитектуру в текущем развитии проекта. А сегодня вдруг нужно срочно добавить новый компонент. Пусть это будет фотоальбом (обычный список на каждого юзера - url, название, размер и т.д.). Нужно сеть и подумать, что выгоднее - sql, nosql или что-то совместное. Для подобных простых компонент выход очевиден - нужно завести таблицу. Как это сделать для всех десятков млн юзеров - тема отдельная (это уже все реализовали на предыдущих этапах развития проекта). Программисту остается сделать следующее:
1. Открыть Txt файл, дописать "CREATE TABLE + структура" (или модифицировать старые таблицы, добавив новые поля туда).
2. Запустить скрипт апдейта базы, дождаться его исполнения (например, через сутки). Только набрать имя скрипта + ентер нажать.
3. Сразу начать писать sql запросы в новом классе, который будет просто читать и писать эту новую таблицу.
4. Как только модель данных готова, у главного объекта USER появляются новые методы, объекты и т.д. (архитектура скрыта, новые объекты появились).

Другой вид информации не нужно хранить в табличках, т.к. будут тормоза. Надо думать головой. Например, статистику просмотра этих фоток не нужно писать в базу, ляжет. Заводим пул мемкешей. Т.к. это вне удобной системы спотов, то нужно программить чуть больше и головой думать о балансировке. Как хранить реальные деньги - тоже надо думать головой. Очевидно, отдельный пул серверов с максимум изоляции и записью транзакций на диск. А остальные, не биллинг сервера, хоть и имеют транзакции, но не пишут их на диск + пониженная изоляция. Уже благодаря только этому обычная тормозная транзакция, мгновенно кладущая HDD, начинает более менее работать, не упираясь в жесткий диск.

zerkms
У нас без оракла есть эмуляция транзакций на несколько SQL серверов и MEMCACHE сервер (который вообще их не имеет, тем более отката не имеет даже в теории). Не таких настоящих, конечно, как у Оракла, но все же.. Я про это пару слов говорил, как делать. Весьма редкая фишка. И кто будет ставить Ораклы в хайлоде? Денег много на десятки инстансов? Приходится извращаться с тем, что есть.

> Слушай, тебе реально на рынок пальцами разводить.

Я высказал предельно четкие ответы на твои упреки. Никаких пальцев. Ни на один из них ты не среагировал и не ответил. Хотя, после антипаттерна "Я Пастернака не читал, но хочу заявить..." уже не о чем говорить и троллинг очевиден .-)
 

whirlwind

TDD infected, paranoid
atv да полно примеров. Самый частый - запрос во внешнюю систему. Как ты данные оптимально не храни у себя, тут зависимость от третьей стороны. Транзакцию делать нельзя ибо она непозволительно-длинная. Что делать? Или например, есть update-сервер который принимает транзакции на переводы средств. Но 100500 клиентов хотят быстро видеть свои переводы. Что делать? Вот это и есть необходимость оптимизации структуры под задачу. А некоторые просто не понимают про что это я написал. Потому что сложностей кроме объема прокачанных данных у них нет.
 

atv

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

zerkms

TDD infected
Команда форума
atv
Ещё критерии - как доставать :) Другими словами - какая информация у тебя уже будет для того, чтобы выбрать из KV хранилища.
 

DiMA

php.spb.ru
Команда форума
Так ты напиши конкретно, что за данные-то.
 

atv

Новичок
Так ты напиши конкретно, что за данные-то.
Ну не буду же я постоянно обращаться к тебе. Поэтому и хотел бы получить обобщённый ответ, если такой возможен.

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

Или например, есть update-сервер который принимает транзакции на переводы средств. Но 100500 клиентов хотят быстро видеть свои переводы.
Как быстро? Через минуту, через секунду? Очередь, про которую была речь на мастер классе не подходит? Если нет, то почему?

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

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Я тут собеседовал одного паренька недавно, он сильно и подробно хвалил symfony.
Когда я сказал, что symfony довольно тяжелый и громоздкий, он ответил: "Какая разница, главное - честное горизонтальное масштабирование".
О, думаю - Дима поработал! :)
 

Koc

Новичок
а что такое честное горизонтальное масштабирование? бывает лживое?

у меня невольно ассоциации сразу с объявлениями: "правильный хостинг", "правильный перевод", "куплю правильную двухкомнатную квартиру". Это как ваще??!
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
это просто фраза, которую Дима часто использует в своих статьях и, как я понимаю, выступлениях
речь изначально шла о том, что надо не экономить на архитектурных элементах, а строить систему, которую легко развернуть
но люди все понимают по-своему, запоминают лозунги - и вперед
 

DiMA

php.spb.ru
Команда форума
Koc

бывает, что тюлени ставят nginx, осваивают get/set в мемкеше и думают, что пришел хайлод с масштабированием
 

fixxxer

К.О.
Партнер клуба
Интересно как он собрался Честно Горизонтально Масштабировать symfony.

Там вроде даже банального партишенинга нет. Не, ну понятно, что можно кулаком вбить, но, я так понимаю, речь об этом не шла.
 

AmdY

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