Давай возьмем абстрактный крупный проект. Основная сложность - как хранить базовые сущности по сотням серверов. Сущность - профайлы юзеров с произвольным набором таблиц, которые могут быть товаром, топиком и т.д. Самая-самая базовая часть обучения - это как именно нужно хранить (читать/писать) профайлы (+куча связных таблиц компонент), чтобы легко выжить при бешеном росте проекта, чтобы в любой момент времени программист смог добавить любой новый функционал. Какие потребности могут возникнуть? От элементарных - организовать поиск, сортировку, фильтрацию по сущностям. До более сложных и заранее непрогнозируемых - например, биллинг, как в твоем случае.
Проблема в том, что ты не видишь общей картины. Уже говорил про "компанию-одного-проекта" - сидите делаете местные костыли, не видя аналогий. Сначала нужно идеально решить самые азы, как хоть что-то хранить, чтобы потом этот метод боком не вышел (считай, каждый день новый функционал добавляем/расширяем). Только потом нужно думать, как выгоднее делать отдельные компоненты. А ты меня упрекаешь, будто я дурак, не подумал о компонентах. Так вот, базовая нагрузка будет заключаться в примитивном характере запросов (но ее много!). Поэтому explain там ни в одном глазу не понадобится (ну, пару раз, когда впервые индекс создан). Нужны оптимизации иного рода.
Далее. Про один из таких компонент я рассказывал. Я раз десять за день повторял, но судя по топику не все тролли поняли... Одно дело - как хранить профайлы поштучно (оперировать сразу 3-мя и более профайлами запрещено - слишком тяжело для хайлода). Другое дело - как сделать компонент, который оперирует всем множеством профайлов. Не ими самими, а только их свойствами. Пример компонента - анкетный поиск по нескольким характеристикам. Этот компонент никакого отношения к системе спотов не имеет. Там нужно чуть-чуть думать об explain. Почему? Потому, что основная забота не как запрос составить (он сложнее, но по прежнему простой), а как оптимизировать общий доступ на самый узкое место компонента - большую поисковую таблицу.
Следующий компонент - твой биллинг. Это просто один из компонент. Не имеет никакого отношения ни к спотам, ни к поиску, ни к чему. Это отдельные сервера с повышенным уровнем изоляции транзакции (не повышенный, а стандартный, это везде в округе - пониженный и транзакции не пишутся на диск ради скорости). Как сделать этот или десятки других возможных компонент чьих проектов - я не знаю, не думал и этому невозможно обучить за 8-10 часов. Ты надеялся, что я забью на общую структуру и сосредоточусь на этом компоненте? Нет, это невозможно. Такие же отдельные компоненты - это сбор отчетов по системе (бизнес-логика), чаты (IM) и пр. Самое главное - как сделать такие отдельные компоненты программисты догадаются сами. Не дураки. И разумеется, если у вас проект это целиком система документооборота (некий компонент в моем понимании), то к большим веб-проектам это не просто отношения не имеет.
Просто нонсенс какой-то... как вам вдвоем в голову пришло нихера не прослушать и придти сюда меня учить? Что за вопросы "Что означает моя фраза ...."? Это же мегапиздец и троллинг. Я рассказывал об этом. Или мне письменно тут пересказать? Напиши мне что-нибудь по делу конкретное - вот тут ошибаюсь, это лучше сделать по другому. Я учту свои ошибки и скажу спасибо. Но на фоне того, как вы облажались с задачей на атомарность (вы же опытные, хайлод есть), то уровень твоих упреков меня немного смущает... Не знать SELECT FOR UPDATE и теорию изоляции транзакций - позорище высшей степени для *умудренных опытом* хайлодщиков (кто с хайлом не сталкивался, этим не интересовались, это простительно).
По твоим пунктам.
1. Я не знаю, что ты под нодой подразумеваешь. Видимо, вся тачка или инстанс целиком. У меня другие представления о "ноде". Более абстрактные и подходящие под любой веб-проект (кроме оговорок, все уже озвучивал).
2. Более непонятно написать не мог? .-) Или ты все про свой проект... надеялся, я телепатически это узнаю и с темой угадаю?
3,4,5. Подробно рассказывал.
Особенно умиляет пункт 3. Оптимизация транзакций. Так не делай транзакцию, мля .-) Я при вас это рассказывал. Смысл оптимизации не транзакцию улучшать, а придумать метод хранения информации так, чтобы данные надежно можно было модифицировать за счет базовой атомарности обычных команд, типа UPDATE ... x=1 WHERE x=0 (тоже позорище, вы не называли способа). Разумеется, не всегда возможно.
