Здравствуйте!
Скажем, есть некая сущность, назовем ее "фича". Фич имеется 18 штук, в будущем возможно увеличение их количества.
У каждой фичи разумеется есть ряд своих свойств, но это не суть. Все фичи лежат в отдельной таблице.

Так же есть сущность "юзер", у которого так же отдельная таблица и нобор своих индивидуальных свойств.
Юзеров много, пусть будет 5 млн. они расшардины скажем на 5 серверов по табличкам в 50 тысяч в каждой.

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

1) Первым делом приходит в ум таблица вида (ид_юзера, ид_фичи, количество).
Ок, пусть будем так же масштабировать таблицу по ид_юзера на множество серверов.
Но размеры будут значительно больше, то есть суммарное количество записей в базе будет 5 млн. * 18 = больно дохрена.
К тому же добавление новых фич будет весьма трудозатратным.

2) Второй вариант - сделать таблицу вида (ид_юзера, ид_фичи_1, ид_фичи_2, ид_фичи_3...ид_фичи_18)
Таким образом получаем удобную структуру для хранения и выборки фич юзера.
Шардинг так же возможен по ид_юзера. Суммарное количество записей не будет превышать количество записей юзеров.
Добавление новых фич хоть и геморойно, но мне кажется более удобным, чем первый вариант, то есть нужно добавлять новое поле к таблице.

3) Третий вариант - Добавляем новое поле к таблице юзеров, поле "фичи", в котором храним в структурированном виде имеющие у юзера фичи, например содержание поля может выглядить вот так 1,3,0,5,0,... то есть через запитую все фичи.
Странный конечно вариант, но с точки зрения выборки и уменьшения нагрузки на базу наверное самое то, то есть уходит лишняя выборка и таблицы вообще. Правда возрастают накалдные расходы на парсинг этого поля, но это уже расходы не базы.
Конечно минус еще в том, что добавлять новые фичи будет так же несколько накладно, придется пробежаться по всем юзерам, хотя учитывая шардирование, это не так критично.
Минус еще в том, что пропадает возможность аналитических выборок имеющихся фич у юзеров, но статистику можно вести в другом месте и иначе.

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

Спасибо за ответы!

Dimitry SibiryakovЧто за недо-СУБД у вас, которой доставляют проблемы жалкие пять миллионов записей в таблице?..

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

Как я понимаю, денормализация данных при больших нагрузках это обычное, а иногда необходимое дело?

_модОднозначно 1. Причем нулевые значения не хранить, а получать 0 в запросе
Можете пожалуйста аргументированно объяснить, чем второй вариант хуже первого своими словами? (третий брать не будем, это явный треш).
То есть важно не просто получить совет, а именно понять, почему так, а не иначе.

Arhat109ewb, заметьте, что первый и второй вариант по объему хранимой инфы - однофигственен. Третий - приемлем только в одном случае: если у Вас список фич "в структруированном" виде достаточно компактен (банально экономит место) И нет запросов селектирующих юзверя по тем или иным фичам И разбор выбранной структуры незатратен по времени/объему, например выборка всегда небольшого количества юзверей с фичами (идеально всегда только одного). Вот ежели их надо выбирать небольшими партиями по 50тыщ шт., да для кажного юзверя распарсивать ваше "структруированное" хранение (как в Кашэ)... будет весело.
Выборка будет происходить только по ID юзера, никак иначе.
И только один запрос - один юзер.
Никаких сложных запросов, никаких сложных связей.
Следовательно в качестве индекса имеет смысл делать только ID юзера.

При такой схеме индексов, если говорить именно о весе таблицы, второй вариант будет в разы меньше занимать место.
У первого будут большие затраты на обслуживание индексов, в связи с большим количеством записей.
К слову я провел небольшой эксперимент, сделал на дефолтном mysql две таблички по 1 и 2 варианту, заполнил обои 150 тысячами юзеров...размер первой в 20 раз больше второй, но выборка по времени практически одинаковая, за небольшим преимуществом второго варианта.

Arhat109ewb, иногда так и делают (2-й вариант), но надо отдавать себе отчет что любое добавление новой фичи приведет к перекройке 80% кода (из моей практики).
А вот это верно. Непосредственно о модернизации кода я не подумал во втором варианте, хотя это далеко не 80%, но может привнести геморой. При первом варианте код можно не обновлять, то есть обслуживание гораздо удобнее.

Dimitry SibiryakovБросьте, ваши "порядка 1-5 тысяч юзеров" может обработать даже бесплатный Firebird на
среднего уровня железе. Что там шардить на пять серверов - совершенно непонятно.

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

