Здравствуйте!
Скажем, есть некая сущность, назовем ее "фича". Фич имеется 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. И нашел больше плюсов в первом, кроме того, скорость выборки при тестах там практически ничем не уступает второму варианту, но вот апдейты будут происходить в несколько раз медленней, ввиду нескольких запросов на апдейт сразу, но удобство добавление новых элементов это компенсирует.

Arhat109У-у-у как всё запущено... :)
Монстры, артефакты, ачивки и прочие сущности, по-хорошему надо моделировать собственными таблицами-справочниками, пардон в терминах РМД "отношениями". И делать отдельно связи с игроком, (пардон опять же "отношения" - таблицы) в части "какой_игрок - какая-сущность - сколько_создал - когда_создал - как создал - сколько_убил - когда_убил - как_убил"... ну или допустить что сколько > 0 -- стало быть создал, а ежели меньше, то убил... а не лепить всё в одну таблицу связи, пардон "отношение"... :)
Может я что то не правильно понял, но на данный момент схема такая:
1) Есть набор сущностей, каждая сущность ограниченное множество. Например, юниты, их 16 штук, они все в отдельной таблице с 16 записями. У каждого юнита есть свой ИД и только присущий ему набор свойств (здоровье, атака, защита и так далее).
2) Есть таблица юзеров, в которой свойства присущие только юзерам и разумеется ИД.
3) Есть таблица связей каждой сущности и каждого юзера, например "уничтоженные юниты". Вот именно о схеме таких таблиц я и задал изначальный вопрос, возможно несколько размыто и не точно, сорри.

Или же вы предлагаете сделать вообще одну таблицу на связь всех сущностей?
То есть ид_юнита, тип_сущности, ид_сущности, количество?
Где тип сущности может быть совершенно любой? То есть от созданных юнитов, до открытых ачивок (всего их 12 штук)?

MasterZivЭто всё не проблема. Запросы будут быстрыми как на чтение, так и на изменение, при условии, что везде будет фильтр по одному игроку. А он тут есть.

Я думаю, ты ошибаешься.
Поясни, какие UPDATE-ы будут происходить в несколько раз медленнее ?

Вы совершенно правы, скорость обновления для одной записи (where id_user = N) примерно одинакова при первом и втором варианте построения таблиц. Но проблема в том, что за один раз (за один вызов скрипта) нужно апдейтить разное количество записей, от 0 до полного обновления всего. Следовательно в первом варианте мне нужно сделать множество запросов на апдейт, что суммарно даст большее время, чем один апдейт на одну сущность при втором варианте. Собственно я это уже проверил экспериментально, разница до 10 раз по суммарному времени апдейта.

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

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

Arhat109проверил
Спасибо! Все примерно так же.
И все же получается второй вариант в целом более производительный, чем первый и имеет некое право на существование?

Arhat109ewb, конечно имеет. Впрочем как и третий... :)

У вас больше проблема с пониманием проектирования БД в целом, чем со способом хранения (1,2 или 3). Это сложнее чем Вы себе сейчас понимаете... я бы посоветовал, отойти слегка от задачи и почитать литературу какую-нибудь (тут рядом топик есть).

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

Это так, рекомендации от человека проектировавшего игрухи военного жанра... :)
Благодарю за помощь! Так и сделаю.
В соседний топик уже заглянул:)