Но похоже я ошибаюсь и мое представление о нагрузках не правильное?
СУБД к слову - mysql.
5 млн. это грубая цифра, вполне возможно, что будет и больше, даже скорее всего так и будет.
Так же онлайн возможен больше. То есть хочется оказаться готовым в случае чего к быстрому росту.
К слову, именно старт приложения обещает быть бурным, то есть порядка миллиона новых юзеров в течении нескольких суток.
Хочу так же уточнить, что таких сущностей типо "фич" на самом деле порядка 6-8.

Скажите пожалуйста, как рассчитать какие пиковые нагрузки сможет выдерживать сервер и база?
Какие лимиты вообще у mysql или все зависит сугубо от железа?

Dimitry Sibiryakov

А не пошел бы ты повернуть свой рычажок адекватности в положение ON?..

Ares_ekbНаоборот, база - агонь
:D

Arhat109несколько странный у вас результат между 1 и 2.
Первая таблица - ид_юзер - индекс, ид_фичи - тиниинт, количество - тиниинт.
Вторая таблица - ид_юзер - уникальный индекс, ид_фичи_1....ид_фичи_18 - тиниинт.

Как я сказал выше, загнал 150 тысяч юзеров, в первой таблице была полная инициализация всех фич сразу, то есть по 18 записей на юзера.
Размер первой - 86 Мб на данные + 40 Мб на индексы.
Размер второй - 6,5 на данные + 0 Мб на индексы.
Согласен, что разница по данным слишком большая, не ясно для меня почему.

Arhat109"хранить надо даже 0" - выполняется и без реального хранения
Верно. Это мое остаточное мышление от второго варианта.
Но тут проблема в том, что так или иначе большинство юзеров (процентов 70) попробуют все фичи, то есть все 18 записей разнесутся по таблице.

Arhat109Если у Вас выборка строго(!) по одному иду юзверя и !внимание! Вы можете гарантировать, что других выборок НЕ появится в будущем при расширении функционала, то наиболее полезный вариант - как раз 3. :)
Никаких усложнений не предвидится, база по сути используется в виде хранилища ключ-значение, то есть никаких сложных выборок нет нигде. Может быть в таком случае перейти на nosql и юзать везде третий вариант? Как я понимаю, как раз для этого оно и предназначено?

Arhat109ewb, Очень странные размеры. Могу попробовать дома повторить ваши измерения.
Был бы очень благодарен.
Хотелось бы понять, почему именно такая дикая разница. Попробую еще сам покопать в этом направлении.

Arhat109С точки зрения проектирования, ваши "юзвери попробуют все варианты" - не аргумент. Не стоит гадать за всех. Каждый чел - уникален.
Пожалуй верно, но приложение будет всеми силами наталкивать его на это:)
А вот агрумент на счет неактивности некоторых пользователей весьма весом, треть или половина будут не активны или слабо активны, но тем не менее неактивные из базы никуда не денутся.

Arhat109Задача сильно похожа на сетевую игру, где "фича" - численное свойство персонажа... в этом случае, конечно же у каждого юзверя есть все фичи сразу и вариант 2 нормален, тем более что логика у каждой фичи своя. Если это накопление возможностей юзверя, то "со временем" - да, все активные юзвери приобретут все фичи... но пока это произойдет, набор фич поменяется раз ..надцать. И вариант 1 тут наиболее верен. Да и в реале, активных юзверей как правило на порядок меньше остальных, и ваша оценка в 5млн.. мне кажется завышена на 1-2 порядка. :)
Совершенно верно! Это игровое приложение для социальной сети. Для относительно небольшой европейской соц.сети, издатель обещает быстрый нагон траффика, суммарно как раз млн. 5 будет установок, поэтому хочется быть готовым, пусть даже с избытком мощностей, тем более, что сервера халявные:)

Если уточнить, то фичи это по сути некие счетчики - цифры присущие каждому игроку, числа эти постоянно меняются, некоторые только в большую сторону, некоторые в обе стороны. То есть одинаково важны, как скорость выборки, так и скорость апдейта.
Пример:
1) хранить сколько и каких монстров убил игрок.
2) сколько и каких монстров создал игрок
3) сколько и каких артефактов у него имеется
4) Какие ачивки открыты
И так далее, всего уже 12 таких сущностей с количеством элементов от 2 до 18 в каждой, которое может варьироваться.
К тому же прибавятся еще и сами сущности.

Arhat109Ну и ещё раз, хочу обратить ваше внимание на посты о правильном проектировании. Верен только вариант 1.
Выбирнать, конечно же Вам.
Спасибо! Я действительно все пересмотрел, понял всю не достаточную гибкость в обслуживание при варианте 2 и 3, особенно скорее 2. И нашел больше плюсов в первом, кроме того, скорость выборки при тестах там практически ничем не уступает второму варианту, но вот апдейты будут происходить в несколько раз медленней, ввиду нескольких запросов на апдейт сразу, но удобство добавление новых элементов это компенсирует